01.10.2015 Brno Dr.J. Withalm Software Modeling, UML.

Brno Dr.J. Withalm19.04.23

Software Modeling, UML

19.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



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



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?



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.



Brno

Needs and Requirements

Identified needs must be transformed into requirements.

However, a product that satisfies requirements does not always satisfies needs.



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.



Brno

QUALITY IN USE CONCEPTS

States – System Model

Cause

Effects

CurrentStates

CurrentStates

GoalStatesGoal

StatesRealizedStates

RealizedStates

CurrentSystemCurrentSystem

ProposedSystem

ProposedSystem

DevelopedSystem

DevelopedSystem

Needs QIU



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.

19.04.23 Dr. J. Withalm 10


Brno

Requirements/1

Business oriented requirements

Functional requirements

Non functional requirements

19.04.23 Dr. J. Withalm 11


Brno

Requirements/2How to measure the fulfillment

19.04.23 Dr. J. Withalm 12


Brno

Requirements/3How to establish Business Strategies

19.04.23 Dr. J. Withalm 13


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

19.04.23 Dr. J. Withalm 14


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

19.04.23 Dr. J. Withalm 15


Brno

Requirements/6Non Functional Requirements/Quality Characteristics

reliability functional performance user friendliness time behaviour consume behaviour maintainability portability

19.04.23 Dr. J. Withalm 16


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

19.04.23 Dr. J. Withalm 17


Brno

Requirements/7SEM Software Quality Evaluation

Definition Quality characteristics Subcharacteristics

List of criteria / checklists

Evaluation procedures

19.04.23 Dr. J. Withalm 20


Brno

Requirements/10Evaluation Procedures

measuring point scaling system evaluation tree

(functional performance) project specific procedures

back up

19.04.23 Dr. J. Withalm 21


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

19.04.23 Dr. J. Withalm 22


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

19.04.23 Dr. J. Withalm 23


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

19.04.23 Dr. J. Withalm 24


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.

19.04.23 Dr. J. Withalm 25


Brno

Overview




Hints &Tips



19.04.23 Dr. J. Withalm 26


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)

19.04.23 Dr. J. Withalm 27


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 !

19.04.23 Dr. J. Withalm 28


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

19.04.23 Dr. J. Withalm 29


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

19.04.23 Dr. J. Withalm 30


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

19.04.23 Dr. J. Withalm 31


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)

19.04.23 Dr. J. Withalm 32


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


19.04.23 Dr. J. Withalm 33


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


19.04.23 Dr. J. Withalm 34


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


19.04.23 Dr. J. Withalm 35


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


19.04.23 Dr. J. Withalm 36


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

19.04.23 Dr. J. Withalm 37


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

19.04.23 Dr. J. Withalm 38


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

19.04.23 Dr. J. Withalm 39


Brno

Overview




Hints &Tips



19.04.23 Dr. J. Withalm 44


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

19.04.23 Dr. J. Withalm 45


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

19.04.23 Dr. J. Withalm 46


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

19.04.23 Dr. J. Withalm 47


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

19.04.23 Dr. J. Withalm 48


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

19.04.23 Dr. J. Withalm 49


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

19.04.23 Dr. J. Withalm 50


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

19.04.23 Dr. J. Withalm 51


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

19.04.23 Dr. J. Withalm 52


Brno

Structural things/7collaboration/2

Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name

Chain ofresponsibility

19.04.23 Dr. J. Withalm 53


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

19.04.23 Dr. J. Withalm 54


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

19.04.23 Dr. J. Withalm 55


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

19.04.23 Dr. J. Withalm 56


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

19.04.23 Dr. J. Withalm 57


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

19.04.23 Dr. J. Withalm 58


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

19.04.23 Dr. J. Withalm 59


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

19.04.23 Dr. J. Withalm 60


Brno

Structural things /15component/2

Graphically, a component is rendered as a rectangle with tabs, usually including only its name

orderform.java

19.04.23 Dr. J. Withalm 61


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

19.04.23 Dr. J. Withalm 62


