I'm planning to take a "domain component" approach. For instance, instead of mapping each individual Servlet instance as separate component, I'd clump them together into a single Servlet component.
The point of the diagram is to see how the different parts of the system interact with each other.
If you were to describe a business process, you'd say something like: "Clerk" takes order, "Accountant" processes order, "Manager" approves. This is much cleaner than giving multiple similar diagrams with individual workers' names. The concept is similar in an architectural domain component diagram - simply mapping out the general process flow through the architecture, showing which type of objects communicate with which other types of objects.
A good workman is known by his tools.
Joined: Jul 03, 2006
not exactly one per use case, something similar to cades example prepare itinerary component payment component view miles component and customer profile component
did anyone create more than one component diagram?
Thanks Sai. [ May 17, 2007: Message edited by: sai maddikay ]
I always create a single Component Diagram in my architectures, because I always thought the Component Diagram is a static view of the components (and their interactions) of the entire system. However going through this forum I realised that people create more than one... so initially I was a bit confused, then I changed my approach: I'm now trying to create 2 component diagrams, one for the Web front-end, one for the GUI. This might simplify the design, 2 diagrams instead of a big messy one.
Cade seems to use different approach, going to the level of displaying the single JSP... if we adopt this approach we definitely need several diagrams, maybe having one per Use Case is not such a bad idea.
I'm still a little puzzled, I must admit. As said I now go for 2 component diagrams only, but might need to change the approach once more.
You need to do what fits best for you. I am approaching this differently
One diagram to show preparing, pricing and changing the itinerary.
One for paying for the itinerary.
One for security and customer specific scenarios.
So I am going with 3 for now. It makes more sense to me going for it this way and it avoids clutter. If the way you have designed your components allows you to put them all in one diagram then go ahead by all means
I'm still waiting for my copy in the mail...
Marc do you mean the book or the assignment ? [ May 29, 2007: Message edited by: John Meyers ]
I created two Component diagrams. The first shows all the tiers (client, web, business, resource mgmt) for the itinerary mgmt components and the second does the same for the payment components. Both diagrams support the web client and the Java Swing client. I got 44 on 44 on my component diagram. I think its important to show as much detail as you can up front in the architecture. There are differences in the tiers for the itinerary vs. payment use cases.
My 2 cents.
Joined: Nov 07, 2006
Hi Francis congratulations for you 44/44!
Can you give some more insights about your Component Diagrams: At which level of detail did you go? Did you name each single JSP? Did you match the component with the Java classes (Class Diagram)? Which additional information did you include? (eg which components implement which patterns, benefits/explanation why you chose each component, protocols between clients and servers)