V 1.0 -- 10/23/2015 10:07:20 AM© 2000 Jean-Paul RigaultUML: Product Definition -- 1 Product...

V 1.0 -- 04/20/23 02:55 AM © 2000 Jean-Paul RigaultUML: Product Definition --

1

Product Definition with theUnified Modeling Language

Jean-Paul RigaultProfessor at ESSI (École supérieure en sciences

informatiques)University of Nice Sophia Antipolis, FranceEmail: [email protected]


2

Objectives

Overview of the Unified Modeling Language

Specific emphasis on the first phases of the development cycle

Requirements capture: Use Case Modeling Analysis: Class and Object Modeling


3

Contents

The Object-Oriented Paradigm A world of objects The importance of modeling

Overview of the UML History and objectives Basic concepts and building blocks

Requirement Capture Functional requirements: Use Cases, Scenarios Formalizing Scenarios: Activity, Sequence, Collaboration

Diagrams Analysis: from Use Cases to Objects

Objects and Classes: Class Diagrams Refining scenarios

References


4

The Object-Oriented Paradigm


5

A World of Objects

The (application) world is composed of objects

These objects are linked together Static relationships

These objects react to stimuli (messages) Either internal or external Originating from other objects or from outside the

system These objects have an internal state

Internal data (attributes) and status of the links with other objects

The state may change when the objects are stimulated


6

The Essence of the Object-Oriented Approach

Identify objects Reduce the gap between the application

world and its computer representation Identify attributes and operations (messages)

Identify static relationships (links) between objects

Architectural decomposition Peer to peer relationships (usually semantic) Hierarchical relationships (usually structural)

Links are the media for messages


7

The Essence of the OO ApproachCommunication by Messages

Usually asymmetric The emitter knows (designates) the receiver The receiver does not know the emitter

Message may carry values (parameters) Messages are usually (but not only)

implemented by operation call Function call with specific syntax to designate the

receiver

y = an_object.f(x1, x2, …);


8

The Essence of the OO ApproachTypes of Messages

Synchronous Function/procedure call, wait for return

Asynchronous Send an event, no return expected

Balking Do not delivered if the receiver is not waiting

for it and notify sender Timed Out Periodic Etc.


9

What's in an Object?

Object = Identity + State + Behavior

Objects should be distinguishableThe identity is independent from the state

Operations, events, messages…Public interface

Internal dataRelationships with other objectsUsually encapsulated


10

What's in a Class

Class = group of objects with Identical structure: same attributes and links Identical behavior: same operations

Instance = a particular object belonging to a class

Although similar in structure and behavior, instances are distinguishable one from the other

A class defines a type Set of values (all instances of the class) Legal operations


11

The Object-Oriented Approach

anOtherObjectInternal

data(attributes)

anObject

Internaldata

(attributes)

message(parameters)

(static) link op1

op2


12

The Object-Oriented Approach

Vehicle

CarVan

AircraftBoat

Basic Concepts

Abstraction

TestVerifValid

Exec Simulation

Real World

Vehicle

Plane Boat Car

Abstraction

Model

RealizationCode


13

Object-Oriented Modeling

Modeling is customary in all engineering disciplines

A model is a simplification of reality The four aims of modeling

Visualize the system Specify the structure and behavior of the

system Provide a template to help us in building the

system Document the decisions we have made


14

Object-Oriented Modeling (cont.)

Principles of modeling The choice of a way of modeling influences how

a problem is attacked, and how a solution is elaborated

Every model may be expressed at different levels of precision or abstraction

The best models are connected to reality No single model is sufficient;

we usually need several nearly independent models


15

Object-Oriented Glossary

Abstraction Separate usage information

from implementation details Modularity

Group semantically related things together

Encapsulation Hiding unnecessary

information Message

Dynamic flow of information between objects

They need links to travel

Link Static relationship between

objects They provides the

infrastructure for exchanging messages

Object An abstraction of a "thing"

in the application world It has crisp boundaries It owns a state, a behavior,

and an identity It has links with other

objects It exchanges messages

with them


16

Object-Oriented Glossary (cont. 1)

Class A group of objects with

identical structure and behavior

A model for a group of objects

It defines a type Type

A set of values together with the legal operations on these values

Instance of an X An object following the

model given by X

Instance of a class An object following the

model given by the class Association

A relationship between to classes, modeling the links that the instances of the two classes may have together

A model of the links between the instances of the classes

Links are instances of associations


17

Overview of the UML


18

ContentsOverview of the UML

Brief history Purpose of the UML A conceptual view of the UML


19

Many OOAD methods(> 50)

Coad-Yourdon

Shlaer-Mellor

Fusion

etc.

Brief History of the UML

1991 1992 1993 1994 1995 1996 1997 1998 1999 2000

Booch (Rose)Good for design

and construction

Rumbaugh (OMT)Good for analysis and

data-intensive systems

Jacobson (OOSE)Good for the capture

of requirements

UML

0.8UML

0.9

Rational

UML

1.0

UML

1.1

OMG request

UMLconsortium

UML

1.2

UML

1.3

UML

2.0?

OMG

OMG vote


20

What is the UML?

The UML is a language for Visualizing Specifying Constructing Documenting

the artifacts of a software-intensive system


21

Where Can the UML Be Used?

Software intensive systems… Enterprise information systems; Banking and financial

services Telecommunications Transportation; Defense; Aerospace Medical electronics Scientific applications Distributed Web-based services etc.

But also non-software systems Workflow Patient healthcare systems Hardware design…


22

The UML and the Software Development Methodologies

The UML is methodology independent However it is better suited to a

development process that is Use case driven Architecture centric Iterative and incremental


23

The UML and the MethodologiesUse Case Driven

Use cases model the major ways of using the system

Use cases are a systematic and intuitive way for capturing functional requirements

They represent the expected behavior of the system as seen by end users, analysts, and testers

They drive the whole development process

Analysis, design, and tests are all drawn from use case


24

The UML and the MethodologiesUse Case Driven (cont.)

Use CaseModel

AnalysisModel

DesignModel

TestModel

DeploymentModel

ImplementationModel

specified by

realized bydistributed by

implemented by

verified by


25

The UML and the MethodologiesArchitecture Centric

The 4+1 views of architecture modeling

Threads and processesConcurrency andSynchonizationProcess View

Threads and processesConcurrency andSynchonizationProcess View

Implementation ViewComponents and files

ReleasesConfigurationmanagement

Implementation ViewComponents and files

ReleasesConfigurationmanagement

Design ViewVocabulary of the systemand its solutionFunctionalRequirements

Design ViewVocabulary of the systemand its solutionFunctionalRequirements

Support hardwareDistribution, installation

Deployment View

Support hardwareDistribution, installation

Deployment View

Use Case ViewBehavior of the systemServices for end users

Use Case ViewBehavior of the systemServices for end users


26

The UML and the MethodologiesIterative and Incremental

InceptionInception ElaborationElaborationConstructionConstructionTransitionTransition

What?For whom?How much?

Market studyEconomic

opportunity

RequirementanalysisDomain

modeling

Productdevelopment

Handlingchanges

Transfertoward

end users

time


27

The UML and the MethodologiesIterative and Incremental (cont.)

Elaboration Construction TransitionInception

Phases

Requirements Capture

Analysis & Design

ImplementationTest

ManagementEnvironmentDeployment

Process Components

Supporting Components

Iterations

preliminaryiteration(s)

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

Organizationalong content

Organization along time


28

A Conceptual View of the UML

Building blocks (modeling elements) Rules to assemble the blocks Common mechanisms


29

A Conceptual View of the UMLBuilding Blocks (Modeling Elements)

"Things" Abstractions, first-class citizen in the model

Relationships Tie "things" together

Diagrams Group interesting collections of things and

express (some of) their relationships


30

A Conceptual View of the UMLBuilding Blocks: "Things"

Structural "things" The "nouns" of the model class, interface, collaboration, use case, active

class, component, node Behavioral "things"

The "verbs" of the model interaction, state machine

Organizing (grouping) "things" package

Annotational "things" note


31

A Conceptual View of the UMLBuilding Blocks: "Things" (cont. 1)

class interface

Personnameaddressmove()marry()

attributes

operations

name

Persistent

Persistentsave()restore()

Object

bill : Person


32


collaboration Defines an interaction A society of roles,

objects, or other elements to provide some cooperative and synergic behavior

Possibly structural as well a behavioral

Used to model Patterns (design or analysis patterns)

