Practical use of UML

Practical use of UMLPractical use of UML

UML in Projects.

Tips, Hints, Pitfalls….

Carl-Fredrik Sørensenmailto:[email protected]

IntroductionIntroduction

Development processes and UML diagrams– …– Prestudy– Requirements specification/analysis– Construction/Design– Implementation– …

Visual ModellingVisual Modelling

Modelling using a standard graphical notation. Used to:

– Represent business processes, objects/classes and logic.– Analyse and design applications.– Handle complexity.– Define software architecture.

Promotes reuse. UML, BPM, ER, DDF etc.

UMLUMLNot a software development process or

methodologyCombines the best of the best from

– Data modelling concepts (ER Diagrams)– Business modelling (workflow)– Object modelling – Component modelling

UMLUMLStandard language for visualisation,

specification, construction and documentation of problems/solutions in a software-intensive system

May be used in all processes/phases in the development cycle, across different implementation technologies

UML ConceptsUML Concepts

UML is used to:– Show main functions and boundaries in a system using

use cases and actors.– Illustrate use case realisations using interaction

diagrams.– Represent a static structure of a system using class

diagrams.– Modelling object behaviour using state diagrams.– Show implementation of the physical architecture using

component and deployment diagrams.– Enhance the functionality using stereotypes.

UML ToolsUML Tools

It is almost a necessity to use a UML tool to model:– Draw consistent diagrams in UML notation– Process support– Maintenance– Traceability– Extensions– Documentation – Code generators (Java, C++, SQL etc.)

UML Diagrams and ElementsUML Diagrams and Elements

Use case diagrams Interaction diagrams

– Sequence, collaboration Static structural diagrams

– Object, class State diagrams Activity diagrams Implementation diagrams

– Packages, Components, Deployment

Use case diagramUse case diagram

ProductionEngineer

Data CaptureControl RoomOperator

ProductionPlanner

Laborant

Create ProductionTest Result

Create WellProductionEstimate

Plan ProductionTest

ImplementProductionEstimates

CreateMeasurement

Correction Factors

Create FlowlineProductionEstimate

RecordProduction Data

VerifyProduction Data

Find StablePeriod

Create CombinedEstimate

uses

uses

extends

extends

extends

extends

Sequence diagramSequence diagram

Instance:EcBsProductionTest

Instance:EcBsProductionTestResult

Load production test loadTestFind Stable Period Find Stable Period

Set Stable Period setStablePeriodStart Create Result createResultCreate a production test result instance EcBsProductionTestResult;2Create Result createResults

Create Separator Results

Create Well Results

Create Flowline Results

Create Separator Results

Create Well Results

Create Flowline Results

Create Flowline Production Estimate Create Flowline Production EstimateCreate Well Production Estimate Create Well Production EstimateCreate Measurement Correction Factors Create Measurement Correction Factors

Collaboration diagramCollaboration diagram

ProductionTest Planner

«user»:EcUsProductionTestConfiguration

«external»:EcBsProductionSystem::EcBsProductionSystem

«external»:EcBsProductionSystem::EcBsTestSeparator

«external»:EcBsProductionSystem::EcBsWell

«external»:EcBsProductionSystem::EcBsTemplate

«external»:EcBsProductionSystem::EcBsFlowline

«external»:EcBsProductionSystem::EcBsFacility

«business»:EcBsProductionTest

Select Production System()1 :

Select Facility()4 :

Select Flowline()7 :

Select Well()10 :

Select Separator()15 :

Apply()18 :

Select Production System()1 :

Select Facility()4 :

Select Flowline()7 :

Select Well()10 :

Select Separator()15 :

Apply()18 :

load()2 :

getProductionSystem()3 :

findFacilities()5 :

getFacility()6 :

load()2 :

getProductionSystem()3 :

findFacilities()5 :

getFacility()6 :

findFlowlines()8 :

getFlowline()9 :

findTestSeparators()16 :

getTestSeparator()17 :

findFlowlines()8 :

getFlowline()9 :

findTestSeparators()16 :

getTestSeparator()17 :

getTemplate;2()11 : getTemplate;2()11 :

findWells()12 :

getWell()14 :

findWells()12 :

getWell()14 :

getName()13 : getName()13 :

save()19 : save()19 :

Class diagramClass diagram

«business»::EcBsProductionSystem

«business»::EcBsFacility

«business»::EcBsPipe

«business»::EcBsSensor{Abstract}

*

1

*

0..2

*

0..1

*

0..1

*2

«business»::EcBsProductionTest

productionSystem_

facilityId_

separatorId_

primaryWell_

flowline_

noWells_

startTime_

endTime_

startStableTime_

endStableTime_

recentWells_

selectedWells_

debug_

systemVersion_

EcBsProductionTest;1



getConnectionString

getDebug

createInterface

initialise

getProductionSystem

getFacility

getSeparator

getPrimaryWell

setPrimaryWell

getFlowline

setFlowline

getStartTime

getEndTime

getWellAssignment

getWells

getEnumWells

getNoWells

getSelectedWells

setWells

saveWellAssignment

addWellToRecordset

removeWellFromRecordset

getProductionTestData

getProductionTestResult

setStablePeriod

getStablePeriod

getStablePeriodStart

getStablePeriodEnd

proposeStablePeriod

createResult

save

loadTest

isWellSelected

State diagramState diagram

ProducingInjecting Testing

Closed

Closed

Established

Component diagramComponent diagram

EcDsProsty.dll EcBsProductionSystem.dll

EcBsProductionTest.dllEcBsPVT.dll

UML support in software UML support in software developmentdevelopment

Development processes and UML diagrams– Prestudy– Requirements specification/analysisRequirements specification/analysis– Construction/designConstruction/design– ImplementationImplementation

PrestudyPrestudy

Activity diagrams should be used to model/describe the current/future business processes, dataflow etc.

Try to investigate/model the processes at the same abstraction level (used for communication).

Refine processes until the problem space is understood in enough detail to ”find” req’ts.

Do not overdo it (analysis paralysis).

Activity DiagramsActivity Diagrams

Stereotypes may be used to define special activity classes to obtain/show additional information.

Do not use to many colours…

Prestudy continuedPrestudy continued

Use cases and Use case diagrams may be used to describe functional req’ts in existing systems.– Remember that the cardinality between use

cases and dialogues is not necessarily 1:1.


Development processes and UML diagrams– PrestudyPrestudy– Requirements specification/analysis– Construction/designConstruction/design– ImplementationImplementation

Requirement SpecificationRequirement Specification

Functional requirements.Non-functional requirements.

– Not supported directly in UML.– Very important for the design of the software

architecture, influence design/ implementation/ selection of support software.

Architectural and system description.– May use implementation diagrams as a sketch.

Functional requirementsFunctional requirements

Use cases and Use case diagrams.Interaction diagrams (sequence).Class diagrams (business model).State diagrams.

Use casesUse cases

A use case tells a story of reaching a goal,or a set of stories of both getting and failing.

A use case is performed by one actor in a timely manner, i.e. should be achieved in a reasonable time.

Examining the Goals the system supports makes good functional requirements.

Use casesUse cases

Naming: active verb first.Use cases may be numerated. To many use case (50+) may mean a wrong

understanding/use of use cases.

Use casesUse cases Use cases address “how to make functional

requirements readable, reviewable.”– Use cases hold functional requirements in an easy-to-

read, easy-to-track, text format.– A use case collects how a goal succeeds/fails; A

scenario shows one specific condition; Scenarios & use cases nest.

– Use cases show only the functional req’ts.– They make a framework for non-functional

requirements & project details.– Design is not done only in use case increments.

Use casesUse casesUse cases do not collect formulae, state,

cardinality. Capture them separately (e.g. in the scenario descriptions).

Pre- and post-conditions should be used to show dependencies between use cases.

Use case diagramsUse case diagrams

If you find common behaviour in several use cases, this behaviour may be added in a new use case that the other use cases ”inherits” by use of the <<uses>> stereotype.

Some use cases may represent alternative or exceptions scenarios for an important use case. These use cases may be extensions of the main use case. This may represent optional behaviour.

Use case diagramsUse case diagrams

Use cases may be organised in diagrams:– Together with related use cases (same business

process/area).– For each actor.

Remember that actors represents active roles, not named people or passive systems/people.

Use cases and Interaction Use cases and Interaction diagramsdiagrams

Write the use case scenarios so that you can use the stepwise description directly as steps in interaction diagrams (especially sequence diagrams).

Each use case is normally realised by an interaction diagrams.

Business Class ModelBusiness Class Model

Only address business/domain classes. Classes may be found:

– Statically by studying the functional requirements/domain knowledge.

– Dynamically from the interaction diagrams.Show associations, optionally cardinality.Assign associations when classes need to

know about another. Look both ways.


Add important methods/attributes, e.g. from the construction of interaction diagrams.

Remember the meaning of using interaction diagrams in this context; do not dig to deep (then you are designing).

