Practical use of UML UML in Projects. Tips, Hints, Pitfalls…. Carl-Fredrik Sørensen...
-
Upload
alvin-byrd -
Category
Documents
-
view
213 -
download
0
Transcript of Practical use of UML UML in Projects. Tips, Hints, Pitfalls…. Carl-Fredrik Sørensen...
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
EcBsProductionTest;2
EcBsProductionTest;3
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.
UML support in software UML support in software developmentdevelopment
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.
Business Class ModelBusiness Class Model
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.
Business Class ModelBusiness Class Model
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.
UML support in software UML support in software developmentdevelopment
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.
Construction/designConstruction/design
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.
Construction/designConstruction/design
Classes that implement interfaces ”refines” the interfaces.
Interaction/activity diagrams may be used to model algorithms (important functions).
Construction/designConstruction/design
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.
Construction/designConstruction/design
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.
Construction/designConstruction/design
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.
Construction/designConstruction/design
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.
UML support in software UML support in software developmentdevelopment
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.)