• Post Reply Bookmark Topic Watch Topic
  • New Topic

how to design an easy to develope and maintain software  RSS feed

 
Tafta Zani
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,

I'm a greenhorn in Java but i choose Java as programming language to work my final project. My final project is to build a system that runs above a middleware built using Java that will create and deploy mobile agents to do various things over network.

One of my final project objectives is to build the system so it is easy to
maintain and develope. How do i achieve this by using Java?

FYI since i'm using the middleware i have to use certain classes provided by the middleware.

Thank you for the answers.
 
Stuart Gray
Ranch Hand
Posts: 410
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well you could write a whole book on the subject (and people have)! Just a few things I wanted to say. Firstly, I don't think this issue is too related to the implementation language - design is design for the most part.

Secondly, this is probably a good time to review your previous lessons and lectures - hopefully they have pushed you at least slightly in the right direction.

Finally, from experience of my own project a few years ago, I would say taking time on the planning is essential. I think it is very important not to start coding too soon. This is stressed over and over again, but often not followed. Create a plan, check, rethink, amend - before you start any code. On the other hand, be aware that no plans is ever followed absolutely precisely, and in this situation what separates a good plan from a bad plan is flexibility. The ability of your plan to adapt to new and previously unforseen requirements is very important. On a practical note, using concepts such as Interfaces can aid this flexibility quite a lot because they allow changing of implementation and so on.

I sure others will be able to shed much more light on the subject, but that was just my two pennies worth
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like Stuart says - think first. Personally I draw lots of diagrams and pseudo flow charts.
Don't be surprised if you program yourself into a corner and have to throw out one or more designs.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My advice is quite contrary: while designing, get feedback from real code early and often. A diagram is just a fantasy about what the code will be like, and without much experience not a very well educated one, naturally.

Learn how to apply the Principles of Object Oriented Design to manage your code dependencies, so that when you have to make a change, that change won't spread over your whole code base.