MVC pattern

Model

Controler

View


33


use case Set of sequences of

actions that a system performs and that yields an observable result

A set of related services provided by the system, together with scenarios of use

Place an order


34


active class A class owing its

own thread of control

Its behavior is concurrent with other elements

PerformanceControler

activate()suspend()


35


component Physical and replaceable

part of a system Realize a set of interface Source code, library…

node Physical element that

exists at run time representing computational resource

FileServer

person.cpp


36


interaction Exchange of

messages between objects

state machine Sequence of states

through which an object or an interaction goes during its lifetime, in response to eventsbill : Customer

: BillingSystem

pay() Wait password

Check password

state

transitionpasswd entered


37


package General-purpose

mechanism for organizing model elements into groups

Purely conceptual (exists only at development time)

note Explanatory parts,

comments May be attached to

any modeling element

ProductDefinition

Model

This is a package


38

A Conceptual View of the UMLBuilding Blocks: Classifiers

Classifier Describe structural and behavioral features Can have instances Can be involved in a generalization relationship

UML classifiers class, interface, datatype, signal component, node use case subsystem (specialized package)


39

A Conceptual View of the UMLBuilding Blocks: Relationships

dependency A semantic relationship between two things When the target changes, the source might have to change

association A structural relationship describing a set of links Some special cases (aggregation, composition)

generalization Objects of the specialized element are substitutable for

objects of the more general element realization

Semantic relationship between classifiers wherein one component specifies a contract that the other guarantees to carry out


40

A Conceptual View of the UMLBuilding Blocks: Relationships (cont. 1)

dependency

Link Instance of association

Graphicinterface

MFC

ProductDefinition

Model

DesignModel

Man Womanwedlock

association

bill : Man

hilary : Woman


41

A Conceptual View of the UMLBuilding Blocks: Relationships (cont. 2)

generalization realization

Vehicle

Plane Boat

Man Woman

Person

Persistent

Person

Persistent

Person


42

Dynamicdiagrams

A Conceptual View of the UMLBuilding Blocks: Diagrams

Class diagram Object diagram Use case diagram Sequence diagram Collaboration

diagram Statechart diagram Activity diagram Component diagram Deployment diagram

Static diagrams

Static (implementation) diagrams

Interaction diagrams

State-transition diagrams


43

A Conceptual View of the UMLModeling Software Architecture

Mapping the UML building blocks on the 4+1 views

Same diagrams as for the Design ViewFocus on active classes

Process View

Same diagrams as for the Design ViewFocus on active classes

Process View

Implementation ViewComponent diagrams

Interaction, statecharts,and activity

diagrams

Implementation ViewComponent diagrams

Interaction, statecharts,and activity

diagrams

Design ViewClass & object diagramsInteraction, statecharts,and activitydiagrams

Design ViewClass & object diagramsInteraction, statecharts,and activitydiagrams

DeploymentDiagrams

Interaction, statecharts,and activity diagrams

Deployment View

DeploymentDiagrams

Interaction, statecharts,and activity diagrams

Deployment View

Use Case ViewUse case diagrams

Interaction, statecharts, and activitydiagrams

Use Case ViewUse case diagrams

Interaction, statecharts, and activitydiagrams


44

A Conceptual View of the UMLRules

Well-formed model Rules for

Names Scopes Visibility Integrity Execution

Badly-formed models

Elided Incomplete Inconsistent

Badly-formed models cannot be avoided during the project life-cycle


45

A Conceptual View of the UMLCommon mechanisms

Specifications (usually textual-like) Representations stating

the exact details of a model element (its properties)

Adornments Graphical or textual adornments supplying

extra semantics Common divisions Extensibility mechanisms


46

A Conceptual View of the UMLCommon mechanisms: Divisions

Separation principles Separation Class/Instance

Class and objects Association and links Use cases and scenarios…

Separation Interface/Implementation Interface: declaration of a contract Implementation: one concrete realization of that

contract Interface and concrete classes Use case and collaboration Operation and method


47

A Conceptual View of the UMLCommon mechanisms: Extensibility

stereotypes Extend the UML vocabulary New kinds of building blocks derived from

existing ones tagged values

Extend the properties of an UML building block New information in the element's specification

constraints Extend the semantics of a building block New rules or modification of existing ones Specialized language: Object-Constraint

