Passed part II + III with 98%

[alain hsiung]

Just saw the result today.
Score: 98
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70. Class Diagram (44 maximum) ............................... 44 Component Diagram (44 maximum) ........................... 42 Sequence/Colloboration Diagrams (12 maximum) ............. 12
Thanks for all your good advices on this group!
Alain Hsiung
Ideartis Inc.

[Saket Barve]

Congratulations, Alain. That's a very good achievement on your part. I hope to achieve this goal some day in the future!
Saket

[Ritu Chawla]

Hi Alain, Congratulations. Thats a great score indeed. Can you please comment on your approach for the level 2 exam?
Thanks in Advance,
Ritu

[alain hsiung]

Hi
the most important point for a good understand of the domain was the definition of "flight". I distingished between 2 concepts of flights. In the assignement the one term flight is used implicitly in 2 different ways. I choose to define the 2 different concepts of flight and everything went clear. I won't tell more here.
Making a reservation online also helped a lot to understand domain concepts. You can make a reservation at http://www.flight.co.uk/scheduled/default.asp.
As method I used the OOA/OOD (Object Oriented Analysis and Design) approach.
1. Write the use cases as top-level sequence diagrams, i.e. where there is only the user and the system (as a whole). This is quite similar to the assigment use case text but it helps entering the problem domain, thinking of what it means and using your own words. Note that the result of this step is re-used for the step of drawing the sequence diagrams.
2. At the same time you write most of the assumptions because you begin to understand the problem domain and realize that not everything in the assignment is unambiguous.
3. Draw the class diagram (only one) starting from the business domain model of the assignment. I was very careful with the relationships (aggregation, composition, cardinality, navigability). When you draw the class diagram very carefully drawing the sequence diagrams is a pleasure. But if you begin with sequence diagram (in full details) without having a stable class diagram you will hate the exercice.
4. At the same time your write the design decisions concerning the class diagram.
5. Draw the sequence diagrams.
6. At the same time you will check the consistency with the class diagram and eventually modify it to enable navigability for example. Add the methods to the classes to ensure the consistency. If you designed your class diagram carefully this step should be small.
7. Draw the component diagram. I have only one. Almost all design patterns of the Core J2EE Patterns are used. Every Dependency link is labeled ("call", "EJB invocation", "build", "use bean", "forward", "submit", "create", "aggregate" -for aggregation from the class diagram-, etc.).
Every component has a stereotype (when not it is assumpted that it is a normal Java class). A stereotype may be "JSP", "Servlet", "Java Bean", etc), i.e. always something "programmatically meaningful". E.g. DAO is not specified as stereotype but in the name of the component.
8. At the same time write the design decisions for the component diagram. A lot of design patterns here and shortly how they work (with the specific component names here).
9. Design the security. Do not begin with security, make it a last step of the architecture but integrate the changes in the existing diagrams. Basic questions are "how is the authentication and authorization at the entry of each subsystem?" (container-managed or application-level), "how is the credential propagated?", etc.
10. Check all diagrams and the document for coherency, completeness and redundancy.
The deliverable contains
- the diagrams
- the assumptions
- the terminology
- the design decisions
. class diagram design
. component diagram design
. security design
It tooks me 100h. About a 30-40% was understanding the domain (read and re-read the assignment, google, etc.) and another 30-40% to make it clean (check all coherency, completeness, redundancy, etc.)
Hope this summary helps.
Regards
Alain Hsiung
ideartis Inc.
[Content edited by Chris Mathews, please see note below ]
[ June 13, 2003: Message edited by: Chris Mathews ]

[James Ward]

Excellent score...
Congrats...

[kapil kumar]

jitu
have u finished part 2?

[alain hsiung]

Originally posted by kapil kumar:
jitu
have u finished part 2?

yes, my first mail (passed eith 98%)is the result of part 2+3.
Alain Hsiung
Ideartis Inc.

[fred wang]

Congratulations, Alain. may you answer me two question?
first,why you pay attention to the business mainly,not the common architecture,as all others.but i think the foundation architecture is more important,like petstore,struts.
second,why the design patterns are used in component diagram?not in class diagram?
thanks!

[Chris Mathews]

redw25,
Thanks for joining JavaRanch, but could you take a quick look at the naming policy and edit your profile accordingly.

[alain hsiung]

Originally posted by redw25:
Congratulations, Alain. may you answer me two question?
first,why you pay attention to the business mainly,not the common architecture,as all others.but i think the foundation architecture is more important,like petstore,struts.
second,why the design patterns are used in component diagram?not in class diagram?
thanks!

1. I think that other solutions may be correct too. To my understanding the architect should do both modeling the business AND design an architecture with the state-of-the-art technologies. I must admit that I did design an alternative component diagram with Struts framework which I didn't send. I compared my "MVC model 2" and my "struts" component diagrams and I chose to send the "MVC model 2" because it is more concrete. The "struts" variant could almost be copy/paste from a struts book, it didn't show much. In reality (not for the SCEA exam) I would take the struts variant. Don't be afraid of sending a more "foundation architecture" variant!
2. the J2EE design pattern are in the component diagram because here I have all the tiers and all technological decisions! The class diagram models the business and is technology neutral! The class diagram forms the basis for EJB design (in the component diagram) but there is no mention of stateful session bean, entity bean, etc. in the class diagram. The class diagram may be reused with other technologies than EJB (plain Java, .net, etc). Class diagram is important as a communication mean between domain expert and computer scientist. It is as constant as the domain. Component diagram reflects the technology decisions, may change with the technologies and is used by the programmer.
Alain Hsiung
Ideartis Inc.

[Louis Fegun]

Hi Alain-
Congratulations!!!. Thanks for sharing your insight on the assignment. Quick question for you. Do you have to show all the classes bearing the pattern and framework - e.g. Business delegate, Service Locator classe, etc, in the sequence diagram. My sequence diagram is already looking very long because of many classes and I am trying to control it.
I will appreciate any suggestions on this.
Thanks.
Louis.

[alain hsiung]

Originally posted by Louis Fegun:
Hi Alain-
Congratulations!!!. Thanks for sharing your insight on the assignment. Quick question for you. Do you have to show all the classes bearing the pattern and framework - e.g. Business delegate, Service Locator classe, etc, in the sequence diagram. My sequence diagram is already looking very long because of many classes and I am trying to control it.
I will appreciate any suggestions on this.
Thanks.
Louis.

In my sequence diagram I had all classes of the class diagram + one frontend subsystem (that encapsulates all classes when the frontend is Java client and all JSP, Servlets, Java Beans when the frontend is a Web Client). In doing so I have no Servlets, JSP, etc. in the sequence diagram and also no VOs, DAOs, etc. A sequence diagram may show the interactions between 15 objects but this is reasonable. The J2EE patterns are not explicitly shown in the sequence diagram.
Alain Hsiung
Ideartis Inc.

[Louis Fegun]

Thanks Alain. That was very helpful.
Louis.

[fred wang]

Originally posted by alain hsiung:

1. I think that other solutions may be correct too. To my understanding the architect should do both modeling the business AND design an architecture with the state-of-the-art technologies. I must admit that I did design an alternative component diagram with Struts framework which I didn't send. I compared my "MVC model 2" and my "struts" component diagrams and I chose to send the "MVC model 2" because it is more concrete. The "struts" variant could almost be copy/paste from a struts book, it didn't show much. In reality (not for the SCEA exam) I would take the struts variant. Don't be afraid of sending a more "foundation architecture" variant!
2. the J2EE design pattern are in the component diagram because here I have all the tiers and all technological decisions! The class diagram models the business and is technology neutral! The class diagram forms the basis for EJB design (in the component diagram) but there is no mention of stateful session bean, entity bean, etc. in the class diagram. The class diagram may be reused with other technologies than EJB (plain Java, .net, etc). Class diagram is important as a communication mean between domain expert and computer scientist. It is as constant as the domain. Component diagram reflects the technology decisions, may change with the technologies and is used by the programmer.
Alain Hsiung
Ideartis Inc.

