This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have recently stuck with a trivial task - preparing component diagram. I am not confident what exactly should be modelled as component. Having speaking with professional java architects, 'component' should be high-level abstraction of system part. On the other hand, Sun assigment defines components as EJBs, Servlets, Managers or main POJOs. I have ended up creating component diagram containing almost every concrete class as component, which, after having a second look, I found ugly and fundamentally wrong.
Therefore, my questions are:
1) Should web actions be modelled as components? Or should it be one generic action component that referres to all action classes? 2) Should persistent entities be modelled as components? Or should it be one generic component that referres to all persistent entities? 3) same with DAO (assuming there's one DAO per one persistent entity class): many DAO components or one DAO component? Or should DAO be rather modelled as a port for entity component?
Any suggestions will be much appreciated.
SCJP 1.4 - 88%
SCBCD 5.0 - 90%
SCEA - 81%
Joined: Mar 19, 2004
Further to the questions above:
4) should component diagram bring information about business logic (e.g. particular action depends on particular component for finalizing customer payment) or should it contain strictly infrastructural information (e.g. web action depends on service locator in order to obtain service)
5) If component referres to conrete class, should it be named after this class (e.g. CustomerEJB) or a more generic way (Customer)?
I'm reside at Egypt not in USA , and i want to purchase for Part2 of SCEA5 but when i follow link to other country, i could not find any link to purchase the exam online , all i found are purchasing courses not puchasing exam, and when i search i found that not every country support online purchaing exam from it's web site so, can any one tell me how to order or purchase exam part2 of SCEA 5 online, or can i online purchaing exam from globle site which belong to USA?
Originally posted by tarek helmy: I'm reside at Egypt not in USA , and i want to purchase for Part2 of SCEA5 but when i follow link to other country, i could not find any link to purchase the exam online , all i found are purchasing courses not puchasing exam, and when i search i found that not every country support online purchaing exam from it's web site so, can any one tell me how to order or purchase exam part2 of SCEA 5 online, or can i online purchaing exam from globle site which belong to USA?
What has this got to do with this thread?
Anyway , getting back to the question , the Sun manual for the SL425 course says :
A component diagram shows the major software components of a system and how they can be integrated.Component diagrams can contain non-object-oriented software components , such as legacy procedural code and web documents
The example given in the manual stuff like: 1. <<artifact>> person.jsp 2. <<component>> Person Business Delegate 3. <<component>> PersonEJB
Joined: Apr 30, 2003
Just to add , what the architects you asked might have been thinking about are components as in how you'd show them in say a deployment diagram , where you'd have stuff like
1.<<component>> Browser 2.<<component>> Apache Web Server etc
Joined: Mar 19, 2004
Hi Jeff, thanks for answering. I fully agree with component definition given by you, but I have an impression Sun SCEA part II requirements are not consistent with it. It is explicitely stated that assignee should model EJBs, servlets, jsp pages, major POJOs and important controllers as components, which brings my confusion. For me, it sounds like every class apart from Remote/Local interfaces and POJIs.
What I would like to understand is how it should be applied in a context of SCEA part II. According to definition quoted by you, I could model each major JSP page / service / entity as separate component, but I have an impression the component diagram would contain too much implementation details. I was wondering maybe it is better having one JSP component / DAO component / Entity Component / Service component with <template> stereotype. In that way, diagram would allow to define architectural-level information (e.g. jsp pages submit requests to ControllerServlet, but are isolated from services) and would be free from low-level implementation details (e.g. that AddUserAction delegates request to UserService and not to RegistrationService).