UML from start to finish

I have been programming in high level languages for a number of years now and through one semi-object orientated language I became very interested in class design and UML. In my searches on the net I cant find any good article that describes the complete process design using UML from requirements illicitation down to code.

I presume you would first do the use case diagrams, then use templates to specify the usage scenarios, then class diagrams to identify attributes of classes, and then progress to the sequence diagrams, and then to code. If your system is state based then a state diagram would be used in place of, or together with sequence diagrams. What do you think? And what are the best resources you have found that have covered the complete design pocess using UML?

After years of tinkering and writing "sections" of good code, I have come to realize that the high level design is where I fall short. My programs become difficult to manage when they get more complex using OO, and sometimes I end up with objects that should be able to communicate withb each other but cant because of lack of foresight in the design. When I code the same without trying to achive pure OO practises (procedural style), I get from A to B a lot quicker and easier.

And as for code reuse, I find that most business objects have to be recoded from the beginning each time because the problem domain is different for each scanario. I would love to write one object and reuse that a zillion times, but in practise I cant seem to achieve this.

Designing loosely coupled systems and making use of design patterns will take you a long way towards good OO code.

I've been working as a BA for the last year and to awnser your question - there is no set way of writing UML for a new system. You will not always need to use the same diagrams for each project and in many ways is it Laguage dependant example: C++ and java might look the same but for something like Coldfusion it might be a different story. But the sequence you gave above is a very good guidline. I split that into to sections: Functional and technical. Fuctional spec would have as a basis the following (1)use cases (2)the description of the use cases (3)Write senarios (4)Use Activity diagrams for each senario. For the technical spec you will use the following (1)Class diagrams (2)Relasionship between class diagrams (3)Sequence diagrams. Your Fuctional spec should be very easy to understand, you should be able to sit down with the client and talk them through it so no technical jargon.

A good place to start is UML.org

Deadly, you give good advice here.

On my last project I used Use Case diagrams, backed up by descriptions of the various actors and use cases, as prescribed by Cockburn. I used sequence diagrams for each of the scenarios. But it is important to back it up with a good description of each scenario, since most customers don't understand UML.

I must gloat that that document was one of the better documents on the whole project, so much that the customer used it as a based for their other documents.

BTW, there is no real specific process with UML, besides the RUP, which I feel is slightly over the top. It is up to you to decide which process will work for you. In some cases where the project and team is large, a rigorous process might be needed. But when it is a one man show, definitely not. As long as the requirements is unambiguous.

Agree 100%

Ok, visiting back here again. Thanks for the comments.