• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Architecture/ design Diagrams in real life vs created for exam

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am still waiting for the answer. That will help me to identify where to start.

Thanks,
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic