Upload
teresa-summers
View
231
Download
0
Tags:
Embed Size (px)
Citation preview
Introduction to UML:Structural and Use Case Modeling
2
Software development process has 5 stages
Requirements analysis and definition: Establish the application’s goals and constraints
in consultation with users Design:
Establish the system’s architecture Implementation and unit testing:
Realize the design as a set of programs or program units Unit testing verifies that each unit meets its specification
Integration and system testing: Integrate the program units and test as a complete
system Maintenance:
Correct errors, improve implementation, and enhance the system’s services as new requirements are discovered
3
What is the primary driver of software costs?
Most money and effort spent in testing and maintenance But: 85% of errors are introduced during
requirements analysis and design
4
Background
What are object-oriented (OO) methods?
OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures
In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs
What are the benefits of OO?
OO enhances key software quality factors of a system and its constituent components
What is the rationale for using OO?
In general, systems evolve and functionality changes, but objects and classes tend to remain stable over time
5
Background
Software Quality Factors:Object-oriented techniques enhance key external and internal software quality factors, e.g.,
1. External (visible to end-users)(a) Correctness(b) Robustness and reliability(c) Performance
2. Internal (visible to developers)(a) Modularity(b) Flexibility/Extensibility(c) Reusability(d) Compatibility (via standard/uniform interfaces)
6
Background
OOA, OOD, and OOP
Object-oriented methods may be applied to different phases in the software life-cycle, e.g., analysis, design, implementation, etc.
OO analysis (OOA) is a process of discovery
Where a development team models and under-stands the requirements of the system
OO design (OOD) is a process of invention and adaptation
Where the development team creates the abstractions and mechanisms necessary to meet the system's behavioral requirements determined during analysis
7
Who are users for this system?
How to design a registration management system?
8
How to design a registration management system?
Who are users for this system?
9
What is the role for each user?
How to design a registration management system?
10
How to design a registration management system?
What is the role for each user?
11
Difference between XML and UML
What is XML?
What is UML?
12
XML stands for EXtensible Markup Language
XML was designed to describe data and to focus on what data is. (Widely used in database management)
HTML was designed to display data and to focus on how data looks. (used on WWW)
What is XML?
13
UML stands for Unified Modeling Language In the field of software engineering, UML
is a standardized specification language for object modeling.
UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.
What is UML?
14
• Is a language. It is not simply a notation for drawing diagrams, but a complete language for capturing knowledge(semantics) about a subject and expressing knowledge(syntax) regarding the subject for the purpose of communication.
• Applies to modeling and systems. Modeling involves a focus on understanding a subject (system) and capturing and being able to communicated in this knowledge.
• It is the result of unifying the information systems and technology industry’s best engineering practices (principals, techniques, methods and tools).
What is UML?
15
Unified Modeling Language (UML)
used for both database and software modeling version 1.1 was adopted in November 1997 by
the Object Management Group (OMG) as a standard language for object-oriented analysis and design
Initially based on a combination of the Booch, OMT (Object Modeling Technique) and OOSE (Object-Oriented Software Engineering) methods, UML was refined and extended by a consortium of several companies, and is undergoing minor revisions by the OMG Revision Task Force.
Ivar Jacobson is known as the father of Use Cases.
16
1. Structural Modeling with UMLStructural model: a view of an system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations.
2. Use Case Modeling with UMLuse case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
Topics on UML
17
What you will learn: what the UML is and what is it not UML’s basic constructs, rules and diagram
techniques how the UML can model large, complex
systems how the UML can specify systems in an
implementation-independent manner how UML, XML Metadata Interchange (XMI)
and Meta Object Facility (MOF) can facilitate metadata integration
18
Quick Tour Why do we model? Why do we develop the UML? Foundation elements Unifying concepts Language architecture Relation to other OMG
technologies
19
Modeling is a way of thinking about the problems using models organized around the real world ideas.
A modeling method comprises a language and also a procedure for using the language to construct models.
modeling is the only way to visualize your design and check it against requirements before your crew starts to code.
Why do we model?
20
Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage
complexity Reduce time-to-market for business
problem solutions Decrease development costs Manage the risk of mistakes
Why do we model?
21
Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html
The Challenge
22
Fallingwater: http://www.adelaide.net.au/~jpolias/FLW/Images/FallingWater.jpeg
The Vision
23
Why do we model graphically?
Graphics reveal data. Edward Tufte
The Visual Display of Quantitative Information, 1983
1 bitmap = 1 megaword. Anonymous visual modeler
24
The UML is a graphical language for specifying visualizing constructing documenting
the artifacts of software systems Added to the list of OMG adopted
technologies in November 1997 as UML 1.1 Minor revisions are in UML 1.2 (1998), 1.3
(1999), 1.4 (2001), and 1.5 (2003). Major revision is UML 2.0, completed in
2005. The current standard.
Quick Tour
25
Define an easy-to-learn but semantically rich visual modeling language
Unify the Booch, OMT, and Object modeling languages
Include ideas from other modeling languages Incorporate industry best practices Address contemporary software development
issues scale, distribution, concurrency, executability, etc.
Provide flexibility for applying different processes
Enable model interchange and define repository interfaces
UML Goals
26
OMG UML Evolution
1970: First object-oriented languages (Simula-67, Smalltalk).1980:More than 50 different OOAD languages
cause the users trouble to find complete and appropriate tools.1992:New iterations of methods appear.
Booch ‘93, OOSE (Jacobson), OMT-2 (Rumbaugh)
1995:Unification, UML 0.9 by Booch, Rumbaugh1997:Standardization, UML 1.1 by Booch,
Rumbaugh, Jacobson. Object Management Group (OMG) adapts UML as OOAD standard1999:Evolving standard in version 1.32005:Major revision in version 2.0
27
OMG UML Evolution
28
OMG UML Specification
UML Summary UML Semantics UML Notation Guide UML Example Profiles
Software Development Processes Business Modeling
Model Interchange Model Interchange Using XMI Model Interchange Using CORBA IDL
Object Constraint Language
29
Focus: the Language
language = syntax + semantics syntax = rules by which language
elements (e.g., words) are assembled into expressions (e.g., phrases, clauses)
semantics = rules by which syntactic expressions are assigned meanings
UML Notation Guide – defines UML’s graphic syntax
UML Semantics – defines UML’s semantics
30
Building blocks Well-formed rules
Foundation Concepts
31
The basic building blocks of UML are: model elements (classes, interfaces,
components, use cases, etc.) relationships (associations, generalization,
dependencies, etc.) diagrams (class diagrams, use case diagrams,
interaction diagrams, etc.) Simple building blocks are used to create
large, complex structures cf. elements, bonds and molecules in
chemistry cf. components, connectors and circuit boards
in hardware
Building Blocks
32
Diagram: Class View
Elem ent
Carbon Hydrogen
<<covalent>>
<<covalent>>C
C
C H
33
Diagram: Instance View
:Carbon :Carbon
:Hydrogen
:Hydrogen
:Hydrogen
:Hydrogen
:Hydrogen:Hydrogen
34
Well-Formed Rules Well-formed: indicates that a model or
model fragment adheres to all semantic and syntactic rules that apply to it.
UML specifies rules for: naming scoping visibility integrity execution
However, during iterative, incremental development it is expected that models will be incomplete and inconsistent.
35
Well-Formed Rules (cont’d)
Example of syntactic rules: Class Basic Notation: A class is drawn as a solid-
outline rectangle with three compartments separated by horizontal lines.
Presentation Option: Either or both of the attribute and operation compartments may be suppressed.
Example of syntactic guideline: Class Style Guideline: Begin class names with an
uppercase letter.
36
Unifying Concepts class-instance dichotomy
e.g., an object is an instance of a class ORa class is the classifier of an object
specification-realization dichotomy e.g., an interface is a specification of a
class ORa class is a realization of an interface
analysis-time vs. design-time vs. run-time modeling phases (“process creep”) usage guidelines suggested, not enforced
37
Structural Modeling
What is structural modeling? Core concepts Diagram tour When to model structure Modeling tips
38
What is structural modeling?
Structural model: a view of an system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations.
39
Construct Description Syntax
class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.
interface a named set of operations that characterize the behavior of an element.
component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.
node a run-time physical object that represents a computational resource.
«interface»
Structural Modeling: Core Elements
40
Structural Modeling: Core Elements (cont’d)
Construct Description Syntax
constraint¹ a semantic condition or restriction.
{constra in t}
¹ An extension mechanism useful for specifying structural elements.
41
Construct Description Syntax
association a relationship between two or more classifiers that involves connections among their instances.
aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.
generalization a taxonomic relationship between a more general and a more specific element.
dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).
Structural Modeling: Core Relationships
42
Construct Description Syntax
realization a relationship between a specification and its implementation.
Structural Modeling: Core Relationships (cont’d)
43
Show the static structure of the model the entities that exist (e.g., classes,
interfaces, components, nodes) internal structure relationship to other entities
Do not show temporal information
Kinds static structural diagrams
class diagram object diagram
implementation diagrams component diagram deployment diagram
Structural Diagram Tour
44
Static Structural Diagrams
Shows a graph of class elements connected by static relationships.
kinds class diagram: class view object diagram: instance view
45
Classes
Window
display ()
size: Areavisibility: Boolean
hide ()
Window
Window
+default-size: Rectangle#maximum-size: Rectangle
+create ()
+display ()
+size: Area = (100,100)#visibility: Boolean = true
+hide ()
-xptr: XWindow*
-attachXWindow(xwin:Xwindow*)
{abstract,author=Joe,status=tested}
46
Classes: compartments with names
bill no-shows
Reservation
operations
guarantee()cancel ()change (newDate: Date)
responsibilities
match to available rooms
exceptions
invalid credit card
47
Classes: method body
report ()
BurglarAlarm
isTripped: Boolean = false
PoliceStation
1 station
*
{ if isTrippedthen station.alert(self)}
alert (Alarm)
48
Types and Implementation Classes
Set«type»
addElement(Object)removeElement(Object)testElement(Object):Boolean
* elements
Object«type»
HashTableSet«implementationClass»
addElement(Object)removeElement(Object)testElement(Object):Boolean
1 body
HashTable«implementationClass»
setTableSize(Integer)
49
Interfaces: Shorthand Notation
+crea te ()+ log in (U serN am e, P assw d)+ find (S to re Id )+ge tP O S to ta ls (P O S id )+upda teS to reTo ta ls (Id ,S a les)+ge t(Item )
-s to re Id : In teger-P O S lis t: L is t
Store
P O S te rm ina l
P O S te rm ina lH om e
<<use>>
S to reH om e
S to re
POSterm inal
50
Interfaces: Longhand Notation
+create()+login(UserNam e, Passwd)+find(StoreId)+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item )
-storeId: Integer-POSlist: List
Store
POSterm inal
POSterm inalHom e
<<use>>
StoreHom e
POSterm inal
+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item )
<<interface>>Store
51
Associations
Person
Manages
JobCompany
boss
worker
employeeemployer
0..1
Job
Account
Person
Corporation
{Xor}
salary
52
Association Ends
Polygon PointContains
{ordered}
3..1
GraphicsBundle
colortexturedensity
1
1
-bundle
+vertex
53
PlayerTeam
Year
Record
goals forgoals againstwinslosses
goalkeeper
season
team
ties
Ternary Associations
54
Composition
Window
scrollbar [2]: Slidertitle: Headerbody: Panel
Window
scrollbar title body
Header Panel
2 1 1
Slider
111
55
Composition (cont’d)
scrollbar:Slider
Window
2
title:Header1
body:Panel1
56
Generalization
Shape
SplineEllipsePolygon
Shape
SplineEllipsePolygon
Shared Target Style
Separate Target Style
. . .
. . .
57
Generalization
Vehicle
WindPoweredVehicle
MotorPoweredVehicle
LandVehicle
WaterVehicle
venue
venuepowerpower
SailboatTruck
{overlapping} {overlapping}
58
Dependencies
«friend»ClassA ClassB
ClassC
«instantiate»
«call»
ClassD
operationZ()«friend»
ClassD ClassE
«refine»ClassC combines
two logical classes
59
Dependencies
Controller
DiagramElements
DomainElements
GraphicsCore
«access»
«access»
«access»
«access»
«access»
60
Derived Attributes and Associations
Person
birthdate/age{age = currentDate - birthdate}
Company
Person
Department
WorksForDepartment
/WorksForCompany
{ Person.employer=Person.department.employer }
1
1
1employer
employerdepartment
61
Objects
triangle: Polygon
center = (0,0)vertices = ((0,0),(4,0),(4,3))borderColor = blackfillColor = white
triangle: Polygon
triangle
:Polygon
scheduler
62
Composite objects
horizontalBar:ScrollBar
verticalBar:ScrollBar
awindow : Window
surface:Pane
title:TitleBar
moves
moves
63
Links
downhillSkiClub:Club Joe:Person
Jill:Person
Chris:Person
member
member
member
treasurer
officer
president
officer
64
Constraints and Comments
Member-of
Chair-of
{subset}Person Committee
Person Company
boss
{Person.employer =Person.boss.employer}
employeremployee
0..1
0..1
1
Representsan incorporated entity.
65
Class Diagram Example
+getOrderStatus+setOrderStatus+getLineItem s+setLineItem s+getCreditApproved+setCreditApproved
...
OrderBean{abstract}
LineItem{abstract}
Product
1
*
1
*
<<interface>>EntityBean
CreditCard{abstract}
Custom er
PM Order
PM LineItem
PM CreditCard
*
1
*
buyer
order
order
item
item
com m odity
66
Implementation Diagrams
Show aspects of model implementation, including source code structure and run-time implementation structure
Kinds component diagram deployment diagram
67
Shows the organizations and dependencies among software components
Components may be specified by classifiers (e.g.,
implementation classes) implemented by artifacts (e.g., binary,
executable, or script files)
Component Diagram
68
Components
<<Entity>>030303zak:Order
O rderH om e
O rder
O rderP K
<<Session>>ShoppingSession
S hopp ingS ess ionH om e
S hopp ingS ess ion
O rderIn fo
<<focus>>:Order
<<auxiliary>>:OrderPK
<<auxiliary>>:OrderInfo
O rderH om e
O rder
69
Component Diagram
<<EJBEntity>>Catalog
CatalogHom e
Catalog
CatalogPK
<<EJBSession>>ShoppingSession
ShoppingSessionHom e
ShoppingSession
CatalogInfo
<<file>>CatalogJAR
<<focus>>Catalog
<<auxiliary>>CatalogPK
<<auxiliary>>CatalogInfo
CatalogHom e
Catalog
<<EJBEntity>>ShoppingCart
ShoppingCartHom e
ShoppingCart
70
Component Diagram with Relationships
<<ejbEntity>>Catalog
<<auxiliary>>CatalogInfo
<<focus>>Catalog
<<res ide>> <<res ide>>
<<auxiliary>>CatalogPK
<<res ide>>
<<file>>CatalogJAR
<<im plem ent>>
71
Deployment Diagram
Shows the configuration of run-time processing elements and the software components, processes and objects that live on them
Deployment diagrams may be used to show which components may run on which nodes
72
Deployment Diagram (1/2)
:DBServer
videoStoreServer:AppServer
<<Container>> V ideoStoreApplication
:Client
<<brow ser>>:OpenSourceBrow ser
<<Session>>ShoppingSession
<<Focus>>ShoppingSession
<<Entity>>Catalog
<<Focus>>Catalog
<<Entity>>ShoppingCart
<<Focus>>ShoppingCart
<<database>>:VideoStoreDB
73
Deployment Diagram (2/2)
backupServer:AppServer
backupBroker:BondBroker
:QuoteService<<database>>:AccountsDB
prim aryServer:AppServer
prim aryBroker:BondBroker
:QuoteService
<<database>>:AccountsDB
<<becom e>>
74
When to model structure
Adopt an opportunistic top-down+bottom-up approach to modeling structure
Specify the top-level structure using “architecturally significant” classifiers and model management constructs
Specify lower-level structure as you discover detail re classifiers and relationships
If you understand your domain well you can frequently start with structural modeling; otherwise
If you start with use case modeling (as with a use-case driven method) make sure that your structural model is consistent with your use cases
If you start with role modeling (as with a collaboration-driven method) make sure that your structural model is consistent with your collaborations
75
Structural Modeling Tips Define a “skeleton” (or “backbone”) that can be
extended and refined as you learn more about your domain.
Focus on using basic constructs well; add advanced constructs and/or notation only as required.
Defer implementation concerns until late in the modeling process.
Structural diagrams should emphasize a particular aspect of the structural model contain classifiers at the same level of abstraction
Large numbers of classifiers should be organized into packages
76
Interface-Based Design Interface-based design is a design approach
that emphasizes the specification of system interfaces separates the specification of service operations
(interfaces) from their realization (implementation) CORBA IDL is typically used for interface-
based design of CORBA applications defines interfaces for business and system objects
without constraining their implementations defines the structure of an distributed application doesn’t allow you to specify object behavior or
class relationships other than generalization
77
Interface-Based Design (cont’d)
The following example shows how UML can model the interfaces for a Point of Sale application originally specified in CORBA IDL.
78
Example: Interface-based design
module POS{ typedef long POSId; typedef string Barcode;
interface InputMedia { typedef string OperatorCmd;
void barcode_input(in Barcode item); void keypad_input(in OperatorCmd cmd); };
interface OutputMedia { boolean output_text(in string string_to_print ); };…..
79
Example: Interface-based design
….. interface POSTerminal { void login(); void print_POS_sales_summary(); void print_store_sales_summary(); void send_barcode( in Barcode
item); void item_quantity( in long
quantity); void end_of_sale(); };
};
#endif /* _POS_IDL_ */
80
Point-of-Sale
POSterm inal
+outputText()
«IDLinterface»IOutputM edia
InputM edia +initialization()+barcodeInput()+keypadInput()
+POSref : POSterm inal
«IDLinterface»IinputM edia
OutputM edia
Store
+initialization()+findPrice()
+depotRef : Depot+taxRef : Tax+storeMarkup : float+storeId : Integer
«IDLinterface»IS toreAccess
+initialization()+calculateTax()+findTaxablePrice()
+rate : float
«IDLinterface»ITax
+initialization()+login()+printPOSsalesSummary()+printS toreSalesSummary()+setItemQuantity()+sendBarcode()+endSale()
+storeRef : S tore+storeAccessRef : S toreAccess+outputMediaRef : OutputMedia+taxRef : Tax+POSid : Integer+item Barcode : Integer+item Quantity : Integer+item Info : Item Info+item Price : Currency+item TaxPrice : Currency+item Extension : Currency+saleSubtotal : Currency+taxableSubtotal : Currency+saleTotal : Currency+saleTax : Currency+POSlist : List
«IDLinterface»IPOSterm inal
+initialization()+login()+getPOStotals()+updateStoreTotals()
+totals : Totals+POSlist : List
«IDLinterface»IS tore
StoreAccess
Tax
81
Use Case Modeling
What is use case modeling? Core concepts Diagram tour When to model use cases Modeling tips Example: Online HR System
82
What is use case modeling?
use case model: a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
83
Use Case Modeling: Core Elements
Construct Description Syntax
use case A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.
actor A coherent set of roles that users of use cases play when interacting with these use cases.
system boundary
Represents the boundary between the physical system and the actors who interact with the physical system.
UseCaseNam e
ActorNam e
84
Construct Description Syntax
association The participation of an actor in a use case. i.e., instance of an actor and instances of a use case communicate with each other.
generalization A taxonomic relationship between a more general use case and a more specific use case.
extend A relationship from an extension use case to a base use case, specifying how the behavior for the extension use case can be inserted into the behavior defined for the base use case.
Use Case Modeling: Core Relationships
<<extend>>
85
Construct Description Syntax
include An relationship from a base use caseto an inclusion use case, specifyinghow the behavior for the inclusion usecase is inserted into the behaviordefined for the base use case.
Use Case Modeling: Core Relationships (cont’d)
<<include>>
86
Shows use cases, actor and their relationships
Use case internals can be specified by text and/or interaction diagrams
Kinds use case diagram use case description
Use Case Diagram Tour
87
Customer
Supervisor
SalespersonPlace
Establishcredit
Check
Telephone Catalog
F ill orde rs
Shipping Clerk
status
order
Use Case Diagram
88
Use Case Relationships
additional requests :
OrderProduct
SupplyArrange
«include»«include»«include»
RequestCatalog
«extend»Extension points
PaymentCustomer Data
after creation of the order
Place Order
1 * the salesperson asks forthe catalog
89
Actor Relationships
EstablishCredit
PlaceOrder
Salesperson
Supervisor
1 *
1 *
90
Use Case Description: Change Flight
Actors: traveler, client account db, airline reservation system Preconditions:
Traveler has logged on to the system and selected ‘change flight itinerary’ option
Basic course System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary.
Alternative courses If no flights are available then …
91
When to model use cases Model user requirements with use
cases. Model test scenarios with use cases. If you are using a use-case driven
method start with use cases and derive your
structural and behavioral models from it.
If you are not using a use-case driven method make sure that your use cases are
consistent with your structural and behavioral models.
92
Use Case Modeling Tips
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams
Factor out common usages that are required by multiple use cases
If the usage is required use <<include>> If the base use case is complete and the usage may be
optional, consider use <<extend>> A use case diagram should
contain only use cases at the same level of abstraction include only actors who are required
Large numbers of use cases should be organized into packages
93
Example: Online HR System
Online HR System
LocateEm ployees
UpdateEm ployee
Profile
Update Benefits
Access TravelSystem
Access PayRecords
Em ployee
M anager
Healthcare Plan System
{if currentMonth = Oct.}
{readOnly}
Insurance P lan System
94
Online HR System: Use Case Relationships
Update M edicalP lan
Update DentalP lan
Update Benefits______________Extension pointsbenefit options:
after required enrollm ents
UpdateInsurance P lan
Em ployee
<<include>> <<include>> <<include>>
ElectReim bursem entfor Healthcare
Elect StockPurchase
<<extend>>em ployee requestsstock purchase option
<<extend>>em ployee requestsreim bursem ent option
extensioncondition
extension pointname andlocation
95
Online HR System: Update Benefits Use
Case
Actors: employee, employee account db, healthcare plan system, insurance plan system Preconditions:
Employee has logged on to the system and selected ‘update benefits’ option
Basic course System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. …
Alternative courses If health plan is not available in the employee’s area the employee is informed and asked to select another plan...
96
UML is effective for modeling large, complex software systems
It is simple to learn for most developers, but provides advanced features for expert analysts, designers and architects
It can specify systems in an implementation-independent manner
10-20% of the constructs are used 80-90% of the time
Structural modeling specifies a skeleton that can be refined and extended with additional structure and behavior
Use case modeling specifies the functional requirements of system in an object-oriented manner
Ideas to Take Away