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 following1. Domain objects and associated value objects2. Domain object keys3. Documentation Services model should at least include1. Class Diagram2. Domain services3. Repositories4. Specifications (which work on domain objects to perform field level validations)5. Assemblers6. DTOs7. Application services8. 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 phase1. 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. Inheritance2. Association 3. Navigability Packaging of the classes will be fine-tuned here1. 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 analysis4. Draw package dependency diagrams and color code them.

S. NoEntityColorRedGreenBlue

1Domain Object255128128

2Domain Object Key25500

3DTO128128255

4Component192192192

5Response255255255

6Domain Service0255128

7Application Service255128255

8Repository2551280

9Enumerations2552550

10Assemblers128255255

11Specification1281280

12BusinessPolicy0128255

13Interface00160

14Strategy/Factory64128128

15Datatype255128192

Factory classes will emerge in this phase1. 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 design1. 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 classes2. Ensure that all attributes are marked as private3. Understand the difference between association & the uses relationship4. 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

Refer below to UML Anti patterns ppt.

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 Guideline5) 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: Grammatical mistakes Spelling mistakes Sentence construction Case sensitivity For all attribute level javadocs the following style should be followedThis attribute denotes.

UML Patterns

1Safe Harbor StatementThe following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decision. The development, release, and timing of any features or functionality described for Oracles products remains at the sole discretion of Oracle.AgendaUML Patterns & Anti-Patterns3IntroductionRelationships are often not clearly understood and lead to models which are correct programmatically but incorrect semanticallyUML Patterns are best practices for commonly encountered problemsAnti-Patterns are common mistakes for commonly encountered problemsUML Pattern & Anti Pattern AssociationDiagram 1 is incorrectAssociation is shown with Currency Linkage and an array of currencyLinkage is also shown in currency packageDiagram 2 is more accurateIt should that CurrencyPackage has multiple currenciesThis is not a completely accurate diagram since the currency package itself could be an association class

Anti-PatternPatternUML Pattern - CompositionSubtle difference between the 2 diagramsBoth diagrams will create the right source codeHowever diagram 2 is more accurate as it says that Balances are owned by Account Balances cannot exist by themselvesIf an Account is removed all instances of the Balances would be too.

Anti-PatternPattern6UML Anti-Pattern - AggregationSubtle difference between the 2 diagramsBoth diagrams will create the right source codeAggregation is considered a placebo in UML and need not be used.It is not incorrect but its not necessary

Anti-PatternPattern7UML Pattern & Anti pattern Self AssociationUse self associations for things that involve references to instances of the same classDiagram 1 shows a bundled product offeringDigram 2 shows that a customer can have 0 to many relatedCustomers The diagram 3 shows the anti-pattern This is the data model and not the object modelDiagram 1 will also translate to the same data model as diagram 3 though diagram 1 is correct

Anti-PatternPatternUML Pattern Association ClassesAssociation Classes are used to qualify relationshipsIn this case a Customer is related to another Customer and this relationship is qualified by the relationship name

UML Anti Pattern Association ClassesThe above depicts the same information as the previous diagramBoth will generate similar codeBut the relationship is not clear from the above

Project DocumentHow To Use Control Units. Design Document

Last update: 3-Aug-10 11:34 AM6Document Revision HistoryRev#DateAffected SectionAuthor

102-Aug-10Initial DesignPradeep Kumar

IntroductionObjectiveThe objective of this document is to let users how to use the control units in starUML. As with the use of these control units multiple users can work together on a single uml project simultaneouly.Deposit uml breakdown

Figure 1 deposit breakdown

ParticipantsEach Module is divided into a single Model. If any user wishes to use a new Module into this system, then he can add a new Model.

Now, lets understand, what is a control unit?

It may be necessary to save a part of a project or unit as a separate unit. For instance, when many developers are working on the project together, the project can be divided into many units and managed by tools like Microsoft Visual SourceSafe or CVS. Only Package, Model and Subsystem elements can be saved as units.

For more use staruml help.Procedure for Creating New Unit:1.Select an element (package, model or subsystem) to make into a unit.

2.Right-click and select the [Unit] -> [Separate Unit] menu.

3.At the Save dialog box, enter the unit file name and click the [Save] button.

4.The selected element is saved as a unit.

Each Model is further divided into three projects : Say for example DemadDeposit :1.com.ofss.fc.add.dda2.com.ofss.fc.domain.dda3.com.ofss.fc.enumeration.dda

As these three projects are tightly coupled to each other, A control unit can be created for a package, Model, subsystem.

Its always advicable to make control units of these projects.

When a control unit is created, then a square sign appears on the package.

Inside a project also, the control units can be created, and its always good to have these control units, as they allow multiple users to work on single uml at a time. Using more control units, chance of conflict can be avoided.

Always save your control unit in the respective folder.

In eclipse it looks like :

Points need to be taken care of:

1. Always use eclipse for checkin.2. Before checkin, make sure you already have backup of you changes.3. Before committing, always take update, and reopen the uml file with updates.4. If the uml file opens without any error, then only commit your changes.5. After committing your changes, if any conflict, report other team members.6. Always use Model explorer to add any class in the Project.7. While renaming or deleting any file please make sure its refrences also get modified.8. Never uncontrol a control unit.9. Anything related to a project must lie in its respective package, whether its a class, class diagram or sequence diagram etc.

For any help contact

Omkar Prabhune : omkar.prabhune@oracle.comBhakti Bhandarkar : bhakti.bhandarkar@oracle.comPradeep Kumar : p.pradeep.kumar@oracle.com