Hi All,
I齰e the three modules in my application(Permissions, ConfigSys and Security). Each module has several class in j2ee patterns(DAO,Helper,Transfer object) and interfaces too. I齧 making a only diagram of class with DAOs, Helpers and TOs classes, but it very large, this way it齭 right or I齰e to make a diagram for each pattern(DAO diagram, Helper diagram and TODiagram)?
Regards,
Luiz
In general, you should not have an uber-diagram. It is confusing, and the whole idea of UML is to model a complex system or component in manageable, understandable pieces.
You have several options to model the components you described:
> Model by pattern implemented (each pattern gets a diagram). This was your original idea, but I think only UML book authors model this way.
> Model by tier/responsibility (DAO's and TO's on one diagram, helpers and controllers on another, views on the third, etc.). This has the advantage of keeping together common components which perform common functionality. Usually, this type of modelling will focus on inheritance over delegation or composition.
> Model by component across tiers (security on one diagram with DAO, TO, helper and controller; permissions on one diagram with DAO, TO, helper and controller; etc.) This makes the most sense to me, as the value of your software is not in the patterns it uses (those make the system more maintainable and adaptable), but rather on the components, interfaces and services it provides. If you do this option, be sure to have a sequence diagram that connects the various class and package diagrams together showing how components interact together to make a system.
Hope that helps. I am sure others will have different thoughts. At the end of the day, as long as people readily understand what you are modelling, you will have generated good UML.
"My karma ran over your dogma." - Anon
It depends on the overall delegation of work in your system across tiers. Usually, transfer objects live in the domain model.
> The persistence tier uses them for database operations, usually in a vendor-specific way. If you are selecting from a database, then usually the DAO will create the TO to pass to the domain model
> The presentation tier will accept user input (normally HTTP POST form values) and then instantiate the appopriate transfer object. (If you want to really separate responsibilities, also implement the Command pattern, which is assembled by the controller in the presentation tier). Thus, TO's can be created in the presentation tier after parsing and passed to the domain model for work.
> Finally, since TO's "live" in the domain model, they can be created here, though usually only by other domain model objects.
So... there is no one answer. If you are parsing user requests into TO's, do it in the presentation tier, ideally in a controller class. If you are retrieving data via a select, do it in the persistence tier. If the object is simply dependent on other business objects and is not in response to user requests or database queries, create it in the domain model tier.
For the instance you are describing (creating a TO for a database insert), the TO would either be created in the domain model (if the result of some other business process) or originally created in the presentation tier (if it was generated by parsing a user request).
Hope that helps.
- Saish