Brno

Structural things/17node/2

Graphically, a node is rendered as a cube, usually including only its name

Server

19.04.23 Dr. J. Withalm 63


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

19.04.23 Dr. J. Withalm 64


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

19.04.23 Dr. J. Withalm 65


Brno

Behavioral things/3interaction/1

Graphically, a message is rendered as a directed line, almost always including the name of its operation

display

19.04.23 Dr. J. Withalm 66


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

19.04.23 Dr. J. Withalm 67


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

19.04.23 Dr. J. Withalm 68


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

19.04.23 Dr. J. Withalm 69


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

19.04.23 Dr. J. Withalm 70


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

19.04.23 Dr. J. Withalm 71


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

19.04.23 Dr. J. Withalm 72


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

19.04.23 Dr. J. Withalm 73


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

19.04.23 Dr. J. Withalm 74


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

19.04.23 Dr. J. Withalm 75


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)

19.04.23 Dr. J. Withalm 76


Brno

Dependency/2

Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label

19.04.23 Dr. J. Withalm 77


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

19.04.23 Dr. J. Withalm 78


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

19.04.23 Dr. J. Withalm 79


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

19.04.23 Dr. J. Withalm 80


Brno

Generalisation/2

Graphically, a generalisation relationship is rendered as a solid line with a hollow arrowhead pointing to the parent

19.04.23 Dr. J. Withalm 81


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

19.04.23 Dr. J. Withalm 82


Brno

Realisation/2

Graphically, a realisation relationship is rendered as a cross between a generalisation and a dependency relationship

19.04.23 Dr. J. Withalm 85


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

19.04.23 Dr. J. Withalm 86


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

19.04.23 Dr. J. Withalm 87


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

19.04.23 Dr. J. Withalm 88


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

19.04.23 Dr. J. Withalm 89


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

19.04.23 Dr. J. Withalm 90


Brno

Diagrams in the UML/8 interaction diagram, sequence diagram

A sequence diagram is an interaction diagram that emphasises the time-ordering of messages

19.04.23 Dr. J. Withalm 91


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

19.04.23 Dr. J. Withalm 92


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

19.04.23 Dr. J. Withalm 93


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.

19.04.23 Dr. J. Withalm 94


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

19.04.23 Dr. J. Withalm 95


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

19.04.23 Dr. J. Withalm 116


Brno

Architecture/5

Design view

Process view Deployment view

Implementation view

Use caseview

vocabularyfunctionali

tybehavior

performancescalability

throughput

system assemblyconfigurationmanagement

system topologydistributiondeliveryinstallation

19.04.23 Dr. J. Withalm 117


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

19.04.23 Dr. J. Withalm 118


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

19.04.23 Dr. J. Withalm 119


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

19.04.23 Dr. J. Withalm 120


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

19.04.23 Dr. J. Withalm 121


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

19.04.23 Dr. J. Withalm 125


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

19.04.23 Dr. J. Withalm 126


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

19.04.23 Dr. J. Withalm 127


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

19.04.23 Dr. J. Withalm 135


Brno

Overview




Hints &Tips



19.04.23 Dr. J. Withalm 136


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

19.04.23 Dr. J. Withalm 137


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

19.04.23 Dr. J. Withalm 138


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.

19.04.23 Dr. J. Withalm 139


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 .

19.04.23 Dr. J. Withalm 140


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.

19.04.23 Dr. J. Withalm 141


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

19.04.23 Dr. J. Withalm 142


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

19.04.23 Dr. J. Withalm 143


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

19.04.23 Dr. J. Withalm 144


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.

19.04.23 Dr. J. Withalm 145


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

19.04.23 Dr. J. Withalm 146


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.

19.04.23 Dr. J. Withalm 147


Brno

Validation and Verification

19.04.23 Dr. J. Withalm 148


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

19.04.23 Dr. J. Withalm 149


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. Withalm19.04.23

Thank youfor your attention!

01.10.2015 Brno Dr.J. Withalm Software Modeling, UML.

Documents