Important question regarding the level of detail of the diagrams for part 2

[Javier Ramos]

Hi, I have a question regarding what type of diagrams should we deliver, specially in the case of the iteration diagrams because I usually write up to 3 different sequence diagrams per scenario each one having a different level of granularity. So, I'm not sure if I have to send all of them or just one.

I usually follow a process similar to the RUP development process. I start gathering requirements and I create the Use Case model. Then, I describe the scenarios of each use case. The next step in the analysis phase is to implement the scenarios using interaction diagrams. I use the high level stereotypes <<control>>, <<entity>> and boundary. This model is platform independent, it is also independent of the architecture used and it's useful to identify the domain classes to create a logical model. The next phase is the design, where I refine the model by defining the architecture. Here, I add more classes witch are mode dependent of the platform but independent of the technologies (EJB, JSF...). Basically, I add more Java classes showing the design pattern giving more details on how the problem is solved. For example, more entity classes are added to show composite objects or Transfer Objects. More Java classes are added to show the design patterns, like mediators, factories, builders, etc. But this class and sequence diagrams don't show EJBs, or JSPs. In other words, you can implement this model in any technology. In the next phase, is when I refine the model adding technology details adding the session beans, JPA entities, Servlets and JSPs. I use a extension of Rationa Rose for Web Applications that uses Web Applications stereotypes like in here: http://www.rationalrose.com/stereotypes/waesetup.htm This is a very detail sequence diagram, I show how entities are created and even I show the server and client side of a JSP. So, I show the forms which are included in a client page (HTML that the JSP servlet generates), I show the server page, the Java servlets, the ejbs, service locator and so on. Something like this: http://sites.google.com/site/javierramos1/example.pdf

This approach shows how the system evolves and helps to identify problems and each diagram will be useful to different people depending on the role, for example, a PM will care only on the high level design. My question, is which level of details the SCEA is looking for. Can I include the 3 types of sequence diagrams in my delivery?

Also, should I add the classes inside a component in the component diagram?

Thanks for your help.

Javi.

[Teja Saab]

Check out http://www.box.net/shared/2s55mfkogg. This will give you a very good idea about the level of detail that you need to provide for your assignment.

[Andrew Monkhouse]

Please provide attribution or posts like this are likely to be deleted - it takes quite some time to check whether something is pirated or not, and if moderators are pressed for time, they may err on the side of caution.

This is obviously chapter 9 from Sun Certified Enterprise Architect for Java EE Study Guide (2nd Edition), and ordinarily the fact that this is not on the publisher's or authors site would look very suspicious. In this particular case I am happy with it though, as Humphrey explicitly mentions that he placed this chapter there in a blog post.

[Teja Saab]

Point taken. Thanks.

[Mihai Lihatchi]

Sorry to reopen this but as I also checked the class diagram from the SCEA book (free example posted above)and I noticed a layer missing from the class diagram
That is :
jsp -> controller (Front controller pattern) -> manager -> entity
I see the service layer (http://martinfowler.com/eaaCatalog/serviceLayer.html) missing and I think a SLSB (remote or not depending on distribution model) would have been a good fit between the controller and the manager. Almost every application I worked on since 2006 had a Service Layer calling one or more DAO's for persistence (in fact calling the DAO's from the controller is something I rarely saw except for very simple examples). Maybe the manager represents a different pattern in EJB3.0 ( I look at them as a HiberanteDao - the ones I used in Spring before) which can handle both transactions and persistence and other services (external systems interaction).

Maybe it is just not displayed because it is not required ? Before checking the solution I tried to provide my own to see if it fits the solution required and I was shocked by the difference .

[Teja Saab]

Mihai Lihatchi wrote:
Maybe it is just not displayed because it is not required ? Before checking the solution I tried to provide my own to see if it fits the solution required and I was shocked by the difference .

There can be many ways to architect the solution for any given IT system. So just because it doesn't match the representation in chapter 9 of the SCEA study guide does not make your solution wrong. Besides, the chapter 9 solution is only meant to provide a general idea about the solution and is certainly not the only way to create a solution architecture.