Transcript st.inf.tu-dresden.de

Future-Proof Software-Systems: Summary
Condensed Summary of Previous Lectures
Lecture Summary of:
22.10.2013
(9 slides)
Future-Proof Software-Systems: Preferred Interaction Style
Summary 22.10.2013
My Preferred Interaction Style
I prefer dialog - rather than monolog:
Please feel free to ask questions at any time
I am available for additional questions or discussions
after each lecture
Lecture Website:
http://st.inf.tu-dresden.de/teaching/fps13
Copyright Frank J. Furrer 2013
2
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Software is one of the most important key success factors
for today‘s and tomorrow‘s products and services
http://myauto24.blogspot.ch/2013/
… etc
 Therefore we need agile, affordable, dependable software – what we call
„future-proof software-systems“
 We – as software engineers – have a high responsibility to produce
„good“ software
 Software production has mutated from an art to an industrial activity –
guided by well-founded architecture principles
Copyright Frank J. Furrer 2013
3
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Software must not only be affordable and dependable – it
must also play its role as a key competitive factor
“It is not the strongest of the species that survives,
nor the most intelligent that survives.
It is the one that is the most adaptable to change.”
Charles Darwin: The Origin of Species (1859)
Key SW-property: Agility
Future-proof software must allow to implement
new requirements in a short time, with
reasonable cost and with adequate quality
Copyright Frank J. Furrer 2013
4
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
„The three devils of systems engineering are:
 Complexity,
 Change,
 Uncertainty”
