• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

when to draw component diagrams (according to Cade's book)

 
Ronald Wouters
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

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
and
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"
and
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 ?

Regards.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic