Applying UML 2 - Pradžiadonatas/PSArchitekturaProjektavimas/Library/UML/2006... · Applying UML 2: Best Practices and Future ... • Most of presented best practices apply to modeling

Applying UML 2:Best Practices and Future Perspectives

Darius Silingas, Ph.D.

Principal Trainer for MagicDraw UML

No Magic, Inc.

Kaunas, Lithuania

[email protected]

(c) 2006, No Magic, Inc. 2

Disclaimer

• This class is NOT– Introduction to applying UML

– Overview of UML 2

– Concise overview of specific method

• Presented best practices are derived mostly from software development

• Most of presented best practices apply to modeling using UML tool

• Best practices are always questionable


Contents

1. UML and Software Development Processes

2. 12 Best Practices for Applying UML

3. UML 2 Diagram-Specific Guidelines

4. Industry Trends and Future Perspectives

1. UML and Software Development Processes

A brief discussion on the role of UML in different software development

processes


Using UML in Software Workflows

Implementation architecturePackage structureInteraction scenariosDetailed class and data modelsUser interface “maps”

Code generation from UMLVisualization of code structureModel transformationsCode model analysis

Test case action flowsTest data object structuresInteractions for test scenarios

Domain analysis modelVisual concept dictionaryUse case scenariosActivity trails


Software Development Processes

UMLRequirements

Design

Testing

Programming

Heavyweight processes

– RUP, ITIL, CMMI

Emphasize the first two workflows

Lightweight processes

– Agile, XP, Scrum, Lean, …

Emphasize the last two workflows


The Role of UML in Different Processes

RUP

Advocates UML-centric approach to software design and UML tool usage

Agile

Advocates informal modeling and using whiteboards, paper, and simple drawing editors


Why Best Practices for Modeling Are Important?

– Modeling is the core of modern software development

• Regardless of what process is applied

– Successful software development requires efficient modeling

��We need to share best practices!We need to share best practices!We need to share best practices!We need to share best practices!

Did You Know?

Software Development magazine Salary Survey 2005 has surveyed over 4000

software developers and managers and has identified that the MOST important skills

needed to produce quality projects and products are architecture modeling and design

(59% of the staff and 56% of the managers indicated this). The survey ranked this

higher than programming, QA, testing, and requirements management.

A fool doesn't learn from his own mistakes

A wise man learns from mistakes of others

2. 12 Best Practices for Applying UML

Introspecting modeling problems and suggesting solutions how to model

efficiently


Best Practice #1

�Apply a subset of UML relevant to your

role

• Paretto Principle: 80% of users will use 20% of UML notation


Application of UML Modeling Skill Sets

Business Analysts– Model business processes

– Capture user desires

– Perform domain analysis

– Model enterprise architecture

Data Designers– Design info data structures

– Introspect existing databases and XML schemas

– Transform OO class model to DB and XML schemas

– Generate DB tables or XML schemas from PSM models

System Architects– Apply UML for different

architectural views

– Transition system models from business models

– Manage modeling teamwork

Developers– Define package structure

– Prepare detailed class models

– Model interactions

– Visualize deployment

– Reverse and visualize code


Survey on Usage of UML 1.x Diagrams91,63%

76,01%73,43%

47,50%

41,14% 39,37%35,91% 34,70%

30,35%27,94%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

Cla

ss

Sequ

ence

Use

cas

e

Act

ivity

Com

mun

icat

ion

Obj

ect

Stat

e

Pack

age

Com

pone

ntDep

loym

ent


Best Practice #2

�Focus on the most valuable modeling

artifacts

• Analysis model artifacts should be consistently modeled and maintained

• Design model artifacts can divided into:

– High value ($$$)

– Medium value ($$)

– Low value ($)


Domain Analysis

Model domain entities and their relationships using simplified class diagram.

This diagram will serve as a visual dictionary of concepts.

It will also be a starting point for your design-level data model.

Loan

Reader

Reservation

Item

Return

Penalty

Category

is given for11

inactivates11

classified by

1..*0..*

grouped by0..*

1

given for overdue

0..1

1

performs

1

0..*

books

0..*

1


Use Case Model

Register items' return

extension pointsoverdue

Make item's reservation

Register items' loan

Review reader's history

Find item

Penalize for overdue

Librarian

Reader

<<extend>>(overdue)

<<include>>

<<include>>

Identify user roles

Capture user goals

Document use cases and generate reports


Activity Diagram for Use Case Scenarios

Select returned items

Identify reader

Show list ofloaned items

Record return data

Penalize for overdue [overdue]

[on time]

Model activity flows for primary and secondary use case scenarios� Relate use cases to the activity

diagram(s) modeling scenarios

� Use activity decomposition

� Include activity diagrams in use case documentation


$$$ High-Value Design Model Artifacts

• Top-level decomposition of software / hardware

• Top-level package dependency diagrams

• Data model in multiple abstraction levels

• System layer / component / subsystem interfaces

• Interactions implementing main usage scenarios


Top-Level Implementation Architecture

J2EE Application Server

<<artifact>>

JSP pages

<<EJB-JAR>>

EJBServices.jar

<<EJB-JAR>>

EJBEntities.jar

Database Server

<<database>>

MagicLibrary.mdb

Web Client

<<executable>>

Internet Browser

Local Client

<<JAR>>

AdminGUI.jar

TCP/IP

HTTP

JDBC


Top-Level Implementation in UML 2 (1)

data

<<component>>

PersistenceService

<<component>>

NotificationService

<<component>>

ReaderWUI

<<component>>

ReaderSessionEJB

<<component>>

LibrarianGUI

<<component>>

LibrarianSessionEJB

NotificationByEmail

LibrarianSession

LibrarianSessionHome

ReaderSessionHome

NotificationBySMS

ReaderSession

TitleManager

TitleSearch

ReaderManager

LoanManager

ReservationManager



data

<<executable>>

MagicLibrarian.exe

<<artifact>>

deployment/jsp

<<component>>

LibrarianGUI

<<component>>

PersistenceService

<<artifact>>

data.jar

<<artifact>>

ReaderEJB.ear

<<component>>

NotificationService

<<artifact>>

persistence.jar

<<artifact>>

notification.jar

<<artifact>>

LibrarianEJB.ear

<<component>>

LibrarianSessionEJB

<<artifact>>

deployment/servlet

<<component>>

ReaderSessionEJB

<<component>>

ReaderWUI

<<database>>

Library DB

<<manifest>><<manifest>>

<<manifest>>

<<manifest>>

<<manifest>> <<manifest>><<manifest>>

<<manifest>>

<<manifest>>



J2EE App Server

deployment/servletLibrarianEJB.ear

ReaderEJB.ear

deployment/jsp

persistence.jarnotification.jar

data.jar

Database Server

Library DB

Web Client

Internet Explorer

GUI Client

MagicLibrarian.exedata.jar

JDBC

10..*

HTTP

10..*

RMI

10..*


Robustness Analysis: Identifying Components

Identify the major components in layered architecture: user interface boundaries, business logic controls, and data entities.

SystemAccessService

NotificationService

ItemSearchForm

ItemBrowser SearchService

ReaderProfile LoanService

LoginDialog

Librarian

Reader

Loan

Item

Penalty

User


Package Dependency Diagram

magiclibrary

(com.nomagic)

gui

<<user interface>>

domain

<<domain>>

service

<<bus ines s logic>>

persistence

<<pers is tence>>

swt

<<framework>>

dbutil

<<library>>


Business Logic Layer Interfaces

service

(com.nomagic.magiclibrary)

SearchService

+findItems( query : String, cateory : Category ) : List

+findUsers( query : String ) : List+findItems( query : String ) : List

ReservationService

+makeItemReservation( customer : Customer, item : Item ) : Loan+canceltemReservation( reservation : Loan ) : void

AdministrationService

+updateCustomer( customer : Customer ) : Customer+removeCustomer( customer : Customer ) : boolean

+addCustomer( customer : Customer ) : Customer

+addItem( item : Item, categories : List ) : Item

+removeItem( item : Item ) : Item+updateItem( Item : Item ) : Item

RegistrationService

+registerReturned( loan : Loan ) : Loan+registerLoaned( loan : Loan ) : Loan

RMIAdministrationService

RMIReservationServiceRMIRegistrationService

RMISearchService

rmi

ServiceFactory

+getAdministrationService() : AdministrationService+getRegistrationService() : RegistrationService

