Professional Documents
Culture Documents
de
Modelling Methods
MMP2
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
• 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
What is a language?
• Mathematics
• Programming Languages
• Semi formal graphical languages (also called modeling methods)
• Elements
c1 c2
Relationship type Identifier
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?
Attributes
• Key attributes
- Identify uniquely one entity
- Surrogat:: One (artificial) attribute which is key
Cardinalities
Generalization/Specialization
• Is-a operator
- Disjoint (XOR)
- Non disjoint (OR)
ODate Name
(0,*) (0,*)
Time Auftrag
Order BusinessPartner
(1,*)
(1,*)
OrderPosition Part
ONo PNo
OposNo Name
PNo
Simple
BusinessPartner
is a
Sophisticated
Geschäftspartner
System Theory
System
Properties
• open
• Socio-technical
• Target oriented
• Is-part-of
• Is-a
• Interacts-with
• Dynamic System
System Behaviour
Surrounding System
Influences Results
System
Modelling Theory
Components of a Model
Relation to map SO to SM
Execution relation
subjective modelling goals
www-wi.cs.uni-magdeburg.de
subjective
Interpretation Target relation
SO SM
Discursive Mapping relation
Object Model
world system Structural
and behavioural system
compliance
Consistency/
completeness
Meta model
Design
Property Expression
Description Data Functions
Organization Processes
perspective Objects
Description Implementation
Business concept IT concept
level concept
Data
Funktions
Objects
Processes
Data
• What is to be changed
Functions
• How to change
Organization
• Who changes
Process
• In which sequence is to be changed
Business Concept
IT Concept
Implementation concept
• Expression of IT implementation
Reference = Recommendation
Master
Application
Composition System Model
(is-part-of)
Reference
theoretical
Models
results
Induction,
in particular
abstraction
(is-a) Company
specific
Models
causes
0, n 0, n
Event type Function type
0, n Is ge- 0, n
nerated
Meta level
Type level
Entity level
07.12.2006 Leitung: Claus Rautenstrauch
39
Meta Meta Level
www-wi.cs.uni-magdeburg.de
Source
0, n 0, n
Node type Edge type
0, n 0, n
Sink
Property Expression
Description Data Functions
Organization Processes
perspective Objects
Description Implementation
Business concept IT concept
level concept
Sources of Derivation
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
Correct Models
Steering Wheel
Relevance
Steering Wheel
Economy
obligatory principles
Quality of Infor-
mation Model
Systematic
Clearness Comparability
Design
Mandatory principles
Syntactical Correctness
Relevance relates to
Pragmatism
• Relationship between model and user
• subjective versus intersubjective clearness
Asthetic Criteria
• Structure
• intuitive accessability
• Transparency
• Readability
Are simple
concept
Draft
Data model
Conceptual
concept
Detail
Projects
P1 P2 P3
Data
Object Modelling
UML – Unified Modelling Language
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
History
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
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
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
Activity diagram
• Sequence of activities
• Depiction of parallel processes
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
Timing diagram
• Time restrictions between state transitions of objects
• For time critical software systems, where time restrictions between state transitions of objects
are relevant
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.
Sales
System
Offer
Sales Manage-
Manager ment
Pricing
Clerk
Invoicing
Foreign
Invoice
s
Accounting
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
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
Inheritage
Order
Order#
OrderDate
…
CreateOrder
RescheduleOrder
...
… … …
Company Employee
Company Department
Name 1 1..*
Name
Anschrift
Consists of>
Product Assembly
P# 1 1..*
Name
PType
Consists of>
Geschaeftspartner
www-wi.cs.uni-magdeburg.de
Hersteller
Lieferant
Server
Rechenzentrum
Aufgabengruppe
Plattform
Vertrag
Listenformulare
Plattform_Verfahren Betreuer
Aufgabe
Schnittstelle
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()
Comment
Class
Package Relationship
Import
Access
Merge
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
Interface
communi-
cation
path
Node
Software
Deployment component
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
Prozessmodellierung
“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)
Function
Environ-
www-wi.cs.uni-magdeburg.de
mental
state
Event
Activity: Event
Transformation of information
or material based
Material on transformation rules
Material
Organizational
Human work
unit Resource
Function hierarchy
Customer Order Management Chain of acitities
or processes
Functions
Technical
Calculation Partial functions
specification
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
Simplificaton of Benchmarking
Activity models
Conversation-oriented Models
• Description of communication between participating agents
• Communication through objects
Sequence of activities
• Function
• Implementation
- Method
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
Loop
Activities
• Functions
• In general: execution of tasks
• Elementary functions: Actions
• Encapsulations are allowed
• Pre and post conditions
Control flow
Objectflow
• Synchronous processing
of Objects
Object
• Object nodes
- Buffer/storage function Object-
node
- Capacity limit
- Edge weights
- Ordering (LIFO, FIFO, …)
• Flows
- Asynchronous processing
Signal
Connectors
A A
• Pointers to interrelationships
Exceptions
Signals
• Send
• Receive
• Explicit modelling of events!
• Timed event
Loops input
parameter
output
parameter
State
www-wi.cs.uni-magdeburg.de
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 ()
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“)
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
Crossing
• Sequence of transitions in ambiguous order
Decision
• XOR situation
Liveline
reservation
- Purchase article
Order position
of articles order stock
reserve (b)
giveOrderPos()
Message active time
OPos
giveArticle()
article
Passive time
giveQty ()
Timeline
quantity
Answer
Activation bar
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
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
message
1.1 giveOrderPos () >
order
liveline
liveline OrderPos
1.1.1 article:=giveArticle() >
1.1.2 qty:= giveQty ()
Liveline
• see sequence diagram
Message
• (sequence, message, direction) triple