File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Cade Example and Sun Blueprints anomaly Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Cade Example and Sun Blueprints anomaly" Watch "Cade Example and Sun Blueprints anomaly" New topic
Author

Cade Example and Sun Blueprints anomaly

Tilak Mitra
Greenhorn

Joined: Sep 29, 2003
Posts: 8
Hi All,
I was looking at the Cade Case Study as well as the Sun Blueprint sample application architecture.
In the Cade case study example, the ServiceLocator class is put in the component diagram(s) whereas in the Sun Blueprint example, the ServiceLocator is placed in the Class diagram (figure 11.9).
Any ideas on which one to follow ?
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Tilak Mitra:

Any ideas on which one to follow ?

Tilak,
I have some misgivings about the Cade examples in general. For example,
Cade uses "package" symbol to represent a Subsystem rather than a component symbol. The UML Reference Manual and other authoritative sources do not designate "package" as a symbol that belongs on any UML Component diagram.
Maybe the SCEA evaluator's grading criteria are not concerned with that. I don't know. But I wouldn't use it.
As for where to "put" the Service Locator, I suggest don't automatically follow one example or another. Decide according to the criteria for "what is a component? Chances are that it is made up of classes that you define in your architecture, or existing utilities or subsystems that you show as a component but do not implement. So depending on your approach,
a Service Locator component could belong on the component diagram (either as a contributing outside system, or something you implement). And the class diagram would include it if you implement it. A sequence diagram might include it as an "actor" or "client", even if it is not an implementation class. See? Many valid options.
Remember that a "component" represents a deployable unit. If you plan to deploy one or a group of classes that must work together, perhaps packaged as a jar or ear, then that looks a lot like a Component that belongs on the Component diagram.
Remember also that you can use Notes to indicate whether a component is developmental or an external subsystem.
I welcome any contrasting view from others on my comments here. Good luck!


Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Nalla Senthilnathan
Ranch Hand

Joined: Jul 13, 2003
Posts: 40
Originally posted by john prieur:
The UML Reference Manual and other authoritative sources do not designate "package" as a symbol that belongs on any UML Component diagram.

This article can dispel some myths about subsystems:
http://www.therationaledge.com/content/jun_03/t_subsystem_ff.jsp
Nalla
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
This article can dispel some myths about subsystems[/QB]

Thanks for the alternative point of view, Nalla. I appreciate the link.
The article from Rational does not pertain to Component diagrams, and so its discussion of notation for Subsystems does not support the Cade style of component diagramming for the SCEA exam. That is the point in question.
Also, the Rational Unified Process has its own style and "slant" on UML - it is not pure UML. RUP's entire 3-level perspectives idea is one such thing that is outside of the UML itself. But its very useful.
The article points out one VERY USEFUL application of the Package Symbol for describing Components. (This point may seem like a contradiction, but its not.) To use it properly, we need to be cognizant of which Perspective (phase of development) we are dealing with.
The informal diagram on page 3 figure 2 of the article, Components are shown enclosed in a package. This is one appropriate use of Package that you could put on a Component diagram to indicate implementation grouping of the components. This would be most useful in the Implementation perspective. Notice that the dependencies, for the purpose of the logical Component diagram, would be between Component symbols, not the packages (except as a notational short-cut if you have many components "in" a package that all have a common dependency to something outside the package). -- a fine point.
On page 5, figure 3, this Rational article erroneously depicts an external subsystem as being implemented within an internal package . However, I agree that Package Diagram depicting Subsystems as Packages would be VERY useful as part of the Implementation Perspective, where a deployer or system administrator is more concerned with deployment of packages, and not necessarily their logical "component" meanings.
My final point on the RUP's use of the package symbol as it pertains to our purpose here (the SCEA component diagram) is this:
The Component Diagram required for the Sun Certified Enterprise Architect
is in the context of Architecture ,
not the Implementation Perspective,
not the Conceptual Perspective.
If we feel that the RUP is applicable at all, a Specification Perspective leaning would be appropriate for our Component Diagrams.

We should keep in mind that many of these light technical articles from Rational have a marketing agenda and may be useful more as executive summaries. They can mislead and have no obligation to accuracy.

Also, Cade does not mention what their scores were on their projects .
Summary: Package symbols are not defined as a correct notation on Component Diagrams according to UML. They are not the best technique for our SCEA purposes.
(but maybe Sun doesn't care about these fine points anyway )

[ October 08, 2003: Message edited by: john prieur ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Cade Example and Sun Blueprints anomaly