I'm very happy to tell you that i have been approved in the Sun architect certification. I got my results today in the certmanager web site. It is not a very good score, but the more important is: I passed
Here comes my result details:
Sun Certified Enterprise Architect for Java 2 Platform Enterprise Edition Technology Part II (310-061) Date Taken: 2006-04-09 20:01:35.780 Site: bra Grade: P Score: 84 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.
As I promissed, i'm going to scratch some tips about the assignment.
I had been working in this assignment about two months, since i have downloaded the project. As you know, i got the famous "FlyByNight Travel Reservation System".
The most important tip that I could give you is: Pay attemption in the document details. There are too many implicit information in the document. Do not look it and say "That's Easy!" No my friends. It's not easy.
I started spending one month only reading the requirements, and trying to undertand the nature of the system. My first mistake in the assignment, was worry to much with the techical details such as: What patterns to use ? What kind of persistence layer adapt to ?
The main thing that you must worry about in the SCEA assignment certification is on requirements. The most important responsability for ab architect is to meet the customer's needs. If your application will use EJB's, depends of the non functional requirements of the application.
Well, after digesting the requiremtns, and having a ideal snapshot of the solution in my mind, I starded the design activity in the project. As you know, there is a very big difference between analysis and design. You could see the difference in the RUP documentation.
In the design activity, i starded to meet the non functional requirements of the application, such as:
- The application must ensure very short response time betweeb method requests ? * Use the 'ValueListHandler' to reduce the ammount of objects traffing between the tiers * Use the 'ValueObject' pattern, to reduce the too many method calls to the EJB container * Use ServiceLocators with caching (now, is default in the Sun Catalog) * Abuse of the SLSB to promove performance and scalability
- You have to maintain two or more kinds of views from the same business rules ? * Try to use 'BusinessDelegate' pattern to abstract the client portion to the middle tier. And of course, abstract the specific EXCEPTIONS from the client application (never propagate an java.rmi.RemoteException) for an client application * Use MVC. as Nike says: JUST DO IT! * Use EJB's to maintain business rules. I have seen developers using EJB's just to say that they are using a 'very good' technology.
Well, after thinking in the architectural questions for the project, I really started to work in the diagrams. I used the UML 2.0, because i have seen that some use cases will have to many alternative flows. The UML 2.0 provides a very good solutions for this, with the core sentinals as: [loop], [alt], [opt] and so on.
I started creating the class diagram. After, I created the component diagram, and finally, I created the iteration diagrams. I used only sequence diagrams, not comunication diagrams.
After all, i stared to document down the assumptions for the project. Onething very important here, is:
--- Document only what you can't demonstrate in the diagrams!
You don't need 80 pages of HTML documentation. The evaluator will use your assuptions section only to understand, what the diagrams by nature, can't say (Normally, human decisions). Because this, i have only 12 pages of assumptions documentation. I wrote somethings like:
- What persistence layer must be used in the DAO components ? - What tier layout to use (distributed architecture or local architecture) - What transactional approach (CMT or BMT) - What protocols to use to access the tiers (HTTPS, RMI/IIOP, SOAP) - Servers usage (What the pourpose of the E10000, E5500, 450's)
And of course, i wrote my domain decision's about why I have removed some entities, added anothers, created some relationships. Talking about this, you do not have to write why you used a composition. The UML already have explained this for you.
Originally posted by Ricardo Ferreira: ... It is not a very good score, ...
- Your score on Class Diagram is excellent!
- Your score on Sequence Diagrams is good as well!
- What about Component Diagram, your weakest score? I have seen many discussions about Class and Sequence Diagrams, but we easily forget that the Component Diagram makes 34 % of the score.
- Did you provide one overall Component Diagram? - - If so: did you also show or remark the classes belonging to a component? - - - If so: how? By annotations, tool specific remarks, ...? - Did you [additionally] provide a Class Diagram per component showing its inner structure? - Did you show all classes [not components, sorry] of the technical architecture like ServiceLocators too? - Did you form Common Components (jars) of commonly used abstract classes etc. and include these in your business / technical components then? - Do you remember any reasons for loosing points in the Component Diagram?
Again: Congratulations and many thanks for prviding your experiences here!
Thomas [ April 18, 2006: Message edited by: Thomas Taeger ]
Hi Thomas, thanks for the comment. Here's you answers:
Yes, I provided one big component diagram to explain the architectural view of the application. My first idea was to create three separated component diagrams, using the boundarie modeling technique. But, in the end of elaboration, I finished the diagrams with a few components, and i decided to put all them into one diagram to promove clarity.
I did not show any piece of information about wich classes belongs for an component. I just mentionate in the diagrams, the following:
- The components with stereotypes - The dependency relation (even the indirect dependency) - The subsystems - The interfaces provided - The interfaces required
I had only one class diagram to show my domain model. So, i did not provide any additional class diagram to show inner class relations.
I provided all the design architectural features in the component diagram. Those include all the patterns that i've applied in the solution. Only the ACTION components (MVC) has been removed from the diagram, because i finished my design with 34 action classes. Well, I decided remove them to provide more clarity. I justified this remotion in the documentation.
I have used only the patterns that could solve some non functional requirements needs of the application, such as: performance, scalability, security and managebility.
No, I did not provide any super package view for the common components.
Well, there are a few things that now, I know that I could have improved in the diagram. Here they are:
- I forgot to put an JSP component used in an sequence diagram () - I did not use CMP Entity Beans. Since the application, will be accessed for simultaneos users, concurrency must be carried about. I use DAO components with a persistence framework. My solution works fine with DAO components, but with Entity Beans, the concurrency, integrity and bean relationships managing, could be maintained by the container. Never forget that everything that is maintained by the container promoves scalability and independency. And this, is a very good point in any J2EE solution!
Hello Ricardo, many thanks again for letting us know your thoughts on the way to best decisions.
Just one question is left (not necessarily to you, Ricardo): if one (like me) shows technical classes (not "components", sorry) like BusinessDelegate on the Class Diagram(s), shouldn't it be shown being part of a (or several) component(s) too? Who did it and how?