Copyright Frank J. Furrer 2013
Anonymous
5
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Activity: Steering the
development & evolution
Parts of the system
and their relationsships
Definition:
A future-proof software-system is a structure
that enables the management
of complexity, change and uncertainty
with the least effort, with acceptable risk and with specified quality properties
Providing the best value
for the resources ‘money‘
and ‘time-to-market‘
Assuring the desired properties
(„Fit for Purpose“)
Having an adequate probability for
undesired effects and consequences
Copyright Frank J. Furrer 2013
6
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Future-Proof Software-Systems Coordinates
Agility
System State
at time tn+T
Loss of agility
System State
at time tn+kT
System State
at time tn
Business
Value
Copyright Frank J. Furrer 2013
7
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Future-Proof
Software System
(FPSS))
Structure
Architecture
Manifesto of Future-Proof Software-Systems:
1. „Fit-for-Future“ of an IT-system depends on
its structure and is determined by its
architecture
2. The agility must continuously be improved
3. Future-proof software-systems need strong
architects and a farsighted management
Copyright Frank J. Furrer 2013
8
Future-Proof Software-Systems: Summary 22.10.2013
Functionality of a system or an extension
Summary 22.10.2013
• Functionality and architecture
are (nearly) orthogonal
Fm
• Architectures differ by their
quality properties
Agility
Availability
• Architecture assessment &
evaluation  optimum
Safety
Security
etc.
Agility
F5
F4
F3
F2
F1
Availability
Safety
Security
etc.
A1
A2
A3
A4
A5
A9
An
System & software architecture
Copyright Frank J. Furrer 2013
9
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Future-Proof
Software-System
Structure
enables
forms
Architecture
enforce
Future-Proof
Software-Systems
Engineer
Architecture
Principles
Architecture
Architecture
Principle
Architecture
Principle
Principle
http://berxblog.blogspot.ch
Part 1, Slide 90
Copyright Frank J. Furrer 2013
10
Future-Proof Software-Systems: Summary 5.11.2013
Condensed Summary of Previous Lectures
Lecture Summary of:
5.11.2013
(11 slides)
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
http://thoreau.colonial.net/Students/EricksonHoyt/erosion
Architecture Erosion
Sources of Architecture Erosion:
• technological change
•
•
•
•
progress in software-engineering
new laws & regulations
accumulation of mistakes + shortcuts
sloppy system extensions
… and some more
Continuously
improve the
architecture
Quality Properties:
• Business Value
•Agility
• Security
• Availability
• etc.
Copyright Frank J. Furrer 2013
Time
12
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
www.123rf.com
Architecture Views
Sys Mgmt
Security
Safety
etc.
Stakeholders
Architecture documentation:
Overarching documentation
Views:
Documentation Framework
Copyright Frank J. Furrer 2013
13
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
http://www.skyscrapernews.org
http://www.dimensionsinfo.com/dimensions-of-a-dog-house
How much Architecture is enough?
Project effort (€)
100 %
10 %
G. Fairbanks / ISBN 978-0-9846181-0-1
Architecture work (% total €)
Copyright Frank J. Furrer 2013
14
Future-Proof Software-Systems: Summary 5.11.2013
Legacy Software
Liability
Asset
good:
bad:
•
•
•
•
•
eroded architecture
badly or not documented
obsolete technology (HW & SW)
lost knowledge (people left)
difficult integration context
• invaluable implicit knowledge of the
domain and the business processes
• stable operation (mature)
• good solutions/algorithms
• often: suprisingly good code
Copyright Frank J. Furrer 2013
15
http://www.nzz.ch/aktuell/startseite/hintertuerchen-der-banken-bei-den-gold-etf-1.5956390
http://www.123rf.com/photo_4985178_old-rusting-scrapped-cars-in-a-junk-yard.html
Summary 5.11.2013
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
A1
Architecture Principle A1:
Architecture Layer Isolation
Isolate the architecture layers via standardized, technologyindependent and product-independent mechanisms.
Never implement technical functionality in the applications.
Justification: Any reliance on specific technologies or products
generates dependencies which (massively) reduce agility.
Architecture layers should be able to evolve in their own pace without
impacting the other layers by force
Copyright Frank J. Furrer 2013
16
Future-Proof Software-Systems: Summary 5.11.2013
Business
Architecture
(Business Processes)
(Functionality)
Industry
Standards
Technical
Architecture
(Information & Data)
Technology
Services
Integration
Architecture (Cooperation Mechanisms)
Technology Services
Information
Architecture
Technology Services
Business Process Orchestration
Applications
Architecture
Technology
& Product
Independence
(Technical Infrastructure)
Copyright Frank J. Furrer 2013
17
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
A2
Architecture Principle A2:
Partitioning, Encapsulation & Coupling
1. Partition the functionality and data into encapsulation units
according to their coherence and cohesion (thus minimizing
dependencies)
2. Isolate the encapsulation units by strictly hiding any internal
details. Allow access to functionality and data only through stable,
well specified interfaces governed by contracts
3. Minimize the impact of dependencies between the encapsulation
units by using adequate coupling mechanisms
Justification: These 3 principles minimize the number and the
impact of dependencies. The resulting system therefore offers the
least resistance to change, because any change affects the smallest
possible number of system elements. A low resistance to change
corresponds to high agility.
Copyright Frank J. Furrer 2013
18
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
IF
IF
F
F
F
F
IF
IF
F
F
IF
IF
F
F
F
IF
IF
IF
IF
F
IF
IF
IF
IF
F
F
IF
F
F
F
F
IF
IF
IF
F
F
Partition,
encapsulate,
and couple as loosely as possbile
IF
IF
F
F
F
F
IF
IF
IF
F
F
IF
F
F
F
IF
F
IF
F
F
F
F
F
F
F
IF
F
IF
F
F
F
IF
F
F
F
F
IF
Copyright Frank J. Furrer 2013
F
IF
19
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Q1: Boundary between Architecture and Design?
Q2: Granularity of the Encapsulation Units?
Copyright Frank J. Furrer 2013
20
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Q: Boundary between Architecture and Design?
Architecture
System
-ofSystems
Relationsship:
Contract
System
Part: Container for
functionality & data
Technology
Dependence
Component
Application
Design
Relationsship:
Web-Service
Part: EJB,
Java Class
Module
Copyright Frank J. Furrer 2013
21
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Q: Granularity of
the Encapsulation
Units?
loose
System-ofSystems
System
Application
Module
Coupling
Component
tight
Encapsulation
Copyright Frank J. Furrer 2013
22
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Continuation:
A2
Architecture Principle A2:
Partitioning, Encapsulation & Coupling
How do we:
• partition
• encapsulate
• couple
a system?
Part 2, Slide 41
Copyright Frank J. Furrer 2013
23
Future-Proof Software-Systems: Summary 5.11.2013
Condensed Summary of Previous Lectures
Lecture Summary of:
19.11.2013
(11 slides)
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Partitioning, Encapsulation and Coupling
„The three devils of systems engineering are:
 Complexity,
 Change,
 Uncertainty”
Anonymous
Therefore, good engineering is:
1. Reduce complexity as much as possible (Simplify)
2. Limit the effects of change
3. Contain the risks of uncertainty
The most powerful concepts to do so are:
1. Partitioning of the system ( smaller subsystems)
3 main rules:
• Functional
coherence
• Data coherence
• Cohesion
2. Encapsulation ( hide the inner workings)
3. Coupling ( stable interfaces and as loose as possible)
Copyright Frank J. Furrer 2013
25
Future-Proof Software-Systems: Partitioning, Encapsulation & Coupling
Example: Domain Model for a FinancialAInstitution
domain is
Settlement and Clearing
(SCL)
Custody
(CDY)
Corporate Actions
(COA)
Customer & Partner
(CUS)
Product Control
(PRC)
Single Accounts
(SAC)
1: Partners & Persons
Credits and Syndication
(CRS)
Trading
(TRA)
4: Cash and Asset Operations
Wealth Management &
Advisory
(WMA)
3: Trading and Markets
2: Finance, Investment & Sales
(RRL)
Payments
(PAY)
(FAC)
Regulatory, Risk and Liquidity
Financial Accounting
6: Accounting, Controlling and Reporting
a container for all
5: Communications & Collaboration
the functionality and data
Client Communication (CHA)
(SSI)
relatedStreet
toSideaInterfaces
specific
business
– in Research
this &case
Business Partner Applications (BPA)
Enterprise Content Management (ECM) activity
Financial Instruments,
Market Datathe
(FIN)
trading activities
7: Enterprise Common Services
Logistics
(LOG)
Accounting Control
(AOC)
Copyright Frank J. Furrer 2013/14
Basic Facilities
(BAS)
26
Future-Proof Software-Systems: Partitioning, Encapsulation & Coupling
Domain-Driven Architecture and Design
Business People:
http://www.directortom.com
Business
Domain
Concepts &
Terminology
• Finance
• Automotive
• Aerospace
• Medical
•…
Requirements
Requirements Engineering
Software People:
Software
Engineering
Concepts &
Terminology
• Architects
• Designer
• Programmer
• Tester
•…
Copyright Frank J. Furrer 2013
Specifications
27
http://www.hdwpapers.com
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Redundancy in an IT-system is –
in most cases
– poison
for agility and for many of the system‘s quality properties
Functional redundancy: The same or similar function is implemented
several times in the IT-system
Data redundancy: Same elements of data are stored in different places
Interface redundancy: Interface functionality is implemented in more
than one interface or overlaps interfaces
Code redundancy: The same code-sequence is used in several programs
Specification redundancy: The same or similar requirement is stated
in different specifications
etc.
Redundancy sneaks into the system via:
• Requirements
• Specification
• Implementation (Coding)
• Maintenance
Copyright Frank J. Furrer 2013
28
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Manage redundancy !  Managed redundancy
Managed
redundancy
Known or
wanted
Unmanaged
redundancy
Yes
(if valid reason)
NO!
NO!
NO!
Unknown or
unwanted
There is exactly one source for
the functionality and for
the data (both during
development time and
during run-time)
NO WAY !
Avoid and eliminate
Identify (search) and
eliminate
NO WAY !
Avoid and eliminate
All redundant copies must be
materially and time-wise
synchronized
Copyright Frank J. Furrer 2013
29
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
System
Part
A
Interoperability is the capability to exchange
and make use of information and control
Applications Interoperability
Semantic Interoperability
Collaborating applications must
share a common conceptual
model
Meaning of the data
System
Part
B
Instruments:
• Conceptual Models
•Domain Models
• Ontologies
Instruments:
• Controlled Vocabularies
•Taxonomies
Syntactic Interoperability
Structure of the data
Instruments:
• Syntax specification
languages
Technical Interoperability
Interaction infrastructure
Instruments:
• Network standards
• Internet standards
Copyright Frank J. Furrer 2013
30
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Q1: Are there other partitioning rules?
Q2: What is needed for full semantics?
Q3: How do I teach partitioning to my little ones?
Copyright Frank J. Furrer 2013
31
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Q1: Are there other partitioning rules?
1) Functional Coherence
YES ! – under special circumstances
2) Data/Information Coherence
3) Functional and Data &
Information Cohesion
• High performance (HPC) 
standard performance
• Low rate of change  high
rate of change
• Weak technology
dependency  strong
technology dependency
• Low criticality  high
criticality
Copyright Frank J. Furrer 2013
32
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Q1: Are there other partitioning rules?
Hierarchical Partitioning
(Dominant Quality Property)
Very High
Performance
Level 1
http://www.brickbybrickinvesting.comm
Level 2
HPC
Standard
(High Performance
Computing)
(Standard Performance
Computing)
Reduced
Architecture
Principles
Full
Architecture
Principles
Safety
Safety-critical
Non safetycritical
Full
Architecture
Principles
Full
Architecture
Principles
Copyright Frank J. Furrer 2013
33
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Q2: What is needed for full semantics?
Applications Interoperability
Semantic Interoperability
Collaborating
applications
must share a
common
conceptual model
Applications Interoperability
Definition of
the concepts
and their
relationships
Ontology
Syntactic Interoperability
Technical Interoperability
Copyright Frank J. Furrer 2013
34
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Q2: What is needed for full semantics?
Applications Interoperability
Collaborating
applications
must share a
common
conceptual model
Savings Account
Savings Account
Semantic Interoperability
Applications Interoperability
Definition of
the concepts
and their
relationships
Ontology
Syntactic Interoperability
Technical Interoperability
Copyright Frank J. Furrer 2013
35
Future-Proof Software-Systems: Summary 19.11.2013
Q3: How do I teach partitioning to my
little ones?
http://www.hdwallpapers.in
Summary 19.11.2013
Partitioning Rule = Colour
Copyright Frank J. Furrer 2013
36
Future-Proof Software-Systems: Summary 19.11.2013
Summary 19.11.2013
Continuation:
A5
Architecture Principle A5:
Common Functions
Part 2A, Slide 122
(A5: Common Functions)
Copyright Frank J. Furrer 2013
37
Future-Proof Software-Systems: Summary 3.12.2013
Condensed Summary of Previous Lectures
Lecture Summary of:
03.12.2013
(11 slides)
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
Common Functions & Software Infrastructure
Application
Application
Application
Application
Application
Application
Access
(Service)
Common
Common
Tables
Tables
managed
copy
Common
Data
synchronized
in time and
content
access
(Service)
managed
copy
Common
Common
Functions
Common
Functions
Functions
Enterprise-wide common software infrastructure
Copyright Frank J. Furrer 2013
39
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
Reference Architectures, Architecture Frameworks, Architecture Patterns
Reference Architecture:
Architecture Pattern:
A reference architecture
provides a template solution
for an architecture for a
particular application domain
An architectural pattern is
a concept that solves and
delineates some essential
cohesive elements of a
software architecture
- such as financial systems,
automotive, aerospace etc.
http://en.wikipedia.org/wiki/
Architectural_pattern
Architecture Framework:
An architecture framework
establishes a common practice
for creating, interpreting,
analyzing and using
architecture descriptions within
a particular application domain
[ISO/IEC/IEEE 42010]
 highly valuable
software/system architecture
knowledge in proven & easily
accessible form
Copyright Frank J. Furrer 2013
40
Future-Proof Software-Systems: Summary 3.12.2013
Reference Architectures
Architecture Frameworks
Architecture Patterns
Apply & enforce
Future-Proof SoftwareSystems Engineer
Copyright Frank J. Furrer 2013
41
http://biscicol.blogspot.ch/2011/06/biscicol-core-software-architecture.html
Summary 3.12.2013
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
Types of Reuse
Unmodified (1:1) reuse
Parametrization
Reuse
Black Box
Business Rules
True, value-generating Reuse
Reuse
Grey Box
Limited modified reuse
(Specific changes  25 %)
Not reuse  unmanaged redundancy
Reuse
White Box
Significantly modified
(Specific changes  25 %)
Not reuse  unmanaged redundancy
Copyright Frank J. Furrer 2013
42
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
Reuse & Parametrization
Parametrization
Black Box
Business Rules
Change
Black Box
Loaded/Initialized
at Run-Time
Black Box
Parametrization
Black Box
Business Rules
Parametrization
Distributed/Updated
by Configuration
Management System
Black Box
Copyright Frank J. Furrer 2013
Business Rules
43
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
A STANDARD is:
• a formal, established norm for (technical) systems
• a document which establishes uniform (engineering or technical) criteria,
principles, methods, processes and practices
www.iso.org
www.ietf.org
www.omg.org
International Standards Organizations
CS
Business
Object
Model
V1.1/2009
Company
Standards
Copyright Frank J. Furrer 2013
44
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
1715-1789
Napoleonic
Empire
(ca. 1810)
Copyright Frank J. Furrer 2013
45
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
Q1: How many versions in production?
Copyright Frank J. Furrer 2013
46
Future-Proof Software-Systems: Summary 3.12.2013
Grey Box Modification  Divergence (= Unmanaged Redundancy)
 3 versions in production
Grey Box
Change
Change
Change
Modification A
Grey
Box
Modification
B
Grey Box
Change
time
…
Black
Box
V5
Black
Box
V6
…
Black
Box
V7
Modification C
Grey Box
Modification
D
Grey
Box
unmodified reuse
Copyright Frank J. Furrer 2013
47
Future-Proof Software-Systems: Summary 3.12.2013
Summary 3.12.2013
A9: Information Architecture
A10: Formal Modeling
A11: Systems-of-Systems (SoS)
A12: Complexity and Simplification
Additional Topics:
 Software Product Lines
 Resilient Software Systems
 Cloud Computing Architecture
 Legacy System Migration/Modernization
Part 2, Slide 40
Copyright Frank J. Furrer 2013
48
Future-Proof Software-Systems: Summary 17.12.2013
Condensed Summary of Previous Lectures
Lecture Summary of:
17.12.2013
(11 slides)
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
Data/Information Architecture
Classification of data/information
Structure of data/information
Modeling of information
Information
Architecture
Quality assurance of data/information
Protection of data/information
Modeling of data
Deployment of data/information
Data
Architecture
Disaster recovery of data/information
Copyright Frank J. Furrer 2013
50
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
Data/Information Architecture
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://www.ove.uk.com
http://www.ormutual.com
Enterprise data/information
architecture
Vehicle data/information
Architecture
[Embedded Systems]
… unfortunately NO!
Copyright Frank J. Furrer 2013
51
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
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“)
Copyright Frank J. Furrer 2013
52
Future-Proof Software-Systems: Summary 17.12.2013
What is different in embedded systems data & information?
http://thorntoncenter.net
Summary 17.12.2013
Data items have
Time !
timing relationships
between them
… sometimes very
demanding and stringent!
Copyright Frank J. Furrer 2013
53
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
Data Timing & Validation
Data in embedded systems must often be validated before use
Wheel rotation speed sensor
Acquisition
Interval
Brake Control
Validation/Correction
Sensor
Sensor
Sensor
Sensor
http://www.cdxetextbook.com/brakes
FL
BR
FR
BL
Validation: Assure consistency in value and in time
Computing
Intervall
Impact
Interval
Time
ms]
Validation step: Processing of data items before using them in the
computing of actions
Methods: „cleaning“ & plausibility algorithms (simplest: -check)
Copyright Frank J. Furrer 2013
54
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
“All models are wrong – but some are useful“
http://museumvictoria.com.au/treasures
 Models simplify the real world
 Models abstract the real world
 Models focus the real world
Why wrong?
Why useful?
Copyright Frank J. Furrer 2013
55
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
Modeling of IT-Systems: State of the Art
Contracts
Domain
Model
Frameworks
UML
Simulink
Taxonomy
Models
SysML
Business
Object
Directed Hypergraph
Model
Timed Automata
http://www.ubizoo.de
Petri Net
State Machines
Ontology OWL
model@runtime
Copyright Frank J. Furrer 2013
56
Future-Proof Software-Systems: Summary 17.12.2013
Summary 17.12.2013
Modeling of IT-Systems: Engineering Solutions
BO
BO
BO
Domain Model
Structural Model
BO
Business Object
Model
Behaviour Model
Domain Ontology
UML + Profile Model
Application Taxonomy
UML + Profile Model
[Interface Contract Model]
Data Dictionary
ERD-Model
Database Model
Copyright Frank J. Furrer 2013
57
Future-Proof Software-Systems: Summary 17.12.2013
Modeling of IT-Systems: Modeling Instruments
UML
Diagram
Summary 17.12.2013
Structure
Diagram
Class
Diagram
http://www.ubizoo.de
Profile
Diagram
Component
Diagram
Composite
Structure
Diagram
Behaviour
Diagram
Object
Diagram
Deployment
Diagram
Activity
Diagram
Package
Diagram
Sequence
Diagram
Communication
Diagram
Copyright Frank J. Furrer 2013
Interaction
Diagram
Interaction
Overview
Diagram
Use Case
Diagram
State
Machine
Diagram
Timing
Diagram
58
Future-Proof Software-Systems: Summary 17.12.2013
Modeling of IT-Systems: Engineering Solutions
The Future: Contract-Based Systems Engineering
Summary 17.12.2013
Service
Contract
Composition
Interface
Component,
Application
Service
Contract
Service
Contract
Service
Contract
Interface
Interface
Interface
Component,
Application
Component,
Application
Component,
Application
Copyright Frank J. Furrer 2013
59
Future-Proof Software-Systems: Summary 3.12.2013
Summary 17.12.2013
Correction: SoS UML Class Diagram
Question: When will we see job
advertisements for „modeling
engineers“?
Copyright Frank J. Furrer 2013
60
Future-Proof Software-Systems: Summary 17.12.2013
Environment
1
1..*
interacts
1
Users
1..*
is defined by
System-of-Systems
[SoS]
1
1
benefit
1
1..*
1
Mission Owner
[MO]
implements
1
1..*
Coordinator
[CE]
1
Mission [M]
governs
1
1..*
1..*
Cooperation
Domain
[CD]
interconnects
1..*
1..*
Constituent
System Domain
[CSD]
is delineated by
Governance
[Gov]
1
1..*
1
enforces
1
1
1
Cooperation
Standards
[CS]
1
Change
Management
Ownership
Budget
Authority
1..*
Cooperation
Mechanism [CE]
1..*
Cooperation
Contract [CC]
1..*
Process
[Proc]
1..*
Constituent
System
[CS]
1..*
Global
(synchronized)
Time
1
1..*
delivers
utilizes
1..*
State of the Art Example:
SoS Conceptual Model:
Structure (High Level)
Summary 17.12.2013
Capability [C]
1..*
builds
1..*
Function [F]
1..*
1
Function Owner
[FO]
manages
Future-Proof Software-Systems: Summary 3.12.2013
Summary 17.12.2013
http://luciano63.hubpages.com/hub/Sculptural-car-design
Question: When will we see job advertisements for „SW modelling engineers“?
Answer:
• UML-Skills: today !
• Simulink, Modelica, … : today !
• Ontological engineering:
tomorrow
• Advanced modelling mechanisms:
3 … 5 years
Copyright Frank J. Furrer 2013
62
Future-Proof Software-Systems: Summary 3.12.2013
Summary 17.12.2013
A11: Systems-of-Systems (SoS)
A12: Complexity and Simplification
Additional Topics:
 Legacy System Migration/Modernization
 Resilient Software Systems
 Software Product Lines
 Cloud Computing Architecture
Part 2, Slide 126
Copyright Frank J. Furrer 2013
63
Future-Proof Software-Systems: Summary 21.01.2014
Condensed Summary of Previous Lectures
Lecture Summary of:
21.01.2014
[13 slides]
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
# of stakeholders (users, providers, …)
108
What is a system-of-systems ?
(SoS)
106
104
102
Monolithic
System
103
106
MegaSystem
109
SystemofSystems
1012
size (SLOC‘s)
Monolithic systems  Systems-of-systems:
1. Operational Independence of the Elements
Governance
2. Managerial
ofof
the
Elements
ManagerialIndependence
Independence
the
Elements
3. Evolutionary Development
4. Emergent
EmergentBehavior
Behaviour
5. Geographic Distribution
Copyright Frank J. Furrer 2013
Total = more than
the sum of its parts
[5 Maier criteria, 1998]
65
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Type of SoS
SoS (Systems-of-systems) Classification
Description
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 SoS have recognized objectives, a designated manager, and resources for
Acknowledged
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
In collaborative SoS the constituent systems interact more or less voluntarily to fulfill
Collaborative
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 SoS lack a central management authority and a centrally agreed upon purpose
Virtual
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
Copyright Frank J. Furrer 2013
66
http://www.acq.osd.mil/se/initiatives/init_sos-se.html
Directed
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Systems-of-Systems Engineering (SoSE)

SoS
Mission
CS
A
• Reqs
• Constraints
CS
B
CS
D

1) Transparent
architecture
CS
R
2) Explicit dependencies
3) Complete contracts
CS
G
CS
E
4) Risk mitigation
CS
N
5) Monitoring and early
response
http://www.yellowjacketdisposal.com
SoS

CS
F
CS
H
CS
I
CS
L
Copyright Frank J. Furrer 2013
67
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Complexity = (IT-) Risk
“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“
bad
good
• Complexity makes large,
useful systems possible
• It is the single most important
reason for disasters in IT
• It forces us to develop science
for dealing with complexity
• It makes understanding,
explaining and evolving IT-systems
very hard
• it is a highly interesting and
fruitful area of research
• It may lead to unpredictable
(= emergent) behaviour
Complexity must be managed !
•
•
•
Identify it
Understand it
Avoid and reduce it as much as possible
Copyright Frank J. Furrer 2013
68
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
• Req A
• Req B
•…
• Req Y
Architecture Topic Map
http://de.123rf.com
Functionality
Architecture-Quality:
• Agility
• Availability
• Security
• Safety
• Performance
•…
Future-Proof Software-System Engineer
Beautiful
Architecture
Requirements
Architecture-Greatness:
• Simplicity
• Elegance
Copyright Frank J. Furrer 2013
69
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Legacy system modernization strategies:
Type of Migration
Current State
Target State
Replacing
Operational software. Cost, time
and risk for a migration to high
Software has completely been
rewritten, starting from the initial
requirements
Operational software.
Architecture paradigm has
changed
Software runs under the new
architecture paradigm

Completely new
development starting
from systems
requirements
Re-Architecting

Transforming to new
architecture paradigm
(Considerable functional
change)
Re-Engineering

Transforming to new
technology base, e.g.
new infrastructure or
software technology
(limited functional
change)
Re-Factoring

Improving existing code
(no functionality change)
Reverse Engineering

No or insufficient
information (code + doc)
[e.g. monolithic architecture 
service-oriented architecture]
Operational code running on an
outdated execution platform or
using an obsolete software
technology
Code runs on the modern
execution platform or uses
modern software technology
Operational code, deficiencies in
the program implementation
Improved code (quality criteria)
Operational code, massive lack
of documentation, of knowledge
and of source code
System is sufficiently understood
and documented to start
migration
Copyright Frank J. Furrer 2013
70
Future-Proof Software-Systems: Summary 21.01.2014
https://soundcloud.com
Summary 21.01.2014
Resilience:
Environment
Crash
Software
System
Degraded operation
t
t
Malfunction
Fault
http://kanto.stripes.com
t
Copyright Frank J. Furrer 2013
71
Applications Architecture
Information Architecture
Integration Architecture
Copyright Frank J. Furrer 2013
A12 – Simplification
…
A10 –Performance
Formal Modelling
Principles
A11 – SoS
A9 – Inf Arch
Integrity
Safety
Security
etc.
Performance
Business Architecture
A8Integrity
– Industry
Standards
Principles
A7 – Reuse
Principles
A6Safety
– Ref Architectures
A5 – Com F
Security Principles
A4 – Interoperability
Technical Architecture
A3 – Redundancy
Vertical
architecture
layers
Horizontal
architecture
layers
Availability
Summary 21.01.2014
A1 – Layer Isolation
Availability Principles
A2 – Partitioning
Future-Proof Software-Systems: Summary 21.01.2014
How can we build resilient systems ?
72
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Product Line Definition:
A software product line is a set of software-intensive systems
sharing a common, managed set of features,
that satisfy the specific needs of a particular market or mission
[Clements02]
http://www.auto-motor-und-sport.de/
and that are developed from a common set of core assets
Example:
Product line in
automotive
development
Copyright Frank J. Furrer 2013
73
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Economics of Product Line Development:
Single
systems
approach
Great advantage in
cost, time-to-market
and quality
Total
effort
[€, t]
Product
line
approach
Initial effort:
● Prod line def
● Variability
● ↑ Quality
1
2
3
4
5
Copyright Frank J. Furrer 2013
6
…
# of different
systems built
74
Future-Proof Software-Systems: Summary 21.01.2014
End-User
Summary 21.01.2014
Cloud Computing:
Application
Software as a Service
SaaS
Platform as a Service
PaaS
Infrastructure as a Service
IaaS
Cloud =
Execution and
Delivery
Infrastructure
Developper
System Manager
„pay as you go“
Cloud
service
Copyright Frank J. Furrer 2013
provider
Cloud
service
consumer
75
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Cloud Computing Risks:
http://pssiusa.wordpress.com
Loss
of
direct
control
compensate by:
SaaS
Security,
Dependability,
Resilience,
…
PaaS
IaaS
Contract
SLA: Service
Level Agreement
• functional
• operational
• commercial
• legal
Cloud Service Level Agreements (Cloud-SLA)
Copyright Frank J. Furrer 2013
76
Future-Proof Software-Systems: Summary 21.01.2014
Summary 21.01.2014
Future-Proof
Software-Systems
A1
A1
A1
1 Architecture
Architecture
1Principle
A11:
Architecture
1Principle
A11:
Principle A11:
Scientific & Technical Focus
Human Focus
Part 3, Slide 1
Copyright Frank J. Furrer 2013
77