fpss ws1415 part2b v07 20141226 - tu dresdenst.inf.tu-dresden.de/files/teaching/ws14/fps15/... ·...

Future-Proof Software-Systems

1Dr. Frank J. Furrer - WS 2014/15

Future-Proof Software-Systems(Zukunftsfähige Software-Systeme)

Frank J. FurrerDr. sc. techn. ETH-Zürich

TU Dresden WS 2014/2015

Part 2BPart 2B

V0.7 / 26.12.2014

Future-Proof Software-Systems: Content


Future-Proof Software-Systems:

Content

Future-Proof Software-Systems: Lecture Structure


Content

Part 1: Introduction & Motivation

Part 2: Architecture Principles

Part 3: Some Specific Architecture Topics

Part 4: The Role, Personality and Context of the „Future-Proof Software-System Architect“

Architecture Principles and their Use

A1: Architecture Layer Isolation

A2: Partitioning, Encapsulation and Coupling

A3: Redundancy

A4: Interoperability

A5: Common Functions

A6: Reference Architectures, Frameworks and Patterns

A7: Reuse and Parametrization

A8: Industry Standards

A9: Information Architecture

A10: Formal Modeling

A11: Systems-of-Systems (SoS)

A12: Complexity and Simplification




Architecture Principle A7:

Reuse and Parametrization

A7

Future-Proof Software-Systems: Reuse


Definition:Reuse occurs when someoneavoids having to write software byobtaining and using software fromsomeplace else[Jeffrey S. Poulin, 1997, ISBN 0-201-64313-9]

Reuse is:

• very powerful (strong contribution to agility)

• (very) difficult

• if not done correctly: dangerous for the architecture

Software Reuse http

://arto

fsoftw

are

reu

se.c

om

/ta

g/sch

em

as/



Successful Reuse requires:

• a company-wide reuse strategy

• a strong reuse organization

• a dedicated, committed management

• Adequate development & evolution processes



Types of Reuse

Black BoxReuseUnmodified (1:1) reuse

Grey BoxReuse Limited modified reuse(Specific changes 25 %)

White BoxReuseSignificantly modified(Specific changes 25 %)



Levels of Reuse

Functionality:Code

Data:DB-Schema

Level 1:

Encapsulated Functionality & Data:Components

Level 2: Interfaces

Contracts

Applications:Business Functions

Level 3: Services

Business Process

Workflow

Level 4:

BusinessRules



Value of Reuse

Functionality:Code

Data:DB-Schema

Level 1:

Encapsulated Functionality & Data:Components

Level 2: Interfaces

Contracts


Level 3: Services

Business Process

Workflow

Level 4:

BusinessRules

very high

medium

medium

local reuse

„global“reuse



Functionality:Code

Data:DB-Schema

Encapsulated Functionality & Data:ComponentsInterfaces

Contracts


Services

Business Process

Workflow

BusinessRules

Codefragments

Fragments ofcode arereused inprograms

Componentsare composedto applications

Services arecalled to buildapplications orsystems

Business rulesare reused toimplementbusinessprocess steps



Business Case of Reuse€

t

ProjectDevelopmentCost

DevelopmentTime

€

t

Project

one-timeuse

Reuse(n-time use)

Value

Value

DevelopmentCost

DevelopmentTime

Reusable Software



€

t

Project

reuse

Value

DevelopmentCost

DevelopmentTime

Reusable Software

Who is paying?

htt

p:/

/blo

gs.law

yers

.com



Same projectcreating one-time software

The project has additional costand longer time-to-market

Reuse penalty

Pn+21

Pn+5

Pn+1

Pn

All projects reusing the software havelower cost and shorter time-to-market

Reuse benefit

Projectcreating reusable

software

Pla

nn

ed

Tra

deoff


14Dr. Frank J. Furrer - WS 2014/15Copyright Frank J. Furrer 2013 14

One-Time SoftwareDevelopment Process

SpecPhase

BusinessRequirements

ArchitectureRequirements

One-TimeSoftware

Development Process for Reuse

Reusable SoftwareDevelopment Process

SpecPhase

BusinessRequirements

ArchitectureRequirements

ReusableSoftware

SpecPhase

BusinessSzenarios

Reuse ArchRequirements

htt

p:/

/w

ww

.ham

mert

ap.c

om



Elements ofsuccessful Reuse

htt

p:/

/w

ww

.am

isin

su

ran

ce.c

om

A dedicated andcommitted management

ReuseStrategy

A company-widereuse strategy

htt

p:/

/w

ww

.glo

baln

psolu

tion

s.c

om

A strongreuse organizationGood software

architects

http://artofsoftwarereuse.com/tag/schemas/




Why should we work with Reuse?

Because of:

• The benefits (in development cost and time-to-market) areconsiderable

• The quality of the software is higher (mature components,managed evolution and maintenance)

• Use of proven 3rd party components and services

• Optimization: reusable components one-time components




Which are the of Reuse?

Risks:

• Quality of reusable software not sufficient

• Reuse-factor too low

• Reuse-strategy not complete or adequate

• Creation of unmanged redundancy (both functional and data)

• Development and maintenance process more complicated

• Management not sufficiently supportive of reuse-strategy



Black BoxReuse

Unmodified (1:1) reuse

Grey BoxReuseLimited modified reuse(Specific changes 25 %)

White BoxReuseSignificantly modified(Specific changes 25 %)

Parametrization

Business Rules

True, value-generating Reuse

Not reuse unmanaged redundancy

Not reuse unmanaged redundancy



Grey Box

Grey Box Modification Divergence (Unmanaged Redundancy)

Grey Box

Modification A

GreyBox

Modifi-

catio

nB

Grey Box

Modifi-cation C

GreyBox

Modifi-cation

D

Change



Grey Box Modification Divergence (Unmanaged Redundancy)

Grey Box

Grey Box

Modification A

GreyBox

Modifi-

catio

nB

Grey Box

Modifi-cation C

GreyBox

Modifi-cation D

Change

http://www.veggiegardeningtips.com



time

Black Box

Change

V5

Black Box

Change

V6

Black Box

Change

V7

… …

unmodified reuse

3 versions in production



Parametrization and Business Rules

Black BoxReuse

Unmodified (1:1) reuse

Parametrization

Parametrization: Selection of a predefined behaviour of the blackbox by parameters stored outside of the black box (Not part of theblack box functionality or data). The parameters are loaded at run-time. New versions of the black box interpret the parameterscorrectly.

Business Rules

Business Rules: Business rules are specified in BR-languages anddefine processing logic – instead of having the processing logicimplemented in code within the black box (Not part of the black boxfunctionality or data). The business rules are loaded at run-time. Newversions of the black box interpret the business rules correctly



Black Box Usage (Managed Redundancy)

Black Box

Black Box

Black Box

Black Box

Black Box

Parametrization

Business Rules

Parametrization

Business Rules

Parametrization

Business Rules

Change

Distributed/Updatedby ConfigurationManagement System

Loaded/Initializedat Run-Time



Parametrization Example: Different Account Number Formats

Payment OrderAccount Number Format: Bank Leu

Payment OrderAccount Number Format: CREDIT SUISSE

Payment OrderAccount Number Format: IBAN

Payment OrderAccount Number Format: Future Format

PaymentApplication

Accounts DB

ClearingSystem



Business Rules Example

Business Process

Application Software

BusinessLogic

SpecificBusiness

RulesInterpreter

Verbal Expression:

“A car with accumulatedmileage greater than 5’000since its last service mustbe scheduled for service”

Formal Expression:

If Car.miles-current-period > 5000 then

invoke Schedule-service (Car.id)

End if



Measuring the Reuse-Factor:

Functionality:Code

Data:DB-Schema

Encapsulated Functionality & Data:ComponentsInterfaces

Contracts


Services

Business Process

Workflow

BusinessRules

Codefragments

# ofapplications

using theservice

# of calls/hour

# ofapplications

using thecomponent

# of componentsimplementingthe code/DB

fragment

% of reusedbusiness rulesin a different

context




Reuse and Parametrization

1. Use only the black-box concept to build reusable software

2. Whenever possible, configure the reusable modules viaparameters or business rules (loaded or initiated at run-time)

3. Install and consequently use a configuration managementsystem to control the distribution of reusable software modules

4. Provide the 4 elements of successful reuse: Committedmanagement, reuse-strategy, reuse-organization and competent

software architects

5. Adapt your software development process to produce reusablesoftware

A7

Justification: If done correctly, reuseable components have asignificant positive effect on the agility of the IT-system.



If done correctly, reuse has a significant (positive) effecton the agility and quality of the IT-system

Use only the black-box concept (= unmodified reuse) tobuild reusable software

Parametrization and business-rules are powerfulinstruments to adapt reusable software to differentcontexts

Successful reuse is only possible if 5 prerequisites aremet: Committed management, an adequate reuse-strategy, an effective reuse-organization, competentsoftware architects and an adequate development &evolution process

Summary



ReferencesMurer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:

Managed Evolution – A Strategy for Very Large Information Systems

Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5Lim98 Wayne C. Lim:

Managing Software Re-Use

Prentice Hall, USA, 1998. ISBN-13: 978-0-13552-3735-9Coulange98 Bernard Coulange:

Software Reuse

Springer-Verlag, Heidelberg, Berlin, 1998. ISBN 978-3-540-76084-9Leach13 Ronald J. Leach:

Software Reuse – Methods, Models, Costs

Ronald J. Leach Publishing, 2nd edition, 2013. ISBN 978-1-9391-42-35-1Hamlet10 Dick Hamlet:

Composing Software Components – A Software-Testing Perspective

Springer-Verlag, New York, N.Y., USA, 2010. ISBN 978-1-44197147-0Poulin97 Jeffrey S. Poulin:

Measuring Software Reuse – Principles, Practices, and Economic Models

Addison Wesley Longman Inc., Reading MA, USA, 1997. ISBN 0-201-63413-9Grunske10 Lars Grunske, Ralf Reussner, Frantisek Plasil (Editors):

Component-Based Software Engineering

13th International Symposium CBSE 2010 (June 2010). Springer-Verlag, Berlin & Heidelberg, 2010(LNCS 6092). ISBN 978-3-642-13237-7

Arbab12 Farhad Arbab, Peter Csaba Ölveczky (Editors):

Formal Aspects of Component Software

8th International Symposium FACS 2011 (September 2011). Springer-Verlag, Berlin & Heidelberg, 2012(LNCS 7253). ISBN 978-3-642-35742-8





Industry Standards

A8

Future-Proof Software-Systems: Industry Standards


A STANDARD is:

• a formal, established norm for (technical) systems

• a document which establishes uniform (engineering ortechnical) criteria,

principles, methods, processes and practices

www.ietf.org www.omg.orgwww.iso.org

International Standards Organizations

CSBusinessObjectModelV1.1/2009

CompanyStandards



Example:Napoleonic Guns(1/3)

htt

p:/

/civ

ilw

art

alk

.com

/th

reads/la

rgest-

reen

acto

r-can

on

.79423

In early pre-Napoleonic times the artillery cannons wereindividually different and required matched cannon balls difficult logistics

Manufacturing tolerances greatly reduced the accuracy andfiring power of the artillery cannons reduced military impact



Example: Napoleonic Guns

1776: The de Gribeauvalstandard revolutionizedartillery.

1715-1789

de Gribeauval Standard:

• reduced and standardized the calibers

complexity reduction

• introduced normalized parts for the cannons

component technology

• set manufacturing processes & tolerances

reuse



Example: Napoleonic Guns(3/3)

htt

p:/

/w

ww

.san

dro

caste

lli.com

/w

ork

s_p

agin

as/n

apole

on

sem

pir

e.h

tm

NapoleonicEmpire

(ca. 1810)



What is the impact of standards ?

Why are standards important ?

Impact:

• Forcing uniform, interoperable solutions in the industry

• Providing proven, widely accepted and mature solutions

• Enabling exchangeable products (mostly)

• Facilitates reuse

• Foundation for validation & certification

Importance:

• Provides long term stability with managed change

• Forces vendors to comply to interoperable solutions

• Advances industries as a whole

• Provides confidence in technical solutions (e.g. safety or security)

Negative: Standards-setting process is quite slow (Wide consensus required)



Example:WebStandards(1/3)

WebStandards

Domain-specificStandards

TechnicalInfrastructureStandards

Technical Infrastructure

Addressing: URI Unicode

Secu

rity

:C

rypto

gra

ph

y

Trust: PKI

Reasoning & Proofs

BusinessRules:

RIF

Underlying Logic: DL

Semantics(Ontology):

OWLDB Query:SPARQL

Vocabulary: RDF-S

Data Model: RDF

Syntax: XML

Business Applications

SOA-Infrastructure: Web-Services

How can weestablish trust onthe WWW?



Example:WebStandards(2/3)

htt

ps:/

/en

cyclo

pedia

dra

mati

ca.s

e/O

n_t

he_I

nte

rnet,

_nobody_kn

ow

s_you

're_a_dog

On the Internet, nobody knows you're a dog

Example: Authentication:

How can we establish trust in theidentity of an electronic partner ?

Trust: PKI

Answer:

We use aPublic Key Infrastructure (PKI)

Answer:

Use a Public Key Infrastructure(PKI)

PKI assigns Digital Certificatesto entities (Persons, organizations)

Answer:



A digital certificate is anunforgeable electronic proof ofidentity

Answer:



A digital certificate is anunforgeable electronic proof ofidentity

Digital certificates arestandardized in X.509 and areglobally accepted and used



Example: Web Standards(3/3)

ClientServer

CACertification Agency

[Trusted Entity]

X.509Certificate

_issuer_validity_subject_publicKey

_CA-Signature

X.509

presents

X.509




Industry Standards

1. Strictly adhere to proven, accepted industry-standards in all 5architecture layers and for all phases of the system lifecycle

2. Never allow any use of vendor-specific standards «extensions»(even if they look tempting and useful)

3. Keep the number of standards in use to a minimum

4. Introduce new standards only based on very good reasons

5. If for a certain field of your activity there is no industry standard,formulate and instantiate a company standard

6. Enforce strict adherence to (pure) standards via regular reviews

A8

Justification: A heterogenous industry (such as software-production)requires clearly stated foundations for technologies, products andprocesses – otherwise no interoperability, certification, reuse and vendor-independence is possible



Standards are highly important instruments for a numberof IT functions, such as interoperability, security, safety,certification, …

A sufficient (but not overlapping) set of standards shouldbe used, managed and enforced in an organization

No vendor-specific standards extensions (even if they looktempting and useful) should be used

The set of standards established in an organizationrepresents a considerable business value

Summary

As an architect, look at the standards as a help, not a nuisance



References:

ReferencesAkerkar09 Rajendra Akerkar:

Foundations of the Semantic Web – XML, RDF & Ontology

ALPHA Science Intl. Inc., Oxford, UK, 2009. ISBN 978-1-84265-535-1Jakobs00 Kai Jakobs:

Information Technology Standards and Standardization – A Global Perspective

Idea Group Publishing, Hershey, PA, USA, 2000. ISBN 1-878289-70-5Nash01 Andrew Nash, William Duane, Celia Joseph, Derek Brink:

PKI – Implementing and Managing E-Security

Osborne/McGraw Hill, CA, USA, 2001. ISBN 0-07-213123-3Katz08 Jonathan Katz, Yehuda Lindell:

Introduction to Modern Cryptography

Chapman & Hall/CRC, FL, USA, 2008. ISBN 978-1-58488-551-1Hafner09 Michael Hafner, Ruth Breu:

Security Engineering for Service-Oriented Architectures

Springer Verlag, Heidelberg, Germany, 2009. ISBN 978-3-540-79538-4Al-Hakeem12 Mazin S. Al-Hakeem:

Fundamentals of Web Engineering – An Engineering Approach to Develop Web Services, Contents &Environment under Standards Specification of Web Design

LAP LAMBERT Academic Publishing, 2012. ISBN 978-3-65912-492-1Sahai05 Akhil Sahai, Sven Graupner:

Web Services in the Enterprise – Concepts, Standards, Solutions, and Management

Springer-Verlag, Heidelberg, Berlin, 2005. ISBN 978-0-387-23374-1Dawson07 Anthony L. Dawson, Paul L. Dawson, Stephen Summerfield:

Napoleonic Artillery

Crowood Press Ltd., Wiltshire, UK, 2007. ISBN 978-1-86126-923-2





Information Architecture

A9

Future-Proof Software-Systems: Information Architecture


Data/Information Architecture:

Definition:

The Data/Information Architecture defines principles for:

• The classification of data/information

• The structure of data/information

• The modeling of data/information

• The quality assurance of data/information

• The protection of data/information

• The deployment of data/information

• The disaster recovery of data/information

• [The process for building and maintaining the architecture]

htt

p:/

/w

ww

.ub.t

um

.de



IT-System

Data,Information

FunctionalityDocumentation,

Models etc.

Technical Infrastructure

Software(Components,Applications)

Structures,Relationships

Repository

Data/InformationArchitecture



Information (Data)Architecture(Information & Data)

TechnicalArchitecture(TechnicalInfrastructure)

IntegrationArchitecture(CooperationMechanisms)

ApplicationsArchitecture(Functionality)

BusinessArchitecture(Business Processes)

Str

uctu

ralA

rch

itectu

reLayers

Hori

zon

talA

rch

itectu

res

Information (Data)Architecture(Information & Data)



http://ancienthistory.about.com/od/pyramids/tp/91012-The-Main-Pyramids-Of-Egypt.htm

The Pyramid of Knowledge

Chaos

Syn

tax

Data

Information

Knowledge

Wisdom

Do

mai

nM

od

el

Sem

anti

cs

Re

aso

nin

g

Context

Data/InformationArchitecture



Classification of data/information

Structure of data/information

Modeling of information

Quality assurance of data/information

Protection of data/information

Modeling of data

Deployment of data/information

Disaster recovery of data/information

Data/Information Architecture

InformationArchitecture

DataArchitecture




The principles for building applications are the same in all application domains[sometimes with some tradeoffs]

Q: Is this also true for information/data architecture ?

http

://w

ww

.orm

utu

al.c

om

Enterprise data/informationarchitecture

htt

p:/

/w

ww

.ove.u

k.c

om

Vehicle data/informationArchitecture

[Embedded Systems]

… unfortunately NO!



a) Enterprise Data/Information Architecture

http

://w

ww

.orm

utu

al.c

om



IT-System

Software Structures,Relationships

Repository

Data,Information

FunctionalityDocumentation,

Models etc.

htt

p:/

/xn

--80aqafc

rtq.c

c/de

Functionality:• mostly good

• well organized

http

://w

ww

.thegu

ard

ian

.com

Data/Information:• often disorganized

• inconsistent(redundant)

It is easy to change functionality – but very hard to change data/information



Business Model… how to earn money

Databases/Tables… persistent storage of business

entities & transactions

Business Processes… how to execute the business

operations

Applications/Components& Data/Information

… implementation of businessoperations

Data/Information Architecture Stack:

Enterprise Model

Business Logic Model

Domain ModelBusiness Object Model

Database/TableModels

Information Architecture

Data/information architecture = A set of consistent, complete models



Data CriticalityUpdate/Access

RateMirroring-

IntervalSave-

IntervallRemarks

TransactionData

High 40 .. 400 MillionTransactions/day

TransactionLevel

24 h Mainframe

ControlTable Data& ReferenceData

Very high 14’000accesses/sec

After eachupdate

24 h Mainframe

Applicationcontrol data

Very high 2 … 5’000accesses/sec

After eachupdate

24 h Mainframe

Accountingdata

Very high 50 … 100 MillionTransactions/day

24 h 24 h After EOD(= End ofDay)processing

Archive Very high High write, verylow read rate

8 hrs daily

ApplicationData

High 0 … 10 Millionupdates/day

After eachchange

daily After EOD(= End ofDay)processing

Example: Typical volumes (large bank)



Enterprise Data/Information

Structure[DB-Schemas]

PerformanceRequirements

Data/Information Architecture Implementation

Metadata[„Data about

data“]

NamingStandards

DisasterRecovery

&Business

ContinuityStrategy

DisasterRecovery

&Business

ContinuityStrategy

DisasterRecovery

&Business

ContinuityStrategy

Distributed Deployment

DisasterRecovery

&Business

ContinuityStrategy

SecurityStrategy



Enterprise Data/Information Strategyh

ttp:/

/w

ww

.tru

pph

r.com

No enterprise data strategy

= Chaos• bad data quality• redundant data (inconsistent)• inability to integrate• low agility for changes• bad performance• …

Enterprise Data& Information Strategy

Legal & Compliance Requirements

Enterprise Context

Unstructured Data

Business Continuity & Disaster Recovery

Security & Privacy

Performance & Measurement

Metadata

Organizational roles & responsibilities

Data/Information Modelling

Data Integration

Data Quality Standards

APPROVEDby CIO & CEO


Dr. Frank J. Furrer - WS 2014/15 55

Basic Rules for Partitioning :

1) Functional Coherence: Assign functions to encapsulation units based on

their coherence („Dogs to Dogs, Cats to Cats“)

2) Data/Information Coherence: Assign data and information to

encapsulation units based on their similarity (coherence)

(„Apples to Apples, Pears to Pears“)



Data/information is a very valuable asset of theenterprise – in fact: for many enterprises it is the highestvalue they have

The data/information architecture must assure thequality attributes (dependability, performance, …) of thedata/information used in the processing

A successful data/information architecture must bebased on a data strategy

Summary



b) Embedded Systems Data/Information Architecture

htt

p:/

/w

ww

.ove.u

k.c

om

Example: Vehicle data/information Architecture[Embedded Systems]



What is different in embedded systems data & information?h

ttp:/

/th

orn

ton

cen

ter.

net

Time !

Data items have

timing relationships

between them

… sometimes verydemanding andstringent!



Example: Wheel rotation information in a brake-by-wire carh

ttp:/

/w

ww

.tom

orr

ow

ste

ch

nic

ian

.com

Electronic Stability Program(ESP)

Bra

ke

Con

trol

Time ms]Acquisition

Interval

Sensor

FR

Sensor

FL

Sensor

BR

Sensor

BL

Bra

ke

Con

trol

ImpactInterval

ComputingIntervall

< 10 msec100 x/sec



What is different in embedded systems data & information?

Inconsistency

Data items may have

inconsistencies

between them

… due to mechanical,communications orelectronic glitches



Data ValidationData in embedded systems must often be validated before use

Validation: Assure consistency in value and in time

Timems]Acquisition

Interval

Sensor

FR

Sensor

FL

Sensor

BR

Sensor

BL

Bra

ke

Con

trol

ImpactInterval

ComputingIntervall

Validati

on

/C

orr

ecti

on

htt

p:/

/w

ww

.cdxete

xtb

ook.c

om

/bra

kes

Wheel rotation speed sensor

Validation step: Processing of data items before using them in thecomputing of actions

Methods: „cleaning“ & plausibility algorithms (simplest: -check)



Data Acquisition Redundancy

Data in embedded systems must often be validated before use,because it may be unreliable due to possible faults, failures or

intermittent problems of mechanical, electronic or interference causes

Remedy:

Planned redundancy in acquisition (multiple sensors)

Algorithmic „cleaning“ of data

htt

p:/

/w

ww

.desig

nw

orl

don

lin

e.c

om

Sensor data is capturedby 2 or 3 independentsensors, transmitted tothe ECU and „cleaned“by an algorithm



Data/information is a critical element in embeddedsystems – it must be correct, timely and complete withinspecified limits

Assure adequate steps in the acquisition, validation andtransmission of data in the system, such as managedredundancy, fault-tolerance, validation

Define suitable data/information structures

Summary





1. Define and adhere to an enterprise wide data/information strategy(approved by CIO and CEO)

2. Model top-down with consistent, redundancy-free, complete models

3. Assign roles and responsibilities for all data/information items

4. Define and strictly enforce data quality standards

5. Never allow unmanaged redundancy („single version of truth“)

6. Specify and enforce data naming and abbreviation standards

7. Define and implement suitable mechanisms for data validation(correctness, timeliness – possibly using acquisition redundancy)

A9

Justification: A good data/information architecture (andimplementation!) is a highly valuable backbone for the enterprise. Onthe contrary, an unsuitable, inconsistent or badly implementeddata/information architecture is a constant source of problems





Formal Modeling

A10

Future-Proof Software-Systems: Formal Modeling


1. Motivation

2. Definitions

3. State of the Art

4. Engineering Solutions

Modeling of IT-Systems

Hope

htt

p:/

/w

ww

.dom

esti

cati

ngit

.com

Confusion

htt

p:/

/w

ww

.moto

rau

thori

ty.c

om

EngineeringSolutions

Lecture:



1. Motivation

2. Definitions

3. State of the Art





“All models are wrong – but some are useful“

Modeling of IT-Systems: Motivationh

ttp:/

/m

useu

mvic

tori

a.c

om

.au

/tr

easu

res

Models simplify the real world

Models abstract the real world

Models focus the real world

Why wrong?

Why useful?



Modeling of IT-Systems: Motivation

Adequate Models provide:

htt

p:/

/w

ww

.port

lan

dart

.net

Clarity

Committment

Communication

Control

The 4 C‘s of models




ClarityThe concepts, relationships,

and their attributes areunambigously defined andunderstood by allstakeholders

CommittmentAll stakeholders have accepted

the model, its representationand the consequences(agreement)

CommunicationThe model truly and

sufficiently represents thekey properties of the realworld to be mapped into theIT-solution

ControlThe model is used for the

assessment of specifications,design, implementation, reviewsand evolution





Purpose of the Model

Which is the objective of the model? Which solutions shall themodel facilitate? For what shall the model be used? How fine-granular shall the model be? Which is the modeling boundary?

Who is the owner of the model? Which process shall be used toevolve and maintain the model?


Audience of the ModelWho benefits from the model (stakeholders)? Who needs to agree

to the model? Who needs to influence or accept the model? Whofinances the modeling activity and what is the model‘s businesscase?

Before starting any modeling activity, clearly define:



1. Motivation

2. Definitions

3. State of the Art





Modeling of IT-Systems: Definitions

Model: ?

Semi-formalModeling

FormalModeling

Syntax: IntuitiveSemantics: Intuitive

Syntax: FormalizedSemantics: Semi-formal

Syntax: FormalizedSemantics: Formalized

Informal discussions

Semi-formal discussionsModel-exchange, ProfilesLimited Model Checking

Formal discussionsExtensive Model CheckingReasoning

Informal Modeling




Conceptual Model(s)C8

C7

C6

C5

C4

C3

C2

C1

Technology Model(s)

Models the technology elements(servers, networks, busses,system software, backup anddisaster recovery configurationsetc.)

Models the concepts, theirrelationships and theirbehaviour of a specific domain

Database Model(s) Models the elements and thestructure of databases



Technical Infrastructure Architecture Layer

Infrastructure Services

Deployment Architecture Layer

Business Architecture Layer

architecting

Application (Software) Architecture LayerBusiness area:

Financial institution

Example:„Customer“

DatabaseSchema

Attributes:Name: …Address: …Date of birth: …etc.

Concept: Account1…*1…*

association

Database Design

BusinessContinuity& DisasterRecoveryPlan



Servicedesign

Access

con

trol

DR

A DCB

Archive

Disk

Enterprise BusDisk

DiskDisk

Ta-peTa-

peMain-frameMain-

frameMain-frame

ServerServer

Server

Concept: Customer

„A person or organizationbuying goods or servicesfrom our organization“




Definition

Formal Model:

Abstraction of a specific domain using a precise syntaxand rich semantics,

based on a formal logical foundation,

enabling model checking, validation and reasoning


77Dr. Frank J. Furrer - WS 2014/15hybrid

Typediscrete

continuous

Time

dynamic

static

Expressivity

very high

high

medium

low

Modeling of IT-Systems: Definitionsh

ttp

://w

ww

.nam

e-lis

t.n

et/i

mg/

imag

es.p

hp

/Go

del

_5.jp

g

Kurt Gödel

htt

p:/

/ro

.mat

h.w

ikia

.co

m/w

iki/

Geo

rge_

Bo

ole

0,1,,

George Boole

un

decid

able

decid

able

DL

DL = Description Logic




Example: Boolean Logic

Georg

eB

oole

Variables: x [0,1]

htt

p:/

/en

.wik

ipedia

.org

/w

iki/

Boole

an

_alg

ebra

Operators: and, or, not

htt

p:/

/drs

tien

ecker.

com

/te

ch

-332



Example: Car Ontology

{Car}

partOf

partOf

partOf{Body}

{Chassis}

{Power Train}

Parts

Relationship

partOf

{SteeringColumn}

{Engine}

partOf

partOf

partOf

partOf

{Gearbox}

partOf

partOf

partOf

partOf

partOf

partOf

{Door}

partOf{Screw}

instanceOf

instanceOf

instanceOf

instanceOf

instanceOf

Part # 692087Screw M8x20

Part # 653-000-0603Screw 6x3/8“






Example: Car Ontology

<owl:Class rdf:ID=“Car“/>

<owl:Class rdf:ID=“Body“>

<rdfs:subClassOf rdf:resource=“Car“/>

</owl:Class>

<owl:Class rdf:ID=“Chassis“>


</owl:Class>

<owl:Class rdf:ID=“PowerTrain“>


</owl:Class>

OWL-DL (Web Ontology Language) Representation:

{Car}

partOf

partOf

partOf{Body}

{Chassis}

{Power Train}

Part

Relationship

Kurt Gödel



Clarity

Committment

Communication

Control


Modeling is a powerful instrument to provide:

… during the whole life-cycle of an IT-system

The 4 C‘sof models




Model Refinement (Model Hierarchy):

Top LevelModel

Detail 1 LevelModel

Detail 1 LevelModel

Detail 1 LevelModel

1st refinement

Detail 2 LevelModel

Detail 2 LevelModel

Detail 2 LevelModel

2nd refinement

Incre

asin

gle

velof

deta

il

Para

dig

m:In

herita

nce



Example: Domain Model for a Financial Institution

5: Communications & Collaboration

Business Partner Applications (BPA) Financial Instruments, Research & Market Data (FIN)Enterprise Content Management (ECM)

Client Communication (CHA) Street Side Interfaces (SSI)

1:

Par

tne

rs&

Pe

rso

ns

2:

Fin

ance

,In

vest

me

nt

&Sa

les

3:

Trad

ing

and

Mar

kets

4:

Cas

han

dA

sset

Op

era

tio

ns

Cu

sto

mer

&Part

ner

(CU

S)

Wealth Management &Advisory

(WMA)

Credits and Syndication

(CRS)

6:

Acc

ou

nti

ng,

Co

ntr

olli

ng

and

Re

po

rtin

g

Fin

an

cia

lA

ccou

nti

ng

(FA

C)

Regu

lato

ry,

Ris

kan

dLiq

uid

ity

(RR

L)

Accounting Control

(AOC)

Logistics

(LOG)

Basic Facilities

(BAS)

Trading

(TRA)

Product Control

(PRC)

Payments

(PAY)

Settlement and Clearing

(SCL)

Single Accounts

(SAC)

Custody(CDY)

Corporate Actions

(COA)

7: Enterprise Common Services

Domain:Container for

coherentfunctionality

and data(partitioning!) Top Level

Model forPartitioning




Domain

Applicati

on

s(C

ode

+D

ata

)

Subdomain Subdomain Subdomain Subdomain

AdditionalPartitioning

Top LevelModel for

Partitioning

Detail 1Level Model

forPartitioning

Detail 2Level Model

forPartitioning



Business Stakeholders… need to model:

• Business processes• Data/Information content & structure

• Future business scenarios• External relationships

ww

w.1

23rf

.com

htt

p:/

/cre

att

ica.c

om

IT Stakeholders… need to model:

• IT system structure• IT system behaviour

• IT system interaction with the environment• IT system evolution• IS system operation




1. Motivation

2. Definitions

3. State of the Art





World

System-of-Systems (SoS)Application

Domain

System

Structure BehaviourInteraction

with theenvironment


with theenvironment

Metamodel

[ Modelingelements &Notation]

ConceptualModel

[ Concepts &relationships inthe realapplicationdomain world]

ArchitectureModel

[ Structure, i.e.parts and theirconnections]

ImplementationModel

[ Planneddeployment ofthe parts +connections]

Modeling Hierarchy

Modelin

gLevel

F

FF

F

F

F

F

F

F

FF

F

F

FF

F

F

F

F

FF F

F F

FF

F

F

F

F

FF

FF

F F

F

FF

FFF

F F

IT-System

Modeling of IT-Systems: State of the Art



Modeling of IT-Systems:State of the Art

ModelingLevel World

System-of-Systems (SoS)Application

Domain

System


with theenvironment


with theenvironment

Metamodel BoundaryDefinition

SoSMetamodel

SoSInteractionModel

SoSInteractionModel

DomainMetamodel

OMG Meta-model &Profiles,Graphs

ComponentModel

Interfacetheories,ContractModels

ConceptualModel

Upper(World)Ontology

UML,SysML

SystemBlack BoxModel,Gover-nanceModel

SoS-Model,UML, SysML,Contracts(Technical &Legal)

DomainOntology,BusinessObject Model,ApplicationDomain Model(DSL), BusinessProcess Models

UML,SysML

HybridCompo-nents,BusinessProcessOrchestra-tion

SoS-Model,UML, SysML,Contracts

ArchitectureModel

- UML,SysML,Petri-NetsFrame-works,

Contracts,

Web-Stds(e.g.WSDL)

Contracts,

Web-Stds(e.g. WSDL)

Referencearchitecture,ArchitectureFramework

UML,SysML,Petri-NetsFrame-works,Contracts

State-machines,timedautomata,Simulink,Contracts,Web-Stds(e.g.WSDL)

Contracts,Web-Stds (e.g.WSDL)

Implementa-tion Model

- Annotated,directedHyper-graphs

- Annotated,directedHypergraphs



Run-TimeModel

- model@run-time

- model@run-time

- model@run-time

- model@run-time

Modeling Instruments: Overview




htt

p:/

/w

ww

.ubiz

oo.d

e

BusinessObjectModel

Domain Model

SimulinkModels

Frameworks

model@runtime

Timed Automata

Contracts

Directed Hypergraph

Taxonomy

State Machines

Petri Net

Ontology OWL

SysML

UML




Why the confusion?

Modeling is an evolving science (Many papers/books published every year)

Modeling instruments depend heavily on purpose/audience

The standardization bodies (OMG, W3C, ietf, ISO, …) are slow

Strong – and conflicting – interest of major industry players (Divergence)



Modeling of IT-Systems: State of the Arth

ttp:/

/w

ww

.ubiz

oo.d

e

Which are today‘s engineering modeling solutions?

Mature and in wide use:

Domain Models

Business Object Models

Web-Standards (WSDL, …)

OCL

Ontologies (OWL-DL)

UML, SysML + Profiles

State machines

Timed automata

Simulink Models

ERD for Databases

Emerging and in selected use:

Domain Specific Languages

Contracts (CSLs)

(Coloured) Petri Nets

Annotated, directed hypergraphs

Graph rewriting



State of the Art Conclusions (2014):

The power and importance of IT-system modeling is(slowly) being recognized and accepted in industry

IT-system modeling is an unmature, evolving science

Today‘s IT-system modeling landscape is fragmented,inconsistent and incompatible

However, there are some modeling instruments whichare sufficiently powerful, mature and interoperable

IT-system modeling is a highly interesting field of research

IT-system modeling is strongly requested by industry

Summary




Model Checking & Verification

htt

p:/

/w

ww

.cpro

ver.

org

/w

mm

/

A formalized modelbased on a formal logicalfoundation allowsautomatic verification of:

• Syntactical correctness

• Semantic correctness

ModelQuality




A formalized model based on a formallogical foundation allows reasoning:

- extracting implicit knowledge (reasoning)

- deciding statements (true/false)

Reasoning

htt

p:/

/erm

en

tor.

com




Example: Reasoning in an Ontology

Reasoning: From the explicitly formulated knowledge in anOntology (= model) implicit knowledge is extracted via defined rules

Nontrivial example (http://owl.man.ac.uk/2003/why/latest):

Content of the ontology:

• „Cat owners have cats as pets“ Statement in the ontology

• „has pet“ Subproperty of „loves“ (Statement in the ontology)

Reasoning Conclusion:

• „Cat owners love their cats“

deduction checking



1. Motivation

2. Definitions

3. State of the Art





Modeling of IT-Systems: Engineering Solutions

htt

p:/

/w

ww

.ch

oic

ebon

d.c

om

Which instruments can we use in today‘s SW-engineering work?



Modeling of IT-Systems: State of the Arth

ttp:/

/w

ww

.ubiz

oo.d

e

Which are today‘s engineering modeling solutions?


Domain Models



OCL

Ontologies (OWL-DL)


State machines

Timed automata

Simulink Models

ERD for Databases

Emerging and in selected use:

Domain Specific Languages

Contracts (CSLs)

(Coloured) Petri Nets

Annotated, directed hypergraphs

Graph rewriting



Modeling of IT-Systems: Engineering Solutionsw

ww

.123rf

.com

Stakeholders:Business People, …

htt

p:/

/cre

att

ica.c

om

Implementation:SW-People

RequirementsEngineering

Business ObjectModelDomain Model

BO

BOBO

BO

Structural Model Behaviour Model

Database Model Deployment Model




Domain OntologyUML + Profile Model

Application TaxonomyUML + Profile Model[Interface Contract Model]

Data DictionaryERD-ModelGraphs/Petri Nets

Business ObjectModelDomain Model

BO

BOBO

BO

Structural Model Behaviour Model

Database Model Deployment Model



5: Communications & Collaboration

Business Partner Applications (BPA) Financial Instruments, Research & Market Data (FIN)Enterprise Content Management (ECM)

Client Communication (CHA) Street Side Interfaces (SSI)

1:

Par

tne

rs&

Pe

rso

ns

2:

Fin

ance

,In

vest

me

nt

&Sa

les

3:

Trad

ing

and

Mar

kets

4:

Cas

han

dA

sset

Op

era

tio

ns

Cu

sto

mer

&Part

ner

(CU

S)

Wealth Management &Advisory

(WMA)

Credits and Syndication

(CRS)

6:

Acc

ou

nti

ng,

Co

ntr

olli

ng

and

Re

po

rtin

g

Fin

an

cia

lA

ccou

nti

ng

(FA

C)

Regu

lato

ry,

Ris

kan

dLiq

uid

ity

(RR

L)

Accounting Control

(AOC)

Logistics

(LOG)

Basic Facilities

(BAS)

Trading

(TRA)

Product Control

(PRC)

Payments

(PAY)

Settlement and Clearing

(SCL)

Single Accounts

(SAC)

Custody(CDY)

Corporate Actions

(COA)

7: Enterprise Common Services





Domain Ontology

Single Accounts

(SAC)

AccountAttributes:• Owner• Currency• min/max balance• etc.

Checking AccountAttributes:• max overdraft• repay conditions• etc.

Savings AccountAttributes:• max credit/debit/month• etc.

XXX AccountAttributes:• xx• xx• etc.

partOf

partOf

partOf



Exam

ple

:B

usin

ess

Obje

ctM

od

el

for

aF

inan

cia

lIn

stitu

tion

AgreementPortfolioeBO

OrganizationEntityeBO

RequesteBO

OperationeBO

ProducteBO

obligates/entitles

obligates/entitlesAgreementeBO

PartyeBO

aggregatesmanages

conta

ins

(indiv

idual)

iscontra

ctu

al

base

for

issues/a

cts

on

issues/a

cts

on

providesrules for

produces

offers specifies

contains(standard)

supports

/inclu

des

needs/re

ceiv

es

needs/re

ceiv

es

initia

tes/re

sults

from

ow

ns/c

ontro

ls

FinancialInstrumenteBO

iscom

mitte

dto

embodies

inclu

des/s

pecifie

s

Transfers/transforms

EconomicResourceeBO

Document/ReporteBO

TermConditioneBO

Refinement



PartnerdBO

ContactdBO

ServicingdBO

AdressingInstructiondBO

AddressdBO

VariousDatadBO

CompliancedBO

InstructiondBO

SegmentationdBO

PartnerPartnerContextdBO

PartnerDossierContextdBO

PartyeBO

AgreementeBOEnterprise

Level

DomainLevel

DossierdBO

PartnerAgreementdBO

refinement refinement

PartnerGroupdBO

Example: Business Object ModelRefinement for a Financial Institution

Refinement




Domain Models



OCL

Ontologies (OWL-DL)


State machines

Timed automata

Simulink Models

ERD for Databases


The Object Management Group (OMG) is an

international computer industry standardsconsortium

Founded in 1989, OMG standards are drivenby vendors, end-users, academic institutionsand government agencies

OMG’s modeling standards, including theUnified Modeling Language (UML) and ModelDriven Architecture (MDA), enable powerfulvisual design, execution and maintenance ofsoftware and other processes

http://www.omg.org



Modeling of IT-Systems: Modeling Instruments

Diagram

StructureDiagram

BehaviourDiagram

ClassDiagram

ObjectDiagram

ComponentDiagram

CompositeStructureDiagram

ProfileDiagram

DeploymentDiagram

PackageDiagram

StateMachineDiagram

InteractionDiagram

ActivityDiagram

Use CaseDiagram

SequenceDiagram

Communi-cation

Diagram

TimingDiagram

InteractionOverviewDiagram



Function [F]

utilizes

1..*Function Owner

[FO]

1..* 1

manages

Capability [C]

1..*

builds

1..*

1..*

1..*

System-of-Systems[SoS]

Mission [M]1 1

is defined by Mission Owner[MO]

1 1

implements

1..*

Coordinator[CE] 1

governs

CooperationStandards

[CS]

1..*1 enforces

Environment 1 1..*

interacts

Users

1 1..*

benefit

State of the Art Example:SoS Conceptual Model:Structure (High Level)

1

ConstituentSystem Domain

[CSD]

CooperationDomain

[CD]

1..* 1..*

1..*

interconnects

1..*

1..*1..*

1

CooperationMechanism [CE]

CooperationContract [CC]

ConstituentSystem

[CS]

Process[Proc]

1..*1..*

1

Global(synchronized)

Time

delivers

1

Governance[Gov]1

is delineated by

1..*

ChangeManagement

Ownership

BudgetAuthority

1

11




UML and Semantics


Mission [M]1 1


1 1

implements


[CSD]

CooperationDomain

[CD]1..*

interconnects

1..*

Environment 1 1..*

interacts

Users

1 1..*

benefit

Class(Entity)

„meaningless“container

Meaningassigned

by modeler

Association(Relationship)

Meaningassigned

by modeler

Meaningdefinedin UML

Aggregation(Composition)

1

1..* 1..*




UML and Semantics

How can we define semantics (meaning) in UML diagrams?

a) By building an ontology based on a domain-model which formally defines the meaning of allconcepts (classes), relationships (associations) andtheir attributes

htt

p:/

/w

ww

.tech

nolo

gyu

k.n

et

b) By defining an UML-profile,extending UML with a domain-specific vocabulary (includingrelationships)




Definition:

An UML-profile allows UML to model systems intended for use in aparticular domain (for example medicine, financial services orspecialized engineering fields, such as safety-critical embeddedsystems or systems-of-systems).

A profile extends the UML to allow user-defined stereotypes, meta-attributes, and constraints. The vocabulary of the UML is thusextended with a domain-specific vocabulary that allows moremeaningful names to be assigned to model elements.

UML-profiles allow the formalized exchange of domain-knowledgebetween different users and enforce a standardization of UMLmodels.

UML and Semantics




Example: Important UML-profiles (Standardized by the OMG)

MARTE (Modeling and Analysis of Real-Time and EmbeddedSystems): MARTE is an UML profile intended for model-baseddevelopment of real-time and embedded systems

UDMP (Unified Profile for DoDAF and MODAF Profile): Profile

for enterprise and system of systems (SoS) architecturemodeling

UML and Semantics

htt

p:/

/cre

att

ica.c

om

UMLNotation

ModellingLanguage

UMLProfile

Domain/Application-specificconcepts & semantics




Quality of Models

The quality of a model can be expressed as follows:

Syntactic Quality: The model does not violate any syntactic rules of themodeling language

Semantic Quality: All the elements in the model have a unambigouslyspecified and agreed meaning

Pragmatic Quality: The interpretation by the human stakeholders is correctwith respect to what is meant to be expressed by the model. Theinterpretation by the tool(s) is correct with respect to the intendedfunctionality

Social Quality: The model has sufficient agreement by all stakeholders

Completeness Quality: The model contains sufficient information to fullfill itsrole „clarity, committment, communication, control“ for the intended goal




The System Modeler

A good system modeller needs:

A strong theoretical background of the choosen modelling instrument

An excellent fluency in the modelling language and the modelling tools

Good skills to extract the knowledge from the stakeholders in the domain

Mediation skills to reach agreement for the model between the stakeholders

A „touch of art“ – to make simple and beautiful, rich models

A good and reliable memory to have the full model present at all times

YOU !




The Future: Contract-Based Systems Engineering

htt

p:/

/w

ww

.yellow

jacketd

isposal.com

Definition:

Contracts are formal, binding agreements between a service provider and aservice consumer.

They cover the functional interface specifications (functionality and data), thenon-functional properties (timing, security etc.) and in some cases also the

commercial conditions (terms of use, guarantees, liability etc.)





Component,Application

Interface

ServiceContract


Interface

ServiceContract


Interface

ServiceContract


Interface

ServiceContract

Co

mp

osi

tio

n





http

s:/

/w

ww

.dan

se-ip

.eu

/h

om

e/im

ages/deliv

era

ble

s/D

AN

SE

_D

6.3

.2_G

CS

L.p

df

www.publicdomainpictures.net

Example: Emergency Services

“All FireStation host at least one Fire Fighting Car”

SoS.itsFireStations->forAll(fstation | fstation.hostedFireFightingCars->size() >= 1)

“Any district cannot have more than 1 fire station, except if all districts have at least 1”

SoS.itsDistricts->exists(district | district.containedFireStations->size() > 1) impliesSoS.itsDistricts->forAll(containedFireStations->size() >= 1)

“The fire fighting cars hosted by a fire station shall be used all simultaneously at least once in 6 months”

SoS.itsFireStations->forAll(fireStation |Whenever [fireStation.hostedFireFightingCars->exists(isAtFireStation)] occurs,

[fireStation.hostedFireFightingCars->forall(isAtFireStation = false)]occurs within [6 months])

red = identifiers from the model / blue = OCL constraints / bold black = temporal operators




Formal Modeling

1. Model as many parts of your IT-system as possible(organization & skills contraints)

2. Use the highest possible degree of formalization

3. Use industry-standard modeling instruments

4. Treat models as a long-term, highly valuable assets inyour company and maintain them in a repository

A10

Justification: The 4 C‘s – Clarity, Committment,Communication and Control



References:

ReferencesKrogstie12 John Krogstie:

Model-Based Development and Evolution of Information Systems

– A Quality Approach

Springer Verlag, London, 2012. ISBN 978-1-4471-2935-6Embley11 David W. Embley, Bernhard Thalheim (Editors)

Handbook of Conceptual Modeling – Theory, Practice and Research Challenges

Springer Heidelberg, Dordrecht, 2011. ISBN 978-3-642-15864-3Plösch04 Reinhold Plösch:

Contracts, Scenarios and Prototypes – An Integrated Approach to High Quality Software

Springer-Verlag, Berlin Heidelberg, 2004. ISBN 978-3-540-43486-0Daum03a Berthold Daum:

Modeling Business Objects with XML Schema

Morgan Kauffmann Publishers (Elsevier), Amsterdam, 2003. ISBN 978-1-55860-816-0Duffy04 Daniel J. Duffy:

Domain Architectures – Models and Architectures for UML Applications

John Wiley & Sons, Ltd., Chichester, UK, 2004. ISBN 978-0-470-84833-2Ehrig06 Hartmut Ehrig, Karsten Ehrig, Ulrike Prange, Gabriele Taentzer:

Fundamentals of Algebraic Graph Transformations

Springer-Verlag, Berlin Heidelberg, 2006. ISBN 978-3-540-31187-4Gallo92 Giorgio Gallo, Giustino Longo, Sang Nguyen, Stefano Pallottino:

Directed Hypergraphs and Applications

Dipartimento di Informatica, Universita die Pisa, Italy, revised 1992. Downloadable from:http://www.cis.upenn.edu/~lhuang3/wpe2/papers/gallo92directed.pdf [last accessed: 18.1.2013]

Gallo99 Giorgio Gallo, Maria Grazia Scutella

Directed Hypergraphs as a Modelling Paradigm

Rivista di matematica per le science economiche e sociali, Vol. 21, 1999, pp. 97-123. Downloadable from:http://www.academia.edu/1990229/Directed_hypergraphs_as_a_modelling_paradigm [last accessed: 18.1.2013]



References:

ReferencesGnesi13 Stefania Gnesi, Tiziana Margaria:

Formal Methods for Industrial Critical Systems – A Survey of Applications

IEEE Computer Society, John Wiley & Sons, Inc., N.J., USA, 2013. ISBN 978-0-470-87618-3Henderson12 Brian Henderson-Sellers:

On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages

Springer-Verlag, Heidelberg, 2012. ISBN 978-3-642-29824-0Kelly08 Steven Kelly, Juha-Pekka Tolvanen:

Domain-Specific Modeling – Enabling Full Code Generation

John Wiley & Sons, Inc., Hoboken, N.J., USA, 2008. ISBN 978-0-470-03666-2Kleppe09 Anneke Kleppe:

Software Language Engineering – Creating Domain-Specific Languages using Metamodels

Addison-Wesley, N.J., USA, 2009. ISBN 978-0-321-55345-4Girault03 Claude Girault, Rüdiger Valk:

Petri Nets for Systems Engineering – A Guide to Modeling, Verification and Applications

Springer-Verlag, Berlin Heidelberg, 2003. ISBN 978-3-540-41217-4Lacy05 Lee W. Lacy:

OWL – Representing Information using the Web Ontology Language

Trafford Publishing, Victoria, Canada, 2005. ISBN 978-1-4120-3448-5Mitchell02 Richard Mitchell, Jim McKim:

Design by Contract – by Example

Pearson Education (Addison-Wesley), Indianapolis, USA, 2002. ISBN 0-201-63460-0Simsion05 Graeme C. Simsion, Graham C. Witt:

Data Modeling Essentials

Morgan Kaufmann Publisher (Elsevier), 3rd edition, 2005. ISBN 978-0-12-644551-6Weilkiens06 Tim Weilkiens:

Systems Engineering with SysML/UML – Modeling, Analysis, Design

Morgan Kaufman OMG Press, Burlington, USA, 2006. ISBN 978-0-12-374274-2





Systems of Systems(SoS)

A11

Future-Proof Software-Systems: Systems of Systems


Systems-of-Systems

SoS

Systems-of-Systems Engineering

SoSE

SoS

• Principles• Architecture• Models• Interactions• Operation• Evolution• …

• Processes• Governance• Failure Handling• …



What is a system-of-systems ?# of stakeholders (users, providers, …)

size (SLOC‘s)

108

106

104

102

1012109106103

System-of-

SystemsMega-System

MonolithicSystem

Systems-of-systems characteristics:

1. Operational Independence of the Elements

2. Managerial Independence of the Elements

3. Evolutionary Development

4. Emergent Behavior

5. Geographic Distribution [5 Maier criteria, 1998]

Managerial Independence of the Elements

Emergent Behaviour

Governance

Total = more thanthe sum of its parts



SoS Example: AMAZON Businessh

ttp:/

/seekers

port

al.w

ord

pre

ss.c

om

http://blog.winepresspublishing.com

orderbook

supply bookstransport book

deliver book

Governance Boundary 1GovernanceAuthority

1

GovernanceAuthority

2

GovernanceBoundary 2

GovernanceAuthority

3

Governance Boundary 3



SoS (Systems-of-systems) Terminology

CSA

CSE

CSD

CSI

CSH

CSG

CSF

CSC

CSB

CSN

CSMCS

L

CSK

ConstituentSystems (CS)

Dependency

System-of-Systems(SoS)

Mission

StakeholdersLead System



SoS (Systems-of-systems) Classification

Type of SoS Description

Directed

Directed SoS are those in which the integrated system-of-systems is built and managed

to fulfill specific purposes. It is centrally managed during long-term operation to

continue to fulfill those purposes as well as any new ones the system owners might wish to

address. The constituent systems maintain an ability to operate independently, but their

normal operational mode is subordinated to the central managed SoS purpose

Acknowledged

Acknowledged SoS have recognized objectives, a designated manager, and resources for

the SoS. However, the constituent systems retain their independent ownership ,

objectives, funding, and development and sustainment approaches. Changes in the

systems are based on collaboration between the SoS and the systems

Collaborative

In collaborative SoS the constituent systems interact more or less voluntarily to fulfill

agreed upon central purposes. The central players collectively decide how to provide or

deny service, thereby providing some means of enforcing and maintaining standards.

Virtual

Virtual SoS lack a central management authority and a centrally agreed upon purpose

for the system- of-systems. Large-scale behavior emerges – and may be desirable – but

this type of SoS must rely upon relatively invisible mechanisms to maintain it

htt

p:/

/w

ww

.acq.o

sd.m

il/se/in

itia

tives/in

it_s

os-s

e.h

tml



SoS (Systems-of-systems) Classification

Type of SoS Description

Directed

Directed SoS are those in which the integrated system-of-systems is built and managed

to fulfill specific purposes. It is centrally managed during long-term operation to

continue to fulfill those purposes as well as any new ones the system owners might wish to

address. The constituent systems maintain an ability to operate independently, but their

normal operational mode is subordinated to the central managed SoS purpose

Acknowledged

Acknowledged SoS have recognized objectives, a designated manager, and resources for

the SoS. However, the constituent systems retain their independent ownership ,

objectives, funding, and development and sustainment approaches. Changes in the

systems are based on collaboration between the SoS and the systems

Collaborative

In collaborative SoS the constituent systems interact more or less voluntarily to fulfill

agreed upon central purposes. The central players collectively decide how to provide or

deny service, thereby providing some means of enforcing and maintaining standards.

Virtual

Virtual SoS lack a central management authority and a centrally agreed upon purpose

for the system- of-systems. Large-scale behavior emerges – and may be desirable – but

this type of SoS must rely upon relatively invisible mechanisms to maintain it

htt

p:/

/w

ww

.acq.o

sd.m

il/se/in

itia

tives/in

it_s

os-s

e.h

tml

§€



Systems-of-systems characteristics:






Emergent BehaviourTotal = more than

the sum of its parts

SoS Maier Criteria



Example 1 for emerging properties: „flying“ (desirable/positive)h

ttp:/

/w

ww

.mskgm

bh

.com

Constituent systems (CS) of an aircraft:• engines• body• wings• cockpit• etc.

… none of the constituent systems is able to fly !

http

://en

.wik

ipedia

.org

/w

iki/

Airb

us_A

320_fa

mily

Assemble the essentialconstituent systems:

Emerging property: theassembly (= airplane) is ableto fly !



Emergence Desirable/positive Undesirable/negative

Expectedemergentbehavior

Reason for building theSoS (SoS objective)

Mitigate by appropriate designmeasures, such as threat/risk analysisand countermeasures

Unexpectedemergentbehavior

Sometimes (however,quite rarely) an SoSshows unexpected,beneficial behaviour

Unexpected & undesirable negativeemergent behavior is one of the criticalrisks of most SoS

SoS Emergent Behaviour Classification



Example 2 for emerging properties: landing crash (undesirable/unexpected)h

ttp:/

/avio

ners

.net/

2011/03/air

bu

s-a

319-a

ppro

ach

-to-l

an

din

g.h

tml

Constituent systems:

• Airplane (DC-8)

• Airport (Runway)

October 8, 1979: Swiss Air Flight 316overran the Athens runway – 14 deaths

Cause: „Interface“ between therunway and the airplane

• Landing when braking action isless then good

• Crew mistakes



stochastic

deterministic

persistent

temporary

unpredictable

predictable

discontinouos

by degree (incremental)

unexpectedexpected

SoS Emergent Behaviour Classification

www.danse-ip.eu



Monolithic systems Systems-of-systems:






Emergent BehaviourGovernance

SoS Maier Criteria



Managerial Independence: Governance

Definition:

Governance is the exclusive, non-overlapping right of a governance authority

to change any element (such as systems, relationships, operating parameters etc.)

located within the respective governance boundary

In a SoS we have new dimensions of:

• Complexity management

• Change management

• Operational challenges

• Risk assessment and mitigation

„The three devils of systems engineering are:

Complexity,

Change,

Uncertainty”Anonymous

Syste

ms-o

f-syste

ms

en

gin

eeri

ng



CSA

CSE

CSD

CSI

CSH

CSG

CSF

CSC

CSB

CSN

CSMCS

L

CSK

Governance Boundary 1GovernanceAuthority

1

GovernanceAuthority

2

GovernanceBoundary 2

GovernanceAuthority

3

Governance Boundary 3

Managerial Independence: Governance



CSA

CSE

CSD

CSI

CSH

CSG

CSF

CSC

CSB

CSN

CSMCS

L

CSK

GovernanceAuthority

1

GovernanceAuthority

2

GovernanceAuthority

3

Managerial Independence: Governance by Contract

CollaborationContract

• functional• operational• commercial

• legal



• legal



• legal



SoS Engineering: Carmaker & System suppliersh

ttp:/

/sdarc

hit

ect.

word

pre

ss.c

om



• legal

SoS-Engineering = Cross-

system and cross-community

engineering collaboration

SoS-Engineering = Intelligent

and effective distribution of

governance



… now we understand SoS‘s and their challenges

… what does it mean for our future-proof software-systems?

CSA

CSE

CSD

CSI

CSH

CSG

CSF

CSC

CSB

CSN

CSMCS

L

CSK

Mission

1) Transparent architecture

2) Explicit dependencies

3) Complete contracts

4) Risk mitigation

5) Monitoring and earlyresponse


138Dr. Frank J. Furrer - WS 2014/15 Furrer/Kopetz 2013

Function [F]

utilizes

1..*Function Owner

[FO]

1..* 1

manages

Capability [C]

1..*

builds

1..*

1..*

1..*


Mission [M]1 1


1 1

implements

1..*

Coordinator[CE] 1

governs

CooperationStandards

[CS]

1..*1 enforces

Environment 1 1..*

interacts

Users

1 1..*

benefit1


[CSD]

CooperationDomain

[CD]

1..* 1..*

1..*

interconnects

1..*

1..*1..*

1

CooperationMechanism [CE]

CooperationContract [CC]

ConstituentSystem

[CS]

Process[Proc]

1..*1..*

1

Global(synchronized)

Time

delivers

1

Governance[Gov]1

is delineated by

1..*

ChangeManagement

Ownership

BudgetAuthority

1

11

1

CommercialAgreement

OperationalAgreement

InterfaceSpecifications

1..* 1..* 1..*

State of the Art Example:SoS Conceptual Model: Structure (High Level)


139Dr. Frank J. Furrer - WS 2014/15 Furrer/Kopetz 2013

ConstituentSystem

[Sys]

Process[Proc]

1..*1..*

1..* 1..*

See Top-Level Model

Human[H]

Physical Subsystem[PS]

Function [F]

1..*Function Owner

[FO]

1..* 1

manages

Capability [C]

1..*

builds

1..*

1..*

utilizes

1..*

1..*

Component[Comp] Functional objectives

1…*1

is defined by

1..*

1..*1..* 1builds

Run-timeenvironment

System & Communications Software

Hardware Platform

1..*

executes on



Systems-of-Systems

SoS

Systems-of-Systems Engineering

SoSE

SoS

• Principles• Architecture• Models• Interactions• Operation• Evolution• …

• Processes• Governance• Failure Handling• …



CSA

CSE

CSD CS

G

CSB

CSN

Systems-of-Systems Engineering (SoSE)

Mission• Reqs

• Constraints

CSR

CSS

Built and managed to fulfill specific purposes.Centrally managed. Constituent Systems (CS)subordinated to the centrally managed SoSpurpose (mission)

Directed SoS



CSA

CSE

CSD CS

G

CSB

CSN


Mission• Reqs

• Constraints

CSR

Recognized mission, a designated manager, andresources for the SoS. The constituent systemsretain their independent ownership. Changes inthe systems are based on collaboration betweenthe SoS and the systems

Acknowledged SoS

CSI

CSH

CSF

CSL

SoS

SoS



CSA

CSE

CSD CS

G

CSB

CSN


Mission• Reqs

• Constraints

CSR

CSI

CSH

CSF

CSL

SoS

SoS

htt

p:/

/w

ww

.yellow

jacketd

isposal.com



CSA

CSE

CSD CS

G

CSB

CSN


Mission• Reqs

• Constraints

CSR

CSI

CSH

CSF

CSL

SoS

SoS

Systems-of-Systems Engineering & Operation:

Contract-based engineering and monitoring




CSR

CSF

SoS

SoS

InterfaceContract

OperationalAgreement

CommercialAgreement

Service Contract

Behaviour

Functionality Data

Assumption/Guarantees Constraints

…

Operational Parameters

Availability Response time [ms] Throughput [calls/s] Availability [%]

...

Commercial Conditions

Access rights Cost/call [€] Guarantees

Change Management ...




SoS Architect‘s Responsibility:

1) Transparent architecture

2) Explicit dependencies

3) Complete contracts

4) Risk mitigation

5) Monitoring and early response

Structure & Behaviour Model

Identify, document and understand alldependencies (i.e. make them explicit,

no implicit dependencies!)

Define all dependencies by contracts:• Functional• Operational• Commercial

Identify, assess and mitigate all risksin the SoS in relationship with the SoS

mission

Define and implement mechanisms tomonitor the correct operation of theSoS and to react early to deviations




Systems-of-Systems (SoS)

1. Develop and maintain a transparent, complete, up-to-date, welldocumented architecture for the SoS

2. Fully understand and (formally) specify all dependencies

3. Fully understand and (legally) specify the governance of the SoS

4. Define all dependencies by formal contracts

5. Use effective risk analysis and mitigation for the early detectionof operational faults, errors or unwanted emergent behaviour

A11

Justification: Due to the fragmented governance/ownership in a system-of-systems, the management, evolution and operation of a SoS are moredemanding. Therefore new procedures, engineering processes andoperational measures must be used.



Many of the interesting and useful systems are „Systems-of-systems (SoS)“

In a system-of-systems the architect and the management of aspecific constituent system lose considerable (direct)governance

The loss of (direct) governance must be compensated bycomplete contracts (functional, non-functional, legal etc.)

Emerging properties – especially unknown or unwanted, i.e.negative/harmful properties – are a considerable risk in manySoS‘s

Risk management & risk mitigation becomes a central issue inthe development, operation and evolution of SoS‘s

Operational monitoring of the SoS‘s operation for the earlydetection of faults, failures, and emerging properties isimportant

Summary



References:

ReferencesMaier98 Mark W. Maier:

Architecting principles for systems-of-systems

Systems Engineering, Volume 1, Issue 4, 1998. Pages 267–284

Downloadable from: http://www.infoed.com/Open/PAPERS/systems.htm [last accessed: 26.12.2012]DoD08 U.S. Department of Defense (DoD):

Systems Engineering Guide for Systems of Systems

Version 1.0, August 2008

Downloadable from: http://www.acq.osd.mil/se/initiatives/init_sos-se.html [last accessed: 28.12.2012]DoD10 U.S. Department of Defense (DoD):

Systems Engineering Guide for Systems of Systems - Essentials

December 2010

Downloadable from: http://www.acq.osd.mil/se/initiatives/init_sos-se.html [last accessed: 28.12.2012]Dahmann08 Dahmann, Judith, Jo Ann Lane, George Rebovich, Jr. and Kristen J. Baldwin:

A Model of Systems Engineering in a System of Systems Context

Sixth Conference on Systems Engineering Research (CSER 2008), Redondo Beach, CA, April 2008

Downloadable from: http://www.acq.osd.mil/se/initiatives/init_sos-se.html [last accessed: 28.12.2012]ECDG12 European Commission (A3-DG Connect):

Directions in Systems-of-Systems Engineering – Report from the Workshop on Synergies among Projects andDirections in Advanced Systems Engineering. Brussels, July 4 & 5, 2012.

Downloadable from: http://cordis.europa.eu/fp7/ict/embedded-systems-engineering/documents/report_system_of_system.pdf [last accessed: 20.10.2013]

Jamshidi09a Mo Jamshidi (Editor):

Systems of Systems Engineering – Principles and Applications

CRC Press, Taylor & Francis Group, Boca Raton, USA, 2009. ISBN 978-1-4200-6588-6Jamshidi09b Mo Jamshidi (Editor):

Systems of Systems Engineering – Innovations for the 21st Century

John Wiley & Sons Inc., Hoboken, New Jersey, USA, 2009. ISBN 978-0-470-19590-1





Complexity and Simplification

A12

http

://de.1

23rf.c

om

Future-Proof Software-Systems: Complexity + Simplification


htt

p:/

/blo

g.d

igit

al.te

lefo

nic

a.c

om

Complexity• Biology• Sociology• Astronomy• Physics• …• Information Technology (IT)

“Complexity is that property of an IT-system which makes it

difficult to formulate its overall behaviour, even when given

complete information about its parts and their relationships“

Complexity = (IT-) Risk



Example: U.S. FAA Air Traffic Control System

“FAA did not recognize the technical complexity of theeffort, realistically estimate the resources required,adequately oversee its contractors' activities, or effectivelycontrol system requirements"

1995: The FAA (US FederalAviation Agency) admits thecolossal modernization failureof the Advanced AutomationSystem (AAS). That efforttook 16 years of effort andcost taxpayers $23 billion

htt

p:/

/w

ww

.in

form

ati

on

week.c

om

/664/64iu

faa.h

tmh

ttp:/

/cla

rion

con

ten

tmedia

.com



Complexity = (IT-) Risk

good bad

Complexity must be managed !

• Identify it• Understand it• Avoid and reduce it as much as possible

• Complexity makes large,useful systems possible

• It forces us to develop sciencefor dealing with complexity

• it is a highly interesting andfruitful area of research

• It is the single most importantreason for disasters in IT

• It makes understanding,explaining and evolving IT-systemsvery hard

• It may lead to unpredictable(= emergent) behaviour



Classification of Complexity

Necessary or desired complexity:Essential complexity

Unnecessary or undesiredcomplexity: Accidental Complexity

htt

p:/

/ja

ckm

alc

olm

.com

/blo

g/2011/09/sim

plicit

y-s

ells

… is caused by the problem to besolved. Nothing can remove it.Represents the inherent difficulty

… is caused by solutions that we createon our own or by impacts from ourenvironment



ComplexityKnown (identified)Complexity

Unknown (hidden)Complexity

Necessary (desired)Complexity[Essential Complexity]

Unnecessary(undesired)Complexity[Accidental Complexity]

manage it use it carefully

avoid iteliminate it

attack it

Managing Complexity:



Complexity Metric System Boundary (Governance !)

Numberof Parts(EncapsulationUnits)

Numberof internaldependencies

Numberof externaldependencies

Functionalcomplexity ofinternalinterfaces

Functionalcomplexity ofexternalinterfaces



Complexity Contributors:

Contributor Metric

Number of Parts (Structural complexity) Integer number (NP)

Number internal dependencies (Structural complexity) Integer number (NiD)

Number external dependencies (Structural complexity) Integer number (NeD)

Functional complexity of internal interfaces # of FP, UCP (FiIj)

Functional complexity of external interfaces # of FP, UCP (FeIk)

A number of complexity metrics exist in the literature.

However, none of them is satisfactory for engineering system complexity

Interesting open research question (PhD-Level) !

Complexity Metric:

SysCompl = f[NP,NiD,NeD,FiIj,FeIk]



Sources of unnessary and unknown (accidental) IT-complexity:

If you don‘t properly manage complexity, itmay kill your IT-system (… most probably: it will)

If you don‘t properly manage complexity, itmay kill your IT-system (… most probably: it will)

Specifications: overlaps, duplication

Redundancy: functional, data & interface redundancy

Neglected legacy systems: old technology, out-of-use components

Lack of conceptual integrity: diverging concepts, misunderstandings

Disregard of (industry) standards: technology explosion

3rd party software: forced, incompatible concepts, redundancy

Inconsistent housekeeping: „dead“ code & data

Diversity in vertical architectures: proliferation of solutions



The nasty ways of complexity:

How can we manage complexity ?

a) Implement a process step „simplification“ in your development process

b) Periodically carry out re-architecture programs „complexity reduction“

Complexity creeps up, incrementally growing over long time

Containing complexity growth requires continuous andsubstantial architectural intervention and strong managementcommittment

Complexity occurs locally in many different specifications,programs and interfaces, but its impact is global

Complexity may grow to such a state, that the IT-ystembecomes unmanageable or commercially unviable


160Copyright Frank J. Furrer 2013

Implement a process step „simplification“ in your development process

Periodically carry out re-architecture programs „complexity reduction“

Reqs Specs Arch Design Build TestSimplify

Check-list

http://blogs.proquest.com

Application Landscape

Technology Portfolio

Re-Architecture Program 2014 Eliminate … Refactor … Replace … Redesign …

etc.

Effort:1‘100 MM

Cost:27 M€



Complexity Reduction Simplification Process Architecture Exploration

NewRequirements

(Functional & Quality)

Business

Arc

hite

ctu

reIm

ple

men

tatio

n

newchanged

Arc

hite

ctu

reD

evelo

pm

ent

Arc

hite

ctu

reE

valu

atio

n

• Functional Reqs• Quality Properties

• Fit into Legacy• Refactoring

• …




Complexity and Simplification

1. Actively manage the complexity in your system:• Identify it• Understand it• Avoid and reduce it as much as possible

2. Install a formal, controlled process step „simplification“ in your designand evolution procedures

3. For any (substantial) set of requirements develop several possiblearchitectures and use an architecture assessment method to select the

most suitable

4. Periodically execute re-architeture programs with the objective to reducethe complexity of the IT-system

A12

Justification: Complexity is the largest single risk in IT-systems. Bymanaging complexity, the unwanted or unnecessary complexity can bereduced – thus making the IT-system more agile, manageable anddependable.



Architecture Topic Map

Architecture-Greatness:• Simplicity• Elegance

Functionality

Architecture-Quality:• Agility• Availability• Security• Safety• Performance• …

Requirements• Req A• Req B•…• Req Y

Fu

ture

-Pro

ofS

oftw

are

-Syste

mE

ngin

eer

htt

p:/

/de.1

23rf

.com

BeautifulArchitecture



http

s:/

/w

ww

.pin

tere

st.c

om



References:

ReferencesSessions09 Roger Sessions:

The IT Complexity Crisis – Danger and Opportunity. White Paper,

November 2009. Downlodadable from:

http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf (last accessed: 8.2.2013)Sessions08 Roger Sessions:

Simple Architectures for Complex Enterprises

Microsoft Press, Redmond, USA, 2008. ISBN 978-0-7356-2578-5Kopetz11 Hermann Kopetz:

Real-Time Systems – Design Principles for Distributed Embedded Applications

Springer-Verlag, New York, USA. 2nd edition 2011. ISBN 978-1-4419-8236-0Rajan13 Ajitha Rajan, Thomas Wahl:

CESAR - Cost-efficient Methods and Processes for Safety-Relevant Embedded Systems

Springer Verlag, Berlin, Heidelberg, 2013. ISBN 978-3-709-11386-8Spinellis09 Diomidis Spinellis, Georgios Gousios (Editors):

Beautiful Architecture – Leading Thinkers Reveal the Hidden Beauty in Software Design

O’Reilly Media, USA, 2009. ISBN 978-0-596-51798-4Clements02 Paul Clements, Rick Kazman, Mark Klein:

Evaluating Software Architectures – Methods and Case Studies

Addison-Wesley, Boston, USA, 2002. ISBN 0-201-70482-XGell-Mann94 Murray Gell-Mann:

The Quark and the Jaguar – Adventures in the Simple and the Complex

Abacus (Hachette UK), London UK, 1994. ISBN 978-0-349-10649-6Leukert11a Peter Leukert, Andreas Vollmer, Bart Alliet, Mark Reeves:

IT Complexity metrics – How do you measure up?

CAPCO Inc., Washington DC, USA, White Paper 2011. Downloadable from; www.capco.com [last accessed29.9.2013]

Future-Proof Software-Systems


Part 1:

You know now the foundations of future-proof software-systems

Parts 2 + 3:

Explains the important architecture principles + Special Topics

Part 4:

Describes the „future-proof software-systems engineer“ and his workingcontext

fpss ws1415 part2b v07 20141226 - tu dresdenst.inf.tu-dresden.de/files/teaching/ws14/fps15/... ·...

Documents