Hey Folks!
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.
That's It!
