i am trying to generate the component diagram for the assignment. But when i read the tutorials and posts, i see that there are two ideas for the definition of a component.
SCEA Study Guide-Mark Cade book gives a component diagram for each package and each component declared is actually a class used within the application, like "XPageForm" , "XController", "XDAO", etc. And the relations between the components are just indicated with dependency arrows, which are not named at all.
But when I read the tutorials, they say that the component should be a pluggable interface and should communicate with the interfaces. With this logic, one component diagram is enough, which contains very abstract components like "JSFPages", "ManagedBeans", "SessionBeans", "DAO", "Persistence", "University Database" and the relations between the components becomes like the generic interfaces given outside in each component.
Which way is the right way for the SCEA assignment?
I also thought that the second way is better, because first way requires lots of components which may make the scorer lose the concentration on the overall architectural design and a component is not a class, it is an item that performs a key functionality within a system and should be pluggable.
I am planning to use FacesServlet in the component diagram as well because the requirements of the component diagram in the assignment indicate that i should include the servlet.
But if I choose the second way, then another problem arises like how I will decide the provided/required interfaces between some specific components. For example between FacesServlet and BackingBeans components.
I've read the other topics related with this and the overall idea is to use "Reflection API" between them. It seems feasible, so agreed by me.
But what about the dependency between JSFPages and FacesServlet component? I don't know the provided/required interfaces between them. Better to show it with dependency arrow without naming the interfaces?
And I will use Transfer Object Design Pattern, but Transfer Objects are used in lots of layers/components like JSFPages, BackingBeans, SessionBeans, DAOs and Persistence. So if I try to show the dependencies between TransferObjects component and the other related components, my diagram will be complicated. Or should I only put dependency to the JSFPages and BackingBeans components because others are just transfering these objects?
Please supporters, continue sharing your thoughts and the others, please make some brainstorming.
Prabu S Arumugam
posted 10 years ago
To me (SCEA Novice), Component diagram should be a place holder to potray your subsystems and their dependancies (interfaces exposed and used).
Disclaimer: I am still working on my part-II. Haven't cleared it yet.
The url is correct. The web site is down temporarily, I think. I read that article just two days ago from that web site and actually it does not explain what a component really means and what type of "layers" should be included inside the component diagram.
In my opinion every layer/tier should be shown in the component diagram, not only the business components and ejb layer. Due to that, I will include the JSF related components as well.
In the component diagram I would just show a Controller component in the web layer, and in the component diagram description I'd mention that it uses JSF servlet and backing beans for handling user requests and JSP pages for dynamically generating HTML pages. IMHO this would make the component diagram simpler because it'd only show the most important components in the application and their communication paths.
Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Trust God, but always tether your camel... to this tiny ad.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop