OOAD With UML and The UP - Session 4 - Elaboration

Altran CIS
Object-Oriented Analysis and Design
Session 4 Elaboration Phase First Iteration
OOAD Training
Trainers:
Pierre LE FEVERE DE TEN HOVE
1 Richard WALKER
Objectives and Agenda
Objectives
Understand elaboration phase objectives

Master analysis discipline
Acquire know how of class, interaction & state machine diagrams
Understand architecture
Agenda
Elaboration objectives
Analysis discipline overview

Finding analysis classes
Class diagrams basics
Use case realizations
Interaction diagrams
Architecture introduction
Analysis packages
Iteration evaluation
Course organisation
BPM
UC
Domain
Model
Kick-off
Priorit. UC
Kick-off
OOAD Training
Software Engineering Process

Rational Unified Process
Elaboration Phase
Elaboration Main Objectives
Stabilize the vision

Iterative elaboration of the executable architecture baseline
Risks resolution / assessment
Refine requirements
Construction phase plan with realistic estimates
OOAD Training

Elaboration Phase - Main Objectives
Stabilize the vision
Business case revised and agreed
Vision document completed (w/ quality ranges, doc requirements, ...)
Iterative elaboration of the executable architecture baseline

First cut of the system that realize the high level architecture
Fully implemented and tested
Risks resolution / assessment

Major risks have been resolved in the architecture baseline
Risk assessment document revised
Refine requirements
Detail use cases to 80% of the func. req.
Plan next phases

In sufficient details to enable realistic estimates for time, cost and resources
Detailed plan for construction phase
OOAD Training

Elaboration Phase - Disciplines
Elaboration phase Design phase !!
Build the core architecture, resolve high-risk elements, define
most requirements and estimate overall schedule and resources.
Main disciplines:
Analysis Establish what to build

Design Create a stable architecture
But also:
Requirements refine scope and detail use cases
Implementation build architecture baseline
Test test architecture baseline
All the others
OOAD Training

Elaboration Phase
OOAD Training
Objectives

Agenda

Analysis packages
Analysis
Discipline overview
What the system needs to do
(how is for design)
Produce an analysis model
Two key artifacts:
Analysis classes = key concepts in business domain

Use case realizations = how instances realize use cases
OOAD Training
Analysis
RUP Workflow
Analysis & Design
Analyze behavior
Use Case Analysis

Input:
Architecture
Requirements
Output:
Analysis model
Objectives
Find analysis classes
Describe interaction
between them
OOAD Training
10
Objectives

Agenda

Analysis packages
Analysis
But wait, what is a class?
I know, it's inside a class

diagram!
OOAD Training
12

OO pitfalls
To really fail with the RUP,
ignore having or educating people with deep object skills
Not a 1 week course in Java + a 1 week course in OOAD
But 8 weeks of intensive teacher-led education, spread over 6 months + 12 months of
close mentoring by an expert
Craig Larman from How to Fail with the RUP: Seven Steps to Pain and Suffering; Step 3
People are more important than process

Grady Booch
OO is not the use of a particular tool or language
OOAD Training
!!!
13

Introduction
A class diagram describes:

the types of objects in the system
the static relationships between them
It shows features of classes
Feature
Property
Operation
Association
Attribute
Class diagram is the most common type of UML diagram
OOAD Training
14

What is an Object?
A discrete entity with a well-defined boundary that encapsulate

state and behavior J. Rumbaugh
deposit()
Properties
Identity : reference
State : attributes and values
Behavior : operations & methods
1254868
"Bill
Gates"
315.00
withdraw()
getOwner()
setOwner()
an Account object
The structure and behavior of similar Objects are defined in their common
Class
OOAD Training
>>
15

What is a Class?
The description for a set of objects that share the same:

attributes
operation
methods
relationships
behavior
A Class can be viewed as:
A specification
A template for objects
An abstract type
There is an infinite number of ways of classifying objects
OOAD Training
>>
16

Class & Objects
An object is an instance of a class
OOAD Training
>>>
17

Attributes
Named properties, characteristics of a class

Typed: description of the range of possible values
visibility name: type [multiplicity] = initial value
Syntax:
Visibilities
+
#
public
visible to all
private
not visible to callers outside the class
protected only visible to children of the class
Multiplicities
[n]
a collection of n items
[n..m] between n and m items (0 = can be null, * = unlimited)
Only name is mandatory in analysis

OOAD Training
18

Responsibilities
Summary of what the class should do (actions, knowledge, decisions)

1 responsibility = 1 short sentence
Syntax: 1 comment per responsibility in a dedicated compartment
LoanOfficer
OOAD Training
Shape
Name
Identification number
-- determine the risk of a

customer loan
-- handle customer-specific
criteria for loan
-- manage shape state

-- handle basic shape
transformation
!!!
19

Operations
Services that can be invoked on an object

to realize behavior
Define the responsibilities of objects
Shared by all instances of the class
An operation's implementation is called a method

signature
Syntax: visibility name (dir parameterName : type = default value, ... ) : returnType
Parameter directions: in, out, inout or return
Only name is mandatory in Analysis
Use {isQuery = true} property

to indicate operation has no side effect and does not change state
OOAD Training
20

Class scope and instance scope
By default: instance scope

Use class scope to define a set of global features for an entire class of
objects
All objects share the same values

of class scope attributes
Class scope operations do not apply to a

specific instance but to the class itself
Can be invoked even if no instance
OOAD Training
21

Encapsulation
Exposing services and hiding internal details
ag
an
e
+deposit()
e
nc
la
ba
1254868 +withdraw()
"Bill
Gates"
315.00 +getOwner()
an
ag
+setOwner()
ow
ne
r
1. Hide data behind operations

2. Limit access with visibilities
3. Group related operations with interfaces
3 levels of encapsulation:
OOAD Training
!!!
22

Relationships - Associations
An association represents a conceptual connection between classes

It allows links between their instances (objects)
Links are permanent, they exists during the whole life-time of the objects
(even if the instances connected may change over time or be empty)
Same semantic as attributes but different notation
Syntax:
Navigability
Name
Role
Multiplicity
OOAD Training
>>
23

Association examples
OOAD Training
>>
24

Aggregation
A specific type of association: whole - part relationship
Keywords that help identifying aggregations:
consists of, contains, is part of

Syntax:
No particular semantic, "A modeling placebo" (J.Rumbaugh)

Example: a computer and its peripherals
OOAD Training
>>
25

Composition
Stronger form of aggregation (tighter coupling)
A part can be included in only one composite at a time

Composite has sole responsibility for the dispositions of all its parts (creation,
destruction, adoption)
Multiplicity of composite always 0..1 or 1

Syntax:
Example: a tree and its leaves

OOAD Training
!!!
26

Generalization and inheritance
Generalization
relationship between a general element and a more specific one

which conforms completely with the first element
which adds supplementary information
Inheritance
mechanism by which the more specific elements incorporate the
structure and the behavior of more general elements

W
h
e
el
mechanism of sharing attributes and operations using
B
o
d
y
C
ar
M
o
t
o
r
generalization relationship
S
eat
B
erlin
eC
ar
S
p
o
rtC
ar
A
ile
ro
n
Generalization
Specialization
OOAD Training
>>
27

Generalization relationship
Special type of association: parent - child relationship

Keywords for identification: is a type of is a kind of
Properties
The parent class (super-class) is a generalization of the child class (sub
class)
All instances of the child class are also instances of the parent class
Children inherit properties of the parent
Children are able to extend and override the inherited structure
Multiple inheritance is allowed in UML
Generalization is transitive
OOAD Training
28

Classification
Generalization = relation between a child class and its parent class

Classification = relationship between an object and its class
Multiple classification
An object may be belong to several types that are not connected by inheritance
(allowed during analysis)
Usage of generalization sets and names
Constraints on generalization sets
{complete}: an object is always an instance of one of the classes

{incomplete}: an object can be instance of none of the classes
{disjoint}: an object can be instance of one and only one of the classes
{overlapping}: on object can be instance of several classes
Default is {incomplete, disjoint}
OOAD Training
29

Multiple classification example
Classification: "John is an instance of employee"
Generalization: "An employee is a kind of person"
John is also an instance of person
OOAD Training
30
Objectives

Agenda

Analysis packages

Analysis classes
Early conceptual model of the system
Classes with:
Name
Short description
Responsibilities
Attributes
Interrelated in class diagrams with association and generalization links
Focus is on responsibilities
OOAD Training
>>
32

Sources (1/2)
Domain model
Noun/verb extraction from use cases and other req. documents
Categories checklist
Conceptual class categories
OOAD Training
Examples
Physical or tangible objects
Plane, Bottle, Car
Descriptions of things
Flight description
Places
Airports
Interactions
Meeting, Agreement, Interview
Transactions
Reservation
Roles
Pilot, doctor, teacher
Containers
Store
Organizations
Sales Department
33

Sources (2/2)
RUP stereotypes <<boundary>>, <<control>>, <<entity>>
CRC card analysis

Class
Responsibility
Collaborations
OOAD Training
34

RUP BCE
Boundary: responsible for the system boundaries (usually: UI)
Represents the interface between an actor and the system

Correspond to the classes present in GUI design
Objects persist beyond a single execution of the program
Dependent on entity classes: when a change is made to an entity class, the boundary
class updates the GUI display to reflect the change
Control: responsible for transferring control to the appropriate business logic

class
Control the execution of a business process the activities in a use case

Objects do not persist beyond a single execution of the program
Entity: responsible for business functionality and back-end systems interaction

Represents the data structure
Objects persist beyond a single execution of the program
OOAD Training
35

Rejecting Bad Classes
Class with a verbal name
May be a simple operation / method

Class with only one public operation
May be a simple operation / method

Class with no operations
May be an important piece of information

The operation / method may have been missed
Class described as performing something
Maybe no proper data abstraction

Class not part of the system
For Specification and Implementation perspectives

Do not redefine domain names even if bad
OOAD Training
36

Finding Associations
Categories checklist
Conceptual association categories
Examples
A physical part of B
Wheel Car
A logical part of B
FlightPath FlightRoute
A is a description for B
FlightDescription Flight
A is a transaction item of B
SalesItem Sales
A is a member of B
Pilot Airline
A uses B
Pilot Plane
A communication with B
ReservationAgent Passenger
A is an event related to B
Departure Flight
OOAD Training
37

Best practices
Don't try to use all the notations
Start with the simple elements: classes, associations, attributes,

generalization, and constraints
Fit the perspective
Focus on the conceptual and specification perspectives

Do not get bogged down in implementation details too early
OOAD Training
>>
38
Objectives

Agenda

Analysis packages
Introduction (1/2)
Objectives
Understand how the object will behave over time

Which objects communicate with each other ?
What messages are sent ?
What are the effects of that communication ?
Use and implement the object model

Describe the control aspects of a system
Take into account the time
Take into account the sequence of operations
Take into account the interaction between objects
OOAD Training
40
Interaction modeling
Introduction (2/2)
Artefacts
System Sequence Diagram

Presenting the interaction between users and the system
Sequence Diagram
Presenting the interaction between objects
Focusing on the sequence of message describing the scenario
Communication Diagram
Presenting the interaction between objects
Focusing on the behaviour of objects created to perform the scenario
OOAD Training
41
Describe how groups of objects collaborate and communicate to realize some

behavior
Primary focus
Either on time Sequence Diagram
Either on messages Communication Diagram
Show sequences of messages

exchanged between objects
to perform a function: a single path of execution (i.e.: scenario)
OOAD Training
42
Uses and aspects
Main uses of interaction diagrams
To look at the behaviour of several objects within a single use case

To model collaboration (use case realisations)
To model the logic of a method
To model the logic of services
Main aspects of interaction diagrams
Display the interaction between actors and the system

Emphasize the sequenced messages exchange between objects
Model outside system events
Shows the dynamic structure of the model
Objects lifetime and activities

Messages (synchronous, asynchronous, self-messages, )
Loops, iterations, conditions,
guard conditions
OOAD Training
43
Sequence diagrams
Introduction
Sequence diagrams
Shows objects as lifelines

Presents interaction between objects overtime
Which objects communicate with which other?
What messages trigger those communications?
System Sequence diagrams
Presents the interaction between the users and the system

Very useful to illustrate use case scenario
How a user will interact with the system?
And what happens internally to get the work done?
OOAD Training
44
Sequence diagrams
Introductive example
Two dimensions
Vertical axis shows the time
Horizontal axis shows a group of objects
OOAD Training
45
Sequence diagrams
UML Components (1/9)
The lifelines
Represent an individual participant (Actor or object instance)

Represents the existence of an object at a particular time (along the vertical
axis)
Syntax
an object icon with a dash line
a rectangle with the object name and a dashed line

OOAD Training
46
Sequence diagrams
Messages
Communication between two objects conveying information

Object receiving message starts activity = execution occurrence
Shown by thin rectangle on object lifeline

Shows the focus of control
Shows which objects execute at some point in time
Either executing its own code or waiting for return of another object
Messages are shown as arrows between lifelines.

Message can have a signature with name and parameters
OOAD Training
47
Sequence diagrams
Messages
Message sent to receiving object represents invoked operation/method the
receiving object's class implements

Different type of messages
Synchronous message (Call): solid line with solid arrowhead (reply omitted)
Asynchronous message (Signal): solid line with stick arrowhead
Reply message (optional): dotted line with arrowhead back to originating lifeline
Recursive message: recursive call of a method calling another method on the same
object
OOAD Training
48
Sequence diagrams
Lifeline Start and End
An object may be created or destroyed during the timescale of a Sequence
Diagram
Object Creation
Symbol head of created object at a lower level than the creating object
From creator object message passed to created symbol head
Object Deletion
Lifeline is stopped
Cross below lifeline
Execution occurrence
Active instance
Region of control
OOAD Training
49
Sequence diagrams
Combined fragments
Sequence diagrams not intended for complex procedural logic

If required use combined fragments
Split sequence diagrams into fragments
One or more processing steps enclosed in a frame
Executed under specific circumstances and guard conditions
Following types (Interaction Operators) are available
Alternative fragment (denoted alt) : denotes an if then else construction

Option fragment (denoted option) : denotes a switch construction
Parallel fragment (denoted par) : denotes concurrent processing of multiple tasks
Loop fragment (denoted loop) : denotes repetitive logic
Critical Region fragment (denoted region) : denotes a critical section in which
messages can not be interrupted
Interaction Occurrence (denoted ref) : references an interaction captured in
another frame (to break large Sequence Diagram into smaller parts)
Sequence fragment (denoted seq) : denotes a weak sequencing of processing
messages between lifelines (<> Strict fragment )
OOAD Training
50
Sequence diagrams
Combined fragments
Interaction operator
Guard conditions
Interaction operand
OOAD Training
51
Sequence diagrams
Combined fragments
OOAD Training
52
Sequence diagrams
Gates
Connection point for connecting a message inside a fragment with a message
outside a fragment
To pass information between
Sequence diagram and context

Two sequence diagrams
It forms the interface between the combined fragment and its surroundings.
Simple graphical element with no implementation
OOAD Training
53
Sequence diagrams
Time constraints
Useful for modeling

time-bound business process
real-time system
Time along the vertical axis
OOAD Training
54
Sequence diagrams
Forms and Format
Instance Form
Describes a specific scenario in detail

Documents one possible iteration
No conditions, branches or loops
Generic Form
Describes all possible alternatives in a scenario

Branches, conditions and loops are used
Outside system perspective
System Sequence Diagram (SSD)

Only one object: the system
Interacting with Actors
They exchange System Events
Inside system perspective
Sequence diagram
Collaboration: Use case realization
OOAD Training
55
Sequence diagrams
Withdraw Money from ATM
Draws attention to time sequence
OOAD Training
56
Communication diagrams
Introduction
Equivalent to sequence diagrams

Presents interaction between objects overtime
Which objects communicate with which other?
What messages trigger those communications?
Focus on object relationships rather than on message sequences

Allow packages overlaying
Formerly called Collaboration Diagrams
OOAD Training
57
Objects shown with association connectors

Numbering scheme for sequence
Package overlaying
Objects operations
OOAD Training
58
Sequence vs Communication
OOAD Training
59
Sequence vs Communication
OOAD Training
60
Interaction Modeling
Interaction Diagrams
Conclusions
Main advantages
Very useful
to modelise graphically a scenario (input and output events related to the system)
to provide inputs to Specification Class Diagrams (invoked operations)
to discover what external events (called system events) are coming into the system
under study
To illustrate collaboration between systems
Main disadvantages
Not useful for complex logic

The life cycle of objects are not represented
OOAD Training
61
Objectives

Agenda

Analysis packages
Analyze behavior
One per use case

A set of classes + a set of interaction
diagrams showing collaborations
Usually, discovery of new analysis

classes
OOAD Training
63
Objectives

Agenda

Analysis packages
Software Architecture
Introduction
Architecture is many things to many different interested parties
multiple projects stakeholders

with their own concerns and view of the system to be developed
Architecture embodies, for each stakeholder, views of the system that
addresses their concerns, models the choices/decisions, and suppresses
the other details.
Not all systems require all the same number of views
OOAD Training
65
4+1 views
Overview
RUP presents the Software Architecture in the 4+1 views
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
End-user
Functionality
Use-Case View
Process View
System integrators
Performance
Scalability
Synchronisation and concurrency
OOAD Training
Deployment View
System engineering
System topology
Delivery, installation
Communication
66
4+1 views
Detailed views (1/5)
Logical View
High level view focused on design object-oriented model that supports the
functional requirements
Models elements and mechanism of the system

Identifies the domain elements, their relations and interactions
Focus on better understanding of the problem domain
Usually reused and refined in other views
UML diagrams involved
Class diagrams (domain modeling)

Activity diagrams (business process modeling)
Interaction diagrams (System sequence diagrams)
State-machine diagrams
Package diagrams (logical grouping)
OOAD Training
67
4+1 views
Implementation view (also called development view)
A low level view focused on realization of the logical view and on the software
components organization
Components organisation
Classes are usually map to a component

Large classes may be decomposed into several components
Components form subsystems
Building of a layered hierarchy
Configuration management to facilitate maintenance (Sources management,

Documentation)
Class diagrams (specification and implementation perspective)

Interaction diagrams (detailed sequence and communication diagrams)
Component diagrams
Package diagrams (namespaces)
OOAD Training
68
4+1 views
Process view
Focus on processes
Decomposition of the System in tasks (processes) focusing mainly on non-functional
requirements such as performances, availability, etc.
Each task is a separate thread of control is scheduled individually on a processing
node
Map the operations of an object to the threads of control
Address issues of concurrency, system integrity, fault-tolerance, etc.
Important view for multitasks environments
Process interactions
Synchronization and communication of parallelized tasks
Optimisation of CPUs usage
Prioritisation of tasks

Class diagrams (specification perspective)
Activity diagrams (detailed level)
OOAD Training
69
4+1 views
Deployment view (also called physical view)
A view describing the material configuration of the System focusing mainly on

non-functional requirements such as reliability, performance, scalability, etc.
Important view for distributed environments and both testing and production
environments
Definition of the nodes (hardware devices) executing the Components

Servers
Network

Deployment diagrams
OOAD Training
70
4+1 views
Use Case View
This view describes the behaviours of the system from the end-user point of
view
Glue that unifies the 4 others views of the architecture

Redundant view but justifies and motivates the architecture
Focuses on the satisfaction of the user requirements
Assures a consistent and pertinent architecture

Use case diagrams
System Sequence diagrams illustrating the use case scenarios
Activity diagrams illustrating the use case scenarios
OOAD Training
71
Objectives

Agenda

Analysis packages
Package Diagrams
What is a package?
A package
UML element that enable to organize model elements into groups

Higher level of UML classifier represented as a file folders containing
Use-cases
Classes
Other packages
Represents a namespace
Abstract container providing context for items
The same identifier may be defined in multiple namespaces independently
All the element in a package share the same namespace and must have unique names
OOAD Training
73
Package Diagrams
A package diagram
Illustrate the logical architecture of a system

Layers (UI layer UI package)
Subsystems
Java packages
Presents the dependencies between packages
OOAD Training
74
Package Diagrams
Class Package Diagram
A class package diagram
Package diagram that involves classes hierarchy

Grouping classes in packages ?
Group classes in the same inheritance hierarchy
Group classes related via composition
Group classes that collaborate with each other (in sequence diagrams and
communication diagrams)
OOAD Training
75
Package Diagrams
Class Package Diagram
1..*
1
1..*
1
0..*
OOAD Training
Held
at
76
Package Diagrams
Use-case Package Diagram
A use-case package diagram
Organise the use case into packages

Sponsor discussions
Project progress overview
Grouping use cases in packages ?

Group included and extending use cases with base/parent use case
Produce cohesive packages by gathering the use case that are involved in a common
main goal
OOAD Training
77
Objectives

Agenda

Analysis packages
Course organisation
OOAD Training
79
Evalutation
Core metrics
End of elaboration iteration
Work and progress

Iteration planning: plans vs actuals
Budgeted cost and expenditures

Financial insights: plans vs actuals
Staffing and team dynamics

Resource planning: plans vs actuals
Hiring rates, people leaving, people arriving
Change traffic and stability

Iteration planning, schedule convergence
Change requests opened, closed
Breakage and modularity

Software scrap quality, convergence
Rework and adaptability

Software rework and convergence (time to change)
Maturity
Test coverage and adequacy; robustness for use, failure counts
OOAD Training
80
Evalutation
About Fixed-price projects
Recommendation: two contract phases
First phase:
Choose
Short fixed-time and fixed-price with insured margin
Short time-based phase
Completing a few iterations (2 or 3 max)
3 requirements work shops (max 75%)
Core architecture 60% build
10 % final software
Merely producing code
Second phase:
From outputs of the first phase
Fixed-price on better bases
Requirement convergence
OOAD Training
81
Objectives

Agenda

Analysis packages

OOAD With UML and The UP - Session 4 - Elaboration

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OOAD With UML and The UP - Session 4 - Elaboration

Hochgeladen von

Copyright:

Verfügbare Formate

Altran CIS

Object-Oriented Analysis and Design

Session 4 Elaboration Phase First Iteration

Objectives and Agenda

Understand elaboration phase objectives

Analysis discipline overview

Software Engineering Process

Stabilize the vision

Rational Unified Process

Iterative elaboration of the executable architecture baseline

Risks resolution / assessment

Plan next phases

Rational Unified Process

Analysis Establish what to build

Rational Unified Process

Objectives and Agenda

Understand elaboration phase objectives

Analysis discipline overview

Produce an analysis model

Two key artifacts:

Analysis classes = key concepts in business domain

Use Case Analysis

Objectives and Agenda

Understand elaboration phase objectives

Class diagrams basics

But wait, what is a class?

I know, it's inside a class

Class diagrams basics

People are more important than process

OO is not the use of a particular tool or language

Class diagrams basics

A class diagram describes:

Class diagram is the most common type of UML diagram

Class diagrams basics

A discrete entity with a well-defined boundary that encapsulate

Class diagrams basics

The description for a set of objects that share the same:

Class diagrams basics

An object is an instance of a class

Class diagrams basics

Named properties, characteristics of a class

Only name is mandatory in analysis

Class diagrams basics

Summary of what the class should do (actions, knowledge, decisions)

-- determine the risk of a

-- manage shape state

Class diagrams basics

Services that can be invoked on an object

An operation's implementation is called a method

Use {isQuery = true} property

Class diagrams basics

By default: instance scope

All objects share the same values

Class scope operations do not apply to a

Class diagrams basics

Exposing services and hiding internal details

1. Hide data behind operations

Class diagrams basics

An association represents a conceptual connection between classes

Class diagrams basics

Class diagrams basics

consists of, contains, is part of

No particular semantic, "A modeling placebo" (J.Rumbaugh)