thank you very much for your reply.
perhaps now the topic is the architecture we discussing,not the design detail.
during the develop process, we make the technology decisions at the design period.we follow the design technology : principle,layer,mvc,patterns... at this time. we show all these in class diagram ,then generate the frame code.it's very useful for the develop efficiency and the software' quality is not bad.but the component diagram is seldom used.It's can be produced during generating code.
am i right?
[ June 10, 2003: Message edited by: redw25 ]

[alain hsiung]

Originally posted by redw25:


thank you very much for your reply.
perhaps now the topic is the architecture we discussing,not the design detail.
during the develop process, we make the technology decisions at the design period.we follow the design technology : principle,layer,mvc,patterns... at this time. we show all these in class diagram ,then generate the frame code.it's very useful for the develop efficiency and the software' quality is not bad.but the component diagram is seldom used.It's can be produced during generating code.
am i right?
[ June 10, 2003: Message edited by: redw25 ]

As I understand you correctly you define a "design phase" as the step of making the technology decisions. This is fine. Moreover you say that the deliverable of this phase is a class diagram and component diagram is seldom used. This is correct in the real world and it also make sense perhaps except for the design of the web container. In my real world architecture projects I usually create in the "analysis phase" a class diagram which is our SCEA part II class diagram (without technology decisions). This class diagram is called the Business Object Model. And then I create in the "design phase" another class diagram called the Implementation Object Model which is similar to the component diagram of ou SCEA part II, but it's a class diagram. The IOM is a BOM + other classes which has to do with technology decisions. This idea was working very well until the introduction of web applications. To make the design of a web tier clear is not that easy with classes only because you have JSP, HTML, forward relationships, etc. On the other hand it is possible to communicate almost all technology design decisions with a component diagram instead of a IOM.
So for design of web applications if you want to have only 1 diagram you will probably choose a component diagram. But in the real world you can choose to have many diagrams and you may very choose a IOM class diagram and a component diagram for only the web tier.
Alain Hsiung
Ideartis inc.

[venkatesh rajmendram]

Hey Alain,
Congrats!! on your excellent score.
I had couple of questions.
Can you please tell what UML tool/s did you use for drawing all diagrams.
Did you write your Use cases in brief format or expanded format.
Also can you suggest any good web sites/ material for reference.
Thanks
Venkatesh

[alain hsiung]

Originally posted by venkatesh rajmendram:
Hey Alain,
Congrats!! on your excellent score.
I had couple of questions.
Can you please tell what UML tool/s did you use for drawing all diagrams.
Did you write your Use cases in brief format or expanded format.
Also can you suggest any good web sites/ material for reference.
Thanks
Venkatesh

UML tool: Together/J
The only complain is on the interaction diagram: I found the formatting of the arrow label difficult to read when there is a return value. So I simply didn't enter any return value and entered a phrase for the invocation label like "get itinerary details".
Use Cases: I used top-level interaction diagram to represent my use cases. A top-level interaction diagram has an actor and the FBN system only (eventually also the other external systems) but not the objects within the FBN system (Itinerary, etc). This is equivalent to the classical UML use case diagram. It has the advantage of being reusable to create the interaction diagrams proper by replacing the FBN system with the 5-15 objects withing the FBN system which are involved in the interaction.
the label on the interaction arrows are phrase not methods, i.e. "get Itinerary details" and not "getItineraryDetails" but it is almost equivalent because I uses verb + complement almost consistently.
I'm not sure if this is what you mean with "brief format".
Links:
- This forum!
- The Yahoo forum
- The J2EE blueprints:
http://java.sun.com/blueprints/enterprise/
- The J2EE patterns:
http://java.sun.com/blueprints/patterns/catalog.html
- Flight glossary:
http://www.travelselect.com/pages/glossary.html#legseg
- graph theory to understand the search:
http://two-wugs.net/fwa/graph.html
- I didn't found something good on component diagrams but I read this:
http://www.modelingstyle.info/componentDiagram.html
- On security for the Java Client:
http://edocs.bea.com/wls/docs70/security/fat_client.html
- Together/J guide:
http://cui.unige.ch/~queloz/TogetherJ/help/DevGuide/index.html
- On-line flight reservation:
http://www.thestoremaker.com/cgit/porch?agentid=bgvisit
http://www.flight.co.uk/scheduled/default.asp
- Another guy's links:
http://apinkin.net/space/CertificationSCEAPart2
- an this one very often to check if I passed or not:
https://www.certmanager.net/~sun_s/login.html
Alain Hsiung
Ideartis inc.

[Fisher Daniel]

Congratulations to you...
daniel

[venkatesh rajmendram]

Originally posted by alain hsiung:


I'm not sure if this is what you mean with "brief format".

Alain,
Well What I meant by the brief format/detail or expanded format is, did you write a descriptive use case like pre-conditions , post-contitions, normal flow , alternate flow in detail...along with use case diagram.
Thanks for the information that you have provided, its very helpful, I really appreciate your time.
Thanks
Venkatesh

[fred wang]

Alain,
how about the details of the class and the class's method?
1.in sequence diagram,do the operation is required?if so,the operation's parameters is also required?
2.in class diagram ,what methods should be shown?such as business method and other basic methods:create,find,update,remove..
the test is very different from our design,so i'm wondering.please help me.i'll sumit my assign
next week.thanks very much.

[alain hsiung]

Originally posted by venkatesh rajmendram:

Alain,
Well What I meant by the brief format/detail or expanded format is, did you write a descriptive use case like pre-conditions , post-contitions, normal flow , alternate flow in detail...along with use case diagram.
Thanks for the information that you have provided, its very helpful, I really appreciate your time.
Thanks
Venkatesh

I see. Yes I had a format that was quite expanded.
First of all I restate an important point: I draw use cases with (very abstract top-level) sequence diagram, so I do not have use case diagrams per se.
Sequence diagrams format details:
Normal and alternate flow: yes. The alternate flow was drawn on the same interaction diagram and beginning with a comment sticker that describes shortly the alternate case. E.g. the comment may say "the user wants to pay with miles".
Conditional action: yes. An "if" is shown on the label of the arrow when initiated by the actor, e.g. "[user explicitly initiate payment]//here the name of the action". The special IF construct (available in TogetherJ) when the statement applies to an object. This IF construct draws on long vertical bar over possibly many starting actions. I would like to use only this IF construct by it wasn't possible to apply it to an actor, so I used the alternative notation of "[..]" on the label.
Pre- and post-conditions: no.
Entry point: yes. Entry points are locations in the sequence diagram where the flow can begin when it comes from another sequence diagram. I used comment stickers to specify an entry point.
Alain Hsiung
Ideartis inc.

[alain hsiung]

Originally posted by redw25:
Alain,
how about the details of the class and the class's method?
1.in sequence diagram,do the operation is required?if so,the operation's parameters is also required?
2.in class diagram ,what methods should be shown?such as business method and other basic methods:create,find,update,remove..
the test is very different from our design,so i'm wondering.please help me.i'll sumit my assign
next week.thanks very much.

[Content edited by Chris Mathews, please see note below ]
Sorry I don't understand what you mean with "the test is very different from our design". Which test?
Alain Hsiung
Ideartis inc.
[ June 13, 2003: Message edited by: Chris Mathews ]

[fred wang]

Alain,

you are great! appreciate you very much.
"the test" is not important now ,because of your excellent answer. i mean that the Marking standard of scea is different from my fore design method.

[Chris Mathews]

Guys,
I have edited out some of the content of some posts. Please remember that specifics of the exam and of an individual's design should not be discussed. Please see this post.

[alain hsiung]

Originally posted by Chris Mathews:
Guys,
I have edited out some of the content of some posts. Please remember that specifics of the exam and of an individual's design should not be discussed. Please see this post.

it's just funny that my comments that have been removed are the one that have the most details, yes, but the less informative. When I say something like e.g. there are 4 classes with 4 methods and the reader is doing exactly 4 classes with 4 methods he very likely be worst than another that is doing 7 classes with 2 methods.

[Billy Tsai]

