Upload
ngolien
View
226
Download
0
Embed Size (px)
Citation preview
INF5120 Model based System Development 24.01.2011
1
Telecom and Informatics 1
INF5120
”Modellbasert Systemutvikling”
”Modelbased System development”
Lecture 2: 23.01.2012 Arne-Jørgen Berre
[email protected] and [email protected]
Telecom and Informatics 2
INF5120 - Lecture plan - 2012
Part I: SSI – Service Innovation and Agile Service/Software Engineering
Part II: SSMDE – Model Driven Engineering
Part III – Model Driven Interoperability and ADM
1: 16/1: Introduction to Model Based System Development (INF5120)
2: 23/1: SIE I: Enterprise Architecture, Role modeling-Collaboration and Value Networks – Verna Allee (VNA)
3: 30/1: SIE II:: Business Process Modeling with BPMN 2.0 and Business Model Innovation - Peter Lindgren (BMI)
4: 6/2: SIE III: AT ONE – Service Design, Agile User-oriented design – with Use cases/stories and UI models
5: 13/2: SIE IV: Service modeling with SoaML – Service modeling - Design, patterns
6: 20/2: SIE V: Information Modeling with UML and Design with DCI - Design, patterns
7: 27/2: MDE I: Software Process Model Frameworks – Essence/SEMAT, SPEM, EPF and ISO 24744 –Shihong Huang/Brian Elvesæter
8: 5/3: MDE II: Metamodels, Domain specific languages and UML profiles (Franck Fleurey)
9: 12/3: MDE III: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta)
10: 19/3: MDE IV: Model transformations - MOFScript, QVT DSLs with examples
11: 26/3: MDE V: Internet Service Architectures - with BPM/BPEL and SOA/Cloud transformations
2/4, 9/4: EASTER
12: 16/4: MDE VI: User Interface Modeling – IFML etc. - ESITO
13: 23/4: MDI I: Semantic technologies, Ontologies and Semantic annotations , Rules/SBVR
14: 30/4: MDI II: Model Driven Service Interoperability
15: 7/5: MDI III: ADM and Migration to Cloud computing
16: 13/5: Conclusion and Summary for INF5120 - Preparation of Exam
Exam: Monday June 4th, 2011, 1430-1830 (4 hours)
INF5120 Model based System Development 24.01.2011
2
Telecom and Informatics
Content
EA and the Zachman Framework
Architectural Frameworks - (IEEE/ 1471/ISO 42010, UML
2.x, TOGAF, UPDM (DODAF/MODAF)
OO Modeling and abstraction levels
Role modeling
UML Collaboration modeling
GRASP - General Responsibility Assignment Software
Patterns
VNA – Value Network Analysis, Verna Allee
3
Value Network Analysis
Verna Allee [email protected]
4
www.valuenetworksandcollaboration.com
INF5120 Model based System Development 24.01.2011
3
Telecom and Informatics 5
Based on work by
John A. Zachman
VA Enterprise
Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM MODEL
(LOGICAL)
Designer
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
DETAILED
REPRESENTATIONS
(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONING
ENTERPRISE
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM MODEL
(LOGICAL)
Designer
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
DETAILED
REPRESENTATIONS
(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONING
ENTERPRISE
Things Important
to the Business
Entity = Class of
Business Thing
Processes
Performed
Function = Class of
Business Process
Semantic Model
Ent = Business Entity
Rel = Business Relationship
Business Process
Model
Proc = Business Process
I/O = Business Resources
Business Logistics
System
Node = Business Location
Link = Business Linkage
Work Flow Model
People = Organization Unit
Work = Work Product
Master Schedule
Time = Business Event
Cycle = Business Cycle
Business Plan
End = Business Objectiv e
Means = Business Strategy
Important
Organizations
People = Major
Organizations
Business
locations
Node = Major
Business Locations
Ev ents Significant
to the Business
Time = Major
Business Event
Business Goals
and Strategy
Ends/Means =
Major Business Goals
Logical Data
Model
Ent = Data Entity
Rel = Data Relationship
Application
Architecture
Proc = Application Function
I/O = User Views
Distributed System
Architecture
Node = IS Function
Link = Line Characteristics
Human Interface
Architecture
People = Role
Work = Deliv erable
Processing
Structure
Time = System Event
Cycle = Processing Cycle
Business Rule
Model
End = Structural Assertion
Means = Action Assertion
Physical Data
Model
Ent = Segment/Table
Rel = Pointer/Key
System
Design
Proc = Computer Function
I/O = Data Elements/Sets
Technology
Architecture
Node = Hardware/Softw are
Link = Line Specifications
Presentation
Architecture
People = User
Work = Screen Format
Control
Structure
Time = Ex ecute
Cycle = Component Cycle
Rule
Design
End = Condition
Means = Action
Data
Definition
Ent = Field
Rel = Address
Program
Proc = Language Statement
I/O = Control Block
Netw ork
Architecture
Node = Addresses
Link = Protocols
Security
Architecture
People = Identity
Work = Job
Timing
Definition
Time = Interrupt
Cycle = Machine Cycle
Rule
Design
End = Sub-Condition
Means = Step
Data
Ent =
Rel =
Function
Proc =
I/O =
Netw ork
Node =
Link =
Organization
People =
Work =
Schedule
Time =
Cycle =
Strategy
End =
Means =
Based on work by
John A. Zachman
VA Enterprise
Architecture
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
DATAWhat
FUNCTIONHow
NETWORKWhere
PEOPLEWho
TIMEWhen
MOTIVATIONWhy
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM MODEL
(LOGICAL)
Designer
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
DETAILED
REPRESENTATIONS
(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONING
ENTERPRISE
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM MODEL
(LOGICAL)
Designer
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
DETAILED
REPRESENTATIONS
(OUT-OF-CONTEXT)
Sub-Contractor
FUNCTIONING
ENTERPRISE
Things Important
to the Business
Entity = Class of
Business Thing
Processes
Performed
Function = Class of
Business Process
Semantic Model
Ent = Business Entity
Rel = Business Relationship
Business Process
Model
Proc = Business Process
I/O = Business Resources
Business Logistics
System
Node = Business Location
Link = Business Linkage
Work Flow Model
People = Organization Unit
Work = Work Product
Master Schedule
Time = Business Event
Cycle = Business Cycle
Business Plan
End = Business Objectiv e
Means = Business Strategy
Important
Organizations
People = Major
Organizations
Business
locations
Node = Major
Business Locations
Ev ents Significant
to the Business
Time = Major
Business Event
Business Goals
and Strategy
Ends/Means =
Major Business Goals
Logical Data
Model
Ent = Data Entity
Rel = Data Relationship
Application
Architecture
Proc = Application Function
I/O = User Views
Distributed System
Architecture
Node = IS Function
Link = Line Characteristics
Human Interface
Architecture
People = Role
Work = Deliv erable
Processing
Structure
Time = System Event
Cycle = Processing Cycle
Business Rule
Model
End = Structural Assertion
Means = Action Assertion
Physical Data
Model
Ent = Segment/Table
Rel = Pointer/Key
System
Design
Proc = Computer Function
I/O = Data Elements/Sets
Technology
Architecture
Node = Hardware/Softw are
Link = Line Specifications
Presentation
Architecture
People = User
Work = Screen Format
Control
Structure
Time = Ex ecute
Cycle = Component Cycle
Rule
Design
End = Condition
Means = Action
Data
Definition
Ent = Field
Rel = Address
Program
Proc = Language Statement
I/O = Control Block
Netw ork
Architecture
Node = Addresses
Link = Protocols
Security
Architecture
People = Identity
Work = Job
Timing
Definition
Time = Interrupt
Cycle = Machine Cycle
Rule
Design
End = Sub-Condition
Means = Step
Data
Ent =
Rel =
Function
Proc =
I/O =
Netw ork
Node =
Link =
Organization
People =
Work =
Schedule
Time =
Cycle =
Strategy
End =
Means =
Zachman Framework – for Enterprise
Architecture (IBM, 1987)
Telecom and Informatics 6
Zachman Framework
Row 1 – Scope
External Requirements and Drivers
Business Function Modeling
Row 2 – Enterprise Model
Business Process Models
Row 3 – System Model
Logical Models
Requirements Definition
Row 4 – Technology Model
Physical Models
Solution Definition and Development
Row 5 – As Built
As Built
Deployment
Row 6 – Functioning Enterprise
Functioning Enterprise
Evaluation
1
2
3
4
5
6
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
INF5120 Model based System Development 24.01.2011
4
Telecom and Informatics 7
Many Architectural Frameworks ….
ARIS ZACHMAN GERAM
EN/ISO 19439
NIST
EKA - POPS EKA - POPS EKA - POPS
Athena OEA
Telecom and Informatics
TOGAF 9 (The Open Group)
8
INF5120 Model based System Development 24.01.2011
5
Telecom and Informatics
Open
Group
ADM
9
Telecom and Informatics 10
INF5120 Model based System Development 24.01.2011
6
Telecom and Informatics
Building block evolution
11
Telecom and Informatics
Service categories
12
INF5120 Model based System Development 24.01.2011
7
Telecom and Informatics
DODAF 2.0 - viewpoints
13
Telecom and Informatics
EAEA – European Air Traffic
Management Enterprise Architecture
14
INF5120 Model based System Development 24.01.2011
8
Telecom and Informatics
IEEE 1471, ISO 42010
15
Telecom and Informatics
Zachman with OMG standards
16
Data
(What)
Function
(How)
Network
(Where)
People
(Who)
Time
(When)
Motivation
(Why)
Scope
(Contexts)
Business
(Concepts)
System
(Logic)
Technology
(Physics)
Component
(Assemblies)
List of things important
to business
SBVR
List of processes that
the business performs
VDM
List of locations which
the business operates
VDM
List of organizations
important to the business
OSM
List of events/cycles
important to the business
DTFV
List of business
goals/strategies
BMM
Semantic Model
ODM,
IMM (CWM)
Business Process
Model
BPMN, CMPM
Business Logistics
System
BPMN, CMPM
Workflow Model
OSM, BPMN,
CMPM
Master Schedule
BPMN, CMPM,
DTFV
Business
Plan
SBVR
Logical Data Model
ODM,
IMM (CWM), UML
Application
Architecture
SoaML, UML
Distributed
System Architecture
SoaML, UML
Human Interface
Architecture
BPMN, CMPM
Process Structure
BPMN, CMPM,
DTFV
Business Rule
Model
SBVR
Physical Data Model
IMM (CWM), UMLSystem Design
SoaML, UML
Technology
Architecture
SoaML, UML
Presentation
Architecture
Control Structure
BPMN, CMPM,
DTFV
Rule
Design
SBVR
Data Definition
IMM (CWM), UMLProgram
UML
Network
Architecture
UML
Security
Architecture
Timing
Definition
DTFV
Rule
Definition
SBVR
Operation
(Instances)Data Function Network Organization Schedule Strategy
INF5120 Model based System Development 24.01.2011
9
Telecom and Informatics
Use of OMG metamodels
BPMN (BPMN 2.0)
BMM
UML 2.0
SoaML
OSM
VDM
Case Management
SBVR
ODM
17
Telecom and Informatics
OMG standards coverage
18
Data
(What)
Function
(How)
Network
(Where)
People
(Who)
Time
(When)
Motivation
(Why)
Scope
(Contexts)
Business
(Concepts)
System
(Logic)
Technology
(Physics)
Component
(Assemblies)
List of things
important
to business
List of processes
that the business
performs
List of locations
which the business
operates
List of organizations
important to the
business
List of events/cycles
important to the
business
List of business
goals/strategies
Semantic Model
Business
Process
Model
Business
Logistics
System
Workflow
Model
Master
Schedule
Business
Plan
Logical Data ModelApplication
Architecture
Distributed
System
Architecture
Human
Interface
Architecture
Process
Structure
Business Rule
Model
Physical Data Model System DesignTechnology
Architecture
Presentation
Architecture
Control
Structure
Rule
Design
Data Definition ProgramNetwork
Architecture
Security
Architecture
Timing
Definition
Rule
Definition
Operation
(Instances)Data Function Network Organization Schedule Strategy
BMM
SBVR
VDM OSMSBVR
DTFV
BPMN
UMLIMM
(CWM)
CMPM
SoaML
ODM
INF5120 Model based System Development 24.01.2011
10
Telecom and Informatics
Agile Service Development (1/3)
19
New book – in the publishing process until April 2012, Springer.
We will use a publication preprint initially
Telecom and Informatics
Context and Goals
Interactions
Interface
Channels
Roles
Actors
Resources
Functions
Tasks
Executors
Processes
Orchestra- tion
Workflows
Information
Data
Stores and
Messages
EFA
Extra
Functional
Aspects
QoS
SLA
Monitoring,
adaptation
Inte
ract
ion
Requirements
Funct
ion
Co
ord
inat
ion
Info
rmat
ion
Qual
ity
Design
Implementation
Infrastructure
Str
uct
ure
ASD
Framework
INF5120 Model based System Development 24.01.2011
11
Telecom and Informatics
Context and Goals
Interactions
Interface
Channels
Roles
Actors
Resources
Functions
Tasks
Executors
Processes
Orchestra- tion
Workflows
Information
Data
Stores and
Messages
EFA
Extra
Functional
Aspects
QoS
SLA
Monitoring,
adaptation
Inte
ract
ion
Requirements
Funct
ion
Co
ord
inat
ion
Info
rmat
ion
Qual
ity
Design
Implementation
Infrastructure
Str
uct
ure
BPMN Role
Models SoaML UML
Class
Ontologies
Goal oriented
Use cases/stories
UI OCL
collaboration
with
INF5120
Modeling
techniques
Model Driven Architecture/MDE
Telecom and Informatics
Object-orientation
Simula and Smalltalk
OORAM and UML Collaboration
OORAM role modeling, MVC, DCI
Prof. emeritus Trygve Reenskaug
See http://en.wikipedia.org/wiki/Trygve_Reenskaug
Simula-67
Kristen Nygaard
http://en.wikipedia.org/wiki/Kristen_Nygaard
Ole Johan Dahl
http://en.wikipedia.org/wiki/Ole-Johan_Dahl
22
INF5120 Model based System Development 24.01.2011
12
Telecom and Informatics 23
“Scandinavian” Modeling perspective
A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world.
A physical model consists of objects, each object is characterized by attributes and a sequence of actions.
Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions.
Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object.
The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then.
The state of the model is the states of the objects in the model.
(From Simula)
Telecom and Informatics 24
Basis for OO Technology
Quality and Productivity
Modeling Abstraction and Modularisation
Reuse and Maintenance
Object Model
Classification/ Instantiation
Encapsulation Sharing Inheritance
Polymorphism
INF5120 Model based System Development 24.01.2011
13
Telecom and Informatics 25
Object oriented model
An object oriented model is a (simulation)
model that consists of
cooperative objects in
interaction with each other.
Consider also a class model: A set of classes with descriptions of properties and behaviour and a structure of subclasses that inherits from superclasses
Telecom and Informatics 26
System and objects
A system is a part of the real world which we choose to regard
as a whole, separated from the rest of the world during some
period of consideration.
A whole that we choose to consider as a collection of objects,
each object being characterized by attributes and by actions
which may involve itself and other objects.
Mental modell
Manifest Model Real-World
phenomenon
INF5120 Model based System Development 24.01.2011
14
Telecom and Informatics 27
Object oriented modeling
aRealWorld-
Phenomena roleModels
anImplemented
System anObjectModel
Manifest Model
Real-World phenomenon
Mental model Environment Model environment
System model
Telecom and Informatics 28
OO Programming Terminology
Encapsulation
Object
Message
Method
Class
Instance
Inheritance
Polymorphism
Dynamic (Late) Binding
INF5120 Model based System Development 24.01.2011
15
Telecom and Informatics 29
CRC Method, class, responsibilities,
and collaborators
Method to learn
the most basic OO concepts plus OO “thinking”
“The most effective way of teaching the idiomatic way of thinking
with objects is to immerse the learner in the "object-ness" of the
material. To do this we must remove as much familiar material as
possible, expecting that details such as syntax and programming
environment operation will be picked up quickly enough once the
fundamentals have been thoroughly understood.”
Technique also very useful
during informal and creative analysis and design
Created by Kent Beck and Ward Cunningham,
Textronix, 1989
Telecom and Informatics 30
The CRC-Card
an object of paper personalizing the object
Class (Name):
Responsibility: Collaborators:
INF5120 Model based System Development 24.01.2011
16
Telecom and Informatics 31
Class, responsibilities, and
collaborators
Class The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment.
Responsibilities Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing.
Collaborators Objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk, View and Controller operate as near equals while OrderedCollection offers a service with little regard or even awareness of its client.
Telecom and Informatics 32
UML og ( R )UP
Unified
Modeling
Language
Process
Convergence Today
Unification leads to “standards”
Convergence in the future
Process frameworks through consensus
Two parts of a Harmonized Whole
INF5120 Model based System Development 24.01.2011
17
Telecom and Informatics 33
Phase Class
Traditional SA/SD/ERA
SA-based OO
ERA-based OO
Hybrid SA/ER- based OO
SA - Yordon SD - Page Jones
ERA - Chen ER-Rel.db - 3NF
OO RT SA - Wards
OOA/OOD - Coad/Yordon
OMT - Rumbaugh et. al
Fusion - HP
OOAD - Booch (93 w/C++)
HOOD - ESA
OOSD - Wasserman SD-basert OO
OO-based
RDOOD - Wirfs-Brock et. al
CRC-cards - Cunningham
OOram - Reenskaug et. al
ANALYSIS DESIGN DETAILED DESIGN
OOAD - Martin/Odell
OSDL-92 - CCITT/Bræk et. al
OOSE/ObjectOry - Jacobson
Ada(C++)-based
SDL-based OO
UML (96) Booch/OMT/ObjectOry
OOAD methods
Catalysis, Syntropy, SOMA, OBA, BHS, ...
Collaboration
Modeling !
Telecom and Informatics 34
Evolution of the UML
Booch ´91
Booch ´93
Unified Method 0.8
UML 1.0
OMT - 2
OMT - 1 OOSE
UML 0.9 & 0.91
OOPSLA ´95
June ´96 & Oct ´96
Submission of UML 1.1 to OMG
for adoption, Sept ´97
Other methods
public
feedback UML Partners’
Expertise
UML 1.1 (Sept. 1997)
Taskon,SINTEF
UML 1.4 UML 2.0
(2004)
INF5120 Model based System Development 24.01.2011
18
Telecom and Informatics 35
Evolution of methodologies
UML1.0
UML1.1
UML1.2
UML1.3
UML1.4
OMT
Objectory
Booch
UML Components
Catalysis
OOram
KobrA
COMET
COMET-S
UML4EDOC
UML2
Pulse
UP
RUP
Notation
Process
2001
1995-
1999
2000
Objecteering
SOA Agile
Methods
Method
frameworks
Telecom and Informatics 36
UML Structural Modeling
Class Diagram
Object Diagram
Component Diagram (new in UML 2.0)
Package Diagram
Deployment diagram
INF5120 Model based System Development 24.01.2011
19
Telecom and Informatics 37
UML Behavioral Modelling
Use Case Diagrams
Interactions
Sequence diagrams (enhanced in UML 2.0)
Timing diagrams (new in UML 2.0)
Interaction overview diagrams (new in UML 2.0)
Communication diagrams (i.e. collaboration diagram)
State machine diagrams (enhanced in UML 2.0)
Activity Diagrams (enhanced in UML 2.0)
Telecom and Informatics 38
Different kind of models
Conceptual models
Specification models
Implementation models
INF5120 Model based System Development 24.01.2011
20
Telecom and Informatics 39
Dealing with Complexity – and Change
Working at the right level of abstraction
OO dealing with complexity
objects -> components -> services *SOA
Design by contract, role composition
Aspect-oriented programming
Use of patterns
Visual Modeling (MDA)
Architecture
Telecom and Informatics
Role model
The role model is the basic abstraction in OOram. It is an object
oriented model of an object structure and represents a bounded
part of an interesting phenomen
Traveler Authorizer
Book-
keeper
Pay-
master
A role abstraction:
- A general role played
by
many objects
- Part of the
responsibility
for an object
INF5120 Model based System Development 24.01.2011
21
Telecom and Informatics
Authorizer Traveler Secretary Paymaster Bookkeeper TravelAgent
Synthesis of ExpenseReport and
AirlineBooking
Traveler
Traveler
Authorizer Paymaster Bookkeeper
Secretary Paymaster Bookkeeper TravelAgent
ExpenseReport
AirlineBooking
CompositModel
Telecom and Informatics
Use of synthesis
1. Sep. of concern and
composition on one
abstraction level
2. Sep. of concern and
composition between
abstraction levels
3. Specialization -
generalization
INF5120 Model based System Development 24.01.2011
22
Telecom and Informatics
Collaboration
Telecom and Informatics
Collaboration
INF5120 Model based System Development 24.01.2011
23
Telecom and Informatics
CollaborationUse
Telecom and Informatics
CollaborationUse
INF5120 Model based System Development 24.01.2011
24
Telecom and Informatics
CollaborationUse
Telecom and Informatics
OORAM role modeling
See professor Trygve Reenskaug website
http://folk.uio.no/trygver/
See BabyUML
&
Role Modeling
With book reference
Working with objects.
The OOram Software Engineering Method.
Manning/Prentice Hall 1996. ISBN 0-13-452930-8.
INF5120 Model based System Development 24.01.2011
25
Telecom and Informatics
OORAM role model
Telecom and Informatics
Role model
Synthesis
INF5120 Model based System Development 24.01.2011
26
Telecom and Informatics
General Responsibility Assignment
Software Patterns.
Responsibility assignment.
1. knowing (answering)
2. or, doing
Guidance and evaluation in
mechanistic design.
1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don’t Talk to Strangers
Telecom and Informatics
Controller
What class should receive a system event message?
Assign the responsibility for handling a system event message
to one of these choices:
1 The business or “organization” (a façade controller).
2 or, The overall “system” or aggregate concept (a façade
controller).
3 or, An artificial class representing the use case (a use case
controller).
INF5120 Model based System Development 24.01.2011
27
Telecom and Informatics
Expert
Most general purpose responsibility assignment principle?
Assign a responsibility to the information expert—the class
that has the information necessary to fulfill the responsibility.
“That which knows, does”
Who has the most data/information for solving the
problem?
Telecom and Informatics
Expert
To “have the information” means, for example, the object
may:
know it as an attribute or object reference
be able to derive it
What is the motivation for Expert?
Looking for task-owners that support encapsulation and
low coupling.
This reduces change impacts.
INF5120 Model based System Development 24.01.2011
28
Telecom and Informatics
High Cohesion
How to design classes to increase the likelihood of reuse and
not be overwhelmingly complex?
Assign responsibilities so that cohesion remains high.
Telecom and Informatics
Low Coupling
How to create reusable components that are resilient to
change?
Assign responsibilities so that coupling remains low.
INF5120 Model based System Development 24.01.2011
29
Telecom and Informatics
Polymorphism
How to handle alternatives based on type?
When related alternatives or behaviors vary by type
(class),
assign responsibility for the behavior—using polymorphic
operations—to the types for which the behavior vary.
Telecom and Informatics
Applying Polymorphism
GoSquare
landOnBy( p: Player )
LuxuryTaxSquare
landOnBy( p: Player )
IncomeTaxSquare
landOnBy( p: Player )
Square {abstract}
name : String
...
landOnBy( p: Player )
...
PlainSquare
landOnBy( p: Player )
INF5120 Model based System Development 24.01.2011
30
Telecom and Informatics
Other GRASP Patterns
Creator—who creates?
Usually the aggregate or
containing object.
Pure Fabrication—
“design” objects. Make it up
when desperate.
Indirection— “most
problems in computer
science …”
Don’t Talk to Strangers—
Law of Demeter
1. Expert 2. Creator 3. Controller 4. Low Coupling 5. High Cohesion 6. Polymorphism 7. Pure Fabrication 8. Indirection 9. Don’t Talk to Strangers for more information...
Telecom and Informatics
Quick overview of Design Principles
The Open-Closed Principle
by Bertrand Meyer
The Dependency Inversion Principle
by Robert C. Martin
The Liskov Substitution Principle
by Barbara Liskov
The Interface Segregation Principle
by Robert C. Martin
INF5120 Model based System Development 24.01.2011
31
Telecom and Informatics
The Open-Closed Principle
Software should be “open” for extension but “closed” to
modification
The goal is to design software that be easily extended
without changing any of the existing code
Inheritance and the development of abstract base classes
play a big role in trying to fulfill this goal
Telecom and Informatics
The Dependency Inversion Principle
High-level modules should not
depend on low-level modules.
Both should depend on
abstractions
Abstractions should not depend on
details. Details should depend on
abstractions
ButtonClient
Lamp
Button
PushButton
Button and ButtonClient can
now vary independently!
INF5120 Model based System Development 24.01.2011
32
Telecom and Informatics
The Liskov Substitution Principle
Functions that use base class interfaces must not depend on or be
confused by any derivatives of those interfaces
A logical extension of the Open-Closed Principle
All subclasses should implement the interface of the base class in a
manner consistent with the intent of the base class
Telecom and Informatics
The Interface Segregation Principle
Clients should not be forced to depend on interfaces that
they do not use
The principle here is to avoid cluttering up an interface
with things (functions, inheritance relationships) that the
clients don’t need to use
Take a clients’ perspective!!
INF5120 Model based System Development 24.01.2011
33
Telecom and Informatics
Patterns – Abstract Factory
Telecom and Informatics 66
Next Lecture – BPMN and Business
Model Innovation. January 30th, 2012
BPMN
Business Model Innovation, Peter Lindgren
http://www.bpmn.org/