Applying UML 2 - Pradžiadonatas/PSArchitekturaProjektavimas/Library/UML/2006... · Applying UML 2:...

Applying UML 2:Best Practices and Future Perspectives

Darius Silingas, Ph.D.

Principal Trainer for MagicDraw UML

No Magic, Inc.

Kaunas, Lithuania

darius.silingas@nomagic.com

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

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

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

• 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%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

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.

Reader

Reservation

Return

Penalty

Category

is given for11

inactivates11

classified by

1..*0..*

grouped by0..*

given for overdue

performs

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>>

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

Top-Level Implementation in UML 2 (1)

<<component>>

PersistenceService

<<component>>

NotificationService

<<component>>

ReaderWUI

<<component>>

ReaderSessionEJB

<<component>>

LibrarianGUI

<<component>>

LibrarianSessionEJB

NotificationByEmail

LibrarianSession

LibrarianSessionHome

ReaderSessionHome

NotificationBySMS

ReaderSession

TitleManager

TitleSearch

ReaderManager

LoanManager

ReservationManager

<<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>>

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

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

Penalty

Package Dependency Diagram

magiclibrary

(com.nomagic)

<<user interface>>

domain

<<domain>>

service

<<bus ines s logic>>

persistence

<<pers is tence>>

<<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

ServiceFactory

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

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

<<implement>>

<<create>>

<<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 ]

<<control>>

: NotificationService

<<boundary>>

: ReaderProfile

<<control>>

: LoanManager

: Reader <<entity>>

: Loan

cancelReservation()3:

inactivate()4:

getWaitingOrder5:

notifyUser(-)6:

select rezervations for canceling1:

cancelReservations()2:

[for each reservation ]

$$ 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>>

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)

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

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.

Reader

Reservation

Return

Penalty

Category

is given for11

inactivates11

classified by

1..*0..*

grouped by0..*

given for overdue

performs

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

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

-numberOfPages : int

-published : date

-ISBN : String

-edition : int

Penalty

-suspendedUntil : date

-description : String-price : float

-title : String

AudioRecord

-released : date

-artist : String-label : String

Category

-description : String-name : String

-overdueLoan1

-categories

-reader

-childs

-parent

-loaner1

XML Schema Model (PSM)

<<XSDcomplexType>><<XSDsequence>>

Penalty

<<XSDelement>>-suspendedUntil : dateTime

<<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

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

<<XSDelement>>-price : float

<<XSDelement>>-book

<<XSDelement>>

-childs

-parent

<<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

-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

Measurable

<<getter>>+getLength() : float

-s tart

-points

Naming convention indicates method purpose,

thus stereotype can be hidden

Trivial conventional methods, e.g. setters and

getters, toString(), can be hidden

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

MeasurableShape

Measurable

+getLength() : float

-x : int-y : int

Polygon

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

+hasPoints () : int

-points

-s tart

Associations with roles

and multiplicities can be

converted into attributes

-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

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

-resolvedBy

-rolesInProjects

-assignedProject

-registeredBy1

-assignedTo

�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]

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

-registeredBy

-assignedTo

-assignedProject

-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

Specification

Project

contains

references0..*

contains

references

hashas

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

runner

textui swingui awtui

extensionsframework

Top-Level Package Dependency Diagram

runner

textui swingui awtui

extensionsframework

Presentation Layer

CoreExecution Additions

Overview of JUnit Package junit.framework

framework

(junit)

Tes tCase

Assert

Tes tResult

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()

(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

Class Relationships Diagram

Attribute

-dateRegis tered : Date-description : String

-attributes : Map

-title : String

-price : float

Category

ItemSchema

-categories1..*

-s chema1

-attributes

-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

-title : String

AudioRecord

-released : date

-published : date

-ISBN : String

-edition : int

ItemCollection

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

-title : String

AudioRecord

-released : date

-published : date

-ISBN : String

-edition : int

-children

Applying GOF Design Pattern Visitor

ItemCollection

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

-title : String

AudioRecord

-released : date

-published : date

-ISBN : String

-edition : int

-children

ItemCollection

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

ItemVisitor

+visit( type : ItemCollection )

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

-title : String

+accept( visitor : ItemVisitor )

AudioRecord

-released : date

-published : date

-ISBN : String

-edition : int

-children

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

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

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

-published : date

-ISBN : String

-edition : int

Penalty

-suspendedUntil : date

-title : String

AudioRecord

-released : date

Category

-description : String-name : String

-overdueLoan1

-categories

-reader

-childs

-parent

-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>>

<<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>>

-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>>

<<FK>>0..*

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, …

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, …

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!

darius.silingas@nomagic.com

http://www.magicdraw.com

Applying UML 2 - Pradžiadonatas/PSArchitekturaProjektavimas/Library/UML/2006... · Applying UML 2:...

Documents

Conceptual Model or Domain Models Chapter10 Applying UML and pattern

NJIT Designing for Visibility Chapter 19 Applying UML and Patterns Craig Larman

Best Practices for Applying UML, Part I - No Magic Practices for Applying UML, Part I ... They are also a starting point for the design level ... You can decompose activity diagram

1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman

Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman

Free Mini Course: Applying UML 2.0 with MagicDraw

Drawing System Sequence Diagrams Chapter 10 Applying UML and Patterns Craig Larman

1 Chapter 6: Use Cases Chapter 6 in Applying UML and Patterns Book

Last lecture Chapter 1, 2, 3 and 4 Applying UML and Patterns -Craig Larman

Applying Learner-Centered Design Principles to UML Sequence Diagrams - WordPress… · 2018-02-22 · Applying Learner-Centered Design Principles to UML Sequence Diagrams Debra VanderMeer,

Inception Chapter 4 Applying UML and Patterns -Craig Larman

Domain Models Chapter 9 Applying UML and Patterns -Craig Larman

Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman

1 From UML (Fondue) to COOPN An iterative approach applying MDA techniques

1 On To Object Design Chapter 14 Applying UML and Patterns -Craig Larman

USE CASES Ch 6 in Textbook ( Applying UML & Patterns )

Chapter 16 UML Class Diagramsdis.um.es/~jnicolas/CSW/transparencias/Capitulo01p03LarmanDiagClases.pdf · Chapter 16 UML Class Diagrams Larman, C. “Applying UML and Patterns”

Overview: Guide for applying RM-ODP with UML Profile for EDOC

NJIT Applying GOF Design Patterns Chapter 26 Applying UML and Patterns Craig Larman Presented By : Naga Venkata Neelam

Applying Learner-Centered Design Principles to UML ...pdfs.semanticscholar.org/8a30/abf45f42a0786c1a3fd155c75032cf9a261c.pdfUnified Modeling Language (UML) is an ISO standard graphical