did you declare all the attributes and operations for all ur classes?
is it possible to pass without declaring them on classes?
what about EJB's home and remote interface did u draw them as well or just the a class representing the EJB with its interfaces?

[Bijan Mohanty]

Hi Alain,
Congratulation for your excellent score and thanks a lot for those informative replies. I have a question on your component diagram. Did you draw all the MVC2 classes in your component diagrams ? What I meant that did you just draw one Abstract Action class in your diagram or drew all the concrete Action classes(For example CreateUserAction etc.) in addition to the interfaces and the Abstract action sand the concrete actions that extends the abstract Action.
Also did you include the WAF(MVC2) classes in your class diagram or you kept it pure domain specific only.
Thanks a bunch in advance.
Bijan

[Jai Thomas]

Hi Alain,
One quick question for you. You have mentioned earlier that you did only one component diagarm. How did you manage to depict all classes in one component diagram without cluttering it? I am thinking of splitting mine into two or three. Do you see a problem with that? (I noticed that the assigment uses the singular term 'Component Diagram')
Thanks in advance
Jai

[alain hsiung]

Originally posted by Billy Tsai:
did you declare all the attributes and operations for all ur classes?
is it possible to pass without declaring them on classes?
what about EJB's home and remote interface did u draw them as well or just the a class representing the EJB with its interfaces?

- I declare all RELEVANT attributes and operations.
- I don't know if you pass without declaring them but it help me to declare them because I know then what the class is really doing.
- no EJB home and remote. This is not a relevant info at the architecture level because every EJB programmer know that an EJB has to be programmed by defining all this stuff. In the class diagram there is only classes. In the component diagram some classes of the class diagram are represented as EJB (SLSB, SFSB or EB). But there is no remote and home stuff, just one component for an EJB.
Regards
Alain Hsiung
Ideartis Inc.
Alain

[alain hsiung]

Originally posted by Jai Thomas:
Hi Alain,
One quick question for you. You have mentioned earlier that you did only one component diagarm. How did you manage to depict all classes in one component diagram without cluttering it? I am thinking of splitting mine into two or three. Do you see a problem with that? (I noticed that the assigment uses the singular term 'Component Diagram')
Thanks in advance
Jai

