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

07.12.2006

Leitung:

Claus Rautenstrauch 2

Models and Modeling

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 3

First Step

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 4

Example of Functions, Data and Abstraction

www-wi.cs.uni-magdeburg.de
07.12.2006

Leitung:

Claus Rautenstrauch 5

Expression of Models

www-wi.cs.uni-magdeburg.de

 What is a language?

 Languages for Modeling
• Mathematics • Programming Languages • Semi formal graphical languages (also called modeling methods)

07.12.2006

Leitung:

Claus Rautenstrauch 6

A Simple Modeling Language

www-wi.cs.uni-magdeburg.de

 The Entity-Relationship Model (Chen 1976)
• Elements

Entity type

Identifier

Role (attribute)
c1

Identifier

Relationship type

c2 Identifier

07.12.2006

Leitung:

Claus Rautenstrauch 7

How to Find the Object

www-wi.cs.uni-magdeburg.de

 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?

07.12.2006

Leitung:

Claus Rautenstrauch 8

Let„s try it

www-wi.cs.uni-magdeburg.de
07.12.2006

Leitung:

Claus Rautenstrauch 9

Some Extensions of Chen„s Model

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 10

Further Extensions

www-wi.cs.uni-magdeburg.de

 Associative Entity Types
• Mix of Entity and Relationship Type with foreign key attributes

 Generalization/Specialization
• Is-a operator - Disjoint (XOR) - Non disjoint (OR)

07.12.2006

Leitung:

Claus Rautenstrauch 11

Associative Entity Types with Key Attributes and (min, max) Cardinalities

www-wi.cs.uni-magdeburg.de

BPNo

ONo ODate

BPNo Name BusinessPartner

(0,*) Time Auftrag Order

(0,*)

(1,*) (1,*)

OrderPosition

Part

ONo
OposNo

PNo Name

PNo
Leitung: Claus Rautenstrauch 12

07.12.2006

Sub and Super Entity Types

www-wi.cs.uni-magdeburg.de

 Simple

BusinessPartner

is a

Customer

Supplier

Bank

07.12.2006

Leitung:

Claus Rautenstrauch 13

Sub and Super Entity Types

www-wi.cs.uni-magdeburg.de

 Sophisticated
Geschäftspartner

=

Kunde

Lieferant

Bank

07.12.2006

Leitung:

Claus Rautenstrauch 14

www-wi.cs.uni-magdeburg.de

System Theory

07.12.2006

Leitung:

Claus Rautenstrauch 15

Basics

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 16

Example: Enterprise as a System

www-wi.cs.uni-magdeburg.de

 Properties
• open • Socio-technical • Target oriented

07.12.2006

Leitung:

Claus Rautenstrauch 17

System Structure

www-wi.cs.uni-magdeburg.de

 Elements and Relationships
• Is-part-of • Is-a • Interacts-with

 If changeable during life time
• Dynamic System

07.12.2006

Leitung:

Claus Rautenstrauch 18

System State

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 19

System

www-wi.cs.uni-magdeburg.de

Surrounding System
Influences System Results

07.12.2006

Leitung:

Claus Rautenstrauch 20

Processes from Perspective of System Theory

www-wi.cs.uni-magdeburg.de

 Process is Sequence of System States
• Description needs relevant elements and properties • Set of all possible processes describes static system behaviour

07.12.2006

Leitung:

Claus Rautenstrauch 21

Complex versus Complicated

www-wi.cs.uni-magdeburg.de

 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 22

www-wi.cs.uni-magdeburg.de

Modelling Theory

07.12.2006

Leitung:

Claus Rautenstrauch 23

Model Systems

www-wi.cs.uni-magdeburg.de


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)

07.12.2006

Leitung:

Claus Rautenstrauch 24

Mapping Relation

www-wi.cs.uni-magdeburg.de

 Relation to map SO to SM
• Elimination of irrelevant issues • Typization of relevant issues • Formally: Homomorphism r: SO  SM Why not an isomorphism?

07.12.2006

Leitung:

Claus Rautenstrauch 25

Modelling Worldmap

www-wi.cs.uni-magdeburg.de

Execution relation subjective Interpretation

subjective modelling goals
Target relation

