Copyright Frank J. Furrer 20132 I prefer dialog - rather than
monolog: Please feel free to ask questions at any time Future-Proof
Software-Systems: Preferred Interaction Style I am available for
additional questions or discussions after each lecture My Preferred
Interaction Style Summary 22.10.2013 Lecture Website:
http://st.inf.tu-dresden.de/teaching/fps13
Slide 3
Copyright Frank J. Furrer 20133 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 Software is one of the most
important key success factors for todays and tomorrows 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
Slide 4
Copyright Frank J. Furrer 20134 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 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) Software must not only be affordable
and dependable it must also play its role as a key competitive
factor Future-proof software must allow to implement new
requirements in a short time, with reasonable cost and with
adequate quality Key SW-property: Agility
Slide 5
Copyright Frank J. Furrer 20135 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 The three devils of systems
engineering are: Complexity, Change, Uncertainty Anonymous
Slide 6
Copyright Frank J. Furrer 20136 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 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 Parts of the
system and their relationsships Activity: Steering the development
& evolution Providing the best value for the resources money
and time-to-market Having an adequate probability for undesired
effects and consequences Assuring the desired properties (Fit for
Purpose)
Slide 7
Copyright Frank J. Furrer 20137 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 Business Value Agility
Future-Proof Software-Systems Coordinates System State at time t n
System State at time t n+T Project P n Project P n+1 System State
at time t n+kT Loss of agility
Slide 8
Copyright Frank J. Furrer 20138 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
Slide 9
Copyright Frank J. Furrer 20139 Future-Proof Software-Systems:
Summary 22.10.2013 Summary 22.10.2013 Safety Security Agility
Availability etc. Safety Security Agility Availability etc.
Functionality of a system or an extension F1F1 F2F2 F5F5 F4F4 FmFm
F3F3 A1A1 System & software architecture AnAn A4A4 A5A5 A3A3
A2A2 A9A9 Functionality and architecture are (nearly) orthogonal
Architectures differ by their quality properties Architecture
assessment & evaluation optimum
Slide 10
Architecture Principles enforce Copyright Frank J. Furrer 2013
10 Future-Proof Software-Systems: Summary 22.10.2013 Summary
22.10.2013 Future-Proof Software-System Structure enables
Architecture forms http://berxblog.blogspot.ch Future-Proof
Software-Systems Engineer Architecture Principle Architecture
Principle Architecture Principle Part 1, Slide 90
Copyright Frank J. Furrer 201312 Future-Proof Software-Systems:
Summary 5.11.2013 Architecture Erosion
http://thoreau.colonial.net/Students/EricksonHoyt/erosion Quality
Properties : Business Value Agility Security Availability etc. Time
Continuously improve the architecture Summary 5.11.2013 Sources of
Architecture Erosion: technological change progress in
software-engineering new laws & regulations accumulation of
mistakes + shortcuts sloppy system extensions and some more
Slide 13
Copyright Frank J. Furrer 201313 Future-Proof Software-Systems:
Summary 5.11.2013 Architecture Views Stakeholders www.123rf.com Sys
Mgmt Security Safety etc. Architecture documentation: Documentation
Framework Views: Overarching documentation Summary 5.11.2013
Slide 14
Copyright Frank J. Furrer 201314 Future-Proof Software-Systems:
Summary 5.11.2013 How much Architecture is enough? Architecture
work (% total ) Project effort () 10 % 100 %
http://www.skyscrapernews.org
http://www.dimensionsinfo.com/dimensions-of-a-dog-house Summary
5.11.2013 G. Fairbanks / ISBN 978-0-9846181-0-1
Slide 15
Copyright Frank J. Furrer 201315 Future-Proof Software-Systems:
Summary 5.11.2013 Legacy Software
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
LiabilityAsset good : invaluable implicit knowledge of the domain
and the business processes stable operation (mature) good
solutions/algorithms often: suprisingly good code bad : eroded
architecture badly or not documented obsolete technology (HW &
SW) lost knowledge (people left) difficult integration context
Summary 5.11.2013
Slide 16
Copyright Frank J. Furrer 201316 Future-Proof Software-Systems:
Summary 5.11.2013 Architecture Principle A1: Architecture Layer
Isolation Isolate the architecture layers via standardized,
technology- independent and product-independent mechanisms. Never
implement technical functionality in the applications. Architecture
Principle A1: Architecture Layer Isolation Isolate the architecture
layers via standardized, technology- independent and
product-independent mechanisms. Never implement technical
functionality in the applications. A1 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 Summary 5.11.2013
Slide 17
Industry Standards Technology & Product Independence
Copyright Frank J. Furrer 201317 Future-Proof Software-Systems:
Summary 5.11.2013 Technical Architecture (Technical Infrastructure)
Integration Architecture (Cooperation Mechanisms) Applications
Architecture (Functionality) Business Architecture (Business
Processes) Information Architecture (Information & Data)
Business Process Orchestration Technology Services
Slide 18
Copyright Frank J. Furrer 201318 Future-Proof Software-Systems:
Summary 5.11.2013 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
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 A2 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. Summary 5.11.2013
Slide 19
Copyright Frank J. Furrer 201319 Future-Proof Software-Systems:
Summary 5.11.2013 F F F F F F F F FF F F F F F F F F F F F F F IF
Partition, encapsulate, and couple as loosely as possbile Summary
5.11.2013
Slide 20
Copyright Frank J. Furrer 201320 Future-Proof Software-Systems:
Summary 5.11.2013 Summary 5.11.2013 Q1 : Boundary between
Architecture and Design? Q2 : Granularity of the Encapsulation
Units?
Slide 21
Copyright Frank J. Furrer 201321 Future-Proof Software-Systems:
Summary 5.11.2013 Summary 5.11.2013 Q : Boundary between
Architecture and Design? Module Component Application System -of-
Systems Technology Dependence Design Architecture Part : Container
for functionality & data Relationsship : Contract Part : EJB,
Java Class Relationsship : Web-Service
Slide 22
Copyright Frank J. Furrer 201322 Future-Proof Software-Systems:
Summary 5.11.2013 Summary 5.11.2013 Q : Granularity of the
Encapsulation Units? System-of- Systems System Application
Component Module Encapsulation Coupling tight loose
Slide 23
Copyright Frank J. Furrer 201323 Future-Proof Software-Systems:
Summary 5.11.2013 Summary 5.11.2013 Part 2, Slide 41 Continuation:
Architecture Principle A2: Partitioning, Encapsulation &
Coupling Architecture Principle A2: Partitioning, Encapsulation
& Coupling A2 How do we: partition encapsulate couple a
system?
Copyright Frank J. Furrer 201325 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 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) 2. Encapsulation (
hide the inner workings) 3. Coupling ( stable interfaces and as
loose as possible) 3 main rules: Functional coherence Data
coherence Cohesion Partitioning, Encapsulation and Coupling
Slide 26
Copyright Frank J. Furrer 2013/1426 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: Partners & Persons 2: Finance, Investment & Sales
3: Trading and Markets 4: Cash and Asset Operations Customer &
Partner (CUS) Wealth Management & Advisory (WMA) Credits and
Syndication (CRS) 6: Accounting, Controlling and Reporting
Financial Accounting (FAC) Regulatory, Risk and Liquidity (RRL)
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 Future-Proof
Software-Systems: Partitioning, Encapsulation & Coupling
Example: Domain Model for a Financial Institution A domain is a
container for all the functionality and data related to a specific
business activity in this case the trading activities
Slide 27
Copyright Frank J. Furrer 201327 Future-Proof Software-Systems:
Partitioning, Encapsulation & Coupling Domain-Driven
Architecture and Design Business People: Finance Automotive
Aerospace Medical Requirements Software People: Architects Designer
Programmer Tester Specifications Requirements Engineering Business
Domain Concepts & Terminology Software Engineering Concepts
& Terminology http://www.directortom.com
Slide 28
Copyright Frank J. Furrer 201328 Future-Proof Software-Systems:
Summary 19.11.2013 Redundancy in an IT-system is in most cases
poison for agility and for many of the systems 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. Summary
19.11.2013 http://www.hdwpapers.com Redundancy sneaks into the
system via: Requirements Specification Implementation (Coding)
Maintenance
Slide 29
Copyright Frank J. Furrer 201329 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Manage redundancy ! Managed
redundancy There is exactly one source for the functionality and
for the data (both during development time and during run-time) All
redundant copies must be materially and time-wise synchronized NO
WAY ! Avoid and eliminate NO WAY ! Avoid and eliminate Identify
(search) and eliminate
Slide 30
Copyright Frank J. Furrer 201330 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 System Part A System Part B
Interoperability is the capability to exchange and make use of
information and control Technical Interoperability Interaction
infrastructure Syntactic Interoperability Structure of the data
Semantic Interoperability Meaning of the data Applications
Interoperability Collaborating applications must share a common
conceptual model Instruments: Conceptual Models Domain Models
Ontologies Instruments: Controlled Vocabularies Taxonomies
Instruments: Syntax specification languages Instruments: Network
standards Internet standards
Slide 31
Copyright Frank J. Furrer 201331 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?
Slide 32
Copyright Frank J. Furrer 201332 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Q1 : Are there other
partitioning rules? 1)Functional Coherence 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 YES ! under special
circumstances
Slide 33
Copyright Frank J. Furrer 201333 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Q1 : Are there other
partitioning rules? Hierarchical Partitioning (Dominant Quality
Property) Level 1 Very High Performance Safety Level 2 HPC (High
Performance Computing) Standard (Standard Performance Computing)
Safety-critical Non safety- critical Reduced Architecture
Principles Full Architecture Principles Full Architecture
Principles Full Architecture Principles
http://www.brickbybrickinvesting.comm
Slide 34
Copyright Frank J. Furrer 201334 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Q2 : What is needed for full
semantics? Technical Interoperability Syntactic Interoperability
Semantic Interoperability Definition of the concepts and their
relationships Applications Interoperability Ontology Applications
Interoperability Collaborating applications must share a common
conceptual model
Slide 35
Copyright Frank J. Furrer 201335 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Q2 : What is needed for full
semantics? Technical Interoperability Syntactic Interoperability
Semantic Interoperability Definition of the concepts and their
relationships Applications Interoperability Ontology Applications
Interoperability Collaborating applications must share a common
conceptual model Savings Account
Slide 36
Copyright Frank J. Furrer 201336 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Q3 : How do I teach
partitioning to my little ones? http://www.hdwallpapers.in
Partitioning Rule = Colour
Slide 37
Copyright Frank J. Furrer 201337 Future-Proof Software-Systems:
Summary 19.11.2013 Summary 19.11.2013 Part 2A, Slide 122 (A5:
Common Functions) Continuation: Architecture Principle A5: Common
Functions Architecture Principle A5: Common Functions A5
Copyright Frank J. Furrer 201339 Future-Proof Software-Systems:
Summary 3.12.2013 Common Functions & Software Infrastructure
Enterprise-wide common software infrastructure managed copy managed
copy managed copy Access (Service) access (Service) access
(Service) Common Tables Common Data Common Functions Application
synchronized in time and content Summary 3.12.2013
Slide 40
highly valuable software/system architecture knowledge in
proven & easily accessible form Copyright Frank J. Furrer
201340 Future-Proof Software-Systems: Summary 3.12.2013 Reference
Architecture: A reference architecture provides a template solution
for an architecture for a particular application domain - such as
financial systems, automotive, aerospace etc. 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] Architecture Pattern: An architectural pattern is a concept
that solves and delineates some essential cohesive elements of a
software architecture http://en.wikipedia.org/wiki/
Architectural_pattern Reference Architectures, Architecture
Frameworks, Architecture Patterns Summary 3.12.2013
Slide 41
Copyright Frank J. Furrer 201341 Future-Proof Software-Systems:
Summary 3.12.2013 Reference Architectures Architecture Frameworks
Architecture Patterns Future-Proof Software- Systems Engineer Learn
& understand Apply & enforce
http://biscicol.blogspot.ch/2011/06/biscicol-core-software-architecture.html
Summary 3.12.2013
Slide 42
Copyright Frank J. Furrer 201342 Future-Proof Software-Systems:
Summary 3.12.2013 Types of Reuse Black Box Reuse Unmodified (1:1)
reuse Grey Box Reuse Limited modified reuse (Specific changes 25 %)
White Box Reuse Significantly modified (Specific changes 25 %)
Parametrization Business Rules True, value-generating Reuse Not
reuse unmanaged redundancy Summary 3.12.2013
Slide 43
Copyright Frank J. Furrer 201343 Future-Proof Software-Systems:
Summary 3.12.2013 Reuse & Parametrization Black Box
Parametrization Business Rules Parametrization Business Rules
Parametrization Business Rules Change Distributed/Updated by
Configuration Management System Loaded/Initialized at Run-Time
Summary 3.12.2013
Slide 44
Copyright Frank J. Furrer 201344 Future-Proof Software-Systems:
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.ietf.orgwww.omg.org www.iso.org International
Standards Organizations CS Business Object Model V1.1/2009 Company
Standards Summary 3.12.2013
Slide 45
Copyright Frank J. Furrer 201345 Future-Proof Software-Systems:
Summary 3.12.2013 Summary 3.12.2013 1715-1789 Napoleonic Empire
(ca. 1810) The power of standards
Slide 46
Copyright Frank J. Furrer 201346 Future-Proof Software-Systems:
Summary 3.12.2013 Summary 3.12.2013 Q1 : How many versions in
production?
Slide 47
Copyright Frank J. Furrer 201347 Future-Proof Software-Systems:
Summary 3.12.2013 Grey Box Modification Divergence (= Unmanaged
Redundancy) Grey Box Modification A Grey Box Modifi- cation B Grey
Box Modifi- cation C Grey Box Modifi- cation D Change time Black
Box Change V5 Black Box Change V6 Black Box Change V7 unmodified
reuse 3 versions in production
Slide 48
Copyright Frank J. Furrer 201348 Future-Proof Software-Systems:
Summary 3.12.2013 Summary 3.12.2013 Part 2, Slide 40 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
Copyright Frank J. Furrer 201350 Future-Proof Software-Systems:
Summary 17.12.2013 Classification of data/information Structure of
data/information Modeling of information Quality assurance of
data/information Protection of data/information Modeling of data
Deployment of data/information Disaster recovery of
data/information Data/Information Architecture Information
Architecture Data Architecture conceptual Implementation Summary
17.12.2013
Slide 51
Copyright Frank J. Furrer 201351 Future-Proof Software-Systems:
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.ormutual.com Enterprise
data/information architecture http://www.ove.uk.com Vehicle
data/information Architecture [Embedded Systems] unfortunately NO!
Summary 17.12.2013
Slide 52
Copyright Frank J. Furrer 201352 Future-Proof Software-Systems:
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) Summary
17.12.2013
Slide 53
Copyright Frank J. Furrer 201353 Future-Proof Software-Systems:
Summary 17.12.2013 What is different in embedded systems data &
information? http://thorntoncenter.net Time ! Data items have
timing relationships between them sometimes very demanding and
stringent! Summary 17.12.2013
Slide 54
Copyright Frank J. Furrer 201354 Future-Proof Software-Systems:
Summary 17.12.2013 Data Timing & Validation Data in embedded
systems must often be validated before use Validation : Assure
consistency in value and in time Time ms] Acquisition Interval
Sensor FR Sensor FL Sensor BR Sensor BL Brake Control Impact
Interval Computing Intervall Validation/Correction
http://www.cdxetextbook.com/brakes Wheel rotation speed sensor
Validation step : Processing of data items before using them in the
computing of actions Methods : cleaning & plausibility
algorithms (simplest: -check) Summary 17.12.2013
Slide 55
Copyright Frank J. Furrer 201355 Future-Proof Software-Systems:
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? Summary 17.12.2013
Slide 56
Copyright Frank J. Furrer 201356 Future-Proof Software-Systems:
Summary 17.12.2013 Modeling of IT-Systems : State of the Art
http://www.ubizoo.de Business Object Model Domain Model Simulink
Models Frameworks model@runtime Timed Automata Contracts Directed
Hypergraph Taxonomy State Machines Petri Net Ontology OWL SysML UML
Summary 17.12.2013
Slide 57
Copyright Frank J. Furrer 201357 Future-Proof Software-Systems:
Summary 17.12.2013 Modeling of IT-Systems : Engineering Solutions
Business Object Model Domain Model BO Structural Model Behaviour
Model Database Model Domain Ontology UML + Profile Model
Application Taxonomy UML + Profile Model [Interface Contract Model]
Data Dictionary ERD-Model Summary 17.12.2013
Slide 58
Copyright Frank J. Furrer 2013 58 Future-Proof
Software-Systems: Summary 17.12.2013 Modeling of IT-Systems :
Modeling Instruments UML Diagram Structure Diagram Behaviour
Diagram Class Diagram Object Diagram Component Diagram Composite
Structure Diagram Profile Diagram Deployment Diagram Package
Diagram State Machine Diagram Interaction Diagram Activity Diagram
Use Case Diagram Sequence Diagram Communi- cation Diagram Timing
Diagram Interaction Overview Diagram http://www.ubizoo.de Summary
17.12.2013
Slide 59
Copyright Frank J. Furrer 201359 Future-Proof Software-Systems:
Summary 17.12.2013 Modeling of IT-Systems : Engineering Solutions
The Future: Contract-Based Systems Engineering Component,
Application Interface Service Contract Component, Application
Interface Service Contract Component, Application Interface Service
Contract Component, Application Interface Service Contract
Composition Summary 17.12.2013
Slide 60
Copyright Frank J. Furrer 201360 Future-Proof Software-Systems:
Summary 3.12.2013 Correction : SoS UML Class Diagram Question :
When will we see job advertisements for modeling engineers? Summary
17.12.2013
Slide 61
Future-Proof Software-Systems: Summary 17.12.2013 Function [F]
utilizes 1..* Function Owner [FO] 1..*1 manages Capability [C] 1..*
builds 1..* System-of-Systems [SoS] Mission [M] 11 is defined by
Mission Owner [MO] 11 implements 1..* Coordinator [CE] 1 governs
Cooperation Standards [CS] 1..* 1 enforces Environment 11..*
interacts Users 11..* benefit State of the Art Example : SoS
Conceptual Model: Structure (High Level) 1 Constituent System
Domain [CSD] Cooperation Domain [CD] 1..* interconnects 1..* 1
Cooperation Mechanism [CE] Cooperation Contract [CC] Constituent
System [CS] Process [Proc] 1..* 1 Global (synchronized) Time
delivers 1 Governance [Gov] 1 is delineated by 1..* Change
Management Ownership Budget Authority 1 11 Summary 17.12.2013
Slide 62
Copyright Frank J. Furrer 201362 Future-Proof Software-Systems:
Summary 3.12.2013 Summary 17.12.2013 Question : When will we see
job advertisements for SW modelling engineers?
http://luciano63.hubpages.com/hub/Sculptural-car-design Answer:
UML-Skills: today ! Simulink, Modelica, : today ! Ontological
engineering: tomorrow Advanced modelling mechanisms: 3 5 years
Slide 63
Copyright Frank J. Furrer 201363 Future-Proof Software-Systems:
Summary 3.12.2013 Summary 17.12.2013 Part 2, Slide 126 A11:
Systems-of-Systems (SoS) A12: Complexity and Simplification
Additional Topics: Legacy System Migration/Modernization Resilient
Software Systems Software Product Lines Cloud Computing
Architecture
Copyright Frank J. Furrer 201365 Future-Proof Software-Systems:
Summary 21.01.2014 What is a system-of-systems ? ( SoS ) # of
stakeholders (users, providers, ) size (SLOCs) 10 8 10 6 10 4 10 2
10 12 10 9 10 6 10 3 System- of- Systems Mega- System Monolithic
System Monolithic systems Systems-of-systems: 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 than the sum of its parts Summary 21.01.2014
Slide 66
Copyright Frank J. Furrer 201366 Future-Proof Software-Systems:
Summary 21.01.2014 SoS (Systems-of-systems) Classification
http://www.acq.osd.mil/se/initiatives/init_sos-se.html Summary
21.01.2014
Slide 67
Copyright Frank J. Furrer 201367 Future-Proof Software-Systems:
Summary 21.01.2014 Systems-of-Systems Engineering ( SoSE ) CS I CS
H CS F CS L SoS http://www.yellowjacketdisposal.com 1)Transparent
architecture 2) Explicit dependencies 3) Complete contracts 4) Risk
mitigation 5) Monitoring and early response CS A CS E CS D CS G CS
B CS N Mission Reqs Constraints CS R SoS Summary 21.01.2014
Slide 68
Copyright Frank J. Furrer 201368 Future-Proof Software-Systems:
Summary 21.01.2014 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 Summary 21.01.2014 good
Complexity makes large, useful systems possible It forces us to
develop science for dealing with complexity it is a highly
interesting and fruitful area of research bad It is the single most
important reason for disasters in IT It makes understanding,
explaining and evolving IT-systems very hard It may lead to
unpredictable (= emergent) behaviour Complexity must be managed !
Identify it Understand it Avoid and reduce it as much as
possible
Slide 69
Architecture Topic Map Copyright Frank J. Furrer 201369
Future-Proof Software-Systems: Summary 21.01.2014
Architecture-Greatness: Simplicity Elegance Functionality
Architecture-Quality: Agility Availability Security Safety
Performance Requirements Req A Req B Req Y Future-Proof
Software-System Engineer Summary 21.01.2014 http://de.123rf.com
Beautiful Architecture
Slide 70
Copyright Frank J. Furrer 201370 Future-Proof Software-Systems:
Summary 21.01.2014 Legacy system modernization strategies: Summary
21.01.2014
Slide 71
Copyright Frank J. Furrer 2013 71 Future-Proof
Software-Systems: Summary 21.01.2014 Environment Software System
Attack Resilience: Environment Change Fault Human Error Emergent
Behaviour https://soundcloud.com Crash t Degraded operation t t
Malfunction http://kanto.stripes.com Summary 21.01.2014
Slide 72
Copyright Frank J. Furrer 201372 Future-Proof Software-Systems:
Summary 21.01.2014 How can we build resilient systems ? Information
Architecture Technical Architecture Integration Architecture
Applications Architecture Business Architecture Horizontal
architecture layers A1 Layer Isolation A2 Partitioning A3
Redundancy A4 Interoperability A5 Com F A6 Ref Architectures A7
Reuse A8 Industry Standards A9 Inf Arch A10 Formal Modelling A11
SoS A12 Simplification Vertical architecture layers etc. Safety
Security Availability Performance Integrity Availability
PrinciplesSecurity PrinciplesSafety PrinciplesIntegrity Principles
Performance Principles Summary 21.01.2014
Slide 73
http://www.auto-motor-und-sport.de/ Example : Product line in
automotive development Copyright Frank J. Furrer 201373
Future-Proof Software-Systems: 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 and that are
developed from a common set of core assets [Clements02] Summary
21.01.2014
Slide 74
Copyright Frank J. Furrer 201374 Future-Proof Software-Systems:
Summary 21.01.2014 Economics of Product Line Development: 1 2 3 4 5
6 # of different systems built Total effort [, t] Single systems
approach Product line approach Initial effort: Prod line def
Variability Quality Great advantage in cost, time-to-market and
quality Summary 21.01.2014
Slide 75
Copyright Frank J. Furrer 201375 Future-Proof Software-Systems:
Summary 21.01.2014 Cloud = Execution and Delivery Infrastructure
Cloud Computing: SaaS S oftware as a S ervice PaaS P latform as a S
ervice IaaS I nfrastructure as a S ervice Application End-User
Developper System Manager Cloud service consumer Cloud service
provider pay as you go Summary 21.01.2014
Slide 76
Copyright Frank J. Furrer 201376 Future-Proof Software-Systems:
Summary 21.01.2014 Cloud Computing Risks : SaaS PaaS IaaS Contract
SLA: Service Level Agreement functional operational commercial
legal compensate by: Cloud Service Level Agreements (Cloud-SLA)
http://pssiusa.wordpress.com Security, Dependability, Resilience,
Attacks Loss of direct control ??? Summary 21.01.2014
Slide 77
Copyright Frank J. Furrer 201377 Future-Proof Software-Systems:
Summary 21.01.2014 Summary 21.01.2014 Part 3, Slide 1 Future-Proof
Software-Systems Future-Proof Software-Systems Architecture
Principle A11: A1 1 Architecture Principle A11: A1 1 Architecture
Principle A11: A1 1 Scientific & Technical Focus Human
Focus