+getReservationService() : ReservationService+getSearchService() : SearchService

<<implement>>

<<implement>>

<<create>>

<<implement>>

<<implement>>


Interaction Diagram for Implementing Use Case

Model interactions for use case scenarios in order to find out new methodsin existing classes or new classes for specific responsibilities.

[for each reservation ]

loop

<<control>>

: NotificationService

<<boundary>>

: ReaderProfile

<<control>>

: LoanManager

: Reader <<entity>>

: Loan

Login

ref

cancelReservation()3:

inactivate()4:

getWaitingOrder5:

notifyUser(-)6:

select rezervations for canceling1:

cancelReservations()2:

[for each reservation ]

loop

Login

ref


$$ Medium-Value Design Model Artifacts

• Structure of UI classes

• UI screen transition schema

• Reusable implementation solutions

• Logic of complex algorithms


Structure of Web UI Classes

<<client page>>

UserLogin

<<server page>>

Login

<<server page>>

FirstLoad

<<client page>>

IncorrectLogin

<<client page>>

MemberPage

<<form>>

LoginForm

<<redirect>>

<<submit>>{parameters = LoginID, Password}

<<build>>

<<build>><<builds>>


UI Dialog Map


Implementation of Complex Algorithms

x(j+1) = temp

temp = x(j)

x(j) = x(j+1)

j = i

i = 0

i++

swap x(j), x(j+1)

j++

sort array x

[j < size of x]

[x(j) >= x(j+1)]

[i >= size of x-1]

[x(j) < x(j+1)]

[i < size of x-1]

[j >= size of x]


$ Low-Value Design Model Artifacts

• Detailed implementation-level class model

• Dependency diagrams for “deep” packages and classes

• Detailed user interface models

• Interaction diagrams capturing implementation details

• …

– These models change frequently and are difficult to maintain

– It is better to model, implement, and analyze them in IDE tools

– Most of these models can be reversed and visualized in UML


Best Practice #3

�Maintain multiple abstraction levels

Analysis model (CIM)

Design Model (PIM)

Implementation Model (PSM)


Domain Analysis Class Model (CIM)

Model domain entities and their relationships using simplified class diagram.

This diagram will serve as a visual dictionary of concepts.

It will also be a starting point for your design-level data model.

Loan

Reader

Reservation

Item

Return

Penalty

Category

is given for11

inactivates11

classified by

1..*0..*

grouped by0..*

1

given for overdue

0..1

1

performs

1

0..*

books

0..*

1


Detailed Data Class Model (PIM)

Create detailed class diagrams to capture your OO data model.

Later you will be able to transform them into executable code – database DDL scripts, XML schemas, Java code, etc.

Reader

-firstName : String-lastName : String-birthday : date-email : String

Loan

-dateReturned : date = null-dateLoaned : date = null-dateReserved : date

Book

-numberOfPages : int

-published : date

-ISBN : String

-edition : int

Penalty

-suspendedUntil : date

Item

-description : String-price : float

-title : String

AudioRecord

-released : date

-artist : String-label : String

Category

-description : String-name : String

-overdueLoan1

-categories

1..*

0..*

-reader

1

-book

1

-childs

0..*

-parent

0..1

-loaner1


XML Schema Model (PSM)

<<XSDcomplexType>><<XSDsequence>>

Penalty

<<XSDelement>>-suspendedUntil : dateTime


Loan

<<XSDelement>>-dateReserved : dateTime

<<XSDelement>>-dateReturned : dateTime<<XSDelement>>-dateLoaned : dateTime


Reader

<<XSDelement>>-birthday : dateTime

<<XSDelement>>-firs tName : s tring<<XSDelement>>-las tName : s tring

<<XSDelement>>-email : s tring


Category

<<XSDelement>>-description : s tring<<XSDelement>>-name : s tring


Book

<<XSDelement>>-description : s tring<<XSDelement>>-title : s tring

<<XSDelement>>-price : float

<<XSDelement>>-book

1

<<XSDelement>>

-childs

0..*

-parent

0..1

<<XSDelement>>

-loaner1

<<XSDelement>>

-overdueLoan1

<<XSDelement>>

-categories1..*


Best Practice #4

�Choose appropriate level of detail

• Overloaded diagrams are difficult to read and understand


