Class diagrams...

[James Turner]

Hi Guys,

Just a quick question about the class diagram.

The class diagram would show all the classes of our system, the components of the system are also classes, does this mean we show them as well?

For example, I have serveral DAO's, a service locator and a business delegate, these are classed as components and so the component diagram is where I have placed them, but they are also just classes, does this mean they also need to be placed in the class diagram?

Also, is it a usual thing to partition the class diagram into subsystems composed of classes that apply to each of the tiers of the system? Or do we keep them all together?

Thank you for any help.

Regards,
James.

[Ricardo Ferreira]

Originally posted by James Turner:
Hi Guys,

Just a quick question about the class diagram.

The class diagram would show all the classes of our system, the components of the system are also classes, does this mean we show them as well?

For example, I have serveral DAO's, a service locator and a business delegate, these are classed as components and so the component diagram is where I have placed them, but they are also just classes, does this mean they also need to be placed in the class diagram?

Also, is it a usual thing to partition the class diagram into subsystems composed of classes that apply to each of the tiers of the system? Or do we keep them all together?

Thank you for any help.

Regards,
James.

James,

Your class diagram should explain the domain model for you application. The domain model is just the entities and your relationships. Any class that provide some 'service' for you application, is not an entity (even being a class), so, it�s not a good idea show them in the class diagram.

The only exception for this, it is the classes that will participate in the business workflow of your application. This business components are the principal key solution of an architecture since they help the system to measure what happens when you send a message to it.

Now, lets go the diference. One stateless session bean that access, updates or creates an customer in the system, could be added to the diagram, since it is the class managing an workflow.

An DAO class (CustomerDAO), that do this job to, can�t be considered an business component, its just an utility class, as ServiceLocator�s, Transfer Objects, Controllers, etc.

But, this are just some tips for you, not a set of rules for UML diagramming. Try to keep your class diagram more simpliest possible, and don�t worry if your class diagram finish only with 15 classes. Could be perfect for the evaluator, if he can understand what you have planned.

best regards,

[James Turner]

Thank you Ricardo,

very informative response, much appreciated!

Obrigado!

James.

[Kayman]

The only exception for this, it is the classes that will participate in the business workflow of your application. This business components are the principal key solution of an architecture since they help the system to measure what happens when you send a message to it.
==========================

Would a actionservlet controller from a framwork like struts be part of the workflow exception?

[Frederico Melo]

Originally posted by Ricardo Ferreira:


James,

Your class diagram should explain the domain model for you application. The domain model is just the entities and your relationships. Any class that provide some 'service' for you application, is not an entity (even being a class), so, it�s not a good idea show them in the class diagram.

The only exception for this, it is the classes that will participate in the business workflow of your application. This business components are the principal key solution of an architecture since they help the system to measure what happens when you send a message to it.

Now, lets go the diference. One stateless session bean that access, updates or creates an customer in the system, could be added to the diagram, since it is the class managing an workflow.

An DAO class (CustomerDAO), that do this job to, can�t be considered an business component, its just an utility class, as ServiceLocator�s, Transfer Objects, Controllers, etc.

But, this are just some tips for you, not a set of rules for UML diagramming. Try to keep your class diagram more simpliest possible, and don�t worry if your class diagram finish only with 15 classes. Could be perfect for the evaluator, if he can understand what you have planned.

best regards,

Ricardo,

UML class diagrams cannot be limited to exposing Domain Model. This is usually the first model you construct for an application, to help discovering domain entities. Besides this, analysis and design structural models can be very usefull and necessary depending on your system. Identifying the analysis classes and classifying them according to the three key analysis stereotypes (entity, controller, model) is essencial for a good software design and is part of Robustness Analysis. I didn�t understand why you said it�s not a good idea to include classes wich are no entities on the class diagrams. Is this on the SCEA assignment instructions?

[Ricardo Ferreira]

Originally posted by Frederico Melo:


Ricardo,

UML class diagrams cannot be limited to exposing Domain Model. This is usually the first model you construct for an application, to help discovering domain entities. Besides this, analysis and design structural models can be very usefull and necessary depending on your system. Identifying the analysis classes and classifying them according to the three key analysis stereotypes (entity, controller, model) is essencial for a good software design and is part of Robustness Analysis. I didn�t understand why you said it�s not a good idea to include classes wich are no entities on the class diagrams. Is this on the SCEA assignment instructions?

Hi Fred,

James wanted to put some classes there don�t make any sense in the class diagram, as ServiceLocators and Controllers from MVC. What i have said is, focus in the domain model, and of course, in the business workflow of the application. I agree with you that business components should be added, but, for a comprehension of the model, its not necessary to put in the class diagram. But, as i have said too, they are just tips, not rules.

[Ricardo Ferreira]

Originally posted by Kayman:
The only exception for this, it is the classes that will participate in the business workflow of your application. This business components are the principal key solution of an architecture since they help the system to measure what happens when you send a message to it.
==========================

Would a actionservlet controller from a framwork like struts be part of the workflow exception?

Kayman,

I see a very little difference with the following types of workflow:

- Business Workflow
- Application Workflow

An business workflow is an kind of flow management that maps to the logical decisions to the business tier, most of them, based on business requirements from the system. For example:

Banking System
* if balance has no founds, raise an exception
* When the account is disablem deny any access to the balance
* A company account can have one or many sub-accounts for your employes,
if they are working at the company for, at least 2 years.

Book Commerce
* Discounts can be provided to customers with a special profile
* When the shopping cart contains more of 10 itens, give an 15%
discount, otherwise, only 5%

Talking about the application workflow, we can see the flow management of access inside the application. Examples of this workflow could be: after the create profile page, go to the itinerary list page. Anothers examples:

Banking application
* After the customer updates your account, it can move to the resume page, if it has clicked in the resume link.
* If the login is invalid, forward to the 'loginError.jsp', otherwise,
forward to the 'enterInAccount' servlet.

Well, a feel an ActionServlet (the Front Controller) responsable for Application workflow, and I think that cannot be considered an business component (of course, it�s not in the ejb tier )

But, as I have said, its just some tips for modeling, don�t think that i�m an evangelhist of the good patterns, I just say what i think.