Software Modeling, UML
description
Transcript of Software Modeling, UML
Brno Dr.J. Withalm21.04.23
Software Modeling, UML
21.04.23 Dr. J. Withalm 2
Program andSystem EngineeringPSE
Brno
Overview
Motivation/Introduction
CMMI-a brief overview
UML-a brief overview
Hints &Tips
Which UML models are most
appropriate to be applied in which KPA‘s
21.04.23 Dr. J. Withalm 3
Program andSystem EngineeringPSE
Brno
„Quality: the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs“
(ISO8402).
Definitions/1
„Software quality: the totality of features and characteristics of a software product or service that bear on its ability to satisfy
stated or implied needs“
(ISO/IEC9126 )
Quality means to fulfill requirements
21.04.23 Dr. J. Withalm 4
Program andSystem EngineeringPSE
Brno
Software Product Quality
ISO 8402 Quality Vocabulary: The totality of characteristics of an entity
that bear on its ability to satisfy stated and implied needs.
What does “needs” means?
21.04.23 Dr. J. Withalm 5
Program andSystem EngineeringPSE
Brno
NEEDS
“Needs” is expectations for the effects of a product.
A user wants not a product itself but the effects of the product, which are needs.
It is difficult that real needs be identified either by a user or a planner.
21.04.23 Dr. J. Withalm 6
Program andSystem EngineeringPSE
Brno
Needs and Requirements
Identified needs must be transformed into requirements.
However, a product that satisfies requirements does not always satisfies needs.
21.04.23 Dr. J. Withalm 7
Program andSystem EngineeringPSE
Brno
QUALITY IN USE CONCEPTS
Quality In Use (QIU) QIU is an aspect of a product quality. QIU is measured by the effects of the product
when it is used. JTC1/SC7/WG6 introduced QIU concept in the
ISO/IEC 9126: Software Product Quality series.
21.04.23 Dr. J. Withalm 8
Program andSystem EngineeringPSE
Brno
QUALITY IN USE CONCEPTS
States – System Model
Cause
Effects
CurrentStates
CurrentStates
GoalStatesGoal
StatesRealizedStates
RealizedStates
CurrentSystemCurrentSystem
ProposedSystem
ProposedSystem
DevelopedSystem
DevelopedSystem
Needs QIU
21.04.23 Dr. J. Withalm 9
Program andSystem EngineeringPSE
Brno
QIU Definition and CharacteristicsISO/IEC 9126-1
The capability of a software product to enable specified users to achieve specified goals with effectiveness, productivity, safety, and satisfaction in specified context of use.
21.04.23 Dr. J. Withalm 10
Program andSystem EngineeringPSE
Brno
Requirements/1
Business oriented requirements
Functional requirements
Non functional requirements
21.04.23 Dr. J. Withalm 11
Program andSystem EngineeringPSE
Brno
Requirements/2How to measure the fulfillment
21.04.23 Dr. J. Withalm 12
Program andSystem EngineeringPSE
Brno
Requirements/3How to establish Business Strategies
21.04.23 Dr. J. Withalm 13
Program andSystem EngineeringPSE
Brno
Product Value proposition
CustomerInterface
Target Customer
Distribution Channel
Relationship
Infra-structure
Value Configuration
Capability
Partnership
FinancialAspects
Cost Structure
Revenue (Sharing) Model
P4Financial Aspects
P3 Infrastructur
eManagement
P1Product
P2 Customer Interface
Vision&
Strategy
Requirements/4How to establish Business Models
21.04.23 Dr. J. Withalm 14
Program andSystem EngineeringPSE
Brno
Requirements/5Assessment Tree
FV= 0,8218
p= 100
F 1
V 1= 0,847p 1 = 40
F 2 V2= 0,805
p 2= 60
F 11
V11= 0,83p 11= 90
F 12
V12= 1p 12= 10
F 21
V21= 0,9p 21= 50
F 22
V22= 0,75p 22= 10
F 23
V23= 0,7 p 23= 40
F 211
V211= 1p 211= 30
F 212
V212= 0p 212= 10
F 213
V213= 1p 213= 60
v J=
(p, x V,)j
100
v 21=30 x 1 + 10 x 0 + 60 x 1
100= 0,9
21.04.23 Dr. J. Withalm 15
Program andSystem EngineeringPSE
Brno
Requirements/6Non Functional Requirements/Quality Characteristics
reliability functional performance user friendliness time behaviour consume behaviour maintainability portability
21.04.23 Dr. J. Withalm 16
Program andSystem EngineeringPSE
Brno
Requirements/6Action in SEM phases concerning quality evaluation
Application of SEMQuality Evaluation
Definition of qualityobjectives
Direction for technicaland quality assuranceactivities
Examination if qualityobjectives are reached
SEM Phases
InitiationStudy
System DesignDetailed DesignImplementationIntegration
System TestAcceptance
21.04.23 Dr. J. Withalm 17
Program andSystem EngineeringPSE
Brno
Requirements/7SEM Software Quality Evaluation
Definition Quality characteristics Subcharacteristics
List of criteria / checklists
Evaluation procedures
21.04.23 Dr. J. Withalm 20
Program andSystem EngineeringPSE
Brno
Requirements/10Evaluation Procedures
measuring point scaling system evaluation tree
(functional performance) project specific procedures
back up
21.04.23 Dr. J. Withalm 21
Program andSystem EngineeringPSE
Brno
Requirements/10Structuring of quality costs
Quality related costs
Test costsError prevention cost
Process related costs
Cost to be conform to requirements
Error costsInternal/external
Costs to be non conform to requirements
21.04.23 Dr. J. Withalm 22
Program andSystem EngineeringPSE
Brno
Requirements/11Why SW projects are stranding?
95% stranded because Customer and Developer have different views
about requirements Implicit requirements Different knowledge of domain No technical knowledge of customers
Concerning the non functional requirements!!!
Change requests Market driven
Business oriented requirements No clear understanding of impact of
requirements
21.04.23 Dr. J. Withalm 23
Program andSystem EngineeringPSE
Brno
Requirements/12What’s the promising of OO
Improvement of requirement engineering by
Closing/narrowing the semantic gap
In structured analysis/design mapping
between the phases were the main
obstacles
Improvement of maintainability
Enabling of requirement tracing through all
phases.
Improvement of Quality by reusing components
Improvement of the portability
3 - 30
21.04.23 Dr. J. Withalm 24
Program andSystem EngineeringPSE
Brno
Requirements/13And what happened
Improvement of requirement engineering was substantially and accomplished mainly by applying:
OMT and then UML Maintainability and Requirement Tracing
were improved as consequence of applying UML
With regard to reusing of components and portability no clear trends are recognized.
21.04.23 Dr. J. Withalm 25
Program andSystem EngineeringPSE
Brno
Overview
Motivation/Introduction
CMMI-a brief overview
UML-a brief overview
Hints &Tips
Which UML models are most
appropriate to be applied in which KPA‘s
21.04.23 Dr. J. Withalm 26
Program andSystem EngineeringPSE
Brno
CMMI - Capability Maturity Model Integration
model for evaluating software/hardware/systems engineering organizations
developed by the Software Engineering Institute (SEI)
reference model also for derived methods such as Bootstrap and Siemens Process Assessments (CT SE3)
21.04.23 Dr. J. Withalm 27
Program andSystem EngineeringPSE
Brno
1Initial
2Managed
disciplined process
basic projectmanagementand control
3Defined
consistentprocess
process definition
4 Quantitatively
Managedpredictable process
quantitativeprocess management
5Optimizing
continuouslyimproving process
process control
CMMI Maturity Levels (staged)
Quality
Risk
BenefitBenefitEach transition takes
1-3 years !
21.04.23 Dr. J. Withalm 28
Program andSystem EngineeringPSE
Brno
The process is ad hoc and generally based on improvisation (by developers and managers).
Procedures, if existing at all, are not being adhered to.
Strong dependency on individuals (“heroes”).
Product quality and performance very difficult to predict.
Product quality and functionality downgrading to meet deadlines, but deadlines are still exceeded.
The use of new technologies involves major risks.
During a crisis, guidelines/rules are often abandoned as unnecessarily complicating.
Characteristics of an immature process
21.04.23 Dr. J. Withalm 29
Program andSystem EngineeringPSE
Brno
Standardized process, defined and documentedhas been understood and acceptedis being appliedis “alive”
Visible support through managementClear definition and understanding of roles and
responsibilitiesWell-established control – process compliance is
being monitored and enforcedConsistent with the staff’s current way of workingMeasurable and being measuredSupported by means of suitable technologies and
tools
Characteristics of a mature process
21.04.23 Dr. J. Withalm 30
Program andSystem EngineeringPSE
Brno
Requirement Development
Technical Solution
Product Integration
Verification
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management
Decision Analysis and Resolution
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
Quantitative Process Management
Software Quality Management
Organizational Innovation and Deployment
Causal Analysis & Resolution Optimizing (5)
Quantitatively Managed (4)
Defined (3)
Managed (2)
CMMI Process Areas
21.04.23 Dr. J. Withalm 31
Program andSystem EngineeringPSE
Brno
Manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project plans and work products.
Manage Requirements.
Requirements Management
Project Planning
Establish and maintain plans that define project activities.
Establish Estimates Develop a Project PlanObtain Commitment to the Plan
Project Monitoring and Control
Provide understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan
Monitor Project against planManage corrective actions to closure
Process Areas and Specific Goals of ML 2 (1)
21.04.23 Dr. J. Withalm 32
Program andSystem EngineeringPSE
Brno
Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting and configuration audits.
Establish baselinesTrack and control changesEstablish integrity
Configuration Management
Process Areas and Specific Goals of ML 2 (3)
21.04.23 Dr. J. Withalm 33
Program andSystem EngineeringPSE
Brno
Produce and analyze customer, product and product component requirements.
Develop customer requirementsDevelop product requirementsAnalyze and validate requirements
Requirement Development
Technical Solution
Design, develop and implement solutions to requirements. Solutions, designs and implementations encompass either singly or in combinations as appropriate.
Select product component solutionsDevelop the designImplement product design
Process Areas and Specific Goals of ML 3 (1)
21.04.23 Dr. J. Withalm 34
Program andSystem EngineeringPSE
Brno
Assemble the product from the product components, ensure that the product - as integrated – works properly (whole functionality) and deliver the product.
Prepare for product integrationEnsure interface compatibilityAssemble product components and deliver the product
Product Integration
Verification
Ensure that the selected work products meet their specified requirements.
Prepare for verificationPerform peer reviewsVerify selected work products
Process Areas and Specific Goals of ML 3 (2)
21.04.23 Dr. J. Withalm 35
Program andSystem EngineeringPSE
Brno
Demonstrate that the product or product components fulfills its intended use when placed in its intended environment
Prepare for validationValidate product or product components (must be suitable for use in their intended operating environment)
Validation
Organizational Process Focus
Plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.
Determine process improvement opportunitiesPlan and implement process improvement activities
Process Areas and Specific Goals of ML 3 (3)
21.04.23 Dr. J. Withalm 36
Program andSystem EngineeringPSE
Brno
Assessments/ Certification history in general
- after 2 nd world war QA was set up by Deming & Juran in Japan
- in USA, Europe still classical quality validation- by HW development QA did not get acceptance till present times- so-called QA in software in the beginning was only
restricted to tests and error count- in USA above all military (DoD) starts with QA, which is also
checked with audits (AQAP)
- Siemens starts in 1980 with QA system (CSA) to get through audits
back up
quality validation quality assurancesample audits on the current checks duringfinished product the development process
21.04.23 Dr. J. Withalm 37
Program andSystem EngineeringPSE
Brno
Assessments/ Certification history in general/2
- begin of 1980 quality label for SW (pure quality validation)
- discussion about certification since the middle eighties
- in Germany "Made in Germany" syndrom delays certification
- cooperation since 1990 with standards institute on ISO 9000 ff
- since 1992 pressure upon Siemens regarding certification
back up
21.04.23 Dr. J. Withalm 38
Program andSystem EngineeringPSE
Brno
Assessments/ Certification history in general /3connection SW-engineering - QA
- SW engineering has 3 dimensions:organization - method - technology
- organization means:- application of a method (e.g. SEM, SEPP,....)- verification of this application- organization of QA- record of primary data (metrics)
- method means e.g.:- functional development method- object oriented development method
- technology means:- with which tools the method is set up you will find this synonym
also on informatic institutes or universities - in the beginning SW-engineers were only interested in technology
21.04.23 Dr. J. Withalm 39
Program andSystem EngineeringPSE
Brno
Overview
Motivation/Introduction
CMMI-a brief overview
UML-a brief overview
Hints &Tips
Which UML models are most
appropriate to be applied in which KPA‘s
21.04.23 Dr. J. Withalm 44
Program andSystem EngineeringPSE
Brno
Building blocks of the UML
The vocabulary of the UML encompasses three kinds of building blocks:
Things are the abstractions that are first class citizens in a model
relationships tie these things together diagrams group interesting collections of
things
21.04.23 Dr. J. Withalm 45
Program andSystem EngineeringPSE
Brno
Things in the UML
There are four kinds of things in the UML structural things behavioral things grouping things annotational things
these things are the basic object-oriented building blocks of the UML
you use them to write well-formed models
21.04.23 Dr. J. Withalm 46
Program andSystem EngineeringPSE
Brno
Structural things 1
Are the nouns of UML models these are the mostly static parts of a
model, representing elements that are either conceptual or physical
in all, there are seven kinds of structural things
2001-10-01
21.04.23 Dr. J. Withalm 47
Program andSystem EngineeringPSE
Brno
Structural things 2classes/1
A class is a description of a set of objects that share the same
attributes operations relationships semantics
a class implements one or more interfaces
21.04.23 Dr. J. Withalm 48
Program andSystem EngineeringPSE
Brno
Structural things/3classes/2
Graphically, a class is rendered as a rectangle, usually including its
name attributes operations Window
originsize
open()close()move()display()
21.04.23 Dr. J. Withalm 49
Program andSystem EngineeringPSE
Brno
Structural things/4interfaces/1
An interface is a collection of operations that specify a service of a
class component
An interface therefore describes the externally visible behavior of that element
an interface defines a set of operations specifications (that is, their signatures) but never a set of operations implementations
21.04.23 Dr. J. Withalm 50
Program andSystem EngineeringPSE
Brno
Structural things/5interfaces/2
Graphically, an interface is rendered as a circle together with its name
An interface rarely stands alone Rather, it is typically attached to the class
or component that realises the interface
ISpelling
21.04.23 Dr. J. Withalm 51
Program andSystem EngineeringPSE
Brno
Structural things/6collaboration/1
A collaboration defines an interaction is a society of roles and other elements
that work together to provide some cooperative behavior that‘s bigger than the sum of all the elements
collaborations have structural and behavioral dimensions
A given class might participate in several collaborations
these collaborations therefore represent the implementation of patterns that make up a system
21.04.23 Dr. J. Withalm 52
Program andSystem EngineeringPSE
Brno
Structural things/7collaboration/2
Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name
Chain ofresponsibility
21.04.23 Dr. J. Withalm 53
Program andSystem EngineeringPSE
Brno
Structural things/8use cases/1
A use case is a description of a set of sequence of actions
that a system performs that yields an observable result of value to a particular actor
A use case is used to structure behavioral things in a model
a use case is realised by a collaboration
21.04.23 Dr. J. Withalm 54
Program andSystem EngineeringPSE
Brno
Structural things/9use cases/2
Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name
place order
21.04.23 Dr. J. Withalm 55
Program andSystem EngineeringPSE
Brno
Structural things/10
The remaining three things active classes components nodes
Are all class-like, meaning they also describe a set of objects that share the same attributes, operations, relationships and semantics
However, these three are different enough and are necessary for modeling certain aspects of an object-oriented system, and so they warrant special treatment
21.04.23 Dr. J. Withalm 56
Program andSystem EngineeringPSE
Brno
Structural things/11active class/1
An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity
an active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements
21.04.23 Dr. J. Withalm 57
Program andSystem EngineeringPSE
Brno
Structural things/12active class/2
Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations
EventManager
suspend()flush()
21.04.23 Dr. J. Withalm 58
Program andSystem EngineeringPSE
Brno
Structural things/13
The remaining two elements-component, and nodes- are also different
they represent physical things, whereas the previous five things represent conceptual or logical things
21.04.23 Dr. J. Withalm 59
Program andSystem EngineeringPSE
Brno
Structural things/14component/1
A component is a physical and replaceable part of a system
that conforms to and provides the realisation of a set of
interfaces in a system, you‘ll encounter different kinds of
deployment components, such as COM+ Java Bean as well as components that are artifacts of
the developing process, such as source code files
a component typically represents the physical packaging of otherwise logical elements
Classes, interfaces, and collaborations
21.04.23 Dr. J. Withalm 60
Program andSystem EngineeringPSE
Brno
Structural things /15component/2
Graphically, a component is rendered as a rectangle with tabs, usually including only its name
orderform.java
21.04.23 Dr. J. Withalm 61
Program andSystem EngineeringPSE
Brno
Structural things/16node/1
A node is a physical element that exists at run time and represents a computational resource
generally having at least some memory and, often, processing capability
A set of components may reside on a node and may also migrate from node to node
21.04.23 Dr. J. Withalm 62
Program andSystem EngineeringPSE
Brno
Structural things/17node/2
Graphically, a node is rendered as a cube, usually including only its name
Server
21.04.23 Dr. J. Withalm 63
Program andSystem EngineeringPSE
Brno
Behavioral things 1
Behavioral things are dynamic parts of UML models
these are the verbs of a model, representing behavior over time and space
in all, there are two primary kinds of behavioral things
21.04.23 Dr. J. Withalm 64
Program andSystem EngineeringPSE
Brno
Behavioral things/2interaction/1
An interaction is a behavior that comprises a set of messages
exchanged among a set of objects within a particular context
to accomplish a specific purpose the behavior of a society of objects or of an
individual operation may be specified with an interaction
an interaction involves a number of other elements,including
Messages Action sequences
the behavior invoked by a message Links
the connection between objects
21.04.23 Dr. J. Withalm 65
Program andSystem EngineeringPSE
Brno
Behavioral things/3interaction/1
Graphically, a message is rendered as a directed line, almost always including the name of its operation
display
21.04.23 Dr. J. Withalm 66
Program andSystem EngineeringPSE
Brno
Behavioral things/4state machine/1
A state machine is a behavior that specifies the sequence of states an object or an
interaction goes through during its lifetime in response to events, together with its responses to those events
the behavior of an individual class or a collaboration of classes may be specified with a state machine
a state machine involves a number of other elements, including
States Transitions
the flow from state to state Activities
the response to a transition
21.04.23 Dr. J. Withalm 67
Program andSystem EngineeringPSE
Brno
Behavioral things/5state machine/2
Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates , if any
Waiting
21.04.23 Dr. J. Withalm 68
Program andSystem EngineeringPSE
Brno
Grouping things/1
Grouping things are the organisational parts of UML models
these are the boxes into which a model can be decomposed
in all, there is one primary kind of grouping thing, namely, packages
21.04.23 Dr. J. Withalm 69
Program andSystem EngineeringPSE
Brno
Grouping things/2package/1
A package is a general-purpose mechanism for organising elements into groups
structural things, behavioral things, and even other grouping things may be placed in a package
unlike components (which exist at run time), a package is purely conceptual
Meaning that it exists only at development time
21.04.23 Dr. J. Withalm 70
Program andSystem EngineeringPSE
Brno
Grouping things/3package/2
Graphically, a package is rendered as a tabbed folder
Usually including only its name and, sometimes, its contents
Business rules
21.04.23 Dr. J. Withalm 71
Program andSystem EngineeringPSE
Brno
Annotational things/1
Annotational things are the explanatory parts of UML models
these are the comments you may apply to describe illuminate remark
There is one primary kind of annotational thing, called a note
21.04.23 Dr. J. Withalm 72
Program andSystem EngineeringPSE
Brno
Annotational things/2note/1
A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements
21.04.23 Dr. J. Withalm 73
Program andSystem EngineeringPSE
Brno
Annotational Things/3note/2
Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment
return copyof self
21.04.23 Dr. J. Withalm 74
Program andSystem EngineeringPSE
Brno
Relationships in the UML
There are four kinds of relationships in the UML
dependency association generalisation realisation
these relationships are the basic relational building blocks of the UML
you use them to write well-formed models
21.04.23 Dr. J. Withalm 75
Program andSystem EngineeringPSE
Brno
Dependency/1
A dependency is a semantic relationship between two things
in which a change to one (the independent thing) may affect the semantics of the other thing (the dependent thing)
21.04.23 Dr. J. Withalm 76
Program andSystem EngineeringPSE
Brno
Dependency/2
Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label
21.04.23 Dr. J. Withalm 77
Program andSystem EngineeringPSE
Brno
Association/1
An association is a structural relationship that describes a set of links
A link being a connection among objects
Aggregation is a special kind of association representing a structural relationship
between a whole and its parts
21.04.23 Dr. J. Withalm 78
Program andSystem EngineeringPSE
Brno
Association/2
Graphically, an association is rendered as a solid line, possible directed, occasionally including a label, and often containing other adornments
Such as multiplicity and role names
0..1employer
*employee
21.04.23 Dr. J. Withalm 79
Program andSystem EngineeringPSE
Brno
generalisation/1
A generalisation is a specialisation/ generalisation relationship in which
objects of the specialised element (the child) are substitutable for objects of the generalised element (the parent)
in this way, the child shares the structure and the behavior of the parent
21.04.23 Dr. J. Withalm 80
Program andSystem EngineeringPSE
Brno
Generalisation/2
Graphically, a generalisation relationship is rendered as a solid line with a hollow arrowhead pointing to the parent
21.04.23 Dr. J. Withalm 81
Program andSystem EngineeringPSE
Brno
Realisation/1
A realisation is a semantic relationship between classifiers
wherein one classifier specifies a contract that another classifier guarantees to carry out
you‘ll encounter realisation relationship in two places
between interfaces and the classes or components that realise them
between use cases and the collaborations that realise them
21.04.23 Dr. J. Withalm 82
Program andSystem EngineeringPSE
Brno
Realisation/2
Graphically, a realisation relationship is rendered as a cross between a generalisation and a dependency relationship
21.04.23 Dr. J. Withalm 85
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/3
The UML includes nine such diagrams class diagram object diagram use case diagram sequence diagram collaboration diagram statechart diagram activity diagram component diagram deployment diagram
21.04.23 Dr. J. Withalm 86
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/4class diagram
A class diagram shows a set of classes interfaces collaborations
these diagrams are the most common diagrams found in modeling object-oriented systems
class diagrams address the static design view of a system
class diagrams that include active classes address the static process view of a system
21.04.23 Dr. J. Withalm 87
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/5object diagram
An object diagram shows a set of objects and their relationships
object diagrams represent static snapshots of instances of the things found in class diagrams
these diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases
21.04.23 Dr. J. Withalm 88
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/6use case diagram
A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships
use case diagrams address the static use case view of a system
these diagrams are especially important in organising and modeling the behavior of a system
21.04.23 Dr. J. Withalm 89
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/7interaction diagram, sequence diagram
An interaction diagram shows an interaction
consisting of a set of objects and their relationships, including the message that may be dispatched among them
interaction diagrams address the dynamic view of a system
21.04.23 Dr. J. Withalm 90
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/8 interaction diagram, sequence diagram
A sequence diagram is an interaction diagram that emphasises the time-ordering of messages
21.04.23 Dr. J. Withalm 91
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/9 interaction diagram, collaboration diagram A collaboration diagram is an interaction
diagram that emphasises the structural organisation of the objects
that send and receive messages sequence diagrams and collaboration
diagrams are isomorphic Meaning that you can take one and
transform it into the other
21.04.23 Dr. J. Withalm 92
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/10statechart diagrams
A statechart diagram shows a state machine
consisting of states, transitions, events, and activities
statechart diagrams address the dynamic view of a system
they are especially important in modeling the behavior of an object, which is especially useful in modeling reactive systems
21.04.23 Dr. J. Withalm 93
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/11activity diagram
An activity diagram is a special kind of a statechart diagram
that shows the flow from activities within a system
activity diagrams address the dynamic view of a system
they are especially important in modeling the function of a system and emphasize the flow of control among objects.
21.04.23 Dr. J. Withalm 94
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/12component diagram
A component diagram shows the organisation and dependencies among a set of components
component diagrams address the static implementation view of a system
they are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations
21.04.23 Dr. J. Withalm 95
Program andSystem EngineeringPSE
Brno
Diagrams in the UML/13deployment diagram
A deployment diagram shows the configuration of run-time processing nodes and the components that live on them
deployment diagrams address the static deployment view of an architecture
they are related to component diagrams in that a node typically encloses one or more components
21.04.23 Dr. J. Withalm 116
Program andSystem EngineeringPSE
Brno
Architecture/5
Design view
Process view Deployment view
Implementation view
Use caseview
vocabularyfunctionali
tybehavior
performancescalability
throughput
system assemblyconfigurationmanagement
system topologydistributiondeliveryinstallation
21.04.23 Dr. J. Withalm 117
Program andSystem EngineeringPSE
Brno
Architecture/6use case view
The use case view of a system encompasses the use case
that describe the behavior of the system as seen by its end users, analysts, and testers
this view doesn‘t really specify the organisation of a software system
rather, it exists to specify the forces that shape the system‘s architecture
with the UML the static aspect of this view are captured in
the use case diagram the dynamic aspects of this view are captured
in interaction diagrams statechart diagrams activity diagrams
21.04.23 Dr. J. Withalm 118
Program andSystem EngineeringPSE
Brno
Architecture/7design view
The design view of a system encompasses the class, interfaces, and collaborations
that form the vocabulary of the problem and its solution
this view primarily supports the functional requirements of the system
meaning the services that the system should provide to its end users
with the UML the static aspect of this view are captured in
class diagrams and object diagrams
the dynamic aspect of this view are captured in
interaction diagrams, statechart diagrams, and activity diagrams
21.04.23 Dr. J. Withalm 119
Program andSystem EngineeringPSE
Brno
Architecture/8process view
The process view of a system encompasses the threads and processes that form the system‘s concurrency and synchronisation mechanisms
this view primarily addresses the performance, scalability, and throughput of the system
with the UML the static and dynamic aspects of this
view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes
21.04.23 Dr. J. Withalm 120
Program andSystem EngineeringPSE
Brno
Architecture/9implementation view
The implementation view of a system encompasses the components and files that are used to assemble and release the physical system
this view primarily addresses the configuration management of the system‘s releases
made up of somewhat independent components and files that can be assembled in various ways to produce a running system
with the UML the static aspects of this view are captured in
component diagrams the dynamic aspects of this view are
captured in interaction diagrams, statechart diagrams, and activity diagrams
21.04.23 Dr. J. Withalm 121
Program andSystem EngineeringPSE
Brno
Architecture/10deployment view
The deployment view of a system encompasses the nodes that form the system‘s hardware topology on which the system executes
this view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system
with the UML the static aspects of this view are captured in
deployment diagrams the dynamic aspects of this view are captured
in interaction diagrams, statechart diagrams, and activity diagrams
21.04.23 Dr. J. Withalm 125
Program andSystem EngineeringPSE
Brno
Software development life cycle/2use case driven
Use case driven means that use cases are used as a primary artifact
for establishing the desired behavior of the system
for verifying and validating the system‘s architecture
for testing, and for communicating among the stakeholders of the project
21.04.23 Dr. J. Withalm 126
Program andSystem EngineeringPSE
Brno
Software development life cycle/3architecture-centric
Architecture-centric means that a system‘s architecture is used as a primary artifact for
conceptualising constructing managing and evolving the system under
development
21.04.23 Dr. J. Withalm 127
Program andSystem EngineeringPSE
Brno
Software development life cycle/4iterative and incremental
An iterative process is one that involves managing a stream of executable releases
an incremental process is one that involves the continuous integration of the system‘s architecture
to produce these releases, with each new release embodying incremental improvements over the other
together, an iterative and incremental process is risk-driven
meaning that each new release is focused on attacking and reducing the most significant risks to the success of the project
21.04.23 Dr. J. Withalm 135
Program andSystem EngineeringPSE
Brno
Overview
Motivation/Introduction
CMMI-a brief overview
UML-a brief overview
Hints &Tips
Which UML models are most
appropriate to be applied in which KPA‘s
21.04.23 Dr. J. Withalm 136
Program andSystem EngineeringPSE
Brno
UML-Models REQM CM RD TS PI VER VAL
Use cases
deployment
State chart
Interfaces
Process and threads
Events and signals
components
interactions
collaborations
Which UML Model will support us in which Key Process Area of CMMI
21.04.23 Dr. J. Withalm 137
Program andSystem EngineeringPSE
Brno
REQM (Requirement Management)
Specific goal 1: Manage Requirements Obtain an understanding of
requirements Obtain commitment to requirements Manage requirement changes Maintain bidirectional traceability of
requirements Identify inconsistencies between project
work and requirements
21.04.23 Dr. J. Withalm 138
Program andSystem EngineeringPSE
Brno
REQM /2
Use cases, state machine, activity diagram, statechart diagram, interactive diagram try to establish use cases for each
requirement each use case should be analyzed by
interaction diagram which should show the messaging between the objects
Use cases give you a first impression about classes/objects
Try to find out which objects could be active objects in that way that they react to events and which are not active objects
For each object try to find out in which states they are and when transitions take place
Try to find out what activities take place in objects
Try to get commitments for all these questions from project participants.
21.04.23 Dr. J. Withalm 139
Program andSystem EngineeringPSE
Brno
CM (Configuration Management)
Specific goal 1: establish baseline Identify configuration items Establish a CM system Create a release baseline
Specific goal 2: track and control changes Track change requests Control configuration items
Specific goal 3: Establish integrity Establish configuration management records Perform configuration audits .
21.04.23 Dr. J. Withalm 140
Program andSystem EngineeringPSE
Brno
RD (Requirements Development)
Specific goal 1: develop customer needs Elicit needs Develop the customer requirement
Specific goal 2:develop product requirements Establish product and product-component
requirements Allocate product-component requirements Identify interface requirements
Specific goal 3: analyze and validate requirements establish operational concepts and scenarios Establish a definition of required functionality Catalogue requirements Analyze requirements to achieve balance Validate requirements with comprehensive
methods.
21.04.23 Dr. J. Withalm 141
Program andSystem EngineeringPSE
Brno
RD/2 (Transform stakeholder needs, expectation, constrains and interfaces with customer required /Establish and maintain product and product component requirements, which are basics on the customers requirements/ Allocate the requirements for each
product component)
It could be very interesting if all stakeholders see the same use cases in that case it is not necessary to
undertake further modeling as state machines, interactive diagrams
1. Start with the established use case diagrams of the customer requirements
2. Derive a collaboration diagram3. Establish a component diagram4. Establish a deployment diagram Thanks to reverse engineering
methodologies we have the chance from component diagrams evaluating classes, interfaces, collaborations reversing of collaborations brings us
use cases
21.04.23 Dr. J. Withalm 142
Program andSystem EngineeringPSE
Brno
RD/3 (Identify interface requirements )
Use cases are the door between the system and the outer world
Collaborations have realization relationships to use cases
Each collaboration contains classes, interfaces, active classes
Each class has attributes and in that way an interface establish and maintain operational concepts and association scenarios
Basics are use case diagrams Furthermore we need
component/deployment diagrams
21.04.23 Dr. J. Withalm 143
Program andSystem EngineeringPSE
Brno
RD/4 (Establish a definition of required functionality)
Basics are use cases Next step collaboration diagrams –
interaction diagrams – statechart diagrams – activity diagrams
Analyze requirements to ensure that they are necessary and sufficient
Use case diagrams Analyze requirements to balance
stakeholder needs and constraints Use case diagram
Validate requirements to ensure the resulting product will perform as indented in the user’s environment using multiple techniques as appropriate
21.04.23 Dr. J. Withalm 144
Program andSystem EngineeringPSE
Brno
TS (Technical Solutions)
Specific goal 1: select product-component solutions
Develop detailed alternative solutions and selection criteria
Evolve operational concepts and scenarios Select product-component solutions
Specific goal 2:develop the design Design the product or product component Establish a technical data package Design interfaces using criteria Perform make, buy, or reuse analyses
Specific goal 3: implement the product design Implement the design Develop product support documentation.
21.04.23 Dr. J. Withalm 145
Program andSystem EngineeringPSE
Brno
TS/2 ( develop detailed alternative solution and selection criteria/ Evolve the operational concepts and scenarios/ Select the product-component solution that best satisfy the criteria established/ design
the product or product component )
Via use case establish different collaboration interaction, activity diagrams
It’s also useful to establish different component and deployment diagrams
In case of concurrency different active classes
From uses cases to component/deployment diagrams
Component diagrams
Use cases, collaboration, component diagrams
21.04.23 Dr. J. Withalm 146
Program andSystem EngineeringPSE
Brno
PI (Product Integration)
Specific goal 1: prepare for product integration Determine integration sequence Establish the product integration environment Establish product integration procedures and criteria
Specific goal 2: ensure interface compatibility Review interface descriptions for completeness Manage interfaces
Specific goal 3: assemble product components and deliver the product
Confirm readiness of product components for integration
Assemble product components Evaluate assembled product components Package and deliver the product or product
component.
21.04.23 Dr. J. Withalm 147
Program andSystem EngineeringPSE
Brno
Validation and Verification
21.04.23 Dr. J. Withalm 148
Program andSystem EngineeringPSE
Brno
VER (Verification)
Specific goal 1: prepare for verification Select work products for verification Establish the verification environment Establish verification procedures and criteria
Specific goal 2: perform peer reviews Prepare for peer reviews Conduct peer reviews Analyze peer review data
Specific goal 3: verify selected work products Perform verification Analyze verification results and identify
corrective action
21.04.23 Dr. J. Withalm 149
Program andSystem EngineeringPSE
Brno
VAL (Validation)
Specific goal 1: prepare for validation
Select work products for validation
Establish the validation environment
Establish validation procedures and criteria
Specific goal 2: validate product or product
components
Perform validation
Analyze validation results
Brno Dr.J. Withalm21.04.23
Thank youfor your attention!