Software Modeling, UML

1
Software Modeling, UML
2
Overview

• Motivation/Introduction
• CMMI-a brief overview
• UML-a brief overview
• Hints Tips
• Which UML models are most appropriate to be
  applied in which KPAs

3
Definitions/1
Quality the totality of features and
characteristics of a product or service that bear
on its ability to satisfy stated or implied
needs (ISO8402).
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
4
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?

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

6
Needs and Requirements

• Identified needs must be transformed into
  requirements.
• However, a product that satisfies requirements
  does not always satisfies needs.

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

8
QUALITY IN USE CONCEPTSStates System Model
Effects
Needs
QIU
Current States
Goal States
Realized States
Current System
Proposed System
Developed System
Cause
9
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.

10
Requirements/1

• Business oriented requirements
• Functional requirements
• Non functional requirements

11
Requirements/2How to measure the fulfillment
12
Requirements/3How to establish Business
Strategies
13
Requirements/4How to establish Business Models
Product Value proposition
Customer Interface Target Customer
Distribution Channel
Relationship
Infra-structure Value Configuration
Capability
Partnership
Financial Aspects Cost Structure
Revenue (Sharing) Model
14
Requirements/5Assessment Tree
F V 0,8218 p 100
F 1 V 1 0,847 p 1 40
F 2 V2 0,805 p 2 60
F 11 V11 0,83 p 11 90
F 12 V12 1 p 12 10
F 21 V21 0,9 p 21 50
F 22 V22 0,75 p 22 10
F 23 V23 0,7 p 23 40

• (p, x V,)
• j

v J
100
F 211 V211 1 p 211 30
F 212 V212 0 p 212 10
F 213 V213 1 p 213 60
v 21
30 x 1 10 x 0 60 x 1
0,9
100
15
Requirements/6Non Functional Requirements/Quality
Characteristics

• reliability
• functional performance
• user friendliness
• time behaviour
• consume behaviour
• maintainability
• portability

16
Requirements/6Action in SEM phases concerning
quality evaluation
Application of SEM Quality Evaluation Definition
of quality objectives Direction for
technical and quality assurance activities Exami
nation if quality objectives are reached
SEM Phases Initiation Study System
Design Detailed Design Implementation Integration
System Test Acceptance
17
Requirements/7SEM Software Quality Evaluation

• Definition
• Quality characteristics
• Subcharacteristics
• List of criteria / checklists
• Evaluation procedures

18
Requirements/8Subcharacteristics / 1
back up
Quality characteristics in terms of SN 77
350 reliability functional
performance user friendliness time behaviour
Subcharacteristics availability safety completen
ess correctness learnability ease of
handling response time start-up time throughout
rate holding time
19
Requirements/9Subcharacteristics / 2
back up
Quality characteristics in terms of SN 77
350 consume behaviour maintainability port
ability
Subcharacteristics CPU-requirement CPU-load prima
ry storage requirement peripheral storage
requirement peripheral device requirement output
volume - technical portability adaptability
20
Requirements/10Evaluation Procedures
back up

• measuring
• point scaling system
• evaluation tree(functional performance)
• project specific procedures

21
Requirements/10Structuring of quality costs

Quality related costs
Test costs
Error prevention cost
Error costs Internal/external
Cost to be conform to requirements
Costs to be non conform to requirements
Process related costs
22
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

23
Requirements/12Whats 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
24
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.

25
Overview

• Motivation/Introduction
• CMMI-a brief overview
• UML-a brief overview
• Hints Tips
• Which UML models are most appropriate to be
  applied in which KPAs

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

27
CMMI Maturity Levels (staged)
Each transition takes1-3 years !
28
Characteristics of an immature process

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

29
Characteristics of a mature process

• Standardized process, defined and documented
• has been understood and accepted
• is being applied
• is alive
• Visible support through management
• Clear definition and understanding of roles and
  responsibilities
• Well-established control process compliance is
  being monitored and enforced
• Consistent with the staffs current way of
  working
• Measurable and being measured
• Supported by means of suitable technologies and
  tools

30
CMMI Process Areas
Organizational Innovation and Deployment Causal
Analysis Resolution
Optimizing (5)
Quantitative Process Management Software Quality
Management
Quantitatively Managed (4)
Requirement Development Technical
Solution Product Integration Verification Organiza
tional Process Focus Organizational Process
Definition Organizational Training Integrated
Project Management Risk Management Decision
Analysis and Resolution
Defined (3)
Requirements Management Project Planning Project
Monitoring and Control Supplier Agreement
Management Measurement and Analysis Process and
Product Quality Assurance Configuration Management
Managed (2)
31
Process Areas and Specific Goals of ML 2 (1)
32
Process Areas and Specific Goals of ML 2 (3)
33
Process Areas and Specific Goals of ML 3 (1)
34
Process Areas and Specific Goals of ML 3 (2)
35
Process Areas and Specific Goals of ML 3 (3)
36
Assessments/ Certification history in general
back up
- 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
quality validation quality
assurance sample audits on the current
checks during finished product the
development process
37
Assessments/ Certification history in general/2
back up
- 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
38
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
39
Overview

• Motivation/Introduction
• CMMI-a brief overview
• UML-a brief overview
• Hints Tips
• Which UML models are most appropriate to be
  applied in which KPAs

40
Why we model

• A model is a simplification of reality
• We build models so that we can better understand
  the system we are developing
• through modeling, we achieve four aims
• models help us to visualise a system as it is or
  as we want it to be
• models permit us to specify the structure or
  behavior of a system
• models give us a template that guide us in
  constructing a system
• models document the decisions we have made
• We build models of complex system because we
  cannot comprehend such a system in its entirety

41
Principle of modeling

• The choice of what models to create has a
  profound influence on how a problems is attacked
  and how a solution is shaped
• Every model may be expressed at different levels
  of precision
• The best models are connected to reality
• No single model is sufficient. Every nontrivial
  system is best approached through a small set of
  nearly independent models

42
Overview of the UML

• The UML is a language for
• visualising
• specifying
• constructing
• documenting

43
When can the UML be used?

• The UML is intended primarily for
  software-intensive system
• it has been used effectively for such domains as
• enterprise information systems
• banking and financial services
• transportation
• telecommunication
• defense /aerospace
• retail
• Medical electronics
• scientific
• distributed Web-based services

44
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

45
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

46
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
47
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

48
Structural things/3classes/2

• Graphically, a class is rendered as a rectangle,
  usually including its
• name
• attributes
• operations

Window
origin size
open() close() move() display()
49
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

50
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

51
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 thats 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

52
Structural things/7collaboration/2

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

Chain ofresponsibility
53
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

54
Structural things/9use cases/2

• Graphically, a use case is rendered as an ellipse
  with solid lines, usually including only its name

place order
55
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

56
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

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

59
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, youll 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

60
Structural things /15component/2

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

orderform.java
61
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

62
Structural things/17node/2

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

Server
63
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

64
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

65
Behavioral things/3interaction/1

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

66
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

67
Behavioral things/5state machine/2

• Graphically, a state is rendered as a rounded
  rectangle, usually including its name and its
  substates , if any

Waiting
68
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

69
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

70
Grouping things/3package/2

• Graphically, a package is rendered as a tabbed
  folder
• Usually including only its name and, sometimes,
  its contents

Business rules
71
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

72
Annotational things/2note/1

• A note is simply a symbol for rendering
  constraints and comments attached to an element
  or a collection of elements

73
Annotational Things/3note/2

• Graphically, a note is rendered as a rectangle
  with a dog-eared corner, together with a textual
  or graphical comment

74
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

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

76
Dependency/2

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

77
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

78
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

79
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

80
Generalisation/2

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

81
Realisation/1

• A realisation is a semantic relationship between
  classifiers
• wherein one classifier specifies a contract that
  another classifier guarantees to carry out
• youll 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

82
Realisation/2

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

83
Diagrams in the UML/1

• A diagram is a graphical presentation of a set of
  elements
• most often rendered as a connected graph of
  vertices (things) and arcs (relationship)
• you draw diagrams to visualise a system from
  different perspectives
• so a diagram is a projection into a system

84
Diagrams in the UML/2

• For all but the most trivial systems
• a diagram represents an elided view of the
  elements that make up a system
• the same element may appear
• in all diagrams
• only a few diagrams (the most common case)
• in no diagram at all (a very rare case)
• in theory, a diagram may contain any combination
  of things and relationships
• in practice, however, a small number of common
  combinations arise,
• which are consistent with the five most useful
  views that comprise the architecture of a
  software-intensive system

85
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

86
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

87
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

88
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

89
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

90
Diagrams in the UML/8 interaction diagram,
sequence diagram

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

91
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

92
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

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

94
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

95
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

96
Rules of the UML/1

• The UML has semantic rules for
• Names What you can call things,
  relationships, and diagrams
• Scope The context that gives specific meaning
  to a name
• Visibility How those names can be seen and used
  by others
• Integrity How things properly and consistently
  relate to one another
• Execution What it means to run or simulate a
  dynamic model

97
Rules of the UML/2

• Models can also be build that are
• Elided Certain elements are hidden to
  simplify the view
• Incomplete Certain elements may be missing
• Inconsistent The integrity of the model is not
  guaranteed

98
Common mechanisms in UML/1

• Four common mechanisms that apply consistently
  throughout the language
• specifications
• adornments
• common divisions
• extensibility mechanisms

99
Common mechanisms in the UML/2specifications/1

• The UML is more than just a graphical language
• Behind every part of its graphical notation
• There is a specification that provides
• A textual statement of the syntax and semantics
  of that building block
• Things, relationships, and diagrams

100
Common mechanisms in the UML/3specifications/2

• For example, behind a class icon is a
  specification
• That provides the full set of
• Attributes
• Operations-including their full signatures
• And behaviors that the class embodies
• Visually, that class icon might only show a small
  part of this specification
• Furthermore, there might be another view of that
  class that represents a completely different set
  of parts
• Yet is still consistent with the classs
  underlying specification.

101
Common mechanisms in the UML/4specifications/3

• You use the UMLs graphical notation to visualize
  a system
• You use the UMLs specification to state the
  systems details
• Given this split, its possible to build up a
  model incrementally
• By drawing diagrams and then adding semantics to
  the models specification
• Or directly by creating a specification
• Perhaps by reverse engineering an existing system
• And then creating diagrams that are projections
  into those specifications.

102
Common mechanisms in the UML/5specifications/4

• The UMLs specification provide a semantic
  backplane
• that contains all the parts of all the models of
  a system
• each part related to one another in a consistent
  fashion
• the UMLs diagrams are thus simply visual
  projections into that backplane
• each diagram revealing a specific interesting
  aspect of the system

103
Common mechanisms in the UML/6adornments

• shows a class, adorned to indicate that is an
  abstract class
• with two public
• one protected
• one private
• every element in the UMLS notation starts with a
  basic symbol
• to which can be added a variety of adornments
  specific to that symbol

Transaction execute() rollback()
priority() - timestamp()
104
Common mechanisms in the UML/7common division/1

• First, there is the division of class and object
• a class is an abstraction
• an object is one concrete manifestation of that
  abstraction
• every building block in the UML has the same kind
  of class/object dichotomy
• you can have use cases and use case instances
• components and component instances
• nodes and node instances
• graphically, the UML distinguishes an object by
  using the same symbol as its class and then
  simply underlying the objects name

105
Common mechanisms in the UML/8common division/2

• Second, there is the separation of interface and
  implementation
• an interface declares a contract
• an implementation represents one concrete
  realisation of that contract
• almost every building block in the UML has this
  same kind of Interface/implementation dichotomy
• you can have use cases and the collaborations
  that realise them
• as well as operations and the methods that
  implement them

106
Common mechanisms in the UML/9extensibility
mechanisms

• The UMLS extensibility mechanisms include
• stereotypes
• tagged values
• constraints

107
Common mechanisms in the UML/10extensibility/2 s
tereotypes

• A stereotype extends the vocabulary of the UML
• allowing you to create new kinds of building
  blocks
• that are derived from existing ones
• but that are specific to your problem

108
Common mechanisms in the UML/11extensibility
mechanisms/3 tagged values

• A tagged value extends the properties of a UML
  building block
• allowing you to create new information in that
  elements specification

109
Common mechanisms in the UML/12extensibility
mechanisms/4 constraint

• A constraint extends the semantics of a UML
  building block
• allowing you to add new rules or modifying
  existing ones

110
Common mechanisms in the UML/13extensibility
mechanisms/5 example/1

• Stereotype
• You can make exceptions first class citizens in
  your models
• Meaning that they are treated like basic building
  blocks
• By marking them with an appropriate stereotype ,
  as for the class Overflow
• Tagged value
• Extends the properties of a UML building block
• Allowing you to create new information in that
  elements specification.
• For example, the class EventQueue is extended by
  making its version and author explicitly.
• Constraints
• Extends the semantics of a UML building block
• Allowing you to add new rules or modify existing
  ones
• For example, you want to customize the EventQueue
  class so that all additions are done in order.

111
Common mechanisms in the UML/14extensibility
mechanisms/5 example/2
112
Architecture/1

• A systems architecture is perhaps the most
  important artifact that can be used to
• manage different viewpoints
• control the iterative and incremental development
  of a system throughout its life cycle

113
Architecture/2

• Architecture is a set of significant decisions
  about
• the organisation of a software system
• the selection of the structural elements and
  their interfaces by which the system is composed
• their behavior, as specified in the
  collaborations among those elements

114
Architecture/3

• the composition of these structural and
  behavioral elements into progressively larger
  subsystems
• the architectural style that guides this
  organisation
• the static and dynamic elements and their
  interfaces, their collaborations, and their
  composition

115
Architecture/4

• the architecture of a software-intensive system
  can best be described by five interlocking views
• each view is a projection into the organisation
  and structure of the system
• focused on a particular aspect of that system

