Functional and NonFunctional Analysis of ComponentBased Systems and Software Architectures

1

• Functional and Non-Functional Analysis of
  Component-Based Systems and Software Architectures

SEA GroupSoftware Engineering and Architecture
Group
2
Research Overview

• SEA Group
• Headed by Paola Inverardi
• 9 members (1 prof., 2 assist. prof., 6 ph.d.
  students)
• Group Objectives
• To propose techniques for Software Analysis
• Software Architecture
• Middleware
• Component-based systems

3
List of Research Topics

• Model Checking (Pelliccione)
• Testing (Muccini)
• Middleware and Applications (Caporuscio)
• Correct Assembly of Components (Tivoli)
• Adaptable Applications (Mancinelli)

Functional Analysis

• Adequacy of notations for non-functional
  validation
• Composability of non-functional attributes
• Model-to-model transformations
• Quality-based system reconfiguration

Non Functional Analysis
4
Software Architecture-based Model Checking
(principal investigator Patrizio
Pelliccione) pellicci_at_di.univaq.ithttp//www.
di.univaq.it/pellicci
5
Goal
6
Charmy
SA spec
properties
Step2
Step1
Step3
7
www.di.univaq.it/charmy
8
Software Architecture-based Testing(principal
investigator Henry Muccini) muccini_at_di.univaq.i
thttp//www.di.univaq.it/muccini
http//www.HenryMuccini.com
9
Goal

• SA-based Code TestingIEEE_TSE04,
  FASE04ltJoined with A. Bertolino, P. Inverardigt
• SA-based Regression Testing ltJoined with D.
  Richardsongt
• Testing plus Model-Checking of SAITM04,
  submittedltJoined with A. Bucchiarone, P.
  Pierini, P. Pelliccionegt
• Testing of Product Line ArchitecturesTacos03ltJ
  oined with A. van der Hoek, A. Bucchiaronegt

10
SA-based Code Testing IEEE_TSE 04
Code
Software Architecture spec.
Class ------- ------ ------ -------
XClient
ClientA
ClientB
ClientC
Mapping/Tracing ???
11
SA-based Regression Testing Submitted
12
Model-Checking Testing Regression Testing
13
Middleware and Applications(principal
investigator Mauro Caporuscio) caporusc_at_di.univ
aq.ithttp//www.di.univaq.it/caporusc
14
Design and Analysis of Middleware (p/s)
Component
Component
Mobility Support Service for Publish/Subscribe
Middleware MobiKit
Middleware for CSCW Yaco
Analysis of Middleware Model Checking
Component
15
Design and Analysis of Middleware-based
Applications
Component
Component
Component
Component
Development of middleware-based applications
Compositional Verification of middleware-based
Applications
Component
Component
16
Correct Assembly of Components(principal
investigator Massimo Tivoli) tivoli_at_di.univaq.i
thttp//www.di.univaq.it/tivoli
17
Correct automatic assembly of software components

• Building a system from reusable software
  components or from COTS components introduces a
  set of problems
• how to restrict the systems behavior to a subset
  of safe behaviors?
• coordinator synthesis for a correct and automatic
  assembly of COTS components
• how to augment the systems behavior to introduce
  more sophisticated interactions among components?
• coordinator synthesis wrapper insertion for
  automatically enhancing the coordinator
  communication protocol.

18
Method description coordinator synthesis
C1
C2

• deadlock-free
• coordination policies satisfying

C4
C3
19
Method description wrapper insertion
C1
C2
extra-logic specification (e.g.
encrypt/decrypt with C2)
extra-logic specification (e.g. data
compression with C1 and C2)
CBA
K
K
C4
C3
C1
C2
K
K
The composition of K and K is the new
coordinator of the enhanced deadlock-free CBA
We achieve compose-ability in the application of
extra-logic
C4
C3
20
Adaptable Applications(principal investigator
Fabio Mancinelli) mancinel_at_di.univaq.it http/
/www.di.univaq.it/mancinel
21
Adaptable Applications

• Provide a resource aware framework and an
  approach which enable and support the development
  and the distribution of adaptable applications
• Capable of supporting application development
• Capable of establishing the correctness of the
  application with respect to the resource
  available on the execution environment
• Capable of performing the adaptation of the
  applications with respect to the resource
  available on the execution environment
• Declarative
• Supported by a deductive process

22
Adaptable Applications Approach

• Step1 Development
• Source code development
• Definition of an adaptation policy
• Source code compilation and Adaptation predicate
  generation
• Step2 Proof
• Proof generation given the execution environment
  resource profile
• Step3 Adaptation
• Construction of the final code from the annotated
  bytecode and the proof information

23
Adaptable Applications Framework
Step1
Step2
Step3
24
List of Research Topics

• Model Checking (Pelliccione)
• Testing (Muccini)
• Middleware and Applications (Caporuscio)
• Correct Assembly of Components (Tivoli)
• Adaptable Applications (Mancinelli)

Functional Analysis

• Adequacy of notations for non-functional
  validation
• Composability of non-functional attributes
• Model-to-model transformations
• Quality-based system reconfiguration

Non Functional Analysis
25
Research directions in the non-functional area
PERFORMANCE
We mostly work at the architectural level
Model-to-model transformations
Resources representation
Notations comparison
SECURITY in Software Architecture
System reconfiguration
PERFORMABILITY and mobility
RELIABILITY
Performance-based RISK analysis
UML profiling
A general issue composability of
non-functional attributes
Cost/Reliability tradeoff
Non
26
Performance(Paola Inverardi, Vittorio
Cortellessa, Antinisca Di Marco) inverard,corte
lle,adimarco_at_di.univaq.it
Non
27
PERFORMANCE notations comparison
(1) (Cortellessa, Di Marco, Inverardi,
FOCLASA2003)
Software developers world (vocabulary) is
intrinsically distant from performance analysts
one
How can we help a software designer to choose a
notation that better supports performance
analysis?
Non
28
PERFORMANCE notations comparison (2) (Balsamo,
Di Marco, Inverardi, Marzolla, WOSP2004)

• Hard to apply the existing tools to real case
  studies
• Limits of the underlying approaches
• Complexity of the case studies

Starting notations
Joint use of tools may be better than using only
one tool

• How do we choose the set of tools to be jointly
  used?

at least they must start from the same software
notation
Analysis tools

• How do we combine the obtained results to
  determine a suitable issue?

it depends on the underlying approaches
Analysis results
Non
29
PERFORMANCE model-to-model transformations (Cort
ellessa, Di Marco, Inverardi, QEST2004)
Basic Software Model (original notation)
Validation of Functional Requirements
Ready-to-validation Model (possibly new
notation)
Validation of Non-Functional Requirements
Additional Information software annotations
Non
30
PERFORMANCE model-to-model transformations (Cort
ellessa, Di Marco, Inverardi, QEST2004)
UML Use Case Diagrams, Sequence
Diagrams, Deployment Diagrams
Validation of Functional Requirements
Operational profile, Platform characteristics
Performance Validation
Non
31
PERFORMANCE model-to-model transformations (Cort
ellessa, Di Marco, Inverardi, QEST2004)
UML 2 Use Case Diagrams, Sequence
Diagrams, Component Diagrams
Validation of Functional Requirements
Operational profile, Component execution rates
Performance Validation
Non
32
PERFORMANCE resources representation (Cortelless
a, Gentile, ISORC2004)
Using the same notation to represent a software
architecture and the middleware/hardware
infrastructure
Non
33
PERFORMANCE resources representation (Cortelless
a, Gentile, ISORC2004)
What happens in the resource side
What happens in the software side
Non
34
PERFORMANCE system reconfiguration (Castaldi,
Di Marco, Inverardi, RAMSS2004)
Reconfigure it dynamically
We want to
Monitor its performance
a framework
We reach our aims by means of
Decide its next running configuration
Non
35
PERFORMANCE system reconfiguration (Castaldi,
Di Marco, Inverardi, RAMSS2004)
Non
36
Reliability(Vittorio Cortellessa) cortelle_at_di.u
nivaq.it
Non
37
RELIABILITY an UML profile (Cortellessa,
Pompei, WOSP2004)
0...1
REuser
2
REhost
1...
1
1...
1...
REcomponent
REservice
1...
0...
1
2
1...
1
REconnector
1
Non
38
RELIABILITY UML profile and bayesian
model (Cortellessa, Pompei, WOSP2004) (Cortellessa
, Cukic, WOSP2002)
This type of model
?(S) ?(C1) ? ?(C2) ? ? ?(Cn)
can become as follows for reliability modeling
REservice(j).REprob
REcomponent(i).REcompfailprob
FP(S) 1 - Sj1K p(j) ? ( ?i1N
(1-compfp(i))bp(i,j) ? ?(?(l,i))
(1-connfp(l,i))nms(l,i,j) )
REcomponent(i).REbp(j)
REconnector(l,i).REnummsg(j)
REconnector(l,i).REconnfailprob
Non
39
... other recent work in progress ...
Performance-based risk analysis (Ammar,
Cortellessa, Goseva-Popstojanova, submitted to
IEEE-TSE) Performability and mobility (Bracchi,
Cortellessa, WOSP2004, ISSRE2004) Security in
Software Architectures (Inverardi,
Mostarda) Cost/reliability tradeoff in
CB (Cortellessa, Marinelli)
Non
40
AN OPEN QUESTION Which shared playground to
integrate functional and non-functional analysis
of software architectures?
Non
41
A framework for the integration (SEA Group,
TACoS2004)
Non