Common Failure: Too Detailed Models

• Detailed models are difficult to understand and maintain– Such models are rarely used

– It is common to give up their maintenance, thus they become worthless since they do not correspond to the actual code

• It is very important to choose appropriate level of details– Do not model / show irrelevant details

– Show only the most important associations


Different Levels of Details: Sample 1

Polygon

+getPoint( index : int ) : Point

+Polygon( points : Lis t )

+getLength() : float+toString() : String

+hasPoints () : int

MeasurableShape

+compareTo( obj : Object ) : int

Point

-x : int-y : int

+equals ( obj : Object ) : boolean

+Point( x : int, y : int )

+setX( x : int ) : void+setY( y : int ) : void

+toString() : String

+getX() : int+getY() : int

+Line( s tart : Point, end : Point )

+getLength() : float+toString() : String

+getStart() : Point+getEnd() : Point

Line

Measurable

<<getter>>+getLength() : float

-s tart

-end

-points

2..*

Naming convention indicates method purpose,

thus stereotype can be hidden

Trivial conventional methods, e.g. setters and

getters, toString(), can be hidden



Line

+Line( s tart : Point, end : Point )+getLength() : float...

MeasurableShape


Measurable

+getLength() : float

Point

-x : int-y : int

...

Polygon

+getPoint( index : int ) : Point+getLength() : float

+hasPoints () : int

...

-end

-points

2..*

-s tart

Associations with roles

and multiplicities can be

converted into attributes



Line

-s tart : Point-end : Point

+Line( s tart : Point, end : Point )+getLength() : float...

MeasurableShape


Measurable

+getLength() : float

Polygon

-points : Point [2..*]

+getPoint( index : int ) : Point+getLength() : float

+hasPoints () : int

...

Attribute and operation

compartments can be

suppressed if you need to see

only hierarchy and other

relationships between classes



Line

Point

MeasurableShape

Polygon

Measurable

-s tart -end -points 2..*


Best Practice #5

�Model with style

• Modeling style includes:

– Naming conventions

– Layout conventions

– Choosing appropriate diagrams

– Modeling & design principles

– …

• Modeling style should be standardized for company or project!


Diagram Layout

• Use automated layout tools

• Relative positions of elements are important

• Simple layout functions applied to selected elements in a diagram are most helpful– Make sub trees of generalizations, realizations, association;

– Make same width | height;

– Distribute space evenly;

– Align elements to the top | bottom | left | right;

– Route paths orthogonally.


Bad Modeling Style

Defect

-description : char [1..*]-dateRegistered : date

-title : char [1..*]

-priority : int

-id : long

Resolution

-description : char [*]

-dateResolved : date-type : int

Project

-title : char [1..100]

ProjectManager

Developer

-name : char [1..*]-emai : char [5..*]

Programmer

TesterRole

-resolvedDefect

1

-resolvedBy

1

-rolesInProjects

0..*

-assignedProject

1

-registeredBy1

-assignedTo

1

�Different element sizes

�Diagram is not symmetric

�Long, bended, crossing lines

�Horizontal, ungrouped generalization links

�Uneven distribution of space


Better Modeling Style

TesterProgrammer ProjectManager

Project

-title : char [1..100]

Role

Resolution

-description : char [*]

-dateResolved : date-type : int

Developer

-name : char [1..*]-emai : char [5..*]

Defect

-description : char [1..*]-dateRegistered : date

-title : char [1..*]

-priority : int

-id : long

-resolvedBy1

-rolesInProjects

0..*

-registeredBy

1

-assignedTo

1

-assignedProject

1

-resolvedDefect1


Some Modeling Style Rules

• Do not overload diagrams with irrelevant details

• Split large diagrams into multiple smaller diagrams

– Diagram should contain 7±2 elements

• Use colors to identify elements of different type

• Try to maintain symmetry

• Model generalizations and realizations vertically

– Child / implementing class should be below parent / interface

• Model associations and dependencies horizontally

– Recommended direction – left to right

• “The Elements of UML 2.0 Style” by Scott W. Ambler�http://www.agilemodeling.com/style/


Best Practice #6

�First focus on model, only then on

diagrams

• UML tools differentiate between model & view:

– Model elements may be reused in multiple diagrams with different level of detail and presentation properties;