Discursive world

SO Object system

Mapping relation
Structural and behavioural compliance

SM Model system
Consistency/ completeness

Meta model
Leitung: Claus Rautenstrauch 26

07.12.2006

Modelling Goals

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 27

Information Models

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 28

Information Modelling

www-wi.cs.uni-magdeburg.de

Property

Expression Data Objects Functions Organization Processes

Description perspective
Description level Subject area Content individuality Level of abstraction
Leitung:

Business concept
As is model Company specific model Entitiy level

IT concept
To be model Reference model Type level Meta level

Implementation concept Ideal model Master model Meta-meta level
29

07.12.2006

Claus Rautenstrauch

Description View

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 30

Description View

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 31

Simplification of Description View

www-wi.cs.uni-magdeburg.de

Data
• What is to be changed

Functions
• How to change

Organization
• Who changes

Process
• In which sequence is to be changed

07.12.2006

Leitung:

Claus Rautenstrauch 32

Description Level

www-wi.cs.uni-magdeburg.de

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

Leitung:

Expression of IT implementation
Claus Rautenstrauch 33

07.12.2006

Reference Models – Theoretical View

www-wi.cs.uni-magdeburg.de

 

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

07.12.2006

Leitung:

Claus Rautenstrauch 34

Reference Models - Practise

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 35

Master Models

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 36

Objectives of Reference Modelling

www-wi.cs.uni-magdeburg.de

 

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

07.12.2006

Leitung:

Claus Rautenstrauch 37

Mastermodels

www-wi.cs.uni-magdeburg.de

Composition (is-part-of)

Master Application System Model

theoretical results Induction, in particular abstraction (is-a)

Reference Models

Company specific Models
Claus Rautenstrauch 38

07.12.2006

Leitung:

Level of Abstraction

www-wi.cs.uni-magdeburg.de

causes

Event type

0, n 0, n
Is generated

0, n 0, n

Function type

Meta level

Order arrived

Insert order

Order inserted
Type level

Order 4711 arrived Order 0815 arrived Order 0391 arrived

Insert order 4711 Insert order 0815 Insert order 0391

Order 4711 inserted Order 0815 inserted Order 0391 inserted

Entity level
07.12.2006 Leitung: Claus Rautenstrauch 39

Meta Meta Level

www-wi.cs.uni-magdeburg.de

Source

Node type

0, n 0, n
Sink

0, n 0, n

Edge type

07.12.2006

Leitung:

Claus Rautenstrauch 40

Typology of Models

www-wi.cs.uni-magdeburg.de

Property

Expression Data Objects Functions Organization Processes

Description perspective
Description level Subject area Content individuality Level of abstraction
Leitung:

Business concept
As is model Company specific model Entitiy level

IT concept
To be model Reference model Type level Meta level

Implementation concept Ideal model Master model Meta-meta level
41

07.12.2006

Claus Rautenstrauch

www-wi.cs.uni-magdeburg.de

Grundsätze ordnungsmäßiger Modellierung

Principles of Regular Modelling A Framework for Reduction of Subjectivity in Modelling

07.12.2006

Leitung:

Claus Rautenstrauch 42

Literature

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 43

Goals of Definition of PRM

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 44

Deductive Derivation of PRM

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 45

Overview

www-wi.cs.uni-magdeburg.de

     

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

Principle of Relevance Principle of Economy Principle of Clearness Principle of Comparability Principle of Systematic Design

07.12.2006

Leitung:

Claus Rautenstrauch 46

Interdependencies between Correctness, Relevance and Economy

www-wi.cs.uni-magdeburg.de

Correct Models

Steering Wheel Relevance Steering Wheel Economy

07.12.2006

Leitung:

Claus Rautenstrauch 47

Classification of PRM

www-wi.cs.uni-magdeburg.de

obligatory principles

Correctness

Relevance

Economy
Quality of Information Model

Clearness

Comparability

Systematic Design

Mandatory principles

07.12.2006

Leitung:

Claus Rautenstrauch 48

Principle of Correctness

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 49

Principle of Correctness II

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 50

Principle of Relevance

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 51

Principle of Relevance II

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 52

Principle of Economy

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 53

Approaches of „Economic“ Modelling