116
Architecture/5
vocabulary functionality behavior
system assembly configuration management
performance scalability throughput
system topology distribution delivery installation
117
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 doesnt really specify the organisation
  of a software system
• rather, it exists to specify the forces that
  shape the systems 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

118
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

119
Architecture/8process view

• The process view of a system encompasses the
  threads and processes that form the systems
  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

120
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 systems 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

121
Architecture/10deployment view

• The deployment view of a system encompasses the
  nodes that form the systems 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

122
Architecture/11

• Different stakeholders
• end users
• Analysts
• developers
• system integrators
• Testers
• technical writers
• project managers
• bring different agendas to a project, and each
  looks at that system
• in different ways
• at different times over the projects life.

123
Architecture/12

• Each of these five views can stand alone so that
  different stakeholders can focus on the issues of
  the systems architecture that most concern them
• these five views also interact with one another
• nodes in the deployment view hold components in
  the implementation view
• that, in turn, represent the physical realisation
  of classes, interfaces, collaborations, and
  active classes from the design and process view
• the UML permits you to express every one of this
  five views and their interactions

124
Software development life cycle/1

• The UML is largely process-independent
• meaning that it is not tied to any particular
  software development life cycle
• however, to get the most benefit from the UML,
  you should consider a process that is
• use case driven
• architecture-centric
• iterative and incremental

125
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 systems
  architecture
• for testing, and for communicating among the
  stakeholders of the project

126
Software development life cycle/3architecture-cen
tric

• Architecture-centric means that a systems
  architecture is used as a primary artifact for
• conceptualising
• constructing
• managing
• and evolving the system under development

127
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 systems
  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

128
Software development life cycle/5phases/1

• This use case driven, architecture-centric, and
  iterative/incremental process can be broken into
  phases
• a phase is the span of time between two major
  milestones of the process
• when a well-defined set of objectives are met
• artifacts are completed
• decisions are made whether to move into the next
  phase
• there are four phases in the software development
  life cycle
• inception
• elaboration
• construction
• transition

129
Software development life cycle/6phases/2

• workflows are plotted against these phases,
  showing their varying degrees of focus over time

130
Software development life cycle/7inception phase

• Inception is the phase of the process
• when the seed idea for the development is brought
  up to the point of being- at least- sufficiently
  well founded to warrant entering into the
  elaboration phase

131
Software development life cycle/8elaboration
phase

• Elaboration phase is the second phase of the
  process
• when the product vision and its architecture are
  defined
• in this phase, the systems requirements are
  articulated, prioritised and baselined
• a systems requirements may range from general
  vision statements to precise evaluation criteria,
  each specifying particular functional or
  nonfunctional behavior and each providing a basis
  for testing

132
Software development life cycle/9construction
phase

• Construction is the third phase of the process
• when the software is brought from an executable
  architectural baseline to being ready to be
  transitioned to the user community
• here also, the systems requirements and
  especially its evaluation criteria are constantly
  reexamined against the business needs of the
  project, and resources are allocated as
  appropriate to actively attack risks to the
  project

133
Software development life cycle/10transition
phase

• Transition phase is the fourth phase of the
  process
• when the software is turned into the hands of the
  user community
• rarely does the software development process end
  here
• for even during this phase, the system is
  continuously improved, bugs are eradicated, and
  features that didnt make an earlier release are
  added

134
Software development life cycle/11iteration

• One element that distinguishes this process and
  that cuts across all four phases is an iteration
• an iteration is a distinct set of activities,
  with a baselined plan and evaluation criteria
  that result in a release, either internal or
  external
• this means that the software development life
  cycle can be characterised as involving a
  continuous stream of executable release of the
  systems architecture
• it is this emphasis on architecture as an
  important artifact that drives the UML to focus
  on modeling the different views of a systems
  architecture

135
Overview

• Motivation/Introduction
• CMMI-a brief overview
• UML-a brief overview
• Hints Tips
• Which UML models are most appropriate to be
  applied in which KPAs

136
Which UML Model will support us in which Key
Process Area of CMMI
UML-Models REQM CM RD TS PI VER VAL
Use cases
deployment
State chart
Interfaces
Process and threads
Events and signals
components
interactions
collaborations
137
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

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

139
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
• .

140
RD (Requirements Development)

• Specific goal 1 develop customer needs
• Elicit needs
• Develop the customer requirement
• Specific goal 2develop 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.

141
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
• Start with the established use case diagrams of
  the customer requirements
• Derive a collaboration diagram
• Establish a component diagram
• 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

142
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

143
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 users
  environment using multiple techniques as
  appropriate

144
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 2develop 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.

145
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
• Its 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

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

147
Validation and Verification
148
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

149
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

150
Thank youfor your attention!