– Model elements may not be included in any diagrams.


MagicDraw UML Tool Concepts

Code Engineering Set

ElementDiagram Symbol

Module

Symbol Properties

Model

Specification

Project

Code

has

contains

1

references0..*

contains

0..*

1

contains

0..*

contains

0..*

uses

1..*

10..*

references

hashas

has


Model & View

• Views always have an assigned model element

Model Data (Browser) View (Diagram)

Understanding the relationships between data and views will saveyou MANY headaches using UML tool.

• Data entities may have multiple independent view


Best Practice #7

�Reuse model elements

• Model elements can be reused in multiple diagrams:– Assign class as instance type in object diagrams;

– Call defined class operations in sequence diagrams;

– Assign class and state to data flow elements in activity diagrams;

– Represent existing actors or components by activity swimlanesin order to capture responsibilities;

– Define signal class for triggering transitions between states;

– Decompose and reuse activities, interactions, state machines, …

– …

• The power of UML is its ability to specify consistent integrated models!


Reusing Modeling Elements in Multiple Diagrams

: Open Enrollment Service

Send AutomatedEmail Announcement

Publish info

: Marketing : Trainer

Provide agenda : ClassInfo

[Announced]

Closed for Registration

Open for Registration

Running

Finished

Canceled

Announced

Announce Class

Marketing

Trainer

Update Website

Notify Local Customers


Best Practice #8

�Organize models using notes, hyperlinks, and content diagrams

• Problem:– Large models become cumbersome to understand and navigate.

• Solution:– Define conventions for model package structure;

– Use notes for explanations;

– Define hyperlinks from model elements to other model elements, diagrams, external files, URLs;

– Create content diagrams for showing diagram relationships.


Organizing Models: Content Diagram


Requirements Definition

Analysis andDesign

Implementation

Testing

Software Development Activities Artifacts

Project Plan

Requirements Specification

Design Specification

Software ProductVersion

Software APIDocumentation

Double click on the shape to drill in

Hyperlinks to documents on your disk can be added for model elements

Diagram describes typical software development process activities and artifacts.

Software Development Process

New iteration

Needs design change or refinement

Implementationcomplete

Needs fixor improvement

Analysis anddesign complete

Requirements changed

Requirements defined

Organizing Models: Using Notes and Hyperlinks


Best Practice #9

�Use reverse engineering for code

analysis and visualization

• Code engineering within modeling environment is an effective means for retrieving model structure and visualizing it in UML

– A picture is worth a thousand words!


Source Code Analysis Using UML

• After you are done with source code, you can analyze its structure using UML models– Model can be reversed from source code using reverse

engineering tools

– UML tools include model visualization tools that help to create diagrams from reversed model quickly

– For model analysis, it is common to use dependency diagrams

• Possibility to track related elements

• Calculation of various code analysis metrics


Top-Level Package Dependency Diagram

junit

runner

textui swingui awtui

extensionsframework


Top-Level Package Dependency Diagram

junit

runner

textui swingui awtui

extensionsframework

Presentation Layer

CoreExecution Additions


Overview of JUnit Package junit.framework

framework

(junit)

Tes tCase

Assert

Tes tResult

Tes t

...

Tes tSuite

Tes tLis tener

...

AssertionFailedError

Tes tFailure

ComparisonFailure

Protectable

...


Core JUnit Classes

Tes tSuite

(junit.framework)

+addTes tSuite( clas s : Clas s ) : void

+run( tes tresult : Tes tResult ) : void

+addTes t( tes t : Tes t ) : void+Tes tSuite( s tring : String )

+countTes tCases () : int

+Tes tSuite()

...

Tes t

(junit.framework)

+run( testresult : TestResult ) : void+countTestCases() : int

Assert

(junit.framework)

+as s ertNotSame( object : Object, object1 : Object ) : void

+as s ertEquals ( object : Object, object1 : Object ) : void

+as s ertSame( object : Object, object1 : Object ) : void

+as s ertEquals ( b : boolean, b1 : boolean ) : void+as s ertEquals ( f : float, f1 : float, f2 : float ) : void

+as s ertNotNull( object : Object ) : void+as s ertEquals ( i : int, i1 : int ) : void

+as s ertNull( object : Object ) : void

+as s ertFals e( b : boolean ) : void+as s ertTrue( b : boolean ) : void