- I manage to represent all components on 1 diagram by having 4 big subsystems (and 3 very small), within these subsystems components are layouted with some logic so that only very few (4-5) relationships are crossing.
- I think there is no problem with splitting the component diagram into 2-3 subdiagrams as long as the relationships between components over 2 subdiagrams are represented (you have still to think as it would be 1 diagram and not only focus on the subdiagram's components).
Regards
Alain Hsiung
Ideartis Inc.

[alain hsiung]

Originally posted by Bijan Mohanty:
Hi Alain,
Congratulation for your excellent score and thanks a lot for those informative replies. I have a question on your component diagram. Did you draw all the MVC2 classes in your component diagrams ? What I meant that did you just draw one Abstract Action class in your diagram or drew all the concrete Action classes(For example CreateUserAction etc.) in addition to the interfaces and the Abstract action sand the concrete actions that extends the abstract Action.
Also did you include the WAF(MVC2) classes in your class diagram or you kept it pure domain specific only.
Thanks a bunch in advance.
Bijan

Hi Bijan
excellent question!
In fact I made 2 alternatives of component diagrams: (a) with framework classes and without much domain specific classes and (b) without abstract framework classes and with the precise domain specific classes. I sent only alternative (b) to the submission. Perhaps I lost the 2% there(?)
I cannot answer your question because I was unsure myself about the expectation of the examiner. Perhaps you may begin with 2 alternatives and choose one as soon as you are more confident that one has the right level of details and architectural relevance.
- there should be no technical (MVC2) classes in the class diagram, there should be only domain classes.
Regards
Alain Hsiung
Ideartis Inc.

[Bijan Mohanty]

Hi Alain,
Thanks again for your input. I have one last question. Did you draw all the jsps in both Component and Sequence diagrams or created one subsystem like GUI subsystem in the diagrams ? Drawing all the JSPs in the component diagram is kinda cluttering my diagram.
Thanks lot.
Bijan

[alain hsiung]

Originally posted by Bijan Mohanty:
Hi Alain,
Thanks again for your input. I have one last question. Did you draw all the jsps in both Component and Sequence diagrams or created one subsystem like GUI subsystem in the diagrams ? Drawing all the JSPs in the component diagram is kinda cluttering my diagram.
Thanks lot.
Bijan

Hi Bijan
- the seq diagram had one GUI subsystem, no further level of details concerning JSPs. But it is certainly allowed to go further in details. Although the examiner don't seem to expect this level of details because I got 100% on seq diagram.
- the component diagram had quite a lot of JSP,etc components but it was manageable. If you have too much of them you can try to represent similar components and relationships with a "template" component and relationship and write a little comment on the template which lists the components that follow this template. E.g. if you have a component A1 and component B1 and a relationship between the two, as well as a component A2 and component B2, A3 and B3, etc. then just represent a template A and B. The comment tells that A1, B1, etc. follows that template. This is just an example. What I mean is that you can find some ways to reduce the number of components without loosing information for the developer. As soon as your component diagram is understandable for a developer I think that the examiner will be happy.
Regards
Alain Hsiung
Ideartis Inc.

[alain hsiung]

Originally posted by sh yh:
congratulations alain!
I couldn't figure out a clean way to express the idea of scalability or performance in either a class diagram, a component diagram, or a sequence diagram. Did you stress scalability or performance in any of your diagram?
TIA.

You are right, scalability and performance are not shown in diagrams so you cannot express them in part II. The 4 questions of part III are basically questions on these topics.
Alain Hsiung
Ideartis Inc.

[dbala subramaniam]

Amazing Alain
Excellent Score!
I submiited Part II on Aug 11 till no result
Please let me know any details about Part III
how many questions what type questions and any details
please provide me
with regards
bala

[erich sun]

Hi,
I cannot understand why in the assignment, they let agent use application client instend of web browser.
which kinds application client is appropriate, Web clients (connecting to the Web tier)or EJB clients (connecting to the EJB tier)?
thanks.

[Roger Zacharias]

Hi Alain,
concratz!!!
Concerning your class-diagram (I think this is the crux in most assignments and you have negotiated it):
- Did you show attributes and ops in the class diagram?
- How many classes do you have?
- Have you changed the BDM?
- Have you consolidated some BDM classes?
Best regards
Roger

[alain hsiung]

Originally posted by Roger Zacharias:
Hi Alain,
concratz!!!
Concerning your class-diagram (I think this is the crux in most assignments and you have negotiated it):
- Did you show attributes and ops in the class diagram?
- How many classes do you have?
- Have you changed the BDM?
- Have you consolidated some BDM classes?
Best regards
Roger

Hi Roger
- yes, I show the attributes and ops in the class diagram
These attributes and ops cover the use cases.
- 22 classes (but you could also get 100% score with a different number of classes)
- yes and no. I started with the Business Domain Model and mainly extended it but I didn't modified it (or only very slightly). I.e. I did't remove classes and modified relationships only very slightly. I basically made the model more precise and absolutely coherent with the use cases.
- yes, I consolidate all BDM classes by taking the use cases, filling the attributes and ops of each BDM classes, eventually adding new classes (because the use case requires it), making the relationship more precise (directionality, cardinality, has-a relationship, etc.) and adding more relationships (again because the use case requires it).
Regards
Alain Hsiung
Ideartis inc.

[allison ai]

Congrats, Alian!
I have been struggling with the component diagram(s) for a while. I would appreciate your comments very much and thanks in advance!
The component diagram counts a significant portion of the total score, so it should be fairly complex, at least when compared to the sequence diagrams. But my component diagrams are more like those in the Case Study chapter of Cade's Study Guide book, i.e. they look quite straightforward and simple: no specific JSPs, Servlets, or EJBs, only components (abstraction entities, each contains specific JSPs, Servlets, or EJBs). For example, my diagrams contain basic components like user view, web controller, request filter, EJB controller, session facade, etc.
What troubles me are the two generic issues regarding component diagrams in UML (I hope my questions are not revealing the specifics of the assignment too much):
1. How to include all JSPs, Servlets, and EJBs in component diagrams in general UML drawing? My reading of the requirement is to include all SPECIFIC JSP pages, Servlets, EJBs and other JavaBeans in the diagram. Am I right? But I thought a component diagram is a way of showing how the application is broken down into different components (more like sub-systems, not individual objects) and how those components interact with / depend on one another. I have been searching other books and online resources, but not found answers yet. What I have done so far is to list those individual concrete objects under the components they belong to as a note under each diagram. E.g., a search JSP page belongs to the user view component. I doubt this is the right way to do it.
2. How to show the design patterns in component diagrams? E.g. a command pattern is implemented by a couple of specific objects, which all belong to the EJB controller component in my design. Since those concrete objects are not shown in my diagram, but only listed in the note attached to the diagram, how can the command pattern be illustrated in the diagram then? Since I have included all specific objects in my class diagram, including JSPs and Servlets, the patterns are shown more clearly there. But again, I am not sure if it is acceptable.
Thanks again!

[alain hsiung]

Originally posted by allison ai:
Congrats, Alian!
I have been struggling with the component diagram(s) for a while. I would appreciate your comments very much and thanks in advance!
The component diagram counts a significant portion of the total score, so it should be fairly complex, at least when compared to the sequence diagrams. But my component diagrams are more like those in the Case Study chapter of Cade's Study Guide book, i.e. they look quite straightforward and simple: no specific JSPs, Servlets, or EJBs, only components (abstraction entities, each contains specific JSPs, Servlets, or EJBs). For example, my diagrams contain basic components like user view, web controller, request filter, EJB controller, session facade, etc.
What troubles me are the two generic issues regarding component diagrams in UML (I hope my questions are not revealing the specifics of the assignment too much):
1. How to include all JSPs, Servlets, and EJBs in component diagrams in general UML drawing? My reading of the requirement is to include all SPECIFIC JSP pages, Servlets, EJBs and other JavaBeans in the diagram. Am I right? But I thought a component diagram is a way of showing how the application is broken down into different components (more like sub-systems, not individual objects) and how those components interact with / depend on one another. I have been searching other books and online resources, but not found answers yet. What I have done so far is to list those individual concrete objects under the components they belong to as a note under each diagram. E.g., a search JSP page belongs to the user view component. I doubt this is the right way to do it.
2. How to show the design patterns in component diagrams? E.g. a command pattern is implemented by a couple of specific objects, which all belong to the EJB controller component in my design. Since those concrete objects are not shown in my diagram, but only listed in the note attached to the diagram, how can the command pattern be illustrated in the diagram then? Since I have included all specific objects in my class diagram, including JSPs and Servlets, the patterns are shown more clearly there. But again, I am not sure if it is acceptable.
Thanks again!

Hi Allison
1. About granularity of components. One way to see components is as sub-systems. The goal is to define a service. The other way is to see components as the (technology dependent) entities that an architect can define and a developer implement. The goal is to define the "interface" between the architect and the developer. For this goal a component "EJB" with the stereotype SFSB is the right level of granularity, as well as "JSP", "Servlet", etc. because the developer knows what to do to implement an EJB (define remote and home interface, implement the class, define XML descriptor). The component "EJB" includes 3-4 java classes and 2 descriptors (1 standard and 1 vendor specific). The developer understands the architect speeking about "EJB".
For components (as sub-systems) I used packages (not components). A packages contains many components.
A component diagram is a way to communicate the technological decision of an architect to a developer. NB: a class diagram does not do that.
Your're right, there is almost no litterature about component diagram's goal and granularity of components (of the diagram). The book "Developing enterprise application with J2EE and UML" for example is very misleading in this respect because it propose a very low level component granularity (class level). I do not agree with this view. In my understanding, the class diagram (+ sequence diagram for the dyanmic aspect) is the way to communicate the requirements from the domain expert to the architect and the component diagram is the way to communicate technical decisions from the architect to the developer.
2. Design patterns can be represented with stereotypes and/or comments.
Regards
Alain Hsiung
Ideartis inc.