Seminar pasqualina potena

2
My Research Background
Short Biblio:
- Degree in Computer Science from University of L’Aquila, and Ph.D. degree
from University of Chieti e Pescara (Italy)
- PhD guest student at Mälardalen University, Mälardalen Real-Time Research
Centre (Västerås, Sweden)
- Research fellow at the University of L’Aquila, Politecnico di Milano, and
University of Bergamo
- Post-doc position linked to project ICEBERG funded by EU under IAPP Marie
Curie Program, University of Alcalà, Spain.
Research keywords:
system design, system adaptation, distributed systems, optimization techniques,
system properties, adaptive software applications, cloud computing, embedded
system, intelligent environments, SBSE search methodologies (e.g., genetic
algorithms, evolutionary algorithms), etc.

3Research activities comprise:
§ Design/Adaptation Space Exploration for component-based and service-based
systems (e.g., [1])
§ Quantifying the influence of failure repair/mitigation costs on service
based systems (e.g., see [2])
§ Resource Allocation, Trading and Adaptation in Self-Managing Systems
(e.g., see [3])
§ Architectural Decisions for HW/SW Partitioning based on multiple
Properties (e.g., see [4])
§ Other (e.g., testing decisions under quality, cost, and time constraints)
[1] Potena, P.: “Optimization of adaptation plans for a service-oriented architecture with cost, reliability,
availability and performance tradeoff”, Journal of Systems and Software, Vol. 86, Issue 3, 2013, pp.624-648.
[2] Cortellessa, V., Marinelli, F., Mirandola, R., Potena, P.: “Quantifying the influence of failure repair/mitigation
costs on Service based Systems”, Proc. of ISSRE 2013, pp.90-99, 2013.
[3] Lulli, G., Mirandola, R., Potena, P., Raibulet C.: “Resource Management in the Air Traffic Domain ”,
Proc. of ECSA 2011, LNCS, pp. 97-104, 2011.
[4] Sapienza, G., Crnkovic, I., Potena, P.: “Architectural Decisions for HW/SW Partitioning based on multiple
Extra-Functional Properties”. Proc. of 11th Working IEEE/IFIP Conference on Software Architecture (WICSA),
pages 175–184. IEEE, Sydney, Australia, 2014.

4
Research and Knowledge Transfer
For example: the ICEBERG project funded by EU under the Marie
Curie IAPP programme (http://www.iceberg-sqa.eu/).
The project investigated a novel approach to improving understanding of the
real cost impacts of poor quality software and supporting the suite of
management decisions required to take corrective action across the entire
software development cycle.
I have worked to understand the real needs of practitioners in industry.

5
Presentation roadmap
•  Software Quality: Why? What? How?
•  Optimization models for tradeoff analysis
•  Sum up and future perspective

7
Software Quality: Why?
It is commonly perceived today (?!) that software
quality is becoming more and more a first-class issues
of Software Architecture
… some factual reasons…
•  Complex distributed software services
•  Devices with limited resource capabilities
•  Heterogeneity of networks
•  Cloud computing (resources on demand, pricing)
• …

8
How to understand if NF properties are relevant?
And, if they are relevant, which ones to consider?
NON-FUNCTIONAL REQUIREMENTS
Software Quality: What?

9Software Quality: How?
Single attribute analysis of monolithic systems
(e.g. response time, MTTF, etc…)
+ Focusing on a single software aspect
+ Well-assessed methodologies/notations/tools
+ Reasonable solution time for large/detailed models
- Focusing on a single software aspect!!!
- Unable to capture interactions between components
- Unable to capture relationships among attributes
Composition

10
Non-functional composition
1)  Interactions between components
2) Relationships among attributes

11
1)  Interactions between components
•  Relating (possibly in a closed form) a whole system
attribute to component/service attributes
C1
Ф(C1)
C2
Ф(C2)
Cn
Ф(Cn)
Connectors
Ф(S) = Ф(C1) ⊗ Ф(C2) ⊗ … ⊗ Ф(Cn)
Ф() : non functional
attribute (e.g., failure
probability)
•  Splitting a whole system requirement into
component/service requirements
Non-functional composition

12
Non-functional attribute composition
2) Relationships among attributes
Expressing (possibly in a closed form) the
relationships/tradeoffs/dependencies among attributes
Requirement:
<<data confidentiality>>
C2sendData
C1
C2
sendData Encryption*
Decryption*
C1
Throughput
Workload
initial system
secure system
t1
t2
λ

13
OPTIMIZATION MODELS FOR
TRADEOFF ANALYSIS

14
Optimization models
Optimization models have recently revealed to be useful for
supporting different decisions in multiple contexts:
•  Service broker based on quality (Cardellini et al., 2012)
•  Allocation of testing resources (Berman et al., 2004)
• …
Component/Service-based Software Engineering
Aldeida Aleti et al.,
Software architecture optimization methods: a systematic literature review,
IEEE TSE 39 (5): 658-683 (2013)

15
Component/Service-based Software
CLASS OF PROBLEMS
Choice of components/services driven by
non-functional properties
Optimization models
DOMAIN

16
ARCHITECTURAL PHASE
Cost vs reliability and delivery time
Cost vs satisfaction of requirements
REQUIREMENTS PHASE
Change management
MAINTENANCE PHASE
DEPLOYMENT PHASE
Cost vs reliability and performance
Optimization models

17
ARCHITECTURAL PHASE
REQUIREMENTS PHASE
Change management
MAINTENANCE PHASE
DEPLOYMENT PHASE
Optimization models

18
In this phase, the goal is to find appropriate candidates that might be
integrated into the system.
A pre-selection of components at the requirements phase, in particular related to
a combination of functional and non-functional requirements, can sensibly improve
the efficiency of the whole process and decrease the development costs.
We intend to determine the combination of single COTS
components and assemblies of COTS that satisfy the
requirements while minimizing costs.
REQUIREMENTS PHASE

19
In [Alves et al. 2005], using the outlines of the goal-
oriented requirements engineering [Lamsweerde 2001] that
defines requirements as goals, the authors present a goal-
based approach to match the goals of the system and the
features of the COTS components.
[Alves et al. 2005] Alves, C., Franch, X., Carvallo, J.P., Finkelstein, A.: “Using Goals and Quality Models to Support
the Matching Analysis During COTS Selection”, Proc. of ICCBSS 2005, LNCS 3412, 146-156, 2005.
[Lamsweerde 2001] Lamsweerde, A.: “Goal-Oriented Requirements Engineering: A Guided Tour”, Invited mini-
tutorial paper, appared in Proc. of RE 2001, 249-263, Toronto, August 2001.
GOAL-ORIENTED REQUIREMENTS ENGINEERING

20
A non-functional goal g:
For Example The acceptable level of reliability for a
service should range between 0.8 and 0.9
Let C be a COTS component that provides the service and let 0.92 be the
value of the reliability guaranteed from the component C.
Therefore, the degree of satisfaction that C meets the goal g (i.e.
Satg(0.92)) is equal to 1. Then, we can conclude that the COTS C
completely satisfies the goal g.
Sat g
if x
x if x
if x
_
.
. .
.
=
<
− ≤ <
≥
⎧
⎨
⎪
⎩
⎪
0 08
10 8 08 09
1 09

21
C = {C1, . . . ,C|C|}
a set of COTS components.
A = {A1, . . . ,A|A|}
a set of assemblies of COTS
components.
G = {g1, . . . , gn}
a set of n operational goals, each of
which represents a non-functional
requirement of the system.
xi =
1 if the i-th COTS is chosen (1 ≤ i ≤ |C|)
0 otherwise
yj =
1 if the j-th assembly is chosen (1 ≤ j ≤ |A|)
0 otherwise
VARIABLES
ci purchase cost of the i-th COTS
component
cj cost of the j-th assembly (i.e.
integration and adaptation cost)
OPTIMIZATION MODEL
{ }
{ } ||...,
||...,
:|,|...
...],[
min
||
||
|| ||
A1j10y
C1i10x
ACiA1jxy
1y
n1kSatykjSAT
ycxc
j
i
jiij
A
1j
j
k
A
1j
j
C
1i
A
1j
jjii
=∀∈
=∀∈
∈∀=∀≤
=
=∀≥
+
∑
∑
∑ ∑
=
=
= =
cost
function

22
xi =
1 if the i-th COTS is chosen (1 ≤ i ≤ |C|)
0 otherwise
yj =
1 if the j-th assembly is chosen (1 ≤ j ≤ |A|)
0 otherwise
VARIABLES
OPTIMIZATION MODEL
S A T [ j , k ] r e p r e s e n t s t h e
satisfaction degree with which an
assembly j meets a goal k
Satk is the satisfaction degree
required for goal k
{ }
{ } ||...,
||...,
:|,|...
...],[
min
||
||
|| ||
A1j10y
C1i10x
ACiA1jxy
1y
n1kSatykjSAT
ycxc
j
i
jiij
A
1j
j
k
A
1j
j
C
1i
A
1j
jjii
=∀∈
=∀∈
∈∀=∀≤
=
=∀≥
+
∑
∑
∑ ∑
=
=
= =

23
An example: a distributed e-health system
It is a client/server system, where the AE Client subsystem is connected via a network (Network
subsystem) to the AE Server subsystem.
The communication between the entities of the system is performed using Digital Imaging and
Communication in Medicine (DICOM) standard, which is typically used, for example, for producing,
processing and exchanging medical images.
Static view

24
Let us assume that the AE Client subsystem has to guarantee
two non-functional operational goals.
Costs of available COTS components
We have taken into account 25 assemblies of components.

25Model Solution
Model solution for multiple values of the
required satisfaction degree for the
nfg1 and nfg2 goals.

26Model Solution
Optimal solution for all previous cases
(i.e. selection of assemblies of components)

27
Model builder
Model solverAnnotate
Transform
Optimization
model
-  Operational
Goals of the
system
- Set of COTS
components and
assemblies
- Set of COTS
components
and assemblies
DEER FRAMEWOK
DEER (DEcision support for componEnt-based softwaRe)
generates and solves the models automatically.
Relevance of tool support

28
ARCHITECTURAL PHASE
REQUIREMENTS PHASE
Change management
MAINTENANCE PHASE
DEPLOYMENT PHASE
Optimization models

29
On the basis of an architectural design, for each software
component we assume to have different COTS available to buy
or an in-house version to build.
We also assume that all components are equivalent by a
functional viewpoint.
We intend to determine the combination of available COTS
products and in-house developed components that minimizes the
software costs under (delivery time and) reliability constraints.
As a ”side effect”, we provide the amount of testing to be
performed on each in-house component in order to achieve the
required reliability level.
ARCHITECTURAL PHASE

30
C1
C2
Ci
Connectors
ARCHITECTURAL PHASE

31
C1
C2
Ci
Connectors
y1
x11
x12
x1m
in-house
COTS
ARCHITECTURAL PHASE

32
C1
C2
Ci
Connectors
y1
x11
x12
x1m
in-house
COTS
yi in-house
xi1
xi2
xim
COTS
x21 x22 x2m
y2 in-house
COTS
ARCHITECTURAL PHASE

33
C1
C2
Ci
Connectors
y1
x11
x12
x1m
in-house
COTS
yi in-house
xi1
xi2
xim
COTS
x21 x22 x2m
y2 in-house
COTS
ARCHITECTURAL PHASE

34
C1
C2
Ci
Connectors
y1
x11
x12
x1m
in-house
COTS
yi in-house
xi1
xi2
xim
COTS
x21 x22 x2m
y2 in-house
COTS
ARCHITECTURAL PHASE

35OPTIMIZATION MODEL
average
number of
failures of a
component
instance
probability of
failure on-demand
Ntot
i the number of successful (i.e. failure free) tests
performed on an in-house instance
a very simple cost
(irrealistic?!) model
Selection boolean variables

36
Main aspects of the model:
-  Decision variables
-  Reliability growth model
(alternative models can be used)
-  Composition of reliability attributes
-  Additional variable on the number of tests
OPTIMIZATION MODEL

37
First Scenario
Behavioral
view

38
Second Scenario
Behavioral
view

39
Third Scenario
Behavioral
view

40
Parameters for COTS products
Parameters for in-house developed components

41
Model Solutions
Model solution for multiple values of
bound R between 0.89 and 0.99

42
Model Solutions
Model solution for multiple values of
bound R between 0.89 and 0.99

43
COST and RELIABILITY
Definining a set of optimization models
that allow quantifying the costs of service failure
repair/mitigation actions aimed at keeping the whole SBS
reliability over a certain threshold.
Quantifying the Influence of
Failure Repair/Mitigation Costs on
Service-Based Systems

44
Most reliability models for software that is assembled from basic elements
(e.g. objects, components or services [1] [2]) assume
that the elements are independent, namely they do not take into account the
dependencies that may exist between elements.
We have relaxed this assumption here and we have proposed a path-based
reliability model for Service-Oriented Architecture (SOA) that embeds the
“error propagation” property.
Probability that a service may propagate
an erroneous message when it receives as
input an erroneous message.
[1] Goseva-Popstojanova, K., Trivedi, K.S, “Achitecture based-approach to reliability assessment of software systems”,
Performance Evaluation, vol. 45 (2001),179-204.
[2] Kokash, N., “A Service Selection Model to Improve Composition Reliability”, Proc. of International Workshop on AI
for Service Composition, in conjunction with ECAI¡S06, 2006.
RELIABILITY and ERROR PROPAGATION

45
ARCHITECTURAL PHASE
REQUIREMENTS PHASE
Change management
MAINTENANCE PHASE
DEPLOYMENT PHASE
Optimization models

46
Same as previous model…
… with an additional constraint on performance…
… and the model solution also suggests the best
deployment of components on nodes.
DEPLOYMENT PHASE
…adding a constraint on performance…

47
UML software model
(Component Diagram,
Sequence Diagram, …)
Model builder
Model solver
Annotate
Transform
Optimization
model
Results
-  component
selection
- amount of
testing on
in-house
components,…
CODER FRAMEWORK
CODER (Cost Optimization under DElivery and Reliability
constraints) generates and solves the optimization model
Relevance of tool support

48
ARCHITECTURAL PHASE
REQUIREMENTS PHASE
Change management
MAINTENANCE PHASE
DEPLOYMENT PHASE
Optimization models

49
We intend to drives the choice of MAINTENANCE PLANS
in correspondence of a CHANGE SCENARIO (i.e a set of new
requirements) with the minimum cost and guaranteeing a
given level of reliability.
Selecting Optimal Maintenance Plans based on Cost/Reliability
Tradeoffs for Software Subject to Structural and Behavioral Changes
MAINTENANCE PHASE

51
A MAINTENANCE PLAN is a set of maintenance actions that address
a certain requirement.
(software) MAINTENANCE ACTIONS
Ø  Introducing new software units
Ø  Replacing existing unit instances with functionally equivalent ones
Ø  Modifying the interactions between software units in a certain
functionality

52
FEATURES N.
Maintaining a smartphone mobile application
Trancoding
Translation
Merging
Compression
Multimedia ServiceClient
Locations
Database
The Multimedia Service sends
(i) news in textual format,
(ii) news with both textual and video content, and
(iii) a geographical map with the user location to the Client.
EXISTING UNITS 7
NUM. INSTANCES 3
AVAILABLE
NEW UNITS 4
NUM. FUNCTIONALITY 3
A Running Example

53
Requirement ID

Maintenance Plan ID Maintenance Plan Description
req1

mp11
mp12
Adding a new service newun1
Adding a new service newun4 AND Replacing
Client with its second instance
req2

mp21
mp22
mp23
Replacing Trancoding with its second instance
req3
mp31
mp32
mp33
Locations Database with its first instance
Replacing Multimedia Service with its sec. instance
Requirement ID Requirement Specification
req1 The compression should also be performed in a different way
req2

The video should also be provided in AVI format
req3
The map should provide additional information, such as a list of the closer
hotels or restaurants
CHANGE SCENARIO
MAINTENANCE PLANS

54
min
| || |
Cost c x c zij ij h
h
NewS
j
Aval
i
n
h
i
= +
===
∑∑∑ 111
…
Re ( ) ( )
| || |
l pexec x z Rk ij ij
newbpex
h h
newbpn
h
NewS
j
Aval
i
n
k
K
ki kh
i
= − −
⎛
⎝
⎜
⎞
⎠
⎟ ≥
====
∏∑∏∑ 1 1
1111
θ θ
OPTIMIZATION MODEL
Number of busy periods
that the existing unit i
shows in the SD k after
the maintenance phase
…existing units

55
min
| || |
Cost c x c zij ij h
h
NewS
j
Aval
i
n
h
i
= +
===
∑∑∑ 111
…
Re ( ) ( )
| || |
l pexec x z Rk ij ij
newbpex
h h
newbpn
h
NewS
j
Aval
i
n
k
K
ki kh
i
= − −
⎛
⎝
⎜
⎞
⎠
⎟ ≥
====
∏∑∏∑ 1 1
1111
θ θ
OPTIMIZATION MODEL
Number of busy periods
that the new unit h
shows in the SD k after
the maintenance phase
…new units

56
FEATURES N.
Trancoding
Translation
Merging
Compression
Multimedia ServiceClient
Locations
Database
The Multimedia Service sends
(i) news in textual format,
(ii) news with both textual and video content, and
(iii) a geographical map with the user location to the Client.
EXISTING UNITS 7
NUM. INSTANCES 3
AVAILABLE
NEW UNITS 4
NUM. FUNCTIONALITY 3
A Running Example

57
Requirement ID

req1

mp11
mp12
req2

mp21
mp22
mp23
req3
mp31
mp32
mp33
req2

req3
CHANGE SCENARIO
MAINTENANCE PLANS

58
Model Solution for multiple values of
the probability of failure of
new units newun1 and newun4 and of R.
0
10
20
30
40
50
60
70
80
[0,0003, 0,00002]
[0,0003, 0,005]
[0,005, 0,00002]
[0,005, 0,005]
Cost(inKiloEuros,KE)
0,92
0,95
0,97
0,99
Reliability
threshold
R
Model Solutions

59
Model Solution for multiple values of
the probability of failure of
new units newun1 and newun4 and of R.
0
10
20
30
40
50
60
70
80
[0,0003, 0,00002]
[0,0003, 0,005]
[0,005, 0,00002]
[0,005, 0,005]
0,92
0,95
0,97
0,99
Reliability
threshold
R
Model Solutions

60
0
10
20
30
40
50
60
70
80
[0,0003, 0,00002]
[0,0003, 0,005]
[0,005, 0,00002]
[0,005, 0,005]
0,92
0,95
0,97
0,99
Reliability
threshold
R
Model Solutions
CHANGING THE MAINTENANCE PLAINS FOR A REQUIREMENT:
If mp11 is Replacing the service Compression with its second instance available
INSTEAD OF Adding a new service newun1,
we get the following solution:
[u11, u21, u31, u42, u51, u61, u72] [newun2], [mp11,mp21,mp31]. It costs 51 KE.

61
Resulting static structure of the system after the application of
mp11, mp21 and mp31.
Trancoding - u42
Translation - u51
Merging - u61
Compression - u72
Multimedia Service- u21Client - u11
Locations
Database- u31 newun2
A Running Example

62
Resulting a SD
after the
application
of mp11, mp21
and mp31.
removed
interactions
added
interactions
A Running Example

63
Requirement ID

req1

mp11
mp12
req2

mp21
mp22
mp23
req3
mp31
mp32
mp33
req2

req3
CHANGE SCENARIO
MAINTENANCE PLANS

64
ADAPTATION FRAMEWORK
- Selecting Optimal
Maintenance Plans
based on Cost/
Reliability
Tradeoffs.
-  Optimization of
adaptation plans
for a
service-oriented
architecture with
cost, reliability,
availability and
performance
tradeoff.

65
SOA domain … Some Extentions …
Let us assume that the composite service structure of each
service offered by the system is specified by using BPEL.
An example of activity tree
that represents a BPEL
process
(ii)  a significant subset of operators expressing the composition of services
are considered (e.g., while, flow,…);
(iii)  based on these different kinds of structured activities,
a new reliability model is defined;
(iv) availability and performance constraints are added to the model.
ADAPTATION ACTIVITIES:
•  Introducing new software services
•  Replacing existing service instances with
functionally equivalent ones
•  Modifying the interactions among services in a
certain external service

66
Optimization
Model
Formulation
cost

67
Optimization
Model
Formulation
reliability
and
availability

68
Optimization
Model
Formulation
performance

69An example of Output of the optimization model
The smartphone application example

70
Static aspect of the system after the application of
ap12, ap23 and ap32
An example of Output of the optimization model

71
A BPEL tree
after the
application of
ap12, ap23 and
ap32

72
ADAPTATION FRAMEWORK
- Selecting Optimal
Maintenance Plans
based on Cost/
Reliability
Tradeoffs.
-  Optimization of
adaptation plans
for a
service-oriented
architecture with
cost, reliability,
availability and
performance
tradeoff.
Other than the software
architecture,the hardware
architecture is taken into
account.

73
SUM UP AND
FUTURE PERSPECTIVES

74
• Quality attributes (closed form!)
• Model goal (reconfiguration, component selection, …)
• Target variables
• Parameters to estimate
• Any “composition” to exploit?
• Any specific context (services, components, cloud,…)?
• Role of workload and operational profile
• Model solution technique (exact, metaheuristics, …)
Optimization models – main aspects to consider

75
We have introduced several optimization models for non-
functional requirement validation
PROS
•  Easy representation of modular software (e.g. component-based,
service-oriented)
•  Flexibility in the definition of cost functions
•  Limited solution time for small/medium size problems (i.e. about
20 components and 10 instances for each component)
•  Easy exploration of multiple alternatives (quantification!)
•  Capability of embedding stochastic parameters
Conclusions

76
We have introduced several optimization models for non-
functional requirement validation
CONS
•  Only closed-form expressions can be adopted, and they do not
capture all relevant aspects of non-functional attributes
•  Exponential solution time for growing size problems (possibly
mitigated with meta-heuristic approaches)
•  …
•  Borderline research topic between Optimization and Software
Engineering -> not the highest acceptance rate of papers J
Conclusions

77
•  Application on real large scale problems
(metaheuristics)
•  Optimization models as a support to runtime decisions
(need quick-and-dirty solution approahes)
•  Stochastic optimization
•  Robust optimization
• …
Future perspectives

78
The ideas and results presented in this talk have been
achieved in collaboration with:
Vittorio Cortellessa, Università dell’Aquila
Fabrizio Marinelli, Università Politecnica delle Marche
Ivica Crnkovic, Mälardalen University
Raffaela Mirandola, Politecnico di Milano
Acknowledgments

79Some of our references…
•  Vittorio Cortellessa, Raffaela Mirandola, Pasqualina Potena: “Managing the evolution of a
software architecture at minimal cost under performance and reliability constraints”. Science of
Computer Programming (Elsevier), Vol. 98, Part 4, 2015, pp. 439-463.
•  Pasqualina Potena: “Optimization of adaptation plans for a service-oriented architecture with
cost, reliability, availability and performance tradeoff”, Journal of Systems and Software
(Elsevier), Vol. 86, Issue 3, March 2013, pp. 624-648.
•  Vittorio Cortellessa, Raffaela Mirandola, Pasqualina Potena: Selecting Optimal Maintenance
Plans Based on Cost/Reliability Tradeoffs for Software Subject to Structural and Behavioral
Changes. CSMR 2010:21-30
•  Vittorio Cortellessa, Fabrizio Marinelli, Pasqualina Potena: An optimization framework for
"build-or-buy" decisions in software architecture. Computers & OR (COR) 35(10):3090-3106
(2008)
•  Vittorio Cortellessa, Ivica Crnkovic, Fabrizio Marinelli, Pasqualina Potena: Experimenting the
Automated Selection of COTS Components Based on Cost and System Requirements. J. UCS
(JUCS) 14(8):1228-1255 (2008)
•  Vittorio Cortellessa, Ivica Crnkovic, Fabrizio Marinelli, Pasqualina Potena: Driving the
selection of cots components on the basis of system requirements. ASE 2007:413-416
•  Vittorio Cortellessa, Fabrizio Marinelli, Pasqualina Potena: Automated Selection of
Software Components Based on Cost/Reliability Tradeoff. EWSA 2006:66-81

Seminar pasqualina potena

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (12)

Similar to Seminar pasqualina potena

Similar to Seminar pasqualina potena (20)

Recently uploaded

Recently uploaded (20)

Seminar pasqualina potena