part3b v08 20161123 - tu...

Future-Proof Software

1 Prof. Dr. Frank J. Furrer - WS 2016/17

Future-Proof Software(Zukunftsfähige Software)

Prof. Dr. Frank J. Furrer

TU Dresden WS 2016/2017

Part 3B: Architecting for Agility[2/3]

Part 3B: Architecting for Agility[2/3]

V0.8 / 21.11.2016



Part 1: Introduction & MotivationPart 2: Managed Evolution Strategy

Part 3: Architecting for Agility

Part 4: Architecting for Resilience

Part 5: The „Future-Proof Software 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



Part 3B: Architecting for AgilityPart 3B: Architecting for Agility

Future-Proof Software:

Architecture Principle A7:

Reuse and Parametrization

A7



htt

p:/

/w

ww

.lybecker.

com

CAUTION:

Reuse can be a danger for the consistency of an architecture

Reuse in Software Engineering

Reuse:

Utilization of Software-Artefacts in another Context or Application



Reuse in Software Engineering

Reuse is:

(very) difficult

htt

p:/

/w

ww

.ceph

alo

fair

.com

very powerful

(strong contribution to agility)

http

://arto

fsoftw

are

reu

se.c

om

/ta

g/sch

em

as/

If not done correctly:

Dangerous for the architecture

http

://w

ww

.pd4pic

.com



Successful reuse can be done with:

• Specifications

• Reference architectures

• Patterns

• Code (Functionality)

• Data (Information)

• Algorithms

• Configurations

• ….

http

s:/

/w

ww

.arte

factg

rou

p.c

om



Successful Reuse requires:

• a company-wide reuse strategy

• a strong reuse organization

• a dedicated, committed management

• Adequate development & evolution processes

http

://w

ww

.clip

artb

est.c

om



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

Making software-artefacts reusable requires additional effort



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 reusablesoftware artefacts

Pla

nn

ed

Tra

deoff



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



Black Box Grey Box White Box

htt

p:/

/w

ww

.dorg

ers

oft

.com

Owner

Black BoxNew Reqs

Black Box Vx.y + 0.1 Repository

reutilization



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

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.



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




TechnicalInteroperability

SyntacticInteroperability

SemanticInteroperability

ApplicationsInteroperability

System A

TechnicalInteroperability

SyntacticInteroperability

SemanticInteroperability

ApplicationsInteroperability

System B

AgreedRules



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

International Standards Organizations

CSBusinessObjectModelV1.1/2009

CompanyStandards

A standard is:

• a formal, established norm for (technical) systems

• a document which establishes uniform (engineering ortechnical) criteria, principles, methods, processes and practices



Respected standards are powerful interoperability and

productivity concepts



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(2/3)

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

http

s:/

/open

clip

art.o

rg



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)



… standards for interoperability

… standards for programming languages

… standards for processes



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

Certification:• Safety• Security• Interfaces• …



Technical Impact:• Interoperability• Communications• Technology• …

Knowledge:• Processes• Domain-Knowledge• Cooperation• …

Industry-Standard




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



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




IT-System

Data,Information

FunctionalityDocumentation,

Models etc.

Technical Infrastructure

Software(Components,Applications)

Structures,Relationships

Repository

Data/InformationArchitecture



http

://w

ww

.dm

u.a

c.u

k

Information = Data that is

1. accurate and timely,

2. specific and organized for a purpose,

3. presented within a context that gives it meaning and relevance,

4. leads to an increase in understanding and decrease in uncertaintyhttp://www.businessdictionary.com



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://www.rockley.com



Data/Information Architecture

Definition (1/2):

Information Architecture is a engineering discipline and a

(resulting) structure that is focused on making information:

• dependable

• understandable

• findable

• correct (content- & time-wise)• complete• consistent & integer• protected• accountable

• semantics• structured

• organized• available• unique (no unmanaged redundancy)




Definition (2/2):

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



… a little bit of history:

http

://w

ww

.zelle

r.de

Year: 1472



Information Architecture Artefacts

Structure SemanticsMetadataInformation

Strategy



StructureThe logical organization of theinformation universe of a company

MetadataMetadata is data providinginformation about aspects of thedata (source, purpose, content, …)

SemanticsDefinition and representation ofmeaning of the information

InformationStrategy

Objectives, principles andprocesses for the informationarchitecture



<author>W. H. Jaco</author><title>PL minimal surfaces in $3$-manifolds</title><ISSN>0022-040X</ISSN><URL>J. Differential Goem.</URL><article text>The body of the article included here</article text>

… more

Full template:http://www.ams.org/publications/journals/sample-data-file

Example: Metadata for Publishing

htt

p:/

/w

ww

.gh

tc.u

sp.b

r/sou

rces/cata

logu

e.h

tm

Semantics:Keywords

[ACM Dictionary]

Complete

Machine-readable (XML)

Standardized[ACM]



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


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!



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!



What is different in embedded systems data & information?

Inconsistency !

Data items may have

inconsistencies

between them

… due to mechanical,communications orelectronic glitches



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 generate revenue

Databases/Tables… persistent storage of business

entities & transactions

Business Processes… how to execute the business

operations

Applications/Components& Data/Information

… implementation of businessoperations

Enterprise Model

Business Logic Model

Domain ModelBusiness Object Model

Database/TableModels

Information Architecture

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

Data/Information Architecture Stack:



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



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

Modeling Data/Information:

2 «competing» notations


68 Prof. Dr. Frank J. Furrer - WS 2016/17http://indalog.ual.es/mdd/udbi/DB_ClassDiagram.png

UML Data/Information Model



http://i.stack.imgur.com/GiAos.png

Entity Relationsship Diagram (ERD)

http

://w

ww

.replic

am

useu

m.c

om

Multiple Views:



htt

p:/

/in

dalo

g.u

al.es/m

dd/u

dbi/

DB

_Cla

ssD

iagra

m.p

ng

UML Data/Information Model

Entity Relationsship Diagram (ERD)

htt

p:/

/i.sta

ck.im

gu

r.com

/G

iAos.p

ng

Show onlyrelevant elements

Consistency!



Architecture Principle A9 (a):

Enterprise Data/Information Architecture

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

[ Metadata & Semantics]

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. On thecontrary, an unsuitable, inconsistent or badly implementeddata/information architecture is a constant source of problems



b) Embedded Systems Data/Information Architecture

htt

p:/

/w

ww

.ove.u

k.c

om

Example: Vehicle data/information Architecture[Embedded Systems]



Time & timing relationships are an integral part ofan embedded data/information architecture

htt

p:/

/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



Inconsistency !

Data items may have

inconsistencies

between them

… due to mechanical,communications orelectronic glitches

Inconsistencies are an important part of anembedded data/information architecture



Time[ms]Acquisition

Interval

Sensor

FR

Sensor

FL

Sensor

BR

Sensor

BL

Bra

ke

Con

trol

ImpactInterval

ComputingIntervall

htt

p:/

/w

ww

.cdxete

xtb

ook.c

om

/bra

kes

Wheel rotation speed sensor

Example: Inconsistent wheel rotation information

10 rev/min

10,7 rev/min

19,3 rev/min

9.9 rev/min

?



How do we deal with data inconsistency?

1. Planned redundancy in acquisition (multiple sensors)

2. Algorithmic „cleaning“ of data (Validation)Sensor

FR

A

Sensor

FL

ASensor

BR

A

Sensor

BL

A

Bra

ke

Con

trol

Acquisition Interval

Time[ms]

ImpactInterval

ComputingIntervall

Sensor

FR

B

Sensor

FL

BSensor

BR

B

Sensor

BL

B

Sensor

FR

c

Sensor

FL

CSensor

BR

c

Sensor

BL

c

Validati

on

/C

orr

ecti

onRedundancy



Redundancy & Fault Toleranceh

ttp:/

/w

ww

.desig

nw

orl

don

lin

e.c

om

Sensor data is capturedby 3 independentsensors and transmittedto the computing unit

Example: Triple wheel rotation sensor

Data is acquired multiple times managed redundancySensor

FR

A

Sensor

FL

ASensor

BR

A

Sensor

BL

A

Sensor

FR

B

Sensor

FL

BSensor

BR

B

Sensor

BL

B

Sensor

FR

c

Sensor

FL

CSensor

BR

c

Sensor

BL

c

Sensorredundancy

• Time redundancy• Spatial redundancy• …



Validation

Validati

on

/C

orr

ecti

on

htt

p:/

/w

ww

.ele

vati

on

180.c

om

Multipleacquisition

of data

http

://w

ww

.bfe

-inf.o

rg

Consistent, correct data

Deterministic or statistical algorithms



Architecture Principle A9 (b):

Embedded Data/Information Architecture

1. Define and adhere to a product data/information strategy

2. Model top-down with consistent, redundancy-free, complete models[ Metadata & Semantics]

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

4. Stronly validate data/information after acquisition and before use(correctness, timeliness – possibly using acquisition redundancy)

A9

Justification: A good data/information architecture (andimplementation!) is necessary for all products based on embeddedsoftware.



ReferencesRosenfeld15 Louis Rosenfeld, Peter Morville, Jorge Arango:

Information Architecture – For the Web and Beyond

O’Reilly Media, Sebastopol, CA, USA, 2015. ISBN 978-1-491-91168-6Graham12 Andy Graham:

The Enterprise Data Model

Koios Associates Ltd., USA, 2012. ISBN 978-0-9565-8291-1Godinzez10 Mario Godinez, Eberhard Hechler, Klaus Koenig, Steve Lockwood, Martin Oberhofer, Michael Schroeck:

The Art of Enterprise Information Architecture – A Systems-Based Approach for Unlocking BusinessInsight

IBM Press (published by Pearson Education), USA, 2010. ISBN 978-0-13-703571-7Adelmann05 Sid Adelman, Larissa Moss, Majid Abai:

Data Strategy

Addison-Wesley, Upper Saddle River, N.J., USA, 2010. ISBN 0-321-24099-5Inmon01 W.H. Inmon, Claudia Imhoff, Ryan Sousa:

Corporate Information Factory

John Wiley & Sons, Inc., New York, N.Y., USA, 2nd edition 2001. ISBN 0-471-39961-2Marco00 John Marco:

Building and Managing the Meta Data Repository – A Full Lifecycle Guide

John Wiley & Sons, Inc., New York, N.Y., USA, 2000. ISBN 0-471-35523-2Dietz06 Jan L.G. Dietz:

Enterprise Ontology – Theory and Methodology

Springer Verlag, Berlin, DE, 2006. ISBN 978-3-540-29169-5Pollock04 Jeffrey T. Polock, Ralph Hodgson:

Adaptive Information – Improving Business Through Semantic Interoperability, Grid Computing andEnterprise Integration

John Wiley & Sons, Hoboken, N.J., USA, 2004. ISBN 0-471-48854-2ER ER Model - Basic Concepts: https://www.tutorialspoint.com/dbms/er_model_basic_concepts.htm





Formal Modeling

A10




htt

ps:/

/ifta

ch

kozi

k.w

ord

pre

ss.c

om

On August 10th, 1628 the warship Vasa set sail in Stockholm harbor

on its maiden voyage as the newest ship in the Royal Swedish Navy.

The country was at war with Poland and the ship Vasa was urgently

needed for the war effort.

1628:Swedish Warship Vasa• 2 gun decks• 32 x 24-pound guns

Example: Vasa (1/3)



After sailing about 1’300 meters, a light gust of wind caused the Vasa

to heel over on its side. Water poured in through the gun portals and

the ship sank

http

://w

ww

.hoch

sch

ule

-rhein

-waal.d

e

Example: Vasa (2/3)



Example: Vasa (3/3)

http

://w

ww

.hoch

sch

ule

-rhein

-waal.d

e

http

s:/

/de.w

ikip

edia

.org

/w

iki/

Vasa_(S

ch

iff)

Center of Gravity

Waterline

What happened?

A simple modelwould haveshown that theship was notseaworthy!



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:



Modeling of IT-SystemsModeling of IT-Systems

Motivation



“All models are wrong – but some are useful“

htt

p:/

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



htt

p:/

/m

useu

mvic

tori

a.c

om

.au

/tr

easu

res

Why wrong?

• Oversimplified

• Distances very wrong

• Planet sizes completely wrong

• Movement circular (not elliptical)

Why useful?

• Basic movements understandable

• Important details shown

• Synchronized operation (rotation)

• Projections possible (e.g. distances)



Why models?

Adequate Models provide:

htt

p:/

/w

ww

.port

lan

dart

.net

Clarity

Committment

Communication

ControlThe 4 C‘s of models



The 4 C‘s of models

CommittmentAll stakeholders have

accepted the model, itsrepresentation and theconsequences (agreement)

CommunicationThe model truly and sufficiently

represents the key propertiesof the real world to be mappedinto the IT-solution

ControlThe model is used for the

assessment ofspecifications, design,implementation, reviewsand evolution

ClarityThe concepts, relationships, and

their attributes areunambigously defined andunderstood by all stakeholders



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?

The 4 C‘s of models

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:




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 syntax,

• rich semantics,

• based on a formal logical foundation,

enabling model checking, validation and reasoning



Typediscrete

continuous

Time

dynamic

static

Expressivity

very high

high

medium

low

htt

p:/

/ww

w.n

ame-

list.

net

/im

g/im

ages

.ph

p/G

od

el_5

.jpg

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

Model Expressivity



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

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

The 4 C‘sof models

Modeling is a powerful instrument.

It provides:

htt

p:/

/w

ww

.esa.in

t



However:

htt

p:/

/w

iki.eclipse.o

rg

Models can become very large and complex!

How can we handle model size & complexity?



How can we handle model size & complexity?

Views ToolsHierarchicalrefinement

Domains



Model Refinement «Domains»

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

Partitioning thesystem into

«domains» andmodeling each

domain individually massive

complexity reduction



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 & Hierarchy Model for a Financial Institution

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



Top LevelModel

Model Views:

Structure

Security

etc.



Modeling Tools:

• Language Editor• Syntax Check• Composition• Libraries• Administration• Exchange• Graphics• Profiles/Extensions• Views



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

Modeling of IT-Systems




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



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



Modeling of IT-Systems: State of the Art

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

ERD



Modeling of IT-Systems: State of the Art

Why the confusion?

Modeling is an evolving science (Many papers/bookspublished 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)



htt

p:/

/w

ww

.ubiz

oo.d

e

Which are today‘s engineeringmodeling 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



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



A view into the future:h

ttp:/

/w

ww

.j-c

on

sort

ium

.com

Code:• executable• checked• framework

htt

p:/

/m

odel-

based-s

yste

ms-e

ngin

eeri

ng.c

om

Model:• Structure• Behaviour• Constraints

Automatic Code Generation

Mo

de

l-ba

sed

Sy

stem

Eng

ine

erin

g




Engineering Solutions



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?



htt

p:/

/w

ww

.ubiz

oo.d

e

Which are today‘s engineeringmodeling 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

Architecting &Engineering

Business ObjectModelDomain Model

BO

BOBO

BO

Structural Model Behaviour Model

Database Model Deployment Model




Domain-Model,Business Object ModelDomain OntologyUML + Profile Model

Application TaxonomyUML + Profile(s) 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

Example: Domain Model for a Financial Institution




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



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

System-of-Systems[SoS]

Mission [M]1 1

is defined by Mission Owner[MO]

1 1

implements

ConstituentSystem Domain

[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

ModelingLanguage

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 modeling instrument

An excellent fluency in the modelling language and the modeling 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 providerand a service consumer.

They cover the functional interface specifications (functionality anddata), the non-functional properties (timing, security etc.) and in

some cases also the commercial conditions (terms of use,guarantees, liability etc.)



The Future: Contract-Based Systems Engineering

Component,Application

Interface

ServiceContract


Interface

ServiceContract


Interface

ServiceContract


Interface

ServiceContract

Co

mp

osi

tio

n



The Future:Contract-Based Systems Engineering

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



Granularity (Size) of Services

SOA-Servicecoarse-grained

Microservicefine-grained

Business Process

Services

Application A

Orchestration

ModuleX Module

Y

Micro-Service

Service

IT-System

ApplicationC

ApplicationB

ApplicationA



Micro-Services

„The microservice architectural style is anapproach to developing a single application as asuite of small services, each running in its own process andcommunicating with lightweight mechanisms, often an HTTPresource API.“Martin Fowler:http://martinfowler.com/articles/microservices.html

Microservices have emerged from:

• Domain-driven design

• Continuous delivery

• On-demand virtualization

• Infrastructure automation

• Small autonomous teams

• Systems at scale Sam Newman: Building Microservices, 2015




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 & tools

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



«The glamour liesin software»«The glamour liesin software»

htt

ps:/

/cdn

1.lockerd

om

e.c

om

«The future liesin modeling»

«The future liesin modeling»

http

://w

ww

.mortg

ageorb

.com



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



References:

ReferencesNewman15 Sam Newman:

Building Microservices – Designing Fine-Grained Systems

O’Reilly Media Inc., Sebastopol, CA, USA, 2015. ISBN 978-1-491-95035-7Wolff16 Eberhard Wolff:

Microservices – Grundlagen flexibler Softwarearchitekturen

Dpunkt-Verlag, Heidelberg, DE, 2016. ISBN 978-3-86490-313-7Rainey15 Larry B. Rainey (Editor), Andreas Tolk (Editor) :

Modeling and Simulation Support for System of Systems Engineering Applications

John Wiley & Sons, Hoboken, NJ, USA, 2015. ISBN 978-1-118-46031-3





Systems of Systems(SoS)

A11




«Today all interesting products or services

are systems-of-systems»

http

://w

ww

.darp

a.m

il



Systems-of-Systems

SoS

Systems-of-Systems Engineering

SoSE

SoS

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

• Processes• Governance• Failure Handling• …



What is asystem-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. htt

p:/

/w

ww

.acq.o

sd.m

il/se/in

itia

tives/in

it_s

os-s

e.h

tml

§€

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



Systems-of-systems characteristics:





5. Geographic Distribution

[5 Maier criteria, 1998]

SoS Maier Criteria

Emergent Behaviour

htt

p:/

/w

ww

.foto

com

mu

nit

y.d

e

Total = morethan the sum of

its parts

Reason forbuilding an

SoS



Example 1 for emerging properties: „flying“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)

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

htt

p:/

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



stochastic

deterministic

persistent

temporary

unpredictable

predictable

discontinouos

by degree (incremental)

unexpectedexpected

SoS Emergent Behaviour Classification

www.danse-ip.eu



SoS Maier Criteria

Monolithic systems Systems-of-systems:





5. Geographic Distribution

[5 Maier criteria, 1998]

Governance

htt

ps:/

/w

ww

.sh

u.a

c.u

k

Managerial Independence of the Elements

Collaboration!CollaborationContract

• functional• operational• commercial

• legal



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


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

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



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



Emergence

is today an active research challenge

in various fields

htt

p:/

/sery

zon

e.d

evia

nta

rt.c

om




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.



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



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



Essential complexity Accidental Complexity

… is the inherent complexityof the system to be built.

Essential complexity for agiven problem cannot bereduced.

It can only be lessened bysimplifying the requirementsfor the system extension.

… is introduced in additionto the essential complexityby our development activitiesor by constraints from ourenvironment.

This is unnecessary andthreatening complexity!

However, essentialcomplexity can be managedand its negative effects canbe minimized by goodarchitecture

However, essentialcomplexity can be managedand its negative effects canbe minimized by goodarchitecture

Avoiding and eliminatingaccidental complexity is acontinuous task in thedevelopment process – fromrequirements to deployment!

Avoiding and eliminatingaccidental complexity is acontinuous task in thedevelopment process – fromrequirements to deployment!



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



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]

part3b v08 20161123 - tu...

Documents