when to draw component diagrams (according to Cade's book)
posted 7 years ago
I have been reading both Cade's book and "UML Distilled", especially the sections on component diagrams.
Cade mentions :
Class diagrams address the static design view of a system
Component diagrams address the static implementation view of a system.
However, Cade does not elaborate any further or gives his definition of "design view" and "implementation view". Can this be interpreted as follows : on component diagrams you mention things like JSP pages, EJBs, Servlets, Entities, all clearly "implementation" stuff (using the appropriate uml stereotypes) while on class diagrams you "just" mention more "abstractly" things like classes, interfaces, realizations, generalizations but most certainly NOT a stereotype like <<Stateless>>.
UML Distilled mentions :
"components represent pieces that are independently purchasable and upgradeable. As a result, dividing a system into components is as much a marketing decision as it is a technical decision"
Use component diagrams when you are dividing your system into components and want to show their interrelationships through interfaces or the breakdown of components into a lower-level structure
What I still don't quite have a feeling for, reading the above, is when is it a good time to draw a component diagram. Is it after you have finished a sequence diagram for a use case and you obviously then "know" how you are going to "implement" it ? Do you draw them in parallell, both the dynamic (sequence) and static (component) diagram at the same time ? Or put yet another way, when does drawing a component diagram add the most value/understanding, for the architect / designer himself ?
Sun Certified Developer for the Java 2 Platform
Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5