UML: TIP: DO NOT refer to "analysis" Elements from "design" Packages (or from "design" diagrams) !

For example, consider a UML™ Parsing Analysis of a software tutorial into a UML™ model, with binding of text (in UML containers) to reverse-engineered "design" elements. Do this in analysis diagrams in Models that refer to the "design" elements, NOT the other way around.

Dr Darren says:

I can just hear certain i-have-never-actually-used-UML-in-real-projects IT academics going off about that tip ! Let 'em huff and puff. In my heavily reuse driven approach "design" classes are either (to be) forward or (have been) reverse engineered, and design diagrams NEVER refer to analysis elements of any kind, EVER, and thus the design packages modularise nicely. Which is nice.

I like to think of it this way. According to my model-driven UML™ Parsing Analysis development recipe the "design" classes usually "already exist", the "analysis" classes are merely there to define what you are going to "go and get" (reuse) after reverse engineering candidate packages into design packages. The analysis classes still play the role of "bridge" between use cases and the (possibly already implemented) design classes.

Besides, what are you going to do when the "designed" Classes are in a read-only package (possibly from many years before, and authored by somebody who had no idea how those classes might be used) ? You can «trace» (UML) or «allocate» (SysML) from the "designed" Class to the "analysis" Class if you really want, however that relationship still has to live outside the (read-only) "designed" Package anyway - and preferrably near the "analysis" Class - so you might as well just drop the idea that the "designed" Class knows or cares about the "analysis". Let go, and will promote reuse !

The old idea about design classes "tracing from" analysis classes as part of a formal development process introduces an unwanted "reverse" dependency that prevents modularisation of the design packages. This does not mean one cannot use a process such as: Requirements Analysis - Systems Analysis - Design - Implementation - Testing, one just has to understand the dependencies.

Used in

The UML Parsing Analysis meta-process may be represented as stereotypes (from 2005)