With my addition, you ARE producing class diagrams. This is what I meant by ‘Complete’ classes.
Gil

Most sites I go to, the use cases are large, complex and unreadable.
The business sign them off having only commenting on syntax and having ignored the semantics.
The Analysts feel the need to write requirements documents, because the requirements are all jumbled. At best, they insist on activity diagrams to outline them.
The developers have sometimes refused to use work with them.
The test teams almost start again in building test scenarios.

Use cases should describe the actor-system interaction, NOT the functionality. ‘What’but NOT ‘How’. This gives them a simplified pattern of
Actor does …
System does …
Actor does …
System does … etc

The more common pattern by far is
Actor does …
System does …
System does …
System does …
System does …
Actor does …
System does …
System does …
System does …
Actor does …etc

Examination of a sequence diagram shows that the first ‘System does ….’ could simply call procedures on other classes to achieve the system functionality. Then the subsequent ‘System does …’ clauses appear as procedures (methods) in their appropriate classes.

This is a ‘win-win’ situation for all concerned:

– The use case reverts to its proper pattern, which is then usually very much shorter with an even greater reduction in the number of alternate paths.

– The functional sequences appear in the context of the class that they are sensibly associated with. As these were the most complex parts of bloated use case, they benefit a lot in being described within the context of a static class or two. Alternate paths, become other calls, each to a procedure that does just one thing, and that thing is described in context.

– This is NOT design!!! All we are doing is writing down algorithms or workflows that the business demands. If they are NOT this, then they should never appear in any of the analysis documents. They are as much business requirements as the attributes and association rules you have already described.

– It makes for better Business Classes (or Domain Classes if you prefer), because they are mote complete. They do NOT have some relevant steps outlined in some use case (or may be outlined repeatedly in all the use cases that use that class).

– Once you have the class completely definedthe classes as fully independant items, it is then possible to insist that their influence on the development classes is kept visible. This then keeps the code as a working model of the business process being captured. The better this is, the longer the life of the code plus a number of more short term goals.

Hope this helps,
Gil

My goal was to take one of the most powerful, but inaccessible tools I know – class diagramming, and make it accessible to 10x as many people. Ambler’s articles are great, but you really need a pretty technical background to consume them immediately.

Hopefully this series provides people with enough content, at the right speed, to make them effective with class diagrams, thus improving their ability to uncover hidden requirements (the hard part of requirements analysis).