MMP2

www-wi.cs.uni-magdeburg.
de
Modelling Methods
MMP2
07.12.2006 Leitung: Claus Rautenstrauch

1
www-wi.cs.uni-magdeburg.de
Introduction and First Examples

2
Models and Modeling
 Definition
• A model is an abstract, immaterial mapping of real world structures or
behaviour for the purposes of some subject, i. e.
• A model is an
- Adequate
- simplifying
- idealized
mapping of reality
• Modeling is a creative process of designing a model

3
First Step
 Modeling of Data Structures
• Data (D) are input (I) and output (O) objects of functions f: I  O, or
more generally: f: D  D
• Functions
- are implemented as algorithms of computer programs
- Cause state transitions of a system, documented in change of data
 Abstraction
• Moving from level of Individuals to level of types

4
Example of Functions, Data and Abstraction

5
Expression of Models
 What is a language?
 Languages for Modeling
• Mathematics
• Programming Languages
• Semi formal graphical languages (also called modeling methods)

6
A Simple Modeling Language
 The Entity-Relationship Model (Chen 1976)
• Elements
Entity type Identifier
Role (attribute) Identifier
c1 c2
Relationship type Identifier

7
How to Find the Object
 Conceptual Modelling
• Statements
- „Students join a lecture“
- „Lectures are given by lecturers“
- „Lectures are in a room“
- „A room consists of chairs, whiteboard and table“
• What are
- Entity types
- Relationship types
- Attributes?

8
Let„s try it

9
Some Extensions of Chen„s Model
 Attributes
• Simple Attribute: <Name, Domain> tuple

• Multiple Attribute: Set of multiple values
• Collection Attribute: Record of <Name, Domain> Tuples
• Obligatory versus mandatory attributes

- Mandatory attributes allow NULL values
• Key attributes
- Identify uniquely one entity
- Surrogat:: One (artificial) attribute which is key
 Cardinalities
• (min, max) cardinalities

10
Further Extensions
 Associative Entity Types
• Mix of Entity and Relationship Type with foreign key attributes
 Generalization/Specialization
• Is-a operator
- Disjoint (XOR)
- Non disjoint (OR)

11
Associative Entity Types with Key Attributes and (min, max)
Cardinalities
BPNo ONo BPNo
ODate Name
(0,*) (0,*)
Time Auftrag
Order BusinessPartner
(1,*)
(1,*)
OrderPosition Part
ONo PNo
OposNo Name
PNo

12
Sub and Super Entity Types
 Simple
BusinessPartner
is a
Customer Supplier Bank

13
Sub and Super Entity Types
 Sophisticated
Geschäftspartner
Kunde Lieferant Bank

14
System Theory

15
Basics
 System
• Structural System conception

- Set of elements with properties, which interrelate to each other
• Hierarchical System conception
- Elements can be (sub) systems
• Open versus Closed Systems
- Systems can have relations to a surrounding system

16
Example: Enterprise as a System
 Properties
• open
• Socio-technical
• Target oriented

17
System Structure
 Elements and Relationships
• Is-part-of
• Is-a
• Interacts-with
 If changeable during life time
• Dynamic System

18
System State
 At each dedicated momentum a system has concrete properties
• Distribution of System Objects

• Type, number and directions of relationships
 System Behaviour
• State transitions caused by deployment of interacts-with Relationships

• Trigger: time and resource comsuming task executions
• static versus dynamic system behaviour

19
System
Surrounding System
Influences Results
System

20
Processes from Perspective of System Theory
 Process is Sequence of System States
• Description needs relevant elements and properties

• Set of all possible processes describes static system behaviour

21
Complex versus Complicated
 A system is called complex, if
• Number of elements and relationships is large
 A system is called complicated, if
• Diversity of elements and relationships is high

22
Modelling Theory

23
Model Systems
 Model establishes relationship between two systems
 Components of a Model
• Object system (SO)

- subjective Interpretation of a taget oriented selected part of real world
- relevant surrounding system
• Model system (SM)
- Subjective mapping of object system
- Expressed through suitable mata model (modelling language)

24
Mapping Relation
 Relation to map SO to SM
• Elimination of irrelevant issues

• Typization of relevant issues
• Formally: Homomorphism r: SO  SM
Why not an isomorphism?

