• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Notion of "component" in Assignment

 
Lorent Lempereur
Greenhorn
Posts: 3
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am a bit confused about what a "component" must be regarding the assignment.
When writing component diagrams, I usually define components as high level parts of my architecture, e.g a deployable artifact, a database, a JAR/WAR/EAR... The "OCM Java EE 6 Enterprise Architect Exam Guide" (from Allen & Bambara) book states the same explanation about components.

However, the assignment states:
Examples of components are Enterprise JavaBean (EJB), servlets,

JavaServer Pages (JSP), major Plain Old Java Objects (POJOs), and important Managers /

Controllers / Design Pattern implementations.


This looks very low level, imho.

Does anyone have more clarification about these "components"?

Kind regards,

Lorent
 
K. Tsang
Bartender
Posts: 3583
16
Android Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

I would use the assignment's definition. In general, a component is an artifact or group of artifacts that represents a higher level than a class.

For example you may have bunch of entity classes (say Inventory, InvA, InvB etc) in the class diagram. In the component diagram, you would most likely have a single component named Inventory that represents the group of entity classes mentioned before.

Oracle's intention is to let you identify the "important" components that usually are EJB and/or servlets.

Allen's book' s definition of component is more towards deployment diagram.
 
Lorent Lempereur
Greenhorn
Posts: 3
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, K. Tsang!

I still have some doubts.

1. In your example, do you mean we would end with several components such as "Inventory EJB", "Inventory Entity", "Inventory Web Service" (annotated with stereotypes, for example) ? Or a single "Inventory" component"?

2. Should we "aggregate" these classes to a highest abstraction level:
  • On a technical point of view? (If I use a lot of Transfer Objects, I could group them together into a "Transfer Objects" component)
  • And/or on a business point of view? (If I have several classes that have a high business cohesion, such as your "Inventory Endpoint", for example).

  • 3. May I use components that are not present in the class diagram? e.g. a JAAS component.

    4. Assume I follow the assignment's definition, is this ok to:
  • Group classes into components to obtain some "Low-level component";
  • Include several components into parent components (closer to what I would actually deploy) to obtain "Deployable components";
  • In my deployment diagram, use these "deployable components" only?


  • 5. Should database, queues, etc appear in such a component diagram?

    7. Do we have to mention components that relate to "external systems" that must be used but not defined as part of the assignment scope? (e.g. a pricing system)

    6. I understand why the class diagram is worth a lot of points (40 points). However, it is confusing that sequences diagrams (16 points) - that are very time-consuming - are valued to less than half that the component diagram (40 points as well). I have the feeling that I must produce a huge/complex component diagram even if it is not its purpose.

    Many thanks, again.
     
    K. Tsang
    Bartender
    Posts: 3583
    16
    Android Java
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Lorent Lempereur wrote:
    1. In your example, do you mean we would end with several components such as "Inventory EJB", "Inventory Entity", "Inventory Web Service" (annotated with stereotypes, for example) ? Or a single "Inventory" component"?

    Yes and no. Oracle explicitly mention what they think are important so similar "functional" classes can be grouped together. Think packages. Say you have package "inventory" which may have the EJB, entities, and web services. I would have 3 components: inventory EJB, inventory WS and inventory (the rest) components. Using the same idea if you package as entity.inventory, ws.inventory, and biz.inventory (the EJB) then again I will have 3 components.

    Lorent Lempereur wrote:
    2. Should we "aggregate" these classes to a highest abstraction level:
  • On a technical point of view? (If I use a lot of Transfer Objects, I could group them together into a "Transfer Objects" component)
  • And/or on a business point of view? (If I have several classes that have a high business cohesion, such as your "Inventory Endpoint", for example).



  • No group by function not what they are

    Lorent Lempereur wrote:
    3. May I use components that are not present in the class diagram? e.g. a JAAS component.


    Depends. JAAS is security/auth related, if you need a class to handle security/auth then this class will be in the class and component diagrams. However if it's like JMS and stuff then you can't represent such in classes but only in component diagrams.

    Lorent Lempereur wrote:
    4. Assume I follow the assignment's definition, is this ok to:
  • Group classes into components to obtain some "Low-level component";
  • Include several components into parent components (closer to what I would actually deploy) to obtain "Deployable components";
  • In my deployment diagram, use these "deployable components" only?



  • functional grouping

    Lorent Lempereur wrote:
    5. Should database, queues, etc appear in such a component diagram?


    internal and external systems are part of the component diagram.

    Lorent Lempereur wrote:
    7. Do we have to mention components that relate to "external systems" that must be used but not defined as part of the assignment scope? (e.g. a pricing system)


    The assignment should tell you what those external systems are. There shouldn't be more.

    Lorent Lempereur wrote:
    6. I understand why the class diagram is worth a lot of points (40 points). However, it is confusing that sequences diagrams (16 points) - that are very time-consuming - are valued to less than half that the component diagram (40 points as well). I have the feeling that I must produce a huge/complex component diagram even if it is not its purpose.


    Sequence diagrams are indeed worth way less points but they go somewhat with the class diagram. When doing the sequence diagram for each use case, you should able to trace the step/life line of the sequence diagram in the class diagram from presentation layer to business to integration and back.

    Tip: Tackle each use case at a time doing "both" the sequence diagram and class diagram parts. Iterate until you feel the design/steps are right. Remember to incorporate those tiers.

    Component diagram is worth same as class diagram because as I said before component diagram is basically a high level diagram of class diagram. So if you have a "good" class diagram, your component diagram is practically set. Of course you still need to determine what is "important" that worth its own component.

     
    Lorent Lempereur
    Greenhorn
    Posts: 3
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you very much, K. Tsang!
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic