OOAD With UML and the UP - Session 4 - Elaboration

1OOAD Training

Altran CISObject-Oriented Analysis and Design

Session 4 – Elaboration Phase – First Iteration

Trainers: Pierre LE FEVERE DE TEN HOVE

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

3OOAD Training

Course organisation

DomainModel

UC

BPM

Priorit. UCKick-off

Kick-off

4OOAD Training

Software Engineering ProcessRational Unified ProcessElaboration PhaseElaboration Main Objectives

• Stabilize the vision

• Iterative elaboration of the executable architecture baseline

• Risks resolution / assessment

• Refine requirements

• Construction phase plan with realistic estimates

5OOAD Training

Rational Unified ProcessElaboration 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

6OOAD Training

Rational Unified ProcessElaboration 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

7OOAD Training

Rational Unified ProcessElaboration Phase


• 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





AnalysisDiscipline 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

9OOAD Training

AnalysisModel

P1

P2

P3

P4

10OOAD Training

AnalysisRUP Workflow

Input: • Architecture• Requirements

Output: • Analysis model

ObjectivesFind analysis classesDescribe interaction

between them

Analysis & DesignAnalyze behavior Use Case Analysis


• Objectives


• Agenda


Analysis discipline overview• Finding analysis classes





AnalysisFinding analysis classes

12OOAD Training

But wait, what is a class?

I know, it's inside a class diagram!

13OOAD Training !!!

Class diagrams basicsOO 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

14OOAD Training

Class diagrams basics Introduction

A class diagram describes:• the types of objects in the system• the static relationships between them

It shows features of classes

Class diagram is the most common type of UML diagram

Feature

Property

Attribute Association

Operation

“A discrete entity with a well-defined boundary that encapsulate state and behavior” J. Rumbaugh

Properties

• Identity : reference• State : attributes and values• Behavior : operations & methods

The structure and behavior of similar Objects are defined in their common Class

15OOAD Training >>

Class diagrams basics What is an Object?

1254868"Bill

Gates"315.00 €

deposit()

withdraw()

getOwner()

setOwner()

an Account object

16OOAD Training >>

Class diagrams basics 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

17OOAD Training >>>

Class diagrams basicsClass & Objects

An object is an instance of a class

withdraw()deposit()

number : Stringowner : Stringbalance : double

Account

number = 456owner = "Bill"balance = 1,000,000.00

billAccount : Account

number = 457owner = "Richard"balance = 300.00

richardAccount : Account

<<instantiate>>

<<instantiate>>

18OOAD Training

Class diagrams basics Attributes

• Named properties, characteristics of a class• Typed: description of the range of possible values

Syntax: visibility name: type [multiplicity] = initial value

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

19OOAD Training !!!

Class diagrams basics 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

LoanOfficerName

-- determine the risk of a customer loan-- handle customer-specific criteria for loan

ShapeIdentification number

-- manage shape state-- handle basic shape transformation

20OOAD Training

Class diagrams basics Operations

• Services that can be invoked on an objectto realize behavior

• Define the responsibilities of objects• Shared by all instances of the class

• An operation's implementation is called a method

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} propertyto indicate operation has no side effect and does not change state

signature

21OOAD Training

Class diagrams basics 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

manage balance

manag

e owne

r

22OOAD Training !!!

Class diagrams basicsEncapsulation

Exposing services and hiding internal details

3 levels of encapsulation:1. Hide data behind operations2. Limit access with visibilities3. Group related operations with interfaces

+deposit()

+withdraw()

+getOwner()

+setOwner()

1254868"Bill

Gates"315.00 €

23OOAD Training >>

Class diagrams basics Relationships - Associations

An association represents a conceptual connection between classesIt 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:

Team Personplayer

0..1 0..*

Plays for

Name Role

Multiplicity

Navigability

24OOAD Training >>

Class diagrams basics Association examples

25OOAD Training >>

Class diagrams basics 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

26OOAD Training !!!

Class diagrams basics 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

27OOAD Training >>

Class diagrams basics Generalization and inheritance

Generalization

SpecializationCar

Sport Car

Berline Car

Wheel

Body

Motor

Seat

Aileron

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• mechanism of sharing attributes and operations using

generalization relationship

28OOAD Training

Class diagrams basicsGeneralization relationship

Special type of association: “parent - child” relationshipKeywords 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

29OOAD Training

Class diagrams basicsClassification

Generalization = relation between a child class and its parent classClassification = 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}

• Dynamic or static classification

30OOAD Training

Class diagrams basics 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


• Objectives


• Agenda


Analysis discipline overview• Finding analysis classes





32OOAD Training >>

Finding analysis classes 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

33OOAD Training

Finding analysis classes Sources (1/2)

•Domain model

•Noun/verb extraction from use cases and other req. documents

•Categories checklist

Conceptual class categories Examples

Physical or tangible objects Plane, Bottle, Car

Descriptions of things Flight description

Places Airports

Interactions Meeting, Agreement, Interview

Transactions ReservationRoles Pilot, doctor, teacherContainers Store

Organizations Sales Department

34OOAD Training

Finding analysis classes Sources (2/2)

RUP stereotypes <<boundary>>, <<control>>, <<entity>>

CRC card analysis• Class• Responsibility• Collaborations

35OOAD Training

Finding analysis classes 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

36OOAD Training

Finding analysis classes 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

37OOAD Training

Finding analysis classes Finding Associations

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

Categories checklist

38OOAD Training >>

Finding analysis classesBest 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


• Objectives


• Agenda


Analysis discipline overview Finding analysis classes





40OOAD Training

Interaction diagramsIntroduction (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

41OOAD Training

Interaction modelingIntroduction (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

42OOAD Training

Interaction modelingInteraction diagrams


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

43OOAD Training

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

Interaction modelingInteraction diagrams Uses and aspects

44OOAD Training

Interaction modelingSequence diagramsIntroductionSequence 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?

45OOAD Training

Interaction modelingSequence diagrams Introductive exampleIntroductive example• Two dimensions

• Vertical axis shows the time• Horizontal axis shows a group of objects

46OOAD Training

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

47OOAD Training

Interaction modelingSequence diagrams UML Components (2/9)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

48OOAD Training

Interaction modelingSequence diagrams UML Components (3/9)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

49OOAD Training

Interaction modelingSequence diagrams UML Components (4/9)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

50OOAD Training

Interaction modelingSequence diagrams UML Components (5/9)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 )

51OOAD Training

Interaction modelingSequence diagrams UML Components (6/9)Combined fragments• Interaction operator• Guard conditions• Interaction operand

52OOAD Training

Interaction modelingSequence diagrams UML Components (7/9)Combined fragments

53OOAD Training

Interaction modelingSequence diagrams UML Components (8/9)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

54OOAD Training

Interaction modelingSequence diagrams UML Components (9/9)Time constraints• Useful for modeling

• time-bound business process• real-time system

• Time along the vertical axis

55OOAD Training

Interaction modelingSequence diagramsForms and FormatInstance 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

56OOAD Training

Interaction modelingSequence diagramsWithdraw Money from ATMDraws attention to time sequence

57OOAD Training

Interaction modelingCommunication diagramsIntroductionCommunication diagrams• 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

58OOAD Training

Interaction modelingCommunication diagrams Introductive exampleIntroductive example• Objects shown with association connectors• Numbering scheme for sequence• Package overlaying• Objects operations

59OOAD Training

Interaction modelingCommunication diagrams Sequence vs Communication

60OOAD Training

Interaction modelingCommunication diagrams Sequence vs Communication

61OOAD Training

Interaction ModelingInteraction DiagramsConclusionsMain 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


• Objectives


• Agenda







63OOAD Training

Use case realizations

Use case realizations

• One per use case

• A set of classes + a set of interaction diagrams showing collaborations

• Usually, discovery of new analysis classes

Analyze behavior


• Objectives

Understand elaboration phase objectives• Master analysis discipline Acquire know how of class, interaction & state machine diagrams• Understand architecture

• Agenda



Class diagrams basics Use case realizations




65OOAD Training

Software ArchitectureIntroduction

Architecture is many things to many different interested parties• multiple project’s 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

66OOAD Training

Software Architecture4+1 viewsOverviewRUP presents the Software Architecture in the 4+1 views

Process View Deployment View

Logical View

Use-Case View

Implementation View

End-user Functionality

Programmers Software management

PerformanceScalabilitySynchronisation and concurrency

System integratorsSystem topology

Delivery, installationCommunication

System engineering

Analysts/DesignersStructure

67OOAD Training

Software Architecture4+1 viewsDetailed 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)

68OOAD Training

Software Architecture4+1 viewsDetailed views (2/5)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)

• UML diagrams involved• Class diagrams (specification and implementation perspective)• Interaction diagrams (detailed sequence and communication diagrams)• Component diagrams• Package diagrams (namespaces)

69OOAD Training

Software Architecture4+1 viewsDetailed views (3/5)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

• UML diagrams involved• Class diagrams (specification perspective)• Activity diagrams (detailed level)

70OOAD Training

Software Architecture4+1 viewsDetailed views (4/5)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• …

• UML diagrams involved• Deployment diagrams

71OOAD Training

Software Architecture4+1 viewsDetailed views (5/5)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

• UML diagrams involved• Use case diagrams• System Sequence diagrams illustrating the use case scenarios• Activity diagrams illustrating the use case scenarios


• Objectives

Understand elaboration phase objectives• Master analysis discipline Acquire know how of class, interaction & state machine diagrams• Understand architecture

• Agenda





Architecture introduction• Analysis packages


73OOAD Training

Software ArchitecturePackage DiagramsWhat 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

74OOAD Training

Software ArchitecturePackage Diagrams

A package diagram• Illustrate the logical architecture of a system

• Layers (UI layer UI package)• Subsystems • Java packages

• Presents the dependencies between packages

75OOAD Training

Software ArchitecturePackage DiagramsClass Package DiagramA 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)

76OOAD Training

Software ArchitecturePackage DiagramsClass Package Diagram

1

1..*

0..*1

11..*

Held at

77OOAD Training

Software ArchitecturePackage DiagramsUse-case Package DiagramA 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


• Objectives

Understand elaboration phase objectives Master analysis discipline Acquire know how of class, interaction & state machine diagrams Understand architecture

• Agenda





Architecture introduction Analysis packages


79OOAD Training

Course organisation

80OOAD Training

EvalutationCore 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

81OOAD Training

EvalutationAbout 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


• Objectives

Understand elaboration phase objectives Master analysis discipline Acquire know how of class, interaction & state machine diagrams Understand architecture

• Agenda





Architecture introduction Analysis packages

Iteration evaluation