Learn to notice design problems from the code (aka Code Smells and how to refactor to a better solution.

Write an exhaustive suite of automated tests for the code that will tell you when you break something while applying a change to the system. Don't write the tests as an afterthought, but in parallel with the production code. Consider using Test Driven Development which will not only help you getting a high test coverage, but also guide you in coming up with a well decoupled design.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Feed back from real code won't do you any good if you have not figured out what your "use-cases" are going to be.
On the other hand it is certainly possible to spend way too much time trying to specify everything before any real code gets run.
Bill
 
Tafta Zani
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, thanks for the great clues guys.
How about aspect oriented programming?
My friend told me it can programmer to develope programs w/o making significant changes to the original source.
Have anyone try it?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by William Brogden:
Feed back from real code won't do you any good if you have not figured out what your "use-cases" are going to be.


Actually, feedback from showing a user a running system (even if it doesn't do much yet) can be of great help to find out what he really needs.

I agree, though, that's it's probably not optimal to start coding before you have a solid understanding of what the customer expects from the system. In my experience, an ongoing conversation is much more important for that than drawing diagrams, though.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tafta Zani:
Wow, thanks for the great clues guys.
How about aspect oriented programming?
My friend told me it can programmer to develope programs w/o making significant changes to the original source.
Have anyone try it?


I haven't tried it yet, but my impression is that it is only applicable in very specific situations. It's also quite new, so best practices and patterns still have to emerge. I'd advice to concentrate on learning good OO design first.
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree, though, that's it's probably not optimal to start coding before you have a solid understanding of what the customer expects from the system. In my experience, an ongoing conversation is much more important for that than drawing diagrams, though.

In my experience, sitting down with users / domain experts and drawing diagrams is the BEST way to conduct a conversation, and a lot faster than exposing them to prototypes or just talking. Diagrams are very good at exposing misconceptions. I particularly like white boards plus a camera.
Bill
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by William Brogden:

In my experience, sitting down with users / domain experts and drawing diagrams is the BEST way to conduct a conversation, and a lot faster than exposing them to prototypes or just talking. Diagrams are very good at exposing misconceptions. I particularly like white boards plus a camera.
Bill


Of course I'm not at all against diagrams used to facilitate a conversation!

Just out of curiosity - what kinds of diagrams do you typically draw to do that? Do your customers typically understand UML, for example?
 
Tafta Zani
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
before we go any further,
i just realized that (cmiiw) wether a program is well-designed or not is relative and probably subjective (forgive my bad English, obvious it's not my mother language). We have principles what is a well designed program, but from 0 to 9 where the program goes between, how do we know the exact value? A quetioner maybe? Does anyone know any standard?

onegaishimasu--(now i start talking Japaneese)
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good question! I have a list of a hundred or so quality measures that I ask managers and customers to prioritize before we start work. Here are a few off the top of my head ...

Meets requirements - nobody will use it otherwise.
Robust execution - survives partial failure of hardware or software.
Robust design - survives changing requirements.
Extensible - can grow new features at low cost.
Reusable - contributes components or services to other projects.
Reuses - consumes components or services from other projects.
Interoperable - can integrate with other systems.
Portable - to other OS, DB or hardware platforms.
Conforms to standards - coding, data names, UI
Conforms to standards - team, enterprise, industry
Small memory footprint
Small disk footprint
Small database footprint
Small network througput demand
Availability - scheduled uptime, eg 24x7
Reliability - unscheduled downtime
Scalability - handles current user load, can grow
Performance - meets response time or throughput requirements
Usability - training required, user error rates, satisfaction
Defect free - free?

You can see this list can grow forever. Think of every person who writes code, uses the system, pays for the system, deploys the system, gets called when it fails in the middle of the night and each one has different definitions of quality.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tafta Zani:
before we go any further,
i just realized that (cmiiw) wether a program is well-designed or not is relative and probably subjective (forgive my bad English, obvious it's not my mother language). We have principles what is a well designed program, but from 0 to 9 where the program goes between, how do we know the exact value? A quetioner maybe? Does anyone know any standard?


I don't know of any standard that would make sense to me. In fact, I don't think that "an exact value" would be of any, forgive the pun, value.

What's important to me is to be sensitive to design problems in existing code and to how the code needs to adapt to new requirements - and to learn from the experience. The design principles are just guidelines in this process - there simply aren't any hard and fast rules, just educated gut feel guided by experience and heuristics. That's my experience at least.

And don't worry about your english - it's quite good!
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just out of curiosity - what kinds of diagrams do you typically draw to do that? Do your customers typically understand UML, for example?

Nothing as structured as that - more like data flow and what entity talks to what.
Many years ago I did environmental impact statements and draw ecosystem diagrams so my diagrams tend to reflect that experience. Just getting the entities you are talking about and their relationships to each other in a diagram can replace pages and pages of text.
Bill
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by William Brogden:
Nothing as structured as that - more like data flow and what entity talks to what.
Many years ago I did environmental impact statements and draw ecosystem diagrams so my diagrams tend to reflect that experience.


Sounds good to me!
 
Tafta Zani
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, let me sumerize something...

By following the principles of object oriented programming, we can build an easy to develope and maintain software, correct?

next...
To fullfill one of my final project objective i have to prove that the software i built is easy to develope and maintain. How do i do that?

fiuhh, things are getting clearer here.
I'm sorry for misguiding the conversation by changing subject to "well designed software". Let's focus on the "easy to develope and maintain" one.

Thank you
 
Stuart Gray
Ranch Hand
Posts: 410
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are always told how maintenance of code is the most expensive part, do most likely your instructors are looking for code that make it easy (well, easier) for other coders to read: well documented code that follows typical 'best practise' guidelines (well named variables, one task per method, and so on).
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can look into Robert Martin's package metrics. In This Blog Entry he has links to papers on 11 design principles, described in much more detail in the book also linked from there.

The last 6 are related to packages. JDepends is a free tool that analyses classes (compiled code) and rates your Java packages. It puts out lots and lots of number, but doesn't say "Hey, that was good!". And be aware the metrics are probably better suited to UML's component-level definition of "package" than Java's code organizing definition.

You can make a package dependency graph by hand from the JDepends information that will tell you something about dependencies. For a school project it might be interesting to compare several projects or refactor one of your own with "before and after" measurements.
 
Tafta Zani
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone
To build the software easy to develope and maintain is not the primary goal i have right now, so i'll focus on the primary one

But i wont close this topic, i'll try to have my progress reported here for critics and suggestions,

Thanks for the good tips
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!