Use analysis patterns where applicable.May uncover use cases.


If the model grows large, use packages.Use state diagrams if classes have

interesting life cycles.Build in teams. CRC Cards may be useful.Use inheritance to make abstractions of

common classes. A super class may replace many subclasses/associations.

Baseline architectureBaseline architecture

Consists of:– Use cases.– Domain model.– Technology platform.– Non-functional requirements.

Foundation for construction/implementation.

PersistencePersistence

Schemas may be modelled by using class diagrams.– Class = Entity.– Association = Relation.– Association cardinality.– Needs generally to solve M:N relationships.

Tools will normally have functionality to data modelling (ER). Stereotypes may be used to distinguish persistent classes and relations from the business/design class model.


Development processes and UML diagrams– PrestudyPrestudy– Requirements specification/analysisRequirements specification/analysis– Construction/design– ImplementationImplementation

Construction/designConstruction/design

Class and Object diagrams.Interaction diagrams.State diagrams.Activity diagrams.


Transform the business model to a design model. Use stereotypes to show where the classes belong, some tools may relate these class variants. Every business class will not be design class.

Some business classes and processes may be modelled as interfaces. Interfaces are independent of implementation.


Classes that implement interfaces ”refines” the interfaces.

Interaction/activity diagrams may be used to model algorithms (important functions).


Avoid mixing groups of classes that is not related in the same diagram.

Try to achieve loose coupling and high cohesion! Look for reuse of designs from e.g. design patterns.


Remember that all relationships (associations, dependencies, aggregations) means coupling.

Coupling is however necessary to make the system do something, to collaborate.

Use packages to handle complexity, to minimize coupling, and keeping the model elements cohesive.


Use case scenarios provide the basis for design with responsibilities.

Assign responsibilities to classes that have the knowledge to perform an activity.

Responsibility-based design is based on role-playing a walkthrough of a scenario.


Multiple scenarios provide the basis for asserting that the design delivers the required function.

Use of failure scenarios make the design complete & robust.

Split large classes, join small classes.Decide how to implement cardinalities.Consider Design by Contract.

Software ArchitectureSoftware Architecture

UML does not address important non-functional requirements that influence the software architecture.

Use implementation diagrams to model the software architecture.

Identify components and interfaces. Model component interactions. Use class diagrams and interactions diagrams.

Software ArchitectureSoftware Architecture

Components are typically abstractions at a coarser level than classes.

Components and interfaces may represent a use case at different levels.

Split persistence (data), control (business) and user interface.


Development processes and UML diagrams– PrestudyPrestudy– Requirements specification/analysisRequirements specification/analysis– DesignDesign– Implementation

ImplementationImplementation

Implementation issues affects design models.– Programming Language mechanisms.– Architectural issues.

Navigation in associations may be revealed/changed.

Use round-trip engineering to create/update code from design/design from code.– Dependencies may have been introduced.– Some classes may have appeared/disappeared.– Associations may have appeared/disappeared.

TestingTesting

Use case scenarios are a good starting point for an acceptance test.

Pre- ,post-conditions and invariants may be of help in defining integration and unit tests (these may be modelled formally by OCL).

SummarySummary

Use case (diagrams).– Capture requirements.– Planning and controlling iterations.

Design/implement the most critical/important use cases first.

– Grouping of use cases.

SummarySummary

Class/Object diagrams.– Business/domain modelling (prestudy).– Specification models (construction).– Do not try to use all available notations. Start with the

single stuff (classes, associations, attributes and generalisation). Introduce other notations only if you need them.

– Do not model everything, concentrate on key areas.– Keep in mind which stage the model are supposed to be

used in.

SummarySummary

Interaction diagrams - Shows collaborations.– Looks at the behaviour of several objects within

a use case. – May be used to look at the behaviour of

business methods, outline algorithms (class method).

SummarySummary

Activity diagrams.– Analysing work flow.– Analysing a use case.– Understanding workflow across many use

cases.– Dealing with multi-threaded applications.

SummarySummary

Implementation diagrams.– Handle complexity.– Show architecture as components.– Show dependencies.– Show physical implementation (in little use).

State diagrams.– Model interesting object life cycles (across several use

cases).– Important in real-time systems.

ReferencesReferencesG.Booch, J. Rumbaugh, I. Jacobson: The

Unified Modeling Language User guide, Addison-Wesley 1999

Martin Fowler, Kendall Scott: UML Destilled, Addison-Wesley 1999 (2nd ed.)

Practical use of UML

Documents

Transcript of Practical use of UML