applying uml 2 - pradžiadonatas/psarchitekturaprojektavimas/library/uml/2006... · applying uml 2:...
TRANSCRIPT
Applying UML 2:Best Practices and Future Perspectives
Darius Silingas, Ph.D.
Principal Trainer for MagicDraw UML
No Magic, Inc.
Kaunas, Lithuania
(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
(c) 2006, No Magic, Inc. 3
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
(c) 2006, No Magic, Inc. 5
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
(c) 2006, No Magic, Inc. 6
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
(c) 2006, No Magic, Inc. 7
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
(c) 2006, No Magic, Inc. 8
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
(c) 2006, No Magic, Inc. 11
Best Practice #1
�Apply a subset of UML relevant to your
role
• Paretto Principle: 80% of users will use 20% of UML notation
(c) 2006, No Magic, Inc. 12
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
(c) 2006, No Magic, Inc. 13
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
(c) 2006, No Magic, Inc. 14
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 ($)
(c) 2006, No Magic, Inc. 15
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
(c) 2006, No Magic, Inc. 16
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
(c) 2006, No Magic, Inc. 17
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
(c) 2006, No Magic, Inc. 18
$$$ 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
(c) 2006, No Magic, Inc. 19
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
(c) 2006, No Magic, Inc. 20
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
(c) 2006, No Magic, Inc. 21
Top-Level Implementation in UML 2 (2)
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>>
(c) 2006, No Magic, Inc. 22
Top-Level Implementation in UML 2 (3)
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..*
(c) 2006, No Magic, Inc. 23
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
(c) 2006, No Magic, Inc. 24
Package Dependency Diagram
magiclibrary
(com.nomagic)
gui
<<user interface>>
domain
<<domain>>
service
<<bus ines s logic>>
persistence
<<pers is tence>>
swt
<<framework>>
dbutil
<<library>>
(c) 2006, No Magic, Inc. 25
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>>
(c) 2006, No Magic, Inc. 26
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
(c) 2006, No Magic, Inc. 27
$$ Medium-Value Design Model Artifacts
• Structure of UI classes
• UI screen transition schema
• Reusable implementation solutions
• Logic of complex algorithms
(c) 2006, No Magic, Inc. 28
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>>
(c) 2006, No Magic, Inc. 29
UI Dialog Map
(c) 2006, No Magic, Inc. 30
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]
(c) 2006, No Magic, Inc. 31
$ 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
(c) 2006, No Magic, Inc. 32
Best Practice #3
�Maintain multiple abstraction levels
Analysis model (CIM)
Design Model (PIM)
Implementation Model (PSM)
(c) 2006, No Magic, Inc. 33
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
(c) 2006, No Magic, Inc. 34
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
(c) 2006, No Magic, Inc. 35
XML Schema Model (PSM)
<<XSDcomplexType>><<XSDsequence>>
Penalty
<<XSDelement>>-suspendedUntil : dateTime
<<XSDcomplexType>><<XSDsequence>>
Loan
<<XSDelement>>-dateReserved : dateTime
<<XSDelement>>-dateReturned : dateTime<<XSDelement>>-dateLoaned : dateTime
<<XSDcomplexType>><<XSDsequence>>
Reader
<<XSDelement>>-birthday : dateTime
<<XSDelement>>-firs tName : s tring<<XSDelement>>-las tName : s tring
<<XSDelement>>-email : s tring
<<XSDcomplexType>><<XSDsequence>>
Category
<<XSDelement>>-description : s tring<<XSDelement>>-name : s tring
<<XSDcomplexType>><<XSDsequence>>
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..*
(c) 2006, No Magic, Inc. 36
Best Practice #4
�Choose appropriate level of detail
• Overloaded diagrams are difficult to read and understand
(c) 2006, No Magic, Inc. 37
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
(c) 2006, No Magic, Inc. 38
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
(c) 2006, No Magic, Inc. 39
Different Levels of Details: Sample 2
Line
+Line( s tart : Point, end : Point )+getLength() : float...
MeasurableShape
+compareTo( obj : Object ) : int
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
(c) 2006, No Magic, Inc. 40
Different Levels of Details: Sample 3
Line
-s tart : Point-end : Point
+Line( s tart : Point, end : Point )+getLength() : float...
MeasurableShape
+compareTo( obj : Object ) : int
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
(c) 2006, No Magic, Inc. 41
Different Levels of Details: Sample 4
Line
Point
MeasurableShape
Polygon
Measurable
-s tart -end -points 2..*
(c) 2006, No Magic, Inc. 42
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!
(c) 2006, No Magic, Inc. 43
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.
(c) 2006, No Magic, Inc. 44
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
(c) 2006, No Magic, Inc. 45
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
(c) 2006, No Magic, Inc. 46
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/
(c) 2006, No Magic, Inc. 47
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.
(c) 2006, No Magic, Inc. 48
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
(c) 2006, No Magic, Inc. 49
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
(c) 2006, No Magic, Inc. 50
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!
(c) 2006, No Magic, Inc. 51
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
(c) 2006, No Magic, Inc. 52
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.
(c) 2006, No Magic, Inc. 53
Organizing Models: Content Diagram
(c) 2006, No Magic, Inc. 54
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
(c) 2006, No Magic, Inc. 55
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!
(c) 2006, No Magic, Inc. 56
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
(c) 2006, No Magic, Inc. 57
Top-Level Package Dependency Diagram
junit
runner
textui swingui awtui
extensionsframework
(c) 2006, No Magic, Inc. 58
Top-Level Package Dependency Diagram
junit
runner
textui swingui awtui
extensionsframework
Presentation Layer
CoreExecution Additions
(c) 2006, No Magic, Inc. 59
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
...
(c) 2006, No Magic, Inc. 60
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..*
(c) 2006, No Magic, Inc. 61
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
(c) 2006, No Magic, Inc. 62
Class Dependency Diagram Organized by Instability Metric
(c) 2006, No Magic, Inc. 63
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
(c) 2006, No Magic, Inc. 64
Applying GOF Design Pattern Composite
Item
-description : String-price : float
-title : String
AudioRecord
-released : date
-artist : String-label : String
Book
-numberOfPages : int
-published : date
-ISBN : String
-edition : int
ItemCollection
+getChild( index : int ) : Item+remove( comp : Item )+add( comp : Item )
Item
-description : String-price : float
-title : String
AudioRecord
-released : date
-artist : String-label : String
Book
-numberOfPages : int
-published : date
-ISBN : String
-edition : int
-children
0..*
(c) 2006, No Magic, Inc. 65
Applying GOF Design Pattern Visitor
ItemCollection
+getChild( index : int ) : Item+remove( comp : Item )+add( comp : Item )
Item
-description : String-price : float
-title : String
AudioRecord
-released : date
-artist : String-label : String
Book
-numberOfPages : int
-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
-description : String-price : float
-title : String
+accept( visitor : ItemVisitor )
AudioRecord
-released : date
-artist : String-label : String
+accept( visitor : ItemVisitor )
Book
-numberOfPages : int
-published : date
-ISBN : String
-edition : int
+accept( visitor : ItemVisitor )
-children
0..*
(c) 2006, No Magic, Inc. 66
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
(c) 2006, No Magic, Inc. 67
Model Diff
Deleted elements
Modified element – a diagram
Added element
(c) 2006, No Magic, Inc. 68
Diagram Diff
Find out modified parts in diagrams!
(c) 2006, No Magic, Inc. 69
Best Practice #12
�Apply PIM to PSM transformations
• Avoid modeling detailed PSM manually
• PIM to PSM transformations are automated by UML and MDA tools
(c) 2006, No Magic, Inc. 70
PIM � PSM Transformations
OO Data Model
/DDL Model /XML Schema Model
Transformations
PSM
PIM
(c) 2006, No Magic, Inc. 71
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
-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
(c) 2006, No Magic, Inc. 72
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
(c) 2006, No Magic, Inc. 73
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
(c) 2006, No Magic, Inc. 75
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!
(c) 2006, No Magic, Inc. 76
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
(c) 2006, No Magic, Inc. 77
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)
(c) 2006, No Magic, Inc. 78
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
(c) 2006, No Magic, Inc. 79
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
(c) 2006, No Magic, Inc. 80
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
(c) 2006, No Magic, Inc. 81
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
(c) 2006, No Magic, Inc. 82
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
(c) 2006, No Magic, Inc. 83
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
(c) 2006, No Magic, Inc. 84
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
(c) 2006, No Magic, Inc. 85
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
(c) 2006, No Magic, Inc. 86
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
(c) 2006, No Magic, Inc. 87
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
(c) 2006, No Magic, Inc. 89
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,
…
(c) 2006, No Magic, Inc. 90
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
(c) 2006, No Magic, Inc. 91
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
(c) 2006, No Magic, Inc. 92
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
(c) 2006, No Magic, Inc. 93
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
(c) 2006, No Magic, Inc. 94
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
(c) 2006, No Magic, Inc. 95
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
(c) 2006, No Magic, Inc. 96
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!
?