Guidelines for UML design

1) Use rational approach for UML in Star UML.

2) Design should be based on FS and FS only.
Anything that you plan to introduce which is not there in the FS should find its
way into the FS.
3) Class Diagram Guideline:
Data model should include all of the following
1. Domain objects and associated value objects
2. Domain object keys
3. Documentation
Services model should at least include
1. Class Diagram
2. Domain services
3. Repositories
4. Specifications (which work on domain objects to perform field level
validations)
5. Assemblers
6. DTOs
7. Application services
8. Business policies (which perform validations for a specific use case)
9. Documentation
Color Code your classes according to below table:
The classes identified in the analysis phase will be fine tuned in this phase
1. New attributes may be identified or attributes may be moved across
classes in this phase
The inter class relationships will evolve in this phase
1. Inheritance
2. Association
3. Navigability
Packaging of the classes will be fine-tuned here
1. Inter-package dependencies to be minimized and localized.
2. If there are a few classes which depend on another package, move the
classes to a different package
3. A well defined package diagram will ease the impact analysis

4. Draw package dependency diagrams and color code them.

S.
No Entity
1 Domain Object
Domain Object
2 Key
3 DTO
4 Component
5 Response
Domain
6 Service
Application
7 Service
8 Repository
9 Enumerations
10 Assemblers
11 Specification
12 BusinessPolicy
13 Interface
Strategy/Factor
14 y
15 Datatype

Color

Red
Green Blue
255
128
128
255
128
192
255

0
128
192
255

0
255
192
255

255

128

255
255
255
128
128
0
0

128
128
255
255
128
128
0

255
0
0
255
0
255
160

64
255

128
128

128
192

Factory classes will emerge in this phase

1. Generating objects for similar classes (typically returning the
interface instead of the actual underlying implementing class)
2. This will address the extensibility non-functional requirement
Avoid Deep Class hierarchies : Depth of the class hierarchy will have an
impact on performance and also complicate the design of the system
Class diagrams with hanging classes denote lack of clarity in design
1.
The least a class should have is a dependency or instantiates
relationship with some other class
Class diagrams are normalized
1. Classes should not have duplicate information (denormalized)
2. Use common datatype classes for things like Address, Money
The class diagrams should have compact classes i.e. the attributes should not
be too many that they stand out like a sore thumb in the diagram
Use accessor/mutator methods (java bean style) for data members unless the
class is a pure structure (holding only data)
Use association classes
Do not be too bothered about the database representation when drawing
class diagrams , OR Mapping tools can help ease the transition from object to
relational model
Number your multiplicity. This helps the database team figure our how many
columns to put for a table
Name your associations as an aggregated association will be generated as an
attribute
If a class has an association with another class, the same need not be shown
as an attribute in the class
Keep the documents i.e. Use cases in sync with the code. Time spent on the
same saves a whole lot of time later in the application life cycle.
Follow a consistent naming convention :
1. Use the Sun naming standards as a guideline for attributes and classes
2. Ensure that all attributes are marked as private
3. Understand the difference between association & the uses
relationship
4. Re-use models.

5. The model should be clear and precise and it should show all
relationships
Do not hand edit relationships in the code, change the model instead

Code has to be generated from the Model

New Attributes or classes need to be added to the analysis model and not the
design model

Break model into control units for ease of versioning and collaboration
How to use control
units.docx

Refer below to UML Anti patterns ppt.

UML AntiPatterns
v0.1.pptx

4) Sequence Diagram (showing all relevant sequences for an use case)

Is in time ordered sequence

At the design time, method granularity is fine tuned with the help of
these diagrams
If the developer cannot get a thorough understanding since the
methods are too coarse grained, then refactor the methods to have
smaller well defined functionality
Draw sequence diagrams for use cases which need them.
For e.g. if there are 5 trivial maintenances, we need not draw the
diagrams for all. Document that the sequence diagrams can be
referred from 1 specific one
Sequence diagrams help identify bottlenecks in the code.
If a temporary object is being used multiple times, then removing the
same can be done at the design phase instead of a later benchmark or
performance tuning stage
Sequence diagrams have to be complete
A programmer should be able to use the sequence diagrams and
understand the code

Documentation Guideline
5) Documentation (java doc) for each class/method/attribute is mandatory

Documentation for App layer:

For DTOs always link the entity which it is representing.
DTO attributes must have link to their respective entity
attributes.
Assembler should have link both to entity and DTO.
Information objects must have proper documentation.
Application service should have proper explanation.
Methods of application service must have small examples.

All method level documentation should include a pseudo code or

algorithm showing how the method works. It has to be as detailed as
possible and should allow the developer to code the method without
asking the designer.

Domain Layer Documentation :

Business Policy must have proper explanation.
Specification should cover all validations.
Domain Service must have brief explanation.
Domain Service methods should have little information.
Enumeration Documentation :
Enumeration must have proper explanation, as why it is
introduced.
Enumeration Literal must have detailed explanation, if possible
give examples.
Service Documentation for actual Processing:
Please provide necessary examples.
Miscellaneous :
Do Not start Documentation with lowercase.
Do not start a new sentence with lowercase
Please go through the documentation that you have written and
correct the following or get it corrected by someone who knows
English:
o Grammatical mistakes
o Spelling mistakes
o Sentence construction
o Case sensitivity
For all attribute level javadocs the following style should be followed
This attribute denotes.