+fail( s tring : String ) : void+fail() : void

...

+run( tes tresult : Tes tResult ) : void

+Tes tCase( s tring : String )+countTes tCases () : int

+Tes tCase()

...

Tes tCase

(junit.framework)

-fTes ts

0..*


Class Relationships Diagram

Attribute

Loan

Item

-dateRegis tered : Date-description : String

-attributes : Map

-title : String

-price : float

Category

ItemSchema

-categories1..*

0..*

0..*

-s chema1

1

-attributes

0..*

1

-item1


Class Dependency Diagram Organized by Instability Metric


Best Practice #10

�Apply patterns when modeling with UML

• Patterns are explained using UML diagrams

• Applying analysis & design patterns should be supported by UML modeling tools

• Patterns can be supported for multiple views, abstraction-levels, domains and technologies


Applying GOF Design Pattern Composite

Item


-title : String

AudioRecord

-released : date


Book


-published : date

-ISBN : String

-edition : int

ItemCollection

+getChild( index : int ) : Item+remove( comp : Item )+add( comp : Item )

Item


-title : String

AudioRecord

-released : date


Book


-published : date

-ISBN : String

-edition : int

-children

0..*


Applying GOF Design Pattern Visitor

ItemCollection

+getChild( index : int ) : Item+remove( comp : Item )+add( comp : Item )

Item


-title : String

AudioRecord

-released : date


Book


-published : date

-ISBN : String

-edition : int

-children

0..*

ItemCollection

+accept( visitor : ItemVisitor )+getChild( index : int ) : Item+remove( comp : Item )+add( comp : Item )

ItemVisitor

+visit( type : ItemCollection )

+visit( type : AudioRecord )+visit( type : Book )

Item


-title : String

+accept( visitor : ItemVisitor )

AudioRecord

-released : date



Book


-published : date

-ISBN : String

-edition : int


-children

0..*


Best Practice #11

�Use model analysis tools

• Problem:

– Elements and their relationships can be reused in multiple diagrams

– Modifying an element may have undesirable effect on other elements

– In large projects it is necessary to track changes in model

• Solution:

– Use automated tools for model analysis:

• Tracking used and dependent elements

• Traceability matrices

• Comparing different versions of model


Model Diff

Deleted elements

Modified element – a diagram

Added element


Diagram Diff

Find out modified parts in diagrams!


Best Practice #12

�Apply PIM to PSM transformations

• Avoid modeling detailed PSM manually

• PIM to PSM transformations are automated by UML and MDA tools


PIM � PSM Transformations

OO Data Model

/DDL Model /XML Schema Model

Transformations

PSM

PIM


Detailed Data Class Model (PIM)

Create detailed class diagrams to capture your OO data model.

Later you will be able to transform them into executable code – database DDLscripts, XML schemas, Java code, etc.

Reader

-firstName : String-lastName : String-birthday : date-email : String

Loan

-dateReturned : date = null-dateLoaned : date = null-dateReserved : date

Book


-published : date

-ISBN : String

-edition : int

Penalty

-suspendedUntil : date

Item


-title : String

AudioRecord

-released : date


Category

-description : String-name : String

-overdueLoan1

-categories

1..*

0..*

-reader

1

-book

1

-childs

0..*

-parent

0..1

-loaner1


Relational Database Structure Model (PSM)

<<table>>

Penalty

<<not null>> <<unique>>-fk_Loanid : integer [1]<<not null>>-fk_Readerid : integer [1]-suspendedUntil : datetime<<PK>>-id : integer

<<table>>

Loan

<<not null>> <<unique>>-fk_Readerid : integer [1]<<not null>> <<unique>>-fk_Bookid : integer [1]

-dateRes erved : datetime

-dateReturned : datetime-dateLoaned : datetime

<<PK>>-id : integer

<<table>>

Reader

-firs tName : varchar2-las tName : varchar2

<<PK>>-id : integer

-birthday : datetime-email : varchar2

<<table>>

Book

-des cription : varchar2

<<PK>>-id : integer-title : varchar2

-price : float...

<<table>>

Category

<<not null>>-fk_Bookid : integer [1]-fk_Categoryid : integer-des cription : varchar2

<<PK>>-id : integer-name : varchar2