Language (OCL)


48

A Conceptual View of the UMLCommon mechanisms: Extensibility (cont. 1)

stereotypes

bill

Person

« instanceOf »

Graphicinterface

MFC

« access »

« abstract »Person

Person

« interface »Persistentsave()restore()

Persistentsave()restore()


49


Iconified stereotypes

« actor »Customer

Customer

« realize »

« subsystem »Billing Billing

« model »Design View Design View


50


tagged values and properties

Person{version = 1.0 author = jpr}

name {frozen}addressage

move() marry() single()

{pre: age > 18 and single()}

constraints


51

Requirement Capture


52

ContentsRequirement Capture

A simplified Automatic Teller Machine Which requirements are to be

captured? The activities in Requirement capture

Identification of system boundaries: actors and use cases

Diagramming use cases Elaborating scenarios Dividing large systems Diagramming scenarios


53

A Simplified Automatic Teller Machine

The ATM is associated with only one bank

It gives access to all the accounts the customer owns in the bank

Several types of transactions can be chained in a single session

Withdrawal, deposit, transfer between the customer’s own accounts, consulting an account

The customer may obtain a printed receipt for each transaction


54

A Simplified Automatic Teller Machine (cont. 1)

The card contains an ID number an expiration date a secret code

The card must be verified by the ATM

The customer cannot make more than 3 attempts to enter the correct code, otherwise the card is swallowed

Interface Keyboard and screen, with menus The customer may cancel the

current transaction at meaningful points


55

A Simplified Automatic Teller Machine (cont. 2)

The connections with the bank are kept to a minimum

When a session is opened, a connection makes it possible to known all the accounts the customer owns

Every night, the information about the current day transactions are transferred to the bank

From time to time an employee manually

empties the machine and/or fills it with bank notes

supplies consumables and does any maintenance that may be needed


56

Which requirements are to be captured?

Functional requirements Modeled as Use Cases

Non functional requirements Some are specific to one use case Some relate to technical issues addressed by

implementation diagrams and models Other in some supplementary documents, out

of the UML scope…


57







58

Identifying System BoundariesIdentifying Actors

Actors are anything which interface with the system

People, other systems, hardware, software, networks… They are roles, not necessarily full-fledged objects

Some questions to help identify actors: Who uses, installs, starts up, shuts down, maintains the

system? Who provides (gets) information to (from) the system? What other systems use the system?

Actors are not part of the system They are just at the boundary They won’t produce code!


59

Identifying System BoundariesIdentifying Actors (cont.)

ATM example Customer using the

teller machine Bank Maintenance

technician

What about the card itself?

Customer

Bank

Technician


60

Identifying System BoundariesIdentifying Use Cases

Use cases describe the services the actors want the system to do for them

Questions to ask: What do the actors expect from the system? Does the system store information? Which actors

create, consult, update or delete this information? Does an actor need to notify the system about a

change in its internal state? Are there external events the system must know

about? Which actor informs the system about these events?


61

Identifying System BoundariesIdentifying Use Cases (cont. 2)

Customer expects the following

Processing various sorts of transactions

Get a receipt Verification of the card Authentification Chaining transactions

together

Bank expects the following

Be requested the list of accounts corresponding to a given card

Get the information about the daily transactions

Technician expects the following

Authentification Access to special reset

and maintenance functions


62


Do not model at too low level! Bad Customer use cases

insert the card enter secret code, get ticket select transaction type, select accounts, select

amount… Even worse

push the Enter button on the keyboard… Do not model outside the system!

Bad Customer use cases chosing a particular ATM machine deciding how much money to withdraw


63


Organize use cases Give a meaningful name to each use case

usually an active verbal form Organize use cases hierarchically

ATM example: Customer use cases revisited

Handle Session, which includes Verify Card Authentify Customer Get Customer Information Handle Transaction with optional Deliver Receipt

Handle Deposit, Handle Withdrawal…-


64







65

Diagramming Use CasesTop Level Use Case Diagram

Handle Session

Transfer Daily

Maintain

Bank

Technician

Customer

associationsystem boundary


66

Diagramming Use CasesStereotyped Dependencies

HandleSession

« include »

VerifyCard

« include »

AuthentifyCustomer

« include »

Get CustomerInformation

HandleTransaction

« include »

DeliverReceipt

« extend »


67

Diagramming Use CasesStereotyped Dependencies (cont.)

« include » The included use case is a mandatory part of

the including one

« extend » The extending use case is an optional part of

the extended one

Including« include »Included

Extended« extend »Extending


68

Diagramming Use CasesGeneralization (cont.)

Handle

Transaction

Handle

Deposit

Handle

Withdrawal

Handle

Consult

Handle

Transfer


69

Diagramming Use CasesGeneralization (cont.)

The specialized and generalized use cases are in a “sort of” relationship

Generalized

Specialized


70







71

Elaborating scenariosUse Case and Scenarios

Use cases classify the ways of using the system

To each use case correspond many possible usage scenarios

Thus scenarios are instances of use cases specify use cases

Each use case has generally a primary scenario several secondary (more exceptional) scenarios


72

Elaborating scenariosPrimary Scenario

Use Case: Handle SessionScenario: Primary (typical)Precondition: the ATM is

free1. The scenario starts when

the customer inserts the card

2. The ATM accepts the card3. The customer enters the

secret code correctly4. The ATM gets the

customer information from the bank

5. The customer performs a transaction

6. When the transaction is finished, the customer may ask for another transaction (go to 5) or quit

7. The scenario is finished when the customer decides to quit; the card is ejected

Postcondition: the ATM is free


73

Elaborating scenariosExample of Secondary Scenarios

Use Case: Handle SessionScenario: Secondary

(customer interrupt)Precondition: the ATM is



2. The ATM accepts the card3. The customer enters the

secret code correctly4. The customer cancels the

session

5. The ATM ejects the card and the scenario is finished



74

Elaborating scenariosExample of Secondary Scenarios

Use Case: Handle SessionScenario: Secondary (bad

card)Precondition: the ATM is



2. The ATM rejects the card: this ends the scenario


Use Case: Handle SessionScenario: Secondary (bad

code)Precondition: the ATM is free1. The scenario starts when the

customer inserts the card2. The ATM accepts the card 3. The customer fails to enter a

correct code three times4. The card is swallowed; this

ends the scenarioPostcondition: the ATM is free


75

Elaborating scenariosScenarios and Use Case Inclusion

Use Case: Handle SessionScenario: Primary (typical)Precondition: the ATM is free1. The scenario starts when


2. Include Verify CardThe card is accepted

3. Include Authentify CustomerThe customer enters the secret code correctly

4. The ATM gets the customer information from the bank

5. The customer performs a transaction

6. The customer executes the transactionInclude Handle Transaction

7. When the transaction is finished, the customer may ask for another transaction (go to 5) or quit

8. The scenario is finished when the customer decide to quit; the card is ejected



76

Elaborating scenariosScenarios and Use Case Extension

Use Case: Handle TransactionScenario: Primary (typical)Precondition: the customer has

decided to perform a transaction (in Handle Session)

1. The scenario starts when the customer decides not to quit the session

2. The customer selects and execute the transaction

3. Extension point: Deliver Receipt4. The scenario is finished; go back

to Handle SessionPostcondition: the transaction is

recorded

DeliverReceipt

« extend »

Handle Transactionextension point:

at the end of transaction: Deliver Receipt


77







78

Dividing Large SystemsArchitectural Patterns

3-tier architecture pattern

The database plays a crucial role The system use cases are distributed among

the various subsystems It is difficult to change a subsystem

« subsystem »User Interface

« subsystem »Business Rules

« subsystem »Database


79

Dividing Large SystemsArchitectural Patterns (cont. 1)

Pipe and filter architecture pattern

Each subsystem is responsible for some transformation on the data

Subsystems can be substituted easily, since the only dependence is on the data

« subsystem »Take Orders

« subsystem »Ship Orders

« subsystem »Handle

Payments

« subsystem »Data


80

Dividing Large SystemsArchitectural Patterns (cont. 2)

Object-oriented architecture pattern

Subsystems own data and associated functions The dependencies are more flexible Each function exists in only one place

« subsystem »Take Orders

« subsystem »Ship Orders

« subsystem »Handle

Payments


81

Dividing Large SystemsDecomposing the ATM in subsystem

« subsystem »User Interface

« subsystem »Session Control

« subsystem »Transaction

Archive

« subsystem »SessionControl

« subsystem »Bank

Connection

« subsystem »Transaction

Archive

« subsystem »HardwareControl


82

Dividing Large SystemsTesting the architecture

Each subsystem should have A single functionality Strong internal cohesion Loose external coupling Minimal communication with other subsystems A clear and precise interface with other

subsystems that use it


83

Dividing Large SystemsTesting the architecture (cont.)

« subsystem »Session Control

« subsystem »Bank Connectionget_customer_info

« subsystem »Transaction Archiveget_daily_tranactionsarchive_transaction

« subsystem »Hardware Controlcontrol_card_devicecontrol_cash_deviceetc.


84

Dividing Large SystemsAllocating use cases to subsystems

Use case related to session and transactions

in subsystem Session Control except Get Customer Information Bank

Connection Transaction induces a subordinate use case in

Transaction Archive Daily Transfer use case

in subsystem Bank Connection with subordinate use case in Transaction

Archive


85







86

Diagramming Scenarios

Scenarios are instances of use cases Natural language for expressing

scenarios has a strong power of expression lacks precision makes it difficult to express information like

timing and concurrency Need for formal (UML) expression of

scenarios and use cases


87

Diagramming ScenariosUML ways of expressing scenarios

Activity diagrams Several scenarios (even a full use case) at once Similar to Petri nets, Graphcet, (concurrent) flow

charts… Interaction (sequence and collaboration)

diagrams Only one scenario per diagram Involve/introduce (high level) objects Sequence diagram

Accent on the time flow Collaboration diagram

Accent on the messages between objects


88

Diagramming ScenariosActivity Diagrams

Express a flow of control Composed of Action States connected by

Transitions Transitions may be conditional A Transition is taken if its origin Action State has

completed its action and if its (optional) condition is true

Verify Date [date OK]

Verify Code

condition

transition

action state


89

Diagramming ScenariosActivity Diagrams (cont.)

Verify Card

[card KO]

[card OK]

[code KOand no moreattempts]

Verify Code [code KOand nb attemptsless than 3]

[code OK]

Get CustomerInformation

Eject Card

PerformTransaction

[not Quit]

[Quit]

HandleSessionUse Case


90

Diagramming ScenariosActivity Diagrams: Concurrency

Wait forthirst

Put coffeein filter

Pour waterin coffeemachine

Find cups

Put filterin coffeemachine

Switchmachine

onWait forcoffee

[there is coffee]

[no more coffee]

Get one

[there is beer]

[let’s starve]

Pour coffee

Drink it


91

Diagramming ScenariosSequence Diagrams

Describe one scenario Involve objects and messages Accent is on the time flow of events


92

Diagramming ScenariosSequence Diagrams (cont.)

get_Customer_Information()

select_transaction(sel)

display_menu()

quit

: Customer : Bank

time card_taken

eject_cardcard_returned

insert_card

: ATM

: Session« create »

: Transaction« create »

display_menu()


93

Diagramming ScenariosCollaboration Diagrams

Describe one scenario Involve objects and messages Accent is on messages exchanged

between objects

Sequence and Collaboration diagrams are equivalent


94

Diagramming ScenariosCollaboration Diagrams (cont.)

: Customer

: ATM

: Bank

: Session

: Transaction

1: insert_card

7: card_taken

4: select_transaction

3: get_customer_information

5: « create »

2: « create »

6: eject_card


95

Diagramming ScenariosActivity Diagrams and Objects

Objects do not appear on activity diagrams

However, it is possible to have them appear, in two different manners

Through swim lanes, describing the responsibilities of each object in the overall scenarios

As objects created as a consequence of the execution of some action


96

Diagramming ScenariosActivity Diagrams and Objects (cont.)

Select Withdrawal Setup

WithdrawalAsk Account

Select Account

Ask Amount

Select Amount

DeliverCash

Customer Session WithdrawalArchiveManager

: TransactionRecord

RegisterTransaction


97

Diagramming ScenariosWhich diagram to choose?

Expressing use case and scenarios in the customer’s language (usually natural) remains mandatory

Using formalisms will make descriptions more precise help the analysis work

Do not use too much formalism! For instance, remember that sequence and

collaboration diagrams are equivalent and that is generally useless to use both to describe the same scenario

The same applies to activity diagrams and statecharts


98

Diagramming ScenariosWhich diagram to choose? (cont. 1)

Interaction diagram (sequence and collaboration)

Only one scenario at a time May be very precise and detailed The number of diagrams may become huge Risk of redundancy in the diagrams for

scenarios with only little variations (difficult to maintain)

Some useful features are awkwardly represented (e.g., loops)


99

Diagramming ScenariosWhich diagram to choose? (cont. 2)

Activity diagrams: the most complete Accent is on the flow of control Describe at once a full set of scenarios Describe concurrent operations Created objects and responsibilities of objects may be

represented They may become too complex Risk to forget the objects and to do functional

analysis Activity diagrams with swim lanes and

explicit objects are often a good compromise


100

Analysis: from Use Cases to Objects


101

ContentsAnalysis

Analysis model Class diagrams Collaborations


102

Use Case Model and Analysis Model

Use case model Language of the customer External view of the

system Structured by use cases

Contract between customer and developer

May be redu

ndant or inconsistent Captures the functionality

Defines use cases

Analysis model Language of the developer Internal view of the system Structured by stereotyped

classes and packages Uses primarily by

developers, designers, programmers

Should not be redundant or inconsistent

Outlines a realization of the functionality

Defines use cases realization


103

Analysis Model

Realizing a use case Finding classes collaborating for realizing the use

case Finding their attributes and operations Finding relationships between these classes Refining the use case and scenarios description to

take the new classes into account A group of class collaborating for realizing

a use case is called a Collaboration

collaborationuse case

Class1

Class2


104

Analysis Stereotypical Classes

Entity class Long-lived (persistent) information

Control class Coordination, sequencing,

control…

Boundary class Interaction between the

system and its actors

« entity »

« control »

« boundary »


105

Class DiagramsClass Diagram for the ATM

Cardis inserted into

ATM interface

Session

Transaction

0..1 0..1

*Transaction

Record

0..1 1

CustomerInformation

0..1 1

{ordered}


106

Class DiagramsAssociations: Names and Roles

Companyemploys

Person

Personparent

child

employer employee

role role


107

Class DiagramsAssociations: Cardinality

Companyemploys

Person0..1

0..*

Manwedlock

Woman0..1 0..1

Personparent

child2

*


108

Class DiagramsAssociations: Cardinality (cont.)

from 1 to 4

C2 exactly 2

C1..4

C1..* at least 1

C* 0 or more (0..*)

C2, 4..7, 10..* 2, 4 to 7, 10 or more


109

Class DiagramsAssociations: Association as Class

Exactly one instance of class Job per link

Companyemploys

Person0..1

0..*

Jobsalaryfunctionpromote()


110

Class DiagramsAssociations: Constraints

Companyemploys

Person0..1

*Unemployment

Agency0..1

*{xor}

Companyemploys

Person0..1*

manages{subset}


111

Class DiagramsAssociations: Aggregation

Whole/Parts relationships "is part of", "is composed of" Antisymetric

Two forms Weak aggregation (simply Aggregation) Strong aggregation (Composition)


112

Companyemploys

Person*

0..1

Class DiagramsAssociations: (Weak) Aggregation

Weak coupling Sharing is possible Lifetime of component is not dependent of composite

Family*

*


113

Strong coupling No sharing Life-time of component ends with composite

Class DiagramsAssociations: Composition

Car

Wheel Engine Body4 1 1

Stock

*

0..1 0..1here, cardinalityat most 1


114

Class DiagramsAssociations: Composition (cont.)

Composition association and attributes are equivalent

Car

the_wheels[4]: Wheelthe_engine: Enginethe_Body: Body


115

Class DiagramsClass Diagram for the ATM (once more)

Cardis inserted into

ATM interface

Session

Transaction*

TransactionRecord

0..1 1

CustomerInformation

0..1 0..1

0..1 1

*


116

Class DiagramsClass Diagram for the ATM (cont.)

Transaction

Deposit Transfer

Withdrawal Consult


117

Class DiagramsGeneralization

Relationship Between classes No cardinality Transitive

"Is A", "Is A Sort Of" Substituability principle

Multiple inheritance is supported Multiple classification partially supported Dynamic classification is (less) partially

supported


118

Class DiagramsGeneralization: Substituability Principle

B derives from A: Any instance of B is also an instance of A for

