Embed Size (px)
Citation preview
1
Object OrientedAnalysis and Design
with UML
UNIT 2
2
Summary Unit 1...
Object-Oriented Approach– Is structured in terms of
• Objects (state + behaviour + identity)
• Messages
• Methods
– Supports sharing through• Classes and instances
• Class hierarchies
3
Summary Unit 1...Object-Oriented Techniques
» Are based on– Encapsulating data and procedures
– Inheritance
– Polymorphism
» Facilitate– Modularity
– Reusability and sharing
– Extensibility and change (maintainability)
4
Summary Unit 1.
Needfor a
Strategy
Analysis
Design
Implementation Testing
ExploitationMaintenance
Problem
5
TheUnified
ModellingLanguage
UNIT 2
6
Unit 2 : Outline
The History of the UML General overview of the UML Use Case Diagram Class Diagram
7
Unit 2 : Outline
The History of the UML General overview of the UML Use Case Diagram Class Diagram
8
Unified Modeling Language
Designed by G. Booch, J. Rumbaugh, I. Jacobson (3 amigos)– Started in 1994, version 1.0 finished in 1997
– They put aside their own methods and notations
To end the OO method wars– Lack of standardization : every method, tool, practice
has their own set of symbols and terminology
Became the formal and de facto standard
9
The Evolution of UMLNov ‘97 UML approved by the OMG
10
Contributions to the UML
Meyer
Before and after conditions
Harel
StatechartsGamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
11
Unit 2 : Outline
The History of the UML General overview of the UML Use Case Diagram Class Diagram
12
Why would you use UML To learn OO
– CRC cards Class-Responsibility-Collaboration
– Class diagrams
– Interaction diagrams
– Design patterns
Communicate with domain experts– Use cases
– Class diagrams (conceptual)
– Activity diagrams
13
General Goals of UML
Model systems using OO concepts
Technical Systems
Information Systems
Software Systems
System Software
Distributed Systems
Real-time Systems
Business Systems …
Establish an explicit coupling to conceptual as well as executable artefacts
To create a modelling language usable by both humans and machines
14
Different Types of Systems… Information Systems
– Store, retrieve, transform, present information to users
– Large amounts of data, complex relationships, stored in databases
Technical Systems– Handle, control technical equipment
– Special interfaces e.g. for telecommunications, military systems, industrial processes
– Real-time
15
Different Types of Systems…
Embedded Real-Time Systems– Execute on simple hardware, e.g. mobile phone,
vcr, microwave oven
Distributed Systems– Synchronize communication, ensure data
integrity, security– CORBA, DOM/DCOM
16
Different Types of Systems…
System Software– Operating systems, DBMS, low level
operations on HW
Business Systems– Describes goals, resources, rules, actual work in
a business process
17
Even more : UML is described in UML
Different Types of Systems.
Combinations are possibleUML can be used to model all of these
systems
18
UML Diagrams...
Use-Case diagram Class diagram Object diagram State diagram Sequence diagram
Collaboration diagram Activity diagram Component diagram Deployment diagram
19
Use-Case Diagram
20
Class Diagram
21
Object Diagram
22
State Diagram
23
Sequence Diagram
24
Collaboration Diagram
25
Activity Diagram
26
Component Diagram
27
Deployment Diagram
28
UML Views…
Each view is a projection of the complete system
Each view highlights particular aspects of the system
Views are described by a number of diagrams
No strict separation, so a diagram can be part of more than one view
29
UML Views…
Use CaseView
DeploymentView
ConcurrencyView
ComponentView
LogicalView
30
Use Case View…
Shows the functionality of the system as perceived by external actors
Actors can be users or other systems Described by use case and activity diagrams The central view which drives the development
and planning of other views Used by customers, designers, developers, testers
31
Logical View…
Shows how the functionality of the system is designed / provided
Uses class and object diagrams to represent the static structure
Uses state, sequence, collaboration, and activity diagrams for dynamic behaviour
Used by designers and developers
32
Component View…
Shows the organization of the code components and their dependencies
Described by component diagrams Used by developers
33
Concurrency View…
Addresses the problems with communication and synchronization for a concurrent system
Described by state, sequence, collaboration, activity, deployment, and component diagrams
Used by developers and system integrators
34
Deployment View.
Shows the deployment of the system into the physical architecture with computers and devices
Represented by the deployment diagram Used by developers, system integrators, and
testers
35
A Process for Making Models...
Brainstorming Sketching
Organizing
Specifying
Use informal tools:- Whiteboard- Post-it notes
Organize the informal sketch ina tool to producea formal diagram
Specify the detailsof the diagram, as more and more is learned (iterative)
Input Knowledge, Experience, Problem Description, Goals, …
36
A Process for Making Models.
Check the diagram ,verify/validateagainst req.
Make a prototypeand test…
Evaluate resultgo back andcorrect anydeficiencies
Verifying
Prototyped &Tested
Evaluate
Integrating Validating
37
Unit 2 : Outline
The History of the UML General overview of the UML Use Case Diagram Class Diagram
38
Primary Purpose
Decide and describe functional requirements– Resulting in an agreement and planning
Clear description of what the system should do– Looks at the system as a black box
Used throughout entire development– Communication of requirements to all
developers– Basis for design, system tests, verification
39
Who has Interest in Use Cases?
Customers and end users– Specification of the functionality of the system and
how it can and will be used
Developers– Understanding of what the system should do and a
foundation for future work
System integrators and testers– Basis to check wether the system performs as required
Anyone involved in activities of the system
Very Informal
Formal
Very Formal
40
Parts of a Use Case Diagram...
The system The actors
The use cases
Insurance system
Customer
Customer statistics
41
Parts of a Use Case Diagram...
The system– Could be any system, not just SW systems– Define clear and precise boundaries
• Don’t be too ambitious - think small !• Identify the basic functionality and concentrate on
defining a stable and well-defined system architecture• More functionality can always be added in future
versions
– Compile a catalog of central concepts or entities and describe them !
42
Parts of a Use Case Diagram...
The actors– Who or what uses the system
• Represents a role, not an individual user of the system !
– Communicates with the system by sending and receiving messages
– Actors are in control and initiate actions– Actors can be ranked :
• Primary and secondary actors
43
Parts of a Use Case Diagram.
Use cases– A set of sequences of actions a system performs
• A textual description !
– Always initiated by an actor
– Always delivers an observable result of value to an actor
• ”receive a bill for service” ?
– A use case is connected to an actor through associations• Normally undirected one-to-one relations
44
Steps for Building a Use Case Model
Define the boundaries of the system– Divide into subsystems
Find the actors and use cases– For big systems define the actors first
Define the relationships between the use cases– extends
– uses
Validate and verify the model– Highly interactive with the end users !
– Should include discussions
45
How to Find Actors ?
Who will use the main functionality of the system? Who will need support from the system to do their
daily tasks? Who needs to maintain, administrate and keep the
system working? Which HW devices does the system need to handle? With which other systems does the system interact? Who or what has an interest in the produced results?
46
Describing a Use Case…
Use cases are goal oriented !– What is it trying to achieve– Which functions does the actor require, what
does he need to do?– Which actor initiates the use case and in which
situations?– Which messages or events are necessary
47
Describing a Use Case.
– What is the flow of messages between actors and the use case?
• Depends on conditions and exceptions– Be cautious : don’t be too detailed
– Specific exceptions can be clarified by scenarios
– Which entities are modified and/or used?– When is the use case considered to be finished
and what kind of value is delivered to the actor?
48
Relationships...
Extends relationship– The extension may use parts of the
generalization– Difficult to define the
reused parts• Use cases are written in
natural language !
Signing Insurance Policy
Client under 21
«extends»
49
Relationships...
Uses relationship– The entire use case is used
Signing Insurance Policy
Signing Car Insurance Signing Life Insurance
«uses» «uses»
50
Relationships.
Grouping into a package– Use cases with similar or related functionality
can be grouped (cfr Java packages)
51
Example : Recycling Machine...
Customer Operator
Return Item
Print Daily Report
Change Item Data
52
When the customer returns a deposit item, it is measured by the system.
IF accepted, the customer’s total is incremented and .... IF the item is rejected ...
The following information is printed on a receipt form: name, number returned, ...
Example : Recycling Machine...
Return Item
53
Example : Recycling Machine.
Return Item
Item stuck
extends
When an item gets stuck, the alarm is activated to call the operator.
When the Operator has removed the stuck item he resets the alarm and the Customer can continu to return items.
54
Summary
A technique to describe the functional requirements of a system
Described in terms of external actors, use cases and the system modeled
Use cases can be related to each other : extended, used, grouped.
55
Unit 2 : Outline
The History of the UML General overview of the UML Use Case Diagram Class Diagram
56
Class Diagrams
Perspectives– Conceptual
• No relation with the software
– Specification• Interfaces of the software
– Implementation• The real classes
57
Class Diagrams
Static model type– A view of the system in terms of classes and
relationships (associations – subtypes - …) Classes not only describe information but
also behaviour ! Description of object types .
Attributes and behaviour of a type of objects– All objects are instances of a certain class
58
Examples of Classes…
In business and information systems :– Customer– Agreement– Invoice– Debt– Asset– Quotation
59
Examples of Classes…
In technical systems– Sensor– Display– I/O card– Engine– Button– Control class
60
Examples of Classes.
In system software :– File
– Executable program
– Device
– Icon
– Window
– Scrollbar
Actually everything that has certain properties and behaviour
61
A Class in UML…
A rectangle divided into 3 compartments :– name, attributes, operations
Name
Attributes
Operations
62
A Class in UML…
The name compartment– Starts with an uppercase– Boldface– Most of the time a noun
63
A Class in UML…
The attributes compartment– Starts with a lowercase– Has a type e.g. String, Integer, …– Has a visibility (language depended)
• public (+), private (-), protected (#)
– Default values can be specified– Allowed values can be specified ({...})– Class scope is possible (underlined)
64
A Class in UML…
Invoice
+ amount : Real+ date : Date = Current date+ customer : String+ specification : String- administrator : String = “Unspecified”- number of invoices : Integer+ status : Status = unpaid { unpaid, paid }
65
A Class in UML…
Public class Invoice{ public double amount; public Date date = new Date(); public String customer; static private int number_of_invoices = 0; // Constructor, called every time an object is created
public Invoice() { // Other initialization number_of_invoices++; //increment the class attribute }
// Other methods go here};
Invoice
+ amount : Real+ date : Date = Current date+ customer : String- number of invoices : Integer = 0
66
A Class in UML…
The operation compartment :– Contains the signature of the operation
• a return type
• a name
• zero or more parameters
– Has a visibility• public (+), private (-), protected (#)
67
A Class in UML…
size : Sizepos : Position
+ draw ()+ scaleFigure (percent : Integer = 25)+ returnPos () : Position
Figure
68
A Class in UML.
Public class Figure
{
private int x = 0;
private int y = 0;
public void draw()
{
// Java code for drawing the figure
}
};
- x : Integer = 0- y : Integer = 0
+ draw ()
Figure
69
Finding Classes
Do we have information that should be stored or analysed?
Do we have an external system? Do we have any patterns, class libraries,
components from earlier projects? Are there devices that the system should handle? Do we have organizational parts? Which roles do the actors play? Information comes from requirements !
70
Relationships Between Classes
An association is a connection between classes A generalization is a relationship between a more
general and a more specific element A dependency is a relationship between elements,
one independent another dependent A refinement is a relationship between two
descriptions of the same thing but at different levels of abstraction
71
Association Relationship…
Normally bidirectional Could contain multiplicity
– a range that tells us how many objects are linked
Association
Association name Association direction
UsesAuthor Computer
72
Association Relationship…
A Person Owns 0 or many CarsA Car is Owned by 1 or many Persons
OwnsCarPerson
Owned by
1..* 0..*
Multiplicities
73
Associations
Insurancecontract
Insurancepolicy
Insurancecompany
0..*1
has
refers to
0..*
1..*
refers to
Customer
0..1
hasexp
ressed an
is expressed
in an
74
Recursive Associations
Connecting a class to itself
Node
Connects
*
*
75
Roles in Associations
Specifies the contextof a class and its objects.
Role names arepart of the association not of the class
wife
Insurancecontract
Insurancepolicy
Insurancecompany
0..*1
ha
s
refers to
0..*
1..*
refe
rs to
Person
0..1
has
ex
pre
ss
ed a
n
is ex
pre
sse
d in
an
married to
husband
policyholder
76
Qualified Associations
Specifies how a certain object at the many end is identified (+/- a key)
A Canvas contains many Figures which are identified by a figure id
Canvas figure id*
Figure
77
‘OR’ Associations
In some models not all combinations are valid
An Insurance contract
belongs to a Person OR a Company
Insurancecompany
Insurancecontract
Person
0..*
1..*
Company
0..*
1..*
{or}
78
Ordered Association
Insurancecontract
Customer
0..*
1..*
{ordered}
79
Association Classes
The class Queue is needed for the association
Elevator
Queue
Elevatorcontrol
Button
*
4
80
Ternary Associations
Insurancecompany
Insurancecontract
Person
0..*
1..*
Insurance policy
0..1
policyholder
0..*1
insurer
81
Aggregation
A part-off association What is the difference with an association ? Only use it when it is clear why you use it !
NavyContains
* Warship
82
Composition
Stronger variety of aggregation The parts can only exist if the whole exists
Notation (1/3)
* Text
Window
Listbox
Button
Menu*
*
*
83
Composition Aggregation…
Notation (2/3)* Text
Window
Listbox
Button
Menu*
*
*
Contains
84
Composition Aggregation.
Notation (3/3)
Window
Text
Listbox
Button
Menu
*
*
*
*
85
Generalization…
Inheritance, ‘is-a’ relationship The more specific may be used where the
more general is allowed Private vs. protected
Remember :Using Inheritance
for code reuse, or just because it
looks nice is adangerous practice !
Boat TruckCar
Vehicle
86
Generalization.
Abstract classes & Polymorphism
Facilitated through
Dynamic Binding
87
General Example
Cfr. Composite
Design Pattern
88
Dependency Relationship
Class A depends on Class B
(important to know for maintainability)
Class BClass A«friend»
89
Refinement Relationship
A Design Class is a refinement of an Analysis Class
(important to know for abstraction levels)
Design classAnalysis class
90
Extensibility of UML... Stereotypes
– Allows to define a new kind of model element based on an existing one
– Basically adds extra semantics– There are predefined stereotypes in UML
• simplicity !
Stereotype name Stereotype icon
Customer
Customer<<Actor>>Customer
91
Extensibility of UML (2)
Tagged values– Name-value pairs of information– Hold additional information about elements
Constraints– Restrictions that limit the usage of an element
or the semantics of an element