25
Modelling Worldmap
Execution relation
subjective modelling goals
subjective
Interpretation Target relation
SO SM
Discursive Mapping relation
Object Model
world system Structural
and behavioural system
compliance
Consistency/
completeness
Meta model

26
Modelling Goals
 Explanation of complex and complicated Phenomenons
• Model as an abstract reconstruction of reality
 Design
• Creation of options for (re-)design of real world

• Goal: Improvement of real world
• Model has constructive character

27
Information Models
 Let SO be and information system, then SM is an information

model SI
 An information system is defined as the (whole) information

processing system as part of a discursive world
 Information objects (also called concepts) are elements and

relations of SI
 Special case: Application System Model

28
Information Modelling
Property Expression
Description Data Functions
Organization Processes
perspective Objects
Description Implementation
Business concept IT concept
level concept
Subject area As is model To be model Ideal model
Content Company specific

Reference model Master model
individuality model
Level of Meta-meta
Entitiy level Type level Meta level
abstraction level

29
Description View
 Data
• passive system elements, to be changed through functions

• Expression of system states
• Container of concepts and relationship between them
 Funktions
• Define state transitions of data

• f: I  O

30
Description View
 Objects
• Semantically interconnected functions (called methods) and da are encapulated in

objects
• Communication between object through messages
 Organization (here: Structural Organization)
• Organization units and their relationships
 Processes
• Describe (dynamic) system behaviour

31
Simplification of Description View
 Data
• What is to be changed
 Functions
• How to change
 Organization
• Who changes
 Process
• In which sequence is to be changed

32
Description Level
 Business Concept
• (semi-)formal, implementiation independet description of a business conception or

model
 IT Concept
• Extension of business concept with requirements and restrictions of IT paradigms

and implementation framework
 Implementation concept
• Expression of IT implementation

33
Reference Models – Theoretical View
 Reference = Recommendation
 Typical requirement to reference models is the demand on some

generalization
 Based on such demand, a reference model is an to be or ideal model

for a specific subject area
• E. g. reference process model for order management in textile industry

34
Reference Models - Practise
 Reference models are often (lightweight) abstractions of company

specific models (and therefore often not too generic)
• Often called industry reference models
 Reference models with higher genericity
• Reference data models (high genericity)

• Reference function models (mostly done by scientists from Management Science
and ERP system vondors)
• Reference process models

35
Master Models
 Master models are created through composition of different

reference models
 They are a union of different reference models and therefore

more generic than reference models

36
Objectives of Reference Modelling
 Reduction of design expenditures for company specific models
 Deployment fields (examples)

• Business Process Optimization
- „Reference Organization Models“
- Problem: Influence on competitive advantages?
• Customizing of off-the-shelf-software
- „Reference Application System Models“
- aspects: simplified coupling of Component Ware
Management of software complexity

37
Mastermodels
Master
Application
Composition System Model
(is-part-of)
Reference
theoretical
Models
results
Induction,
in particular
abstraction
(is-a) Company
specific
Models

38
Level of Abstraction
causes
0, n 0, n
Event type Function type
0, n Is ge- 0, n
nerated
Meta level
Order arrived Insert order Order inserted
Type level
Insert order 4711

Order 4711 arrived Insert order 0815 Order 4711 inserted
Order 0815 arrived Insert order 0391 Order 0815 inserted
Order 0391 arrived Order 0391 inserted
Entity level
39
Meta Meta Level
Source
0, n 0, n
Node type Edge type
0, n 0, n
Sink

40
Typology of Models
Property Expression
Description Data Functions
Organization Processes
perspective Objects
Description Implementation
Business concept IT concept
level concept
Subject area As is model To be model Ideal model
Content Company specific

Reference model Master model
individuality model
Level of Meta-meta
Entitiy level Type level Meta level
abstraction level

41
Grundsätze ordnungsmäßiger Modellierung
Principles of Regular Modelling
A Framework for Reduction of Subjectivity in Modelling

42
Literature
 Rosemann, M.: Komplexitätsmanagement in Prozeßmodellen,

Gabler Verlag Wiesbaden 1996.
 Becker, J., Rosemann, M., Schütte, R.: Grundsätze
ordnungsgemäßer Modellierung; Wirtschaftsinformatik 37
(1995) 5, S. 435-445.

43
Goals of Definition of PRM
 Improvement of Model Quality through
• Design recommendations for requirement compliant modelling

• Reduction of diversity of possible modelling variants
• Increase of comparability and integration capabilities of models

44
Deductive Derivation of PRM
 Sources of Derivation
• Ex definitionem: Derivation from goals of infromation modelling

• Objectives which are determined by the model„s addressee
• Objectives which are foundation of any economic behaviour

45
Overview
 Principle of Correctness
• Correct mapping of real world to model
 Principle of Relevance
• Model must be compliant to subjective targets
 Principle of Economy
• Relation of costs and benefits has to be taken into account
 Principle of Clearness
• Model must be easy to understand for modeler and addressee
 Principle of Comparability
• Identities, equivalences and compatibilities of model have to be recognizable
 Principle of Systematic Design
• Information architectures consist of different views, which have to fit to each other

46
Interdependencies between Correctness, Relevance and Economy
Correct Models
Steering Wheel
Relevance
Steering Wheel
Economy

47
Classification of PRM
obligatory principles
Correctness Relevance Economy
Quality of Infor-
mation Model
Systematic
Clearness Comparability
Design
Mandatory principles

48
Principle of Correctness
 Syntactical Correctness
• Completeness regarding the employed meta model

- All methodical elements, which are required by syntax of modelling
language, are used
• Consistency regarding employed meta model
- All information objects and notation rules used in the model are
explained in the meta model

49
Principle of Correctness II
 Semantic Correctness contains
• Homomorphy of the model regarding reality

• Scoring units: Structural and behavioural compliance
- In relation to ideal or to-be-models
- Measured through logical issues and interrelationships
• Semantic consistency
• Up-to-dateness

50
Principle of Relevance
 Selection of all relevant phenomenons from real world
• Priorities complying to economic index numbers or targets

• Analysis of relevance
- If the benefit of a model is reduced through extraction of parts of the
model for the addressee, then the part of the model is relevant

51
Principle of Relevance II
 Relevance is somehow like minimality
 Important: clear determination of goals
 Relevance relates to
• Object system (modeled elements)

• Mapping relation between real world and model (modelling method)
• Model system (application of modelling method)

52
Principle of Economy
 Benefit of model cannot be determined with generic methods,

therefore an analysis of inflencing factors is necessary
• Expenditures for design

• Application period
- Persistency of model
- Flexibility

53
Approaches of „Economic“ Modelling
 Usage of reference models

 Reuse of model units
 Deployment of computer-based modelling tools

54
Principle of Clearness
 Pragmatism
• Relationship between model and user
• subjective versus intersubjective clearness
 Asthetic Criteria
• Structure
• intuitive accessability
• Transparency
• Readability

55
Clear Models
 Are simple
 Graphically well structured

• Positioning of model objects in a grid
• Edges in two orthogonal dimensions
• Best possible linearity of edges
• minimal crossings of edges
• Graphical expression of corresponding elements
• Ordering of objects in reading direction
• Application of naming conventions

56

57
Principle of Comparability
 Relevant in particular in shared working environments

 Model-to-model impact of principle
 Applied meta models have to be compatible
 Conformity of models is reached through application of
conventions regarding usage of names and modelling elements

58
Proceeding Model of Shared Model Development
concept
Draft
Data model
Conceptual
concept
Detail
Projects
P1 P2 P3
Data

59
Principle of Systematic Design
 Requires multiple view meta model

 Creation of integrable model views

60
Object Modelling
UML – Unified Modelling Language

61
Background
 Definition UML
• Graphical modelling language for visualization, specification, construction and documentation
of software systems
 Synthesis
• Co-operation of the „Three Amigos“ (Booch, Rumbaugh und Jacobson)
• Mid of the 90es: Integration of their individual approaches of software modelling
- OOD (Object-Oriented Design) by Grady Booch
- OMT (Object Modeling Technique) by James Rumbaugh
- OOSE (Object-Oriented Software Engineering) by Ivar Jacobsen
 Goals
• A software modelling should reach vom conception until executable tool in an object-oriented
manner
• The language should meet the challenges of complex and enterprise critical applications
• The language must be understandable by humans and machines

62
Background (contd.)
 History
• 1996: UML version 0.9

• Co-operation of leading software companies (e. g. IBM, Microsoft,
Oracle, Hewlett-Packard, Rational Software Corporation) to so called
UML Consortium
• Result: UML version 1.0
• 1997: UML version 1.1 as a standard with Certificate of Object
Management Group (OMG)
• 2006: UML 2.0 published

63
Structure of UML 2.0

64
Structure of UML 2.0
 Structure diagrams
• static design of a software
- Classes and Interfaces
- Components and their relations
- Function inside a software system
 Behaviour diagrams
• Description of dynamic behaviour of a software
• Description of reactions regarding events from outside

65
Structure Diagrams
 Class diagram
• Illustration of classes and interfaces including their properties and relations to
each other
• Creation of a conceptual and specifying view on software
- Conceptual view: relationships (dependencies, aggregation, composition and
inheritance) between clases and interfaces
- Specifying view: Design of a class with methods, functions, variables and
visabilities
• Both views are close to implemenation and form the basis for automatic code
generation
 Package diagram
• Hierarchical structure of classes
• Division of software systems in different components (e. g. presentation, model
and data component), which are implemented in different packages
• Clear division of single components, so that a well understandable structure of
software appears

66
Structure Diagrams (Contd.)
 Deployment diagram
• Configurations of software and their components
• Overview about software components
- Assignment to nodes (computer or runtime environment)
- Interconnection through interfaces
 Component diagram
• Shows the design and dependencies between software software components
 Object diagram
• Snapshot of instances of classes (objects) and their relationships
• Illustration of a class diagram during runtime
 Composite structure diagram

• Decomposition of a class to its internal structure
• Specification of internals of a class during runtime and their relationships to the interfaces of
the class

67
Behaviour Diagrams
 Use case diagram

• Use cases, acting instances and their relationships to a software system
• Definition of functional requirements to a software from different user perspectives
• Since UML defines no rules about content of the use cases, they can be
employed on different levels of abstraction
 Activity diagram
• Sequence of activities
• Depiction of parallel processes
 State machine diagram

• State transitions of a single object during its life cycle including state information,
transitions, events and activities

68
Interaction Diagrams
 Sequence diagram
• Temporal sequence of messages between objects
• Decription of behaviour and exchange of messages between objects in a use case
 Communication diagram
• Temporal sequence of data flows between objects
• Focus on exchange of data
 Interaction overview diagram

• Mix of activity and sequence diagrams, where activities are exchanged through refined
sequence diagrams
 Timing diagram
• Time restrictions between state transitions of objects
• For time critical software systems, where time restrictions between state transitions of objects
are relevant

69
Use Case Diagrams
 Use Case
• Simplified (business) activity
• Different related use cases create a business case
• Business cases depict structural interconnections between activities
• State transitions are assigned to use cases as attibutes, which define pre
and post conditions of a use case
• Further attributes
- Name of the use case
- functional and non-functional requirements
- Description
- Variations
- Contact person etc.

70
Use Case Diagrams (contd.)
 Use case diagram

• Illustration of use cases and their interconnections and to acting instances
• Acting instances are persons or organisational units
• Graphical elements
- Ovals: use cases
- Matchstick men: acting instances, if they are persons
- Rectangles: other acting instances
• Uses or extends relationships between use cases
- Uses: if descriptions of different use cases comply, then compliances are
separated in their own use cases, which are interonnected through uses
relationships
- Extends: connection of variants or special cases with the general case

71
Example
Sales
System
Offer
Sales Manage-
Manager ment
Pricing
Clerk
Invoicing
Foreign
Invoice
s
Accounting

72
Classes
 Are entity types which encapsulate attributes and methods containing

all operations of objects of the class
 Are depicted as rectangles containng only the class name or also the
attributes and methods
 Attributes and methods are delimited through lines within the rectangle
 Attributes are specified by Attribute name, Attribute type, default value
and assertions, where the name only is obligatory
 Methods are specified by their signature
 Defaults are automatically assigned values
 Assertions are
• Predicates which limit the domain types of attributes
• Preconditions which have be fulfilled before a method can be executed

73
Special Classes
 Parametrizable Classes
• Classes which receive classes as parameters
• Example: Class queue
- Methods for handling of elements acording to FIFO principle
- Parameters are for example classes „customer“ or „production order“
 Abstract Classes
• Complilation of common attributes and methods of sub classes to avoid redundancy
• No incarnation of objects
 Utility Classes
• Compliation of all global variables and functions, which cannot be asigned to class hierarchy
in a proper way
• Assigned as attributes and methods
 Interface Classes
• abstract classes, which encapsulate the external behaviour of classes
• They contain methods for information exchange between classes

74
Illustration
Class name
CustomerOrder
Attribute
names Order#: int {order#>0} Assertions
orderDate: date = sysdate
Attribute Defaults
…
types
CreateOrder (o#: int){o# > order#  order#  CustomerOrder}
Method OrderReschedule (from: date, to: sysdate)
names
Parameters

75
Class Diagrams
 Inheritage
Order
Order#
OrderDate
…
CreateOrder
RescheduleOrder
...
CustomerOrder PurchaseOrder ProductionOrder

… … …
… … …

76
Association
Company Employee
Name 1 employs> * Name

Address Address
… employer <is working for employee Emp#

77
Composition and Aggregation
 Composition („consists of“)
Company Department
Name 1 1..*
Name
Anschrift
Consists of>
 Aggregation (parts can exist without related object)
Product Assembly
P# 1 1..*
Name
PType
Consists of>

78
Example: Information Model for Technology Management
Verfahrenshinweis Pruefung Protokoll
Geschaeftspartner
Hersteller
Lieferant
Server
Rechenzentrum
Aufgabengruppe
Plattform
Vertrag
Listenformulare
Plattform_Verfahren Betreuer
Aufgabe
Schnittstelle
Verfahren externe interne
kuerzel
Externestellen bezeichnung
beschreibung
einsatzdatum
abloesedatum
Handbuch nutzung
Elektronischertitel OE
Geschaeftsprozess releasenummer
Manuellegeschaefte releaseeinsatzdatum
entwicklungsart
art
status
bemerkung
Handbuchart
personendaten
mah-relevant Geschaeftspartnergruppen
Teilprozess
vertrieb
bildscharbv
fuegeein() Marktprodukte
loesche()
Produktprozess aendere()

79
Package Diagramm
 Hierarchical structure of classes
 Division of software systems in different components (e. g.

presentation, model and data component), which are
implemented in different packages
 Clear division of single components, so that a well

understandable structure of software appears

80
Paketdiagramm
Comment
Class
Package Relationship
Import
Access
Merge

81
Elements of Package Diagram
 Comments
• Support structuring of package diagramms
 Packages
• Logial complilations of clases or packages
• Definition of name spaces
 Relationships
• Access:
- all names of public elements of a package are added to the importing package as private
• Import:
- all names of public elements of a package are added to the importing package as public
• Merge:
- Non private content of the target package are melted with content of source package

82
Deployment Diagram
 Configurationen of software and their components
 Overview about software components

• Assignment to nodes (computer or runtime environment)
• Interconnection through interfaces

83
Deployment Diagram
Interface
communi-
cation
path
Node
Software
Deployment component

84
Elements of Deployment Diagram
 Nodes
• System resource
 Software component
• Closed executable software artefact
 Interface
• Software for coupling of software components
 Kommunikation path
• Association between two nodes
 Deployment
• „deploys“ relationship

85
Prozessmodellierung
Modelling of System Behaviour

86
Process Definitions from Literature
 “We define a process as a collection of activities that takes one or more kinds of
input and creates an output that is of value for the customer” (Hammer, Champy
1993)
 “The term process means working on objects, i. e. its content is actions and
objects” (Nordsieck 1934)
 “We understnd the procedural orgnzation of a company as the process of

fulfilling tasks under conditions of logical, personal and locational and timed
aspects” (Weidner 1990)

87
Formal Definition of Process from Informatics
 Finite partial order Halbordnung P = (A, ) with
• A = {a1, a2, ..., an} finite set of activities

• partial order (means “is before”)
• For execution of activities resources are necessary

88
Process and Function
 Function
• Business task, which has to be executed at workplaces to transform

information or materials
• Program or module, which supports such task
 General term: activity

89
General Model of Activities
Environ-
mental
state
Event
Activity: Event
Transformation of information
or material based
Material on transformation rules
Material
Organizational
Human work
unit Resource

90
Modelling of Functions
 Function hierarchy
Customer Order Management Chain of acitities
or processes
Offer management Offer follow-ups Order registration
Functions
Technical
Calculation Partial functions
specification
Calculation of Calculation of Elementary

quantities values functions
91
Levels of Hierarchy
 Process oder activity chain

• Complex sequence of activities related to objects
 Function
• Complex activity which can be further subdivided and directly assembled to a
process
 Partial function
• Activity which can be further subdivided and assembled to a function
 Elementary function
• Activity which cannot be further subdivided

92
Final Definition of Term „Process“
 A process is a – related to the content – closed, timed and logic

sequence of functions, which are executed to manage business
objects (here: information)

93
Objects in Processes
 Organizational understanding of objects
• Objects drive processes wirkt ablauftreibend

• Objects ca appear in different processes
• Number and kinds might vary in process execution
• Objects can change their kind
• Objects can be material or immaterial

94
Benefits of process-oriented Strategies
 Focus on competitive factor time
 Focus on customer orientation
 Simplificaton of Benchmarking
 Reduction of object related co-ordination, i. e. reduction of

• Object related interfaces
• Quantity of process objects
• Media changes

95
Types of Process Models
 Activity models
• Goal: Support and control of procedures

• Modelling timed and logical relations between functons
• Functions have no knowledge about sequencing, process control on
higher level is necessary

96
Types of Process Models (II)
 Object migration models
• Control data are in focus

• Objects are understood as electronic files containing documents
• No central procell control
• Knowledge about the process is assigned to objects
 Conversation-oriented Models
• Description of communication between participating agents
• Communication through objects

97
Application Areas
 Analysis of business processes as part of BPR

projects
 Documentation of procedural organization
 Specification, selection and configuration of software
 Specification of workflows
 Simulation
 Project management
 Process costing

98
Processmodelling with UML

99
Activity Diagram
 Sequence of activities
• Function
• Implementation
- Method
 Illustration of parallel processes

100
Example
Object with state

Activity
Pre and post
conditions Start
Proof
completeness Control
Contract flow Contract
[complete] [released]
Proof Call for
compliance authorization
Contract
[compliant] Amount>500
Calculate Release
contract contract
Amount<500
Contract
[calculated]
Assignment of Decision End
condition

101
Example 2: Communication between Agents
Loop

102
Elements of Activity Diagrams
 Activities
• Functions
• In general: execution of tasks
• Elementary functions: Actions
• Encapsulations are allowed
• Pre and post conditions
 Control flow
• Directed connection between activities

• Determines sequence of executions

103
Objectflow
• Synchronous processing
of Objects
Object
• Object nodes
- Buffer/storage function Object-
node
- Capacity limit
- Edge weights
- Ordering (LIFO, FIFO, …)
• Flows
- Asynchronous processing
Signal

104
 Connectors
A A
• Pointers to interrelationships
 Exceptions
 Signals
• Send
• Receive
• Explicit modelling of events!
• Timed event

105
 Pre and post conditions
• As model elements of their own

• Also as annotation inside an activity
- <<precondition>>
- <<postcondition>>
 Start and end nodes
• Special case: end of flow

106
 Decision and union nodes
 Forking and union
• Modelling of parallel processes

• Union specification
- {joinSpec = A or B}: alternative paths
- {joinSpec = A and B}: Parallelity

107
 Loops input
parameter
• For – Do – While Initialization

for
• If – Then – Else –
Else If Test
while Decision node
Pin for test variable

do
Loop body
output
parameter

108
State Machine Diagram
 State transitions of single objects during lifetime
• With state information, transitions, events and activities

109
Example: States of Object „Flight“
State
Self cancel()
Transition [ reservedSeats >1]
reseve()
Without reservation Reserve () partially [ freeSeats >1]
Internal entry / rollback() reserved
Action Transition
cancel()
[ ReservedSeats =1]
reserve()
CreateFlight() DropFlight ()
[ freeSeats =1]
Method
cancel() Event
starting
state
Guard
close ()
Final Booked out
state
closed
close ()

110
Elements of State Machine Diagram
 State
• Represents a situation under dedicated and exactly determined conditions
 Transition
• Directed relationship between two states
• Defines a state transition from source to target state
 Events
• SignalEvent („Boss is coming“)
• Change Event („StockQuantity <0“)
• TimeEvent („between 8 and 12 o„clock“)
• AnyEvent („otherwise“)
• Guard
• Effect („StockQuantity<0/start production“)

111
 Actions Action
 Signals
• See also activity diagram
 Internal Actions
• Event/Internal Action
• Entry
- Will be executed when state is entered and finalized, before further actions
are executed
• Do
- Execution until state is left
• Exit
- Execution while leaving the state

112
 Starting and final state
 Crossing
• Sequence of transitions in ambiguous order
 Decision
• XOR situation

113
Sequence Diagram
 Timed sequence of messages between objects
 Description of behavior and exchange of messages between

objects for an use case

114
Beispiel
Liveline
reservation
- Purchase article
Order position
of articles order stock
reserve (b)
giveOrderPos()
Message active time
OPos
giveArticle()
article
Passive time
giveQty ()
Timeline
quantity
reserve (article, qty)
Answer
Activation bar

115
Elements of Sequence Diagrams
 Liveline
• Represents exactly one participant of an interaction
- Actors from use case diagram
- Objects
• Notation
- Name:Type
 Message
• Defines a communication and direction between participants
- call of a method
- Sending of a signal

116
Elements of Sequence Diagrams
 Message types
• Synchronous
• Asynchronous
• Send message
• Answer message
• Create and drop message
• lost and found message
 Activation bar
• Active versus passive time of an object

117
Communication Diagram
 Timed order of data relationships between objects
 Focus on exchange of data

118
Beispiel
message
1.1 giveOrderPos () >
order
liveline
1: reserve (b) >

article ArticleStorage
reservation
1.1.3 reserve
Clerk- (article, qty) >
liveline OrderPos
1.1.1 article:=giveArticle() >
1.1.2 qty:= giveQty ()
sequence message direction

119
Elemente
 Liveline
• see sequence diagram
 Message
• (sequence, message, direction) triple

120

MMP2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MMP2

Uploaded by

Copyright:

Available Formats

www-wi.cs.uni-magdeburg.

07.12.2006 Leitung: Claus Rautenstrauch

Introduction and First Examples

07.12.2006 Leitung: Claus Rautenstrauch

• Modeling is a creative process of designing a model

07.12.2006 Leitung: Claus Rautenstrauch

 Modeling of Data Structures

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

 Languages for Modeling

07.12.2006 Leitung: Claus Rautenstrauch

 The Entity-Relationship Model (Chen 1976)

Entity type Identifier

Role (attribute) Identifier

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

• Simple Attribute: <Name, Domain> tuple

• Obligatory versus mandatory attributes

• (min, max) cardinalities

07.12.2006 Leitung: Claus Rautenstrauch

 Associative Entity Types

• Mix of Entity and Relationship Type with foreign key attributes

07.12.2006 Leitung: Claus Rautenstrauch

BPNo ONo BPNo

07.12.2006 Leitung: Claus Rautenstrauch

Customer Supplier Bank

07.12.2006 Leitung: Claus Rautenstrauch

Kunde Lieferant Bank

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

• Structural System conception

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

 Elements and Relationships

 If changeable during life time

07.12.2006 Leitung: Claus Rautenstrauch

 At each dedicated momentum a system has concrete properties

• Distribution of System Objects

• State transitions caused by deployment of interacts-with Relationships

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

 Process is Sequence of System States

• Description needs relevant elements and properties

07.12.2006 Leitung: Claus Rautenstrauch

 A system is called complex, if

• Number of elements and relationships is large

 A system is called complicated, if

• Diversity of elements and relationships is high

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

 Model establishes relationship between two systems

• Object system (SO)

07.12.2006 Leitung: Claus Rautenstrauch

• Elimination of irrelevant issues

Why not an isomorphism?

07.12.2006 Leitung: Claus Rautenstrauch

07.12.2006 Leitung: Claus Rautenstrauch

 Explanation of complex and complicated Phenomenons

• Model as an abstract reconstruction of reality

• Creation of options for (re-)design of real world

07.12.2006 Leitung: Claus Rautenstrauch

 Let SO be and information system, then SM is an information

 An information system is defined as the (whole) information