”Modellbasert Systemutvikling” ”Modelbased System development” · Owner SYSTEM MODEL...

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]


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)

mailto:[email protected]

mailto:[email protected]


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


3


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)


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


4


Many Architectural Frameworks ….

ARIS ZACHMAN GERAM

EN/ISO 19439

NIST

EKA - POPS EKA - POPS EKA - POPS

Athena OEA


TOGAF 9 (The Open Group)

8


5


Open

Group

ADM

9



6


Building block evolution

11


Service categories

12


7


DODAF 2.0 - viewpoints

13


EAEA – European Air Traffic

Management Enterprise Architecture

14


8


IEEE 1471, ISO 42010

15


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


9


Use of OMG metamodels

BPMN (BPMN 2.0)

BMM

UML 2.0

SoaML

OSM

VDM

Case Management

SBVR

ODM

17


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


10


Agile Service Development (1/3)

19

New book – in the publishing process until April 2012, Springer.

We will use a publication preprint initially


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


11


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


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

http://en.wikipedia.org/wiki/Trygve_Reenskaug

http://en.wikipedia.org/wiki/Kristen_Nygaard





12


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


Basis for OO Technology

Quality and Productivity

Modeling Abstraction and Modularisation

Reuse and Maintenance

Object Model

Classification/ Instantiation

Encapsulation Sharing Inheritance

Polymorphism


13


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


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


14


Object oriented modeling

aRealWorld-

Phenomena roleModels

anImplemented

System anObjectModel

Manifest Model

Real-World phenomenon

Mental model Environment Model environment

System model


OO Programming Terminology

Encapsulation

Object

Message

Method

Class

Instance

Inheritance

Polymorphism

Dynamic (Late) Binding


15


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


The CRC-Card

an object of paper personalizing the object

Class (Name):

Responsibility: Collaborators:


16


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.


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


17


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 !


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)


18


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


UML Structural Modeling

Class Diagram

Object Diagram

Component Diagram (new in UML 2.0)

Package Diagram

Deployment diagram


19


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)


Different kind of models

Conceptual models

Specification models

Implementation models


20


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


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


21


Authorizer Traveler Secretary Paymaster Bookkeeper TravelAgent

Synthesis of ExpenseReport and

AirlineBooking

Traveler

Traveler

Authorizer Paymaster Bookkeeper

Secretary Paymaster Bookkeeper TravelAgent

ExpenseReport

AirlineBooking

CompositModel


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


22


Collaboration


Collaboration


23


CollaborationUse


CollaborationUse


24


CollaborationUse


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.

http://folk.uio.no/trygver/


25


OORAM role model


Role model

Synthesis


26


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


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


27


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?


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.


28


High Cohesion

How to design classes to increase the likelihood of reuse and

not be overwhelmingly complex?

Assign responsibilities so that cohesion remains high.


Low Coupling

How to create reusable components that are resilient to

change?

Assign responsibilities so that coupling remains low.


29


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.


Applying Polymorphism

GoSquare

landOnBy( p: Player )

LuxuryTaxSquare


IncomeTaxSquare


Square {abstract}

name : String

...


...

PlainSquare



30


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


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


31


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


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!


32


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


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


33


Patterns – Abstract Factory


Next Lecture – BPMN and Business

Model Innovation. January 30th, 2012

BPMN

Business Model Innovation, Peter Lindgren

http://www.bpmn.org/

http://www.bpmn.org/

”Modellbasert Systemutvikling” ”Modelbased System development” · Owner SYSTEM MODEL...

Documents

Transcript of ”Modellbasert Systemutvikling” ”Modelbased System development” · Owner SYSTEM MODEL...