1. Università
degli
Studi
DiparHmento
di
Ingegneria
e
Scienze
1
dell’Aquila
dell’Informazione
e
MatemaHca
(DISIM)
So.ware
Architecture
Patrizio
Pelliccione
patrizio.pelliccione@gmail.com
Università
degli
Studi
dell’Aquila
DiparHmento
di
Ingegneria
e
Scienze
dell’Informazione
e
MatemaHca
[Renzo
Piano:
Architecture
of
the
L’Aquila
(Italy)
new
Auditorium
in
L’Aquila
-­‐
Italy]
So%ware
Architecture
Gothenburg,
February
2013

2. The
architecture
of
buildings
2
Kansas
City
PPolan
dibra
t,
ublic L )
ry
(Missouri,Museum
of
Contempo
House
( po
ed
Source:
hpSo
USA)
rary
Art
(Niteroi,
Bra
The
Crook ://www.flick/2240736671
brocha r.com/photos/jonath So
zil)
ur
an_moreau/41800821 ce:
hp://www.flic
.com/photos/ 2
kr.com/photos/how
//www.flickr vin/7457617764/
Source:
hp:
o No
comparable
intuiHon
for
so%ware
§ We
must
be
more
methodological
and
analyHcal
in
our
approach
o So%ware
is
intrinsically
intangible
§ More
difficult
to
measure,
analyze,
and
evaluate
qualiHes
o So%ware
more
malleable
than
physical
building
materials
§ Types
of
changes
unthinkable
in
a
physical
domain
So%ware
Architecture
Gothenburg,
February
2013

3. So.ware
Architecture
and
So.ware
Engineering
3
o Every
applicaHon
has
an
architecture
Russian
Embassy
(Havana,
Cuba)
hp://upload.wikimedia.org/wikipedia/commons/d/d2/Russian_embassy_in_Havana.jpg
[MedTaylor2009]
So%ware
Architecture
Gothenburg,
February
2013

4. So.ware
Architecture
and
So.ware
Engineering
4
o Every
applicaHon
has
an
architecture
§ The
architecture
of
a
system
can
be
characterized
by
the
principal
design
decisions
made
during
its
development
Architecture
underlying
command-­‐line
shell
programs
ls invoices | grep –e August | sort
Quickly
and
easily
compose
new
applicaHons
from
exisHng
ones
by
following
simple
rules
Filter:
program
that
takes
a
stream
of
text
characters
as
input
and
produces
a
stream
of
characters
as
its
output
Pipe:
a
way
to
connect
two
filters
–
it
routes
the
character
stream
output
of
the
first
filter
to
the
character
stream
input
of
the
second
filter
[MedTaylor2009]
So%ware
Architecture
Gothenburg,
February
2013

5. So.ware
Architecture
and
So.ware
Engineering
5
o Every
applicaHon
has
an
architecture
§ The
architecture
of
a
system
can
be
characterized
by
the
principal
design
decisions
made
during
its
development
Architecture
underlying
command-­‐line
shell
programs
ls invoices | grep –e August | sort
er
d-fi
ltxisHng
ones
by
pipe-an
Quickly
and
easily
compose
new
applicaHons
from
e
following
simple
rules
ural style
Ar chitect
Filter:
program
that
takes
a
stream
of
text
characters
as
input
and
produces
a
stream
of
characters
as
its
output
Pipe:
a
way
to
connect
two
filters
–
it
routes
the
character
stream
output
of
the
first
filter
to
the
character
stream
input
of
the
second
filter
[MedTaylor2009]
So%ware
Architecture
Gothenburg,
February
2013

6. So.ware
Architecture
and
So.ware
Engineering
6
o Every
applicaHon
has
an
architecture
§ The
architecture
of
a
system
can
be
characterized
by
the
principal
design
decisions
made
during
its
development
o Every
applicaHon
has
at
least
one
architect
§ Perhaps
not
known
by
that
Htle
or
recognized
for
what
is
done
o Architecture
is
not
a
phase
of
development
§ Where
did
the
so%ware
architecture
come
from?
§ How
does
it
change?
[MedTaylor2009]
So%ware
Architecture
Gothenburg,
February
2013

7. General
workflow
7
stakeholders
concerns
Software
Ideas
Architecture
synthesis
Architectural constraints C2
Constraints and requirements
C3
C1
Software C4
Req1:..
Architecture
Req2:..
Req3:..
………
Architectural
requirements Evaluation and
Decisions making
[HKNORA07,PIM09]
So%ware
Architecture
Gothenburg,
February
2013

8. So.ware
architecture
characterisLcs
8
o MulHtude
of
stakeholders
§ Dealing
with
a
broad
variety
of
concerns
and
stakeholders,
and
has
a
mulHdisciplinary
nature.
o SeparaHon
of
concerns
§ Stakeholder
concerns
are
addressed
by
modeling
and
describing
the
architecture
from
separate
points
of
view
associated
with
the
various
stakeholder
concerns.
o Quality-­‐driven
§ Architecture
of
a
system
is
closely
related
to
its
quality
aributes,
such
as
fault-­‐tolerance,
backward
compaHbility,
extensibility,
reliability,
maintainability,
availability,
security,
usability,
and
other
such
–iliHes.
o Recurring
styles
§ Common
terms
for
recurring
soluHons
are
architectural
style,
strategy
or
tacHc,
reference
architecture
and
architectural
paerns.
o
Conceptual
integrity
§ The
architect
assumes
the
role
of
“keeper
of
the
vision”,
making
sure
that
changes
to
the
systems
are
in
line
with
the
architecture,
hence
preserving
conceptual
integrity.
So%ware
Architecture
Gothenburg,
February
2013

9. So.ware
architecture
benefits
9
o Basis
for
analysis
of
so,ware
systems'
behavior
before
the
system
has
been
built.
§ SubstanHal
cost-­‐saving
and
risk-­‐miHgaHon.
o Basis
for
re-­‐use
of
elements
and
decisions.
§ Saving
design
costs
and
miHgaHng
the
risk
of
design
mistakes.
o Support
for
early
design
decisions
which
have
high
impact
on
a
system's
development,
deployment
and
maintenance
life.
§ Prevent
schedule
and
budget
overruns.
o Facilitate
communica?on
among
stakeholders,
contribu?ng
to
a
system
that
beAer
fulfills
their
needs.
§ SubstanHal
cost-­‐saving
and
risk-­‐miHgaHon:
communicate
about
design
decisions
before
the
system
is
implemented,
when
they
are
sHll
relaHvely
easy
to
adapt.
So%ware
Architecture
Gothenburg,
February
2013

10. History
-­‐
past
1
0
“Architecture
is
concerned
with
the
selecHon
of
architectural
elements,
their
interacHons,
and
the
constraints
on
those
elements
and
their
interacHons
necessary
to
provide
a
framework
in
which
to
saHsfy
the
requirements
and
serve
as
a
basis
for
the
design.”
Elements
are
divided
into
processing
elements,
data
elements
and
connecHon
elements
[PerryWolf92]
SA
for
a
specific
system
may
be
captured
as
“a
collecHon
of
computaHonal
components
-­‐
or
simply
components
-­‐
together
with
a
descripHon
of
the
interacHons
between
these
components
-­‐
the
connectors”
[GarlanShaw93]
“An
architectural
descripHon
is
organized
into
one
or
more
consHtuents
called
(architectural)
views.
Each
view
addresses
one
or
more
of
the
concerns
of
the
system
stakeholders.
A
view
is
a
parHal
expression
of
a
system’s
architecture
with
respect
to
a
parHcular
viewpoint.”
[IEEE
1471-­‐2000]
So%ware
Architecture
Gothenburg,
February
2013

11. History
-­‐
present
1
1
A
system
architecture
is
the
fundamental
concepts
or
properHes
of
a
system
in
its
environment
embodied
in
its
elements,
relaHonships,
and
in
the
principles
of
its
design
and
evoluHon.
[ISO/IEC/IEEE
2011]
So%ware
Architecture
Gothenburg,
February
2013

12. History
-­‐
present
1
2
A
system
architecture
is
the
fundamental
concepts
or
properHes
of
a
system
in
its
environment
embodied
in
its
elements,
relaHonships,
and
in
the
principles
of
its
design
and
evoluHon.
[ISO/IEC/IEEE
2011]
“A
so%ware
system’s
architecture
is
the
set
of
principal
design
decisions
about
the
system.”
Design
decisions
related
to
system:
structure,
behavior,
interac?on,
non-­‐
func?onal
proper?es,
development,
business
posiHon.
[MedTaylor2007,
MedTaylor2009]
So%ware
Architecture
Gothenburg,
February
2013

13. History
-­‐
near
future
1
3
So%ware
industry
is
moving
from
a
“Specify-­‐Code-­‐Test”
philosophy
to
a
“Explore-­‐Integrate-­‐Validate”
one.
• ExploraHon
of
available
so%ware
and
makes
explicit
the
degree
of
uncertainty
associated
with
it
in
relaHon
to
an
Explore
opportunisHc
goal
G
• Assistance
of
the
producer
in
creaHng
the
appropriate
integraHon
means
towards
G
Integrate
• ValidaHon
of
the
integrated
system
to
assess
its
quality
with
respect
to
G
and
the
current
context
Validate
[ACDIPT2011]
So%ware
Architecture
Gothenburg,
February
2013

14. Architectures
and
architecture
descripLons
1
4
[ISO/IEC/IEEE
2011]
So%ware
Architecture
Gothenburg,
February
2013

15. Architecture
DescripLon
Languages:
history
1
5
o First
generaHon
(1990-­‐2000)
§ Purpose
to
define
the
ideal
ADL
§ Mainly
based
on
component-­‐connector
view
§ Supported
features
• C&C
specificaHon,
composiHon,
abstracHon,
reusability,
analysis…
o Second
generaHon
(2000
up
to
today)
§ Supported
features
• ConfiguraHon
management,
distribuHon,
product-­‐line
modeling,
…
o Result:
ProliferaHon
of
ADLs
(in
a
recent
survey
we
count
125
ADLs)
[MedTaylor2007,
MLMPT13,
MT00]
So%ware
Architecture
Gothenburg,
February
2013

16. What
Industry
needs
from
ADLs:
A
Survey
1
6
o Research
quesHons
§ RQ1:
What
are
the
architectural
descripHon
needs
of
pracHHoners?
§ RQ2:
What
features
typically
supported
by
exisHng
ADLs
are
useful
(or
not
useful)
for
the
so%ware
industry?
o Main
findings
§ F1:
All
top
used
ADLs
have
been
originated
in
industry
§ F2:
ALs
should
combine
features
supporHng
both
communicaHon
and
disciplined
development.
We
call
this
introvert
versus
extrovert
nature
of
architects
role
§ …
So%ware
Architecture
Gothenburg,
February
2013

17. What
Industry
needs
from
ADLs:
A
Survey
1
7
ADLs
used
by
the
interviewed
populaHon
So%ware
Architecture
Gothenburg,
February
2013

18. Being
so.ware
architect…
1
8
So%ware
Architecture
Gothenburg,
February
2013

19. References
1
9
o [ACDIPT2011]
M.
AuHli,
V.
Cortellessa,
D.
Di
Ruscio,
P.
Inverardi,
P.
Pelliccione,
and
M.
Tivoli.
Eagle:
engineering
so%ware
in
the
ubiquitous
globe
by
leveraging
uncertainty.
In
Proceedings
of
the
19th
ACM
SIGSOFT
symposium
and
the
13th
European
conference
on
FoundaHons
of
so%ware
engineering,
ESEC/FSE
’11,
pages
488–491,
New
York,
NY,
USA,
2011.
ACM.
o [GarlanShaw93]
Garlan,
D.
&
Shaw,
M.
“An
IntroducHon
to
So%ware
Architecture,”
1–39.
Advances
in
So%ware
Engineering
and
Knowledge
Engineering,
Vol.
2.
Edited
by
V.
Ambriola
and
G.
Tortora.
New
Jersey:
World
ScienHfic
Publishing
Company,
1993.
o [HKNORA07]
C.
Hofmeister,
P.
Kruchten,
R.L.
Nord,
H.
Obbink,
A.
Ran,
and
P.
America,
“A
General
Model
of
So%ware
Architecture
Design
Derived
from
Five
Industrial
Approaches,”
J.
Systems
and
So%ware,
vol.
80,
no.
1,
pp.
106-­‐126,
2007.
o [IEEE
1471-­‐2000]
IEEE
1471:
ANSI/IEEE
1471-­‐2000:
Recommended
PracHce
for
Architecture
DescripHon
of
So%ware-­‐Intensive
Systems
o [ISO/IEC/IEEE
2011]
ISO/IEC/IEEE
42010:2011
Systems
and
so%ware
engineering
–
Architecture
descripHon,
2011.
o [MedTaylor2007]
Medvidovic,
N.,
Dashofy,
E.
M.,
and
Taylor,
R.
N.
2007.
Moving
architectural
descripHon
from
under
the
technology
lamppost.
Inf.
So,w.
Technol.
49,
1
(Jan.
2007),
12-­‐31.
o [MedTaylor2009]
Taylor,
R.
N.,
Medvidovic,
N.,
and
Dashofy,
E.
M.
2009
So,ware
Architecture:
Founda?ons,
Theory,
and
Prac?ce.
Wiley
Publishing.
o [MLMPT13]
Ivano
Malavolta,
Patricia
Lago,
Henry
Muccini,
Patrizio
Pelliccione,
Antony
Tang,
"What
Industry
Needs
from
Architectural
Languages:
A
Survey,"
IEEE
TransacHons
on
So%ware
Engineering,
2013.
IEEE
computer
Society
Digital
Library.
IEEE
Computer
Society.
o [MT00]
Nenad
Medvidovic
and
Richard
N.
Taylor.
2000.
A
ClassificaHon
and
Comparison
Framework
for
So%ware
Architecture
DescripHon
Languages.
IEEE
Trans.
So%w.
Eng.
26,
1
(January
2000),
70-­‐93.
o [PerryWolf92]
Dewayne
E.
Perry
and
Alexander
L.
Wolf.
``FoundaHons
for
the
Study
of
So%ware
Architecture''.
ACM
SIGSOFT
So,ware
Engineering
Notes,
17:4
(October
1992).
(Original
paper:
Dewayne
E.
Perry
and
Alexander
L.
Wolf.
"So,ware
Architecture".
August
1989)
o [PIM09]
Patrizio
Pelliccione,
Paola
Inverardi
and
Henry
Muccini,
CHARMY:
A
Framework
for
Designing
and
Verifying
Architectural
SpecificaHons
(2009),
in:
IEEE
TransacHons
on
So%ware
Engineering
(TSE),
35:3(325
-­‐
346)
So%ware
Architecture
Gothenburg,
February
2013

20. Università
degli
Studi
DiparHmento
di
Ingegneria
e
Scienze
2
dell’Aquila
dell’Informazione
e
MatemaHca
(DISIM) 0
QuesLons?
Patrizio
Pelliccione
patrizio.pelliccione@gmail.com
Università
degli
Studi
dell’Aquila
DiparHmento
di
Ingegneria
e
Scienze
dell’Informazione
e
MatemaHca
[Renzo
Piano:
Architecture
of
the
L’Aquila
(Italy)
new
Auditorium
in
L’Aquila
-­‐
Italy]
So%ware
Architecture
Gothenburg,
February
2013