any purpose of an A Any instance of B may be substituted to an

instance of A B may

Add new properties to the ones inherited from A Redefine operations inherited from A

B cannot get rid of properties inherited from A


119

Class DiagramsGeneralization: Polymorphism

Figure

Circle Square

surface()

Ellipse

surface()

Rectangle

surface()

Drawing

surface()*

components

sum = 0for all fig in components sum = sum + fig.surface()


120

Class DiagramsMultiple Inheritance

Triangle

Figure

Ellipse Rectangle

Circle Square Isosceles TrRightAngled Tr

RightAngled Isosceles Tr

{overlapping}


121

Class DiagramsGeneralization and Aggregation

Both relationships are transitive antisymmetric

Generalization is a disjunctive relationship (OR)

Aggregation is a conjunctive relationship (AND)


122

Class DiagramsInheritance and Aggregation (cont.)

Civil EngineeringEquipment Engine

Crane Truck

Truck-Crane

Vehicle Engine

Plane Boat

Seaplane


123

Class DiagramsAbstract Classes and Interfaces

Abstract classes Class with no instances May have attributes

operations (abstract or not)

Interfaces Abstract classes Without attributes With only an abstract

operations (list of services)

Figure « abstract »

« abstract » surface()

Figure

surface()

Drawable « interface »

draw()

Drawable

draw()


124

Class DiagramsMultiple Classification and Interfaces

Roles Views …

Drawable

draw()

Persistent

save()restore()

surface()move()draw()save()restore()

Figure


125

Handle Session

CollaborationsRealization of a Use Case

List all the classes (or roles) or objects that together realize a given use case

Allow traceablity from Use Case Model to Class Model

Session TransactionCustomer

Information

ATM interface


126

References


127

The Object-Oriented ApproachGenerality

Object-Oriented Software EngineeringIvar JacobsonAddison Wesley, 1993

Object Oriented Analysis and DesignGrady BoochSecond Edition, The Benjamin/Cummings Publ. Co., 1994

Object-Oriented Software ConstructionBertrand MeyerPrentice Hall, 1988


128

The Object-Oriented ApproachMethodology

The Unified Software Development Process

Ivar Jacobson, Grady Booch, James RumbaughAddison Wesley, 1999

Object Solutions: Managing the Object-oriented Project

Grady BoochAddison Wesley, 1996


129

The Unified Modeling LanguageOfficial References

OMG Unified Modeling Language Specification

Object Management Group, Inc.Version 1.3, June 1999

URL's: http://www.omg.com http://www.rational.com/uml


130

The Unified Modeling LanguageTutorial Books

The Unified Modeling Language User Guide

Grady Booch, James Rumbaugh, Ivar JacobsonAddison Wesley, 1999

The Unified Modeling Language Reference Guide

Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley, 1999

UML in a NutshellSinan Si AlhirO ’Reilly, 1998


131

The Unified Modeling LanguageUsing the UML

UML DistilledMartin Fowler (with Kendall Scott)Addison Wesley, 1997

Visual Modeling with Rational Rose and UML

Terry QuatraniAddison Wesley, 1998


132

The Unified Modeling LanguageUse Cases

Writing Effective Use CasesAlistair CockburnAddison Wesley, 2001

Applying Use Cases: A Practical GuideGeri Schneider, Jason P. Winters Addison Wesley, 1998


133

The Unified Modeling LanguageThe Object Constraint Language (OCL)

The Object Constraint Language: Precise Modeling with UML

Jos Warmer, Anneke Kleppe Addison Wesley, 1999


134

The Unified Modeling LanguageThe UML for French Readers

Modélisation objets avec UMLPierre-Alain Muller, Nathalie Gaertner 2e édition, Eyrolles, 2000

UML en actionPascal Roques, Franck ValléeEyrolles, 2000

De Merise à UMLNasser Kettani, Dominique Mignet, Pascal Paré, Camille Rosenthal-SabrouxEyrolles, 1998


135

The End…

V 1.0 -- 10/23/2015 10:07:20 AM© 2000 Jean-Paul RigaultUML: Product Definition -- 1 Product...

Documents

Transcript of V 1.0 -- 10/23/2015 10:07:20 AM© 2000 Jean-Paul RigaultUML: Product Definition -- 1 Product...