www-wi.cs.uni-magdeburg.de

 Usage of reference models  Reuse of model units  Deployment of computer-based modelling tools

07.12.2006

Leitung:

Claus Rautenstrauch 54

Principle of Clearness

www-wi.cs.uni-magdeburg.de

 Pragmatism
• Relationship between model and user • subjective versus intersubjective clearness

 Asthetic Criteria
• • • • Structure intuitive accessability Transparency Readability

07.12.2006

Leitung:

Claus Rautenstrauch 55

Clear Models

www-wi.cs.uni-magdeburg.de

 

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

07.12.2006

Leitung:

Claus Rautenstrauch 56

www-wi.cs.uni-magdeburg.de
07.12.2006

Leitung:

Claus Rautenstrauch 57

Principle of Comparability

www-wi.cs.uni-magdeburg.de

   

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

07.12.2006

Leitung:

Claus Rautenstrauch 58

Proceeding Model of Shared Model Development

www-wi.cs.uni-magdeburg.de

Conceptual Data model Projects

Detail concept

Draft concept

P1

P2

P3

07.12.2006

Leitung:

Data
Claus Rautenstrauch 59

Principle of Systematic Design

www-wi.cs.uni-magdeburg.de

 Requires multiple view meta model  Creation of integrable model views

07.12.2006

Leitung:

Claus Rautenstrauch 60

www-wi.cs.uni-magdeburg.de

Object Modelling UML – Unified Modelling Language

07.12.2006

Leitung:

Claus Rautenstrauch 61

Background

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 62

Background (contd.)

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 63

Structure of UML 2.0

www-wi.cs.uni-magdeburg.de
07.12.2006

Leitung:

Claus Rautenstrauch 64

Structure of UML 2.0

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 65

Structure Diagrams

www-wi.cs.uni-magdeburg.de

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
Claus Rautenstrauch 66

07.12.2006

Leitung:

Structure Diagrams (Contd.)

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 67

Behaviour Diagrams

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 68

Interaction Diagrams

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 69

Use Case Diagrams

www-wi.cs.uni-magdeburg.de

 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.
Leitung: Claus Rautenstrauch 70

07.12.2006

Use Case Diagrams (contd.)

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 71

Example

www-wi.cs.uni-magdeburg.de

Sales System
Offer Management

Sales Manager Clerk

Pricing

Invoicing

Foreign Invoice s

Accounting

07.12.2006

Leitung:

Claus Rautenstrauch 72

Classes

www-wi.cs.uni-magdeburg.de

      

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

07.12.2006

Leitung:

Claus Rautenstrauch 73

Special Classes

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 74

Illustration

www-wi.cs.uni-magdeburg.de

Class name Attribute names Attribute types Method names

CustomerOrder
Order#: int {order#>0} orderDate: date = sysdate …

Assertions
Defaults

CreateOrder (o#: int){o# > order#  order#  CustomerOrder} OrderReschedule (from: date, to: sysdate)

Parameters

07.12.2006

Leitung:

Claus Rautenstrauch 75

Class Diagrams

www-wi.cs.uni-magdeburg.de

 Inheritage

Order
Order# OrderDate … CreateOrder RescheduleOrder ...

CustomerOrder … …

PurchaseOrder … …

ProductionOrder …

07.12.2006

Leitung:

Claus Rautenstrauch 76

Association

www-wi.cs.uni-magdeburg.de

Company Name Address …

Employee

1

employs>

*

employer

<is working for

employee

Name Address Emp#

07.12.2006

Leitung:

Claus Rautenstrauch 77

Composition and Aggregation

www-wi.cs.uni-magdeburg.de

 Composition („consists of“)
Company Department

Name Anschrift

1 Consists of>

1..*

Name

 Aggregation (parts can exist without related object)
Product Assembly

P# PType

1 Consists of>

1..*

Name

07.12.2006

Leitung:

Claus Rautenstrauch 78

Example: Information Model for Technology Management
Verfahrenshinweis Pruefung Protokoll

Geschaeftspartner

www-wi.cs.uni-magdeburg.de

Hersteller

Lieferant

Server

Rechenzentrum Aufgabengruppe Plattform Vertrag

Listenformulare
Plattform_Verfahren

Betreuer

Aufgabe Schnittstelle Verfahren Externestellen kuerzel bezeichnung beschreibung einsatzdatum abloesedatum nutzung releasenummer releaseeinsatzdatum entwicklungsart art status bemerkung personendaten mah-relevant vertrieb bildscharbv fuegeein() loesche() aendere() Marktprodukte externe interne

Handbuch Geschaeftsprozess Manuellegeschaefte Elektronischertitel

OE

Handbuchart Teilprozess

Geschaeftspartnergruppen

Produktprozess

07.12.2006

Leitung:

Claus Rautenstrauch 79

Package Diagramm

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 80

Paketdiagramm

www-wi.cs.uni-magdeburg.de

Comment

Class

Package

Relationship Import Access Merge

07.12.2006

Leitung:

Claus Rautenstrauch 81

Elements of Package Diagram

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 82

Deployment Diagram

www-wi.cs.uni-magdeburg.de

 Configurationen of software and their components  Overview about software components
• Assignment to nodes (computer or runtime environment) • Interconnection through interfaces

07.12.2006

Leitung:

Claus Rautenstrauch 83

Deployment Diagram

www-wi.cs.uni-magdeburg.de

Interface

communication path

Node

Deployment
Leitung: Claus Rautenstrauch

Software component

07.12.2006

84

Elements of Deployment Diagram

www-wi.cs.uni-magdeburg.de

    

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

07.12.2006

Leitung:

Claus Rautenstrauch 85

www-wi.cs.uni-magdeburg.de

Prozessmodellierung

Modelling of System Behaviour

07.12.2006

Leitung:

Claus Rautenstrauch 86

Process Definitions from Literature

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 87

Formal Definition of Process from Informatics

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 88

Process and Function

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 89

General Model of Activities

www-wi.cs.uni-magdeburg.de

Environmental state

Event

Material

Activity: Transformation of information or material based on transformation rules

Event

Material

Human work
Leitung: Claus Rautenstrauch

Organizational unit

Resource
90

07.12.2006

Modelling of Functions

www-wi.cs.uni-magdeburg.de

 Function hierarchy
Customer Order Management

Chain of acitities or processes

Offer management

Offer follow-ups

Order registration

Functions
Technical specification Calculation

Partial functions

Calculation of quantities
Leitung: Claus Rautenstrauch

Calculation of values

Elementary functions
91

07.12.2006

Levels of Hierarchy

www-wi.cs.uni-magdeburg.de

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

07.12.2006

Leitung:

Claus Rautenstrauch 92

Final Definition of Term „Process“

www-wi.cs.uni-magdeburg.de

 A process is a – related to the content – closed, timed and logic sequence of functions, which are executed to manage business objects (here: information)

07.12.2006

Leitung:

Claus Rautenstrauch 93

Objects in Processes

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 94

Benefits of process-oriented Strategies

www-wi.cs.uni-magdeburg.de


  

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

07.12.2006

Leitung:

Claus Rautenstrauch 95

Types of Process Models

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 96

Types of Process Models (II)

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 97

Application Areas

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 98

www-wi.cs.uni-magdeburg.de

Processmodelling with UML

07.12.2006

Leitung:

Claus Rautenstrauch 99

Activity Diagram

www-wi.cs.uni-magdeburg.de

 Sequence of activities
• Function • Implementation - Method

 Illustration of parallel processes

07.12.2006

Leitung:

Claus Rautenstrauch 100

Example

www-wi.cs.uni-magdeburg.de

Object with state Pre and post conditions Proof completeness Contract [complete] Proof compliance Contract [compliant] Calculate contract

Activity Start

Control flow
Call for authorization

Contract [released]

Amount>500 Release contract

Amount<500

Contract [calculated]

Assignment of condition
Claus Rautenstrauch

Decision

End

07.12.2006

Leitung:

101

Example 2: Communication between Agents

www-wi.cs.uni-magdeburg.de

Loop

07.12.2006

Leitung:

Claus Rautenstrauch 102

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 103

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

Objectflow
• Synchronous processing of Objects • Object nodes - Buffer/storage function - Capacity limit - Edge weights - Ordering (LIFO, FIFO, …) • Flows - Asynchronous processing
Signal Leitung: Claus Rautenstrauch 104 Object

Objectnode

07.12.2006

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

 Connectors
• Pointers to interrelationships
A A

 Exceptions  Signals
• Send • Receive • Explicit modelling of events! • Timed event

07.12.2006

Leitung:

Claus Rautenstrauch 105

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 106

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

 Decision and union nodes  Forking and union
• Modelling of parallel processes • Union specification - {joinSpec = A or B}: alternative paths - {joinSpec = A and B}: Parallelity

07.12.2006

Leitung:

Claus Rautenstrauch 107

Elements of Activity Diagrams

www-wi.cs.uni-magdeburg.de

 Loops
• For – Do – While • If – Then – Else – Else If
for

input parameter Initialization

Test

while

Decision node

Pin for test variable

do
Loop body

output parameter Leitung: Claus Rautenstrauch 108

07.12.2006

State Machine Diagram

www-wi.cs.uni-magdeburg.de

State transitions of single objects during lifetime
• With state information, transitions, events and activities

07.12.2006

Leitung:

Claus Rautenstrauch 109

Example: States of Object „Flight“

www-wi.cs.uni-magdeburg.de

State

Self Transition

cancel() [ reservedSeats >1]

Internal Action

Without reservation entry / rollback()

Reserve ()

partially reserved

reseve() [ freeSeats >1]

Transition
cancel() [ ReservedSeats =1] CreateFlight() DropFlight () cancel() reserve() [ freeSeats =1]

starting state Final state
close () Booked out

Method Event Guard

closed
close ()

07.12.2006

Leitung:

Claus Rautenstrauch 110

Elements of State Machine Diagram

www-wi.cs.uni-magdeburg.de

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
• • • • • •
Leitung:

SignalEvent („Boss is coming“) Change Event („StockQuantity <0“) TimeEvent („between 8 and 12 o„clock“) AnyEvent („otherwise“) Guard Effect („StockQuantity<0/start production“)
Claus Rautenstrauch 111

07.12.2006

Elements of State Machine Diagram

www-wi.cs.uni-magdeburg.de

 Actions  Signals
• See also activity diagram

Action

 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

07.12.2006

Leitung:

Claus Rautenstrauch 112

Elements of State Machine Diagram

www-wi.cs.uni-magdeburg.de

 Starting and final state

 Crossing
• Sequence of transitions in ambiguous order

 Decision
• XOR situation

07.12.2006

Leitung:

Claus Rautenstrauch 113

Sequence Diagram

www-wi.cs.uni-magdeburg.de

 Timed sequence of messages between objects  Description of behavior and exchange of messages between objects for an use case

07.12.2006

Leitung:

Claus Rautenstrauch 114

Beispiel

www-wi.cs.uni-magdeburg.de

Liveline

reservation of articles
reserve (b)

Purchase order

Order position

article stock

giveOrderPos()

Message

OPos giveArticle () article

active time

Passive time

Timeline

giveQty () quantity reserve (article, qty)

Answer Activation bar Leitung: Claus Rautenstrauch 115

07.12.2006

Elements of Sequence Diagrams

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 116

Elements of Sequence Diagrams

www-wi.cs.uni-magdeburg.de

 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

07.12.2006

Leitung:

Claus Rautenstrauch 117

Communication Diagram

www-wi.cs.uni-magdeburg.de

 Timed order of data relationships between objects  Focus on exchange of data

07.12.2006

Leitung:

Claus Rautenstrauch 118

Beispiel

www-wi.cs.uni-magdeburg.de

message

1.1

giveOrderPos () >

order

liveline

1: reserve (b) >

article reservation

ArticleStorage 1.1.3 reserve (article, qty) >

Clerk -

liveline

1.1.1 article:=giveArticle() > 1.1.2 qty:= giveQty ()
message

OrderPos

sequence

direction

07.12.2006

Leitung:

Claus Rautenstrauch 119

Elemente

www-wi.cs.uni-magdeburg.de

 Liveline
• see sequence diagram

 Message
• (sequence, message, direction) triple

07.12.2006

Leitung:

Claus Rautenstrauch 120

Sign up to vote on this title
UsefulNot useful