<<FK>>

1

1

<<FK>>

1

1

<<FK>>

1..*

1

<<FK>>

1

1

<<FK>>0..*

0..1


12 Best Practices

1. Apply a subset of UML relevant to your role

2. Focus on the most valuable modeling artifacts

3. Maintain multiple abstraction levels

4. Choose appropriate level of detail

5. Model with style

6. First focus on model, only then on diagrams

7. Reuse model elements

8. Organize models using notes, hyperlinks, and content diagrams

9. Use reverse engineering for code analysis and visualization

10. Apply patterns when modeling with UML

11. Use model analysis tools

12. Apply PIM to PSM transformations

3. UML Diagram-Specific Guidelines

Additional best practices focused on specific UML 2 diagrams


Use Case Diagram

• A use case should achieve a goal of the end user

• A use case should have well-defined start and end

• Naming conventions– strong verb [attributive] object

• Avoid overusing advanced relationships– <<exclude>>, <<include>>, generalization

• Use Case diagram should be very simple and intuitive!

• Distribute use cases into cohesive packages– Main usage, Administration, etc.

– Show <10 use cases in 1 diagram!


Use Case Diagram (2)

• Assign priorities to the use cases

• Develop activity diagrams for scenarios of complex use cases

• Assign activity diagrams modeling use case scenarios as behaviors of use cases (hyperlink)

• Include text documentation in use case model


Activity Diagram

• Use activity diagrams for use case scenarios

• Use swimlanes for identifying responsibilities

• Use objects/pins for displaying only the most important dataflow items

– Focus is on control flow, not on data flow

• Start activity’s name with verb

• Visualize the algorithms of complex operations with activity diagram (possibly with references to sequence diagrams)


Class Diagram

• Separate analysis, design, and implementation level class models

• Keep precise models of data structures

• Show only important details in diagrams– Attributes and operations compartments can be suppressed or

edited

– Tags, properties, stereotypes, … can be hidden

• Naming conventions:– ClassName [should be a noun]

– attributeName [should be a noun or adjective]

– operationName [should start with verb]

– CONSTANT_NAME


Class Diagram (2)

• Implementation level classes can be reversed from source code mainly for analysis purposes– It is difficult and useless to maintain implementation level diagrams

synchronized with the code

• Each class should have one responsibility– Data encapsulation

– Presentation (GUI, XML, etc.)

– Business logic

• Apply analysis and design patterns

• Assign behavioral diagrams to their classes

• Create class hierarchy and relationships diagrams– You can use visualization tools


Object Diagram

• Informally sketched objects help to find out classes

• Use Object diagram for validating your Class diagrams

• Use Object diagram for modeling test data structures

• Prefer Composite Structure diagram if you need to show inner object relationships for a classifier


Package Diagram

• Apply packages for structuring your models

• Strictly adhere to model packaging conventions

• Keep related classes in one package

• Create package dependency and overview diagrams

– You can use visualization tools

– Avoid stable parts depending on less stable parts

– Avoid cyclic dependencies between packages

• Apply hyperlinks for relating packages to their inner structure diagrams

• Use abstraction dependency between packages modeling the same thing in different abstraction levels


Interaction Diagrams

• Use interaction diagram for assigning responsibilities

• Start discovering implementation classes by sketching draft interaction diagrams

• Prefer sequence to communication diagrams when

using UML modeling tools

• Prefer communication to sequence diagrams when

sketching interactions on a whiteboard

• Model the most important high-level collaborations

• Model low-level interactions if they are frequently reused


Interaction Diagrams (2)

• Use information from structural model

• Update structural model while designing interaction

– Find out new classes and methods

• Show one level of interactions in one diagram

– Create fragments and hyperlinks to cover low level details

• Optimize design by removing interaction bottlenecks

• Place components left-to-right, top-down by interaction

message order


State Diagram

• Model states for important business objects

– Such as order, product, book, …

• Use state diagrams for user interface “roadmap”

– Web pages, frames, dialogs, etc. and events triggering transitions

• Each transition needs specified trigger

• Use composite states when specific event or error can trigger moving to particular state from multiple states


Component Diagram

• Focus on component integration through provided/required interfaces

• Create a separate diagram for showing physical artifact manifestation of components

• Develop profiles with stereotypes defining component types for your projects or organization

