aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Architecture/ design Diagrams  in real life vs created for exam Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Architecture/ design Diagrams  in real life vs created for exam" Watch "Architecture/ design Diagrams  in real life vs created for exam" New topic
Author

Architecture/ design Diagrams in real life vs created for exam

Vis Deo
Ranch Hand

Joined: Jul 02, 2004
Posts: 40
Does anybody know any site / sample of design diagrams that takes short problem / scenario and shows different ways to design and corresponding use case, class, sequence, deployment diagrams. This is for study purpose ( Examples using j2ee technology. )

Also would like to know how much it is followed in real life projects. Showing sequence diagrams for all types of scenarios/ page requests. Considering UI may consists of 70/80 jsps. And at least 3 to 4 actions per jsp. EJB / DAO corrsponding to 3-4 different databases residing one on mainframe/ one on Unix, one read only data from some other place.

Thanks,
Vis Deo
Ranch Hand

Joined: Jul 02, 2004
Posts: 40
I am still waiting for the answer. That will help me to identify where to start.

Thanks,
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782

Does anybody know any site / sample of design diagrams that takes short problem / scenario and shows different ways to design and corresponding use case, class, sequence, deployment diagrams. This is for study purpose ( Examples using j2ee technology. )

Have you seen the Petstore documentation(J2EE blueprints)? It is perhaps the most widely quoted stereotypical J2EE application. The documentation includes all the diagrams you have mentioned. Another place to look is the Mark&Cade SCEA guide. The book presents you with a case study and a step by step approach to architect the system using J2EE technologies. Albeit not very exhaustive, it could be used as a starting point.



Also would like to know how much it is followed in real life projects. Showing sequence diagrams for all types of scenarios/ page requests. Considering UI may consists of 70/80 jsps. And at least 3 to 4 actions per jsp. EJB / DAO corrsponding to 3-4 different databases residing one on mainframe/ one on Unix, one read only data from some other place.

In real life every organization follows a "methodology". I am not talking about RUP-like methodology, but about well established guidelines and templates for documenting system requirements, design and architecture. Naturally, every methodology will be different - some may omit to represent the JSPs and show the system flow only until the construction of VOs. Some may include detailed description of user interfaces( I have worked on projects with dedicated UI teams and usability experts) and page flows. Similarly, EJBs may be represented just as business components and all DAO/persistence logic may be treated as a blackbox( I favor this approach, more so these days as persistence frameworks become an inevitable choice).

In my opinion, one has to use their judgement when it comes to "how much" to show in design artifacts. More than mere artifacts, they serve as tools of communication and documentation. And also think about the audience - people who consume the artifact to produce derived artifacts( such as sourcecode) and people who just review the design/requirements at a very high level. Your goal is to include just enough information in them so that the audience can make sense out of it and the system implementation can proceed without any confusion. You should also remember that these artifacts often may not make sense all by themselves, but only when combined together to paint the big picture. For instance, your component diagram is an absolute requirement if one want to correlate the entities in the class diagram to a potential deployment scenario. Without the component diagram, your class diagram just represents an OO-view of the system without the specifics of the target platform( this is often referred to as "Platform independent design" ).

As you can see, there is more to the usability of the artifacts you produce than just compliance with some notation. If you are unsure about the completeness, you could handover your design docs to a Java developer. If he can understand every bit of it and move on to the next step, you have done a good job. In fact, this is what architects do in real life. The artifacts get handed over to design/dev teams and gets redrawn over time during serveral interations to achive clarity and consistency.


HTH


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Architecture/ design Diagrams in real life vs created for exam