summary lecture of: 22.10 - tu dresdenst.inf.tu-dresden.de/files/teaching/ws13/fps13/summary... ·...
TRANSCRIPT
Future-Proof Software-Systems: Summary
Condensed Summary of Previous Lectures
Summary Lecture of:
22.10.2013(9 slides)
I prefer dialog - rather than monolog:Please feel free to ask questions at any time
Future-Proof Software-Systems: Preferred Interaction Style
My Preferred Interaction Style
Summary 22.10.2013
Copyright Frank J. Furrer 2013 2
I am available for additional questions or discussionsafter each lecture
Lecture Website:http://st.inf.tu-dresden.de/teaching/fps13
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Software is one of the most important key success factorsfor today‘s and tomorrow‘s products and services
http://myauto24.blogspot.ch/2013/
… etc
Copyright Frank J. Furrer 2013 3
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
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 – itmust also play its role as a key competitive factor
Copyright Frank J. Furrer 2013 4
Charles Darwin: The Origin of Species (1859)
Future-proof software must allow to implementnew requirements in a short time, withreasonable cost and with adequate quality
Key SW-property: Agility
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
„The three devils of systems engineering are:
Complexity,
Change,
Uncertainty”Anonymous
Copyright Frank J. Furrer 2013 5
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
Parts of the systemand their relationsships
Activity: Steering thedevelopment & evolution
Copyright Frank J. Furrer 2013 6
of complexity, change and uncertainty
with the least effort, with acceptable risk and with specified quality properties
Providing the best valuefor the resources ‘money‘
and ‘time-to-market‘
Having an adequate probability forundesired effects and consequences
Assuring the desired properties(„Fit for Purpose“)
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Agility
Future-Proof Software-Systems Coordinates
System Stateat time t Loss of agility
Copyright Frank J. Furrer 2013 7
BusinessValue
System Stateat time tn
at time tn+T
System Stateat time tn+kT
Loss of agility
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Future-ProofSoftware System
(FPSS))Structure Architecture
Copyright Frank J. Furrer 2013 8
(FPSS))
Manifesto of Future-Proof Software-Systems:
1. „Fit-for-Future“ of an IT-system depends onits structure and is determined by its
architecture
2. The agility must continuously be improved
3. Future-proof software-systems need strongarchitects and a farsighted management
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Safety
Security
Agility
Availability
etc.
syste
mor
an
exte
nsio
n Fm
• Functionality and architectureare (nearly) orthogonal
• Architectures differ by theirquality properties
• Architecture assessment &evaluation optimum
Copyright Frank J. Furrer 2013 9
Safety
Security
Agility
Availability
etc.
Fu
ncti
on
ality
of
asyste
m
F1
F2
F5F4F3
A1
System & software architecture
AnA4 A5A3A2 A9
ArchitecturePrinciples
enforce
Future-Proof Software-Systems: Summary 22.10.2013
Summary 22.10.2013
Future-ProofSoftware-System
Structure
enables
Architectureforms
Future-ProofSoftware-Systems
Engineer
Copyright Frank J. Furrer 2013 10
http://berxblog.blogspot.ch
Engineer
ArchitecturePrincipleArchitecture
PrincipleArchitecturePrinciple
Part 1, Slide 90
Future-Proof Software-Systems: Summary 5.11.2013
Condensed Summary of Previous Lectures
Summary Lecture of:
5.11.2013(11 slides)
Future-Proof Software-Systems: Summary 5.11.2013
Architecture Erosion
http://thoreau.colonial.net/Students/EricksonHoyt/erosionSummary 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
Copyright Frank J. Furrer 2013 12
Quality Properties:• Business Value
•Agility• Security
• Availability• etc.
Time
Continuouslyimprove thearchitecture
… and some more
Future-Proof Software-Systems: Summary 5.11.2013
Architecture Viewswww.123rf.com
Sys Mgmt
Security
Safety
etc.
Summary 5.11.2013
Copyright Frank J. Furrer 2013 13
Stakeholders
etc.
Architecture documentation:
Documentation Framework
Views:
Overarching documentation
Future-Proof Software-Systems: Summary 5.11.2013
How much Architecture is enough?
http
://w
ww
.skyscra
pern
ew
s.o
rgh
ttp:/
/w
ww
.dim
en
sio
nsin
fo.c
om
/dim
en
sio
ns-o
f-a-d
og-h
ou
se
Summary 5.11.2013
Copyright Frank J. Furrer 2013 14
Architecture work (% total €)
Project effort (€)
10 %
100 %
htt
p:/
/w
ww
.dim
en
sio
nsin
fo.c
om
/dim
en
sio
ns
G. Fairbanks / ISBN 978-0-9846181-0-1
Future-Proof Software-Systems: Summary 5.11.2013
Legacy Softwareh
ttp:/
/w
ww
.nzz.c
h/aktu
ell/
sta
rtseite
/h
inte
rtuerc
hen
htt
p:/
/w
ww
.123rf
.com
/ph
oto
_4985178_o
ld-r
usti
ng-s
cra
pped-c
ars
-in
-a-j
un
k-y
ard
.htm
l
Summary 5.11.2013
Summary 5.11.2013
Copyright Frank J. Furrer 2013 15
http
://w
ww
.nzz.c
h/aktu
ell/
sta
rtseite
/h
inte
rtuerc
hen
-der-b
an
ken
-bei-d
en
-gold
-etf-1
.5956390
htt
p:/
/w
ww
.123rf
.com
/ph
oto
_4985178_o
ld
Liability Asset
good:
• invaluable implicit knowledge of thedomain 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
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.
A1
Summary 5.11.2013
Copyright Frank J. Furrer 2013 16
Never implement technical functionality in the applications.
Justification: Any reliance on specific technologies or productsgenerates dependencies which (massively) reduce agility.
Architecture layers should be able to evolve in their own pace withoutimpacting the other layers by force
IndustryStandards
Future-Proof Software-Systems: Summary 5.11.2013
ApplicationsArchitecture (Functionality)
BusinessArchitecture (Business Processes)
InformationArchitecture (Information & Data)
Orc
hestr
ati
on
Tech
nolo
gy
Serv
ices
Technology& ProductIndependence
Copyright Frank J. Furrer 2013 17
TechnicalArchitecture (Technical Infrastructure)
IntegrationArchitecture (Cooperation Mechanisms)
Bu
sin
ess
Pro
cess
Tech
nolo
gy
Serv
ices
Tech
nolo
gy
Serv
ices
Tech
nolo
gy
Serv
ices
Future-Proof Software-Systems: Summary 5.11.2013
Architecture Principle A2:
Partitioning, Encapsulation & Coupling
1. Partition the functionality and data into encapsulation unitsaccording to their coherence and cohesion (thus minimizing
dependencies)
2. Isolate the encapsulation units by strictly hiding any internaldetails. Allow access to functionality and data only through stable,
A2Summary 5.11.2013
Copyright Frank J. Furrer 2013 18
details. Allow access to functionality and data only through stable,well specified interfaces governed by contracts
3. Minimize the impact of dependencies between the encapsulationunits by using adequate coupling mechanisms
Justification: These 3 principles minimize the number and theimpact of dependencies. The resulting system therefore offers theleast resistance to change, because any change affects the smallestpossible number of system elements. A low resistance to changecorresponds to high agility.
Future-Proof Software-Systems: Summary 5.11.2013
FF
F
F
F
F
F
FF
F
F
FF
F
F
F
F
FF
F
F
F
F
F
FF
IF
IF
IF
IF
IF
IF
IF
IF
IF
IF
IF
Summary 5.11.2013
Copyright Frank J. Furrer 2013 19
FFF
F
FF
FF
F
FF
FFF
F F
FF
FF
F
IF
IF
IF
IF
IF
IF
IFIFIFIF
IF IF
IF
IF
IF IF
IF
IF
IFIFIF
Partition,encapsulate,and couple as loosely as possbile
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013 Q: Boundary between Architecture and Design?
System
System-of-Systems
Arc
hit
ectu
re
Relationsship:Contract
Copyright Frank J. Furrer 2013 20
Module
ComponentApplication
System
TechnologyDependence
Desig
n
Part: Container forfunctionality & data
Part: EJB,Java Class
Relationsship:Web-Service
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Q: Granularity ofthe EncapsulationUnits?
System-of-Systems
System
loose
Copyright Frank J. Furrer 2013 21
Application
Component
Module
Encapsulation
Coupli
ng
tight
Future-Proof Software-Systems: Summary 5.11.2013
Summary 5.11.2013
Continuation:
Architecture Principle A2:
Partitioning, Encapsulation & Coupling
A2
Copyright Frank J. Furrer 2013 22
Part 2, Slide 41
How do we:
• partition
• encapsulate
• couple
a system?