• Model inner structure of components using Composite Structure diagram


Deployment Diagram

• List artifact names on deployment nodes

• Indicate communication protocols

• Develop profiles with stereotypes for deployment, and communication types specific to your project(s) or organization


New UML 2 Diagrams

• Composite Structure Diagram– More useful for system modeling

– Apply it when class / component inner structure is ambiguous in classifier view and variations are important

• Merges class & object views

• Interaction Overview Diagram– Equivalent effect can be achieved using activity

diagram with references to interactions

• Timing Diagram– I leave it for real-time modelers …

4. Industry Trends and Future Perspectives

Analysis of current industry trends related to UML role, and indicating

future perspectives for UML in software development and other areas


UML and Industry Trends

Business-Level Modeling:Goals,

Requirements,Workflows

…

Software-Level Modeling:Classes,

Interactions,Components,Deployments

BPMN, EA, DoDAF, …

MDA

Agile, XP, Scrum, Lean,

…


Dangers for UML

• MDA tools use only a small subset of UML

– Use case, class, activity diagrams are most commonly used

• Business modelers think that UML is too complex

– BPMN is in fact a simplified version of UML activity diagram

– On the other hand, BPMN is a flat flow diagram, which does not support integration with data elements, states, etc.

• Agile developers model informally and modify

notation if necessary

– UML tools are rarely used

– Consistent notation is not very important


New Perspectives in Software Development

• Agile Development– Better support for modeling teamwork

– Model-based refactoring

– Test-driven modeling

• Refactoring– Drag & Drop in UML view

– Apply patterns for refactoring

– Visualizing OO metrics, violations of design principles

• Test-Driven Development (TDD)– More efficient modeling unit and acceptance test scenarios

– Simulation of dynamic models

• Service-Oriented Architecture (SOA)– Subset of UML and extension profiles for SOA modeling

– Support of SOA patterns

• Aspect-Oriented Programming (AOP)– Modeling aspects


UML Re-Applied

• The recent trend towards agile methods is demonstrating that visual

modeling is less important to the development of high quality

software than we thought it was 10 years ago. Arguably, the role of

UML is being turned upside down. It’s no longer as valuable a tool

for designing software as we thought it would be – largely because

of disappointing tool support and the move away from Big Design

Up Front methods. It’s increasingly becoming a very useful tool for

business modeling, where the end result will be a new

understanding or a new way of working – which may or may not

involve software. The challenge for modelers is to let go of the world

of software engineering and to explore and embrace the much wider

universe of information systems in the abstract sense.

– Jason Gorman, 2005


UML and Industry Trends

Business-Level Modeling:Goals,

Requirements,Workflows

…

Software-Level Modeling:Classes,

Interactions,Components,Deployments

BPMN, EA, DoDAF, …

MDA

UML Mappings to EA

Agile, XP, Scrum, Lean,

…

Domain-Specific Modeling,

Real-Time Modeling


New Perspectives

Applying UML for Enterprise Architecture

– Zachman, DoDAF, MoDAF, …

Specializing UML for domain-specific modeling

– Creating meta-models using UML profiles

Using UML for modeling systems

– UML profile for SysML + tool support

Tailoring UML for methods & techniques

– Agile practices, TDD, Usage-Centered Design, …

Expanding UML usage in MDA


Book References

– Scott W. Ambler. The Elements of UML 2.0 Style

– Scott W. Ambler. Agile Modeling

– Craig Larman. Applying UML and Patterns

– Erich Gamma et al. Design Patterns

– Robert C. Martin. Agile Software Development

– Martin Fowler. Refactoring


Internet References

• UML @ www.uml.org

• MagicDraw UML @ www.magicdraw.com

• MDA @ www.omg.org/mda/

• Agile Modeling @ www.agilemodeling.com

• Modeling Style Guidelines @ www.agilemodeling.com/style/

• Test-Driven Development @ www.testdriven.com

• JUnit framework @ www.junit.org

Thank You for Attention!

?

Keep In Touch!

[email protected]

http://www.magicdraw.com

Documents

Applying UML 2 - Pradžiadonatas/PSArchitekturaProjektavimas/Library/UML/2006... · Applying UML 2: Best Practices and Future ... • Most of presented best practices apply to modeling