Assessing dependability for mobile and
ubiquitous systems:
Is there a role for Software Architectures?
Paola Inverardi
Software Engineering and Architecture Group
Dipartimento di Informatica
Università degli Studi dell'Aquila
I-67100 L'Aquila, Italy
Setting the context
» Software architecture
- gives structure to the composition mechanism
- imposes constraints to the interaction mechanism
> roles, number, interaction mode, etc.
» Mobile & Ubiquitous scenario
- location-based
- resource-aware
- content-based
- user-need-aware
SEA Group
2
Context Awareness
» (Physical) Mobility allows a user to move out of his
proper context, traveling across different contexts.
» How different? In terms of (Availability of)
Resources (connectivity, energy, software, etc.) but
not only …
» When building a closed system the context is
determined and it is part of the (non-functional)
requirements (operational, social, organizational
constraints)
» If contexts change, requirements change  the
system needs to change  evolution
SEA Group
3
When and How can the system change?
» When? Due to contexts changes  while it is operating 
at run time
» How? Through (Self)adaptiveness/dynamicity/evolution
Different kind of changes at different levels of granularity,
from software architecture to code line
» Here we are interested in SA changes
SEA Group
4
The Challenge for Mobile & Ubiquitous scenario
» Context Awareness : Mobility and Ubiquity

» (Self-)adaptiveness/dynamicity/evolution: defines
the ability of a system to change in response of
external changes
» Dependability: focuses on QoS attributes
(performance and all ---abilities)
It impacts all the software life cycle but …
How does the SA contribute to dependability?
SEA Group
5
Dependability
» the trustworthiness of a computing system which
allows reliance to be justifiably placed on the service
it delivers ...
Dependability includes such attributes as reliability,
availability, safety, security. (see IFIP WG 10.4 on
DEPENDABLE COMPUTING AND FAULT TOLERANCE
http://www.dependability.org/wg10.4/)
How do we achieve dependability? All along the
software life cycle from requirements to operation to
maintenance.
By analysing models, testing code, monitor
execution
SEA Group
6
Dependability and QoS attributes
» analysing models: functional and non-functional,
several abstraction levels, not a unique model
» testing code: various kind of testing e.g. functionalbased, operational-based (still models behavioral
and stochastic , respectively)
» monitor execution: implies monitoring (yet another
… model of) the system at run time, it impacts the
middleware
» Focus is on models, from behavioral to stochastic
SEA Group
7
Models for SA (examples)
» System dynamic model (LTS, MSC, etc)
» Queuing Network models (+-extended) derived from
the dynamic models
» Models analysis, e.g. reacheability for deadlocks
etc.
» Performance indices evaluation for QN
SEA Group
8
SOFTWARE ARCHITECTURES
» Closed Software Architectures: components +
connectors
» Architectural Styles: family of similar systems. It
provides a vocabulary of components and connector
types, and a set of constraints on how they can be
combined.
» Architectural Patterns: well-established solutions to
architectural problems. It gives description of the
elements and relation type together with a set of
constraints on how they may be used.
SEA Group
10
Variability dimensions in SA
C1
C2
C3
C1
C2
C3
(a)
(b)
» Removal/addition of connector instances by
referring to (a), removing the connector between C2
and C3 produces the SA shown in (b). The vice
versa concerns the addition of a connector instance.
SEA Group
12
Variability dimensions in SA
C1
C2
C1
C3
C3
(a)
(c)
» Removal/addition of both component and connector instances
by
referring to (a), removing the component C2 and its connectors
produces the SA shown in (c). The vice versa concerns the
addition of a component instance and two connector instances.
SEA Group
13
Variability dimensions in SA
C1
C2
C1
C2
2
1
K
3
C3
(a)
C3
(b)
» new component and/or connector types the introduction of new
types of components and connectors makes an existing SA
evolving in a new SA. Indeed, some evolution may lead to the
adoption of a dierent architectural style. An example of this
kind of change is shown in (d) where one can image to
introduce a new type of connector, e.g., a mediating connector
K in the SA of (a)
» Clearly, some properties that hold for (d) might not hold in (a)
SEA Group
14
and vice versa, although the two systems can be equivalent
with respect to the semantics of the provided functionalities.
Variability dimensions in SA
C1
C1
C3
(c)
(e)
R
1
R
» Removal/addition of component instances in (c), removing the
SEA Group
15
component C3, without removing the connector where it is attached,
produces the SA in (e). This SA is partially instantiated. We can
reason about the properties of C1, the connector, the component
abstraction specified by the role R1, and their composition.
Systems having a partially specified SA are open. They allow a
certain degree of variability by defining variation points such as the
role R1. However, in (e), all the possible instantiations of a variation
point have to fulfill a given specification. E.g., every component that
would enter the system in (e), by binding the role R1, has to satisfy
the requirements of R1.
Software Architecture and dependability
» For closed systems allows for predictive analysis:
from the SA dependability properties are deduced
» For open systems the Software Architecture may
represent the invariant with respect to the
applications changes.
» Depending on the architectural change different
level of dependability can be assured by prepreparing the models and the verification strategies
» Allows for implementing reusable verification
strategies.
SEA Group
16
Evolving Systems
» Systems that change structure and/or behaviour
» Change the four Ws:
- Why
there is the need to change?
- What
does (not) change ?
- When
does the change happen?
- What/Who
SEA Group
17
How is the change managed?
Why
» Again the Software Engineering perspective …
- To meet requirements: it can be because the
requirements evolved or it can be that the system
does not behave properly
Functional and Non functional requirements
Some examples of functional and non functional
adaptation
SEA Group
18
What: we only consider Software Architecture
» Structure:
- components can get in and out, new connectors i.e.
new connections and/or new interaction protocols
» Behavior:
- Components can change their functionality,
connectors can change their protocols
Remember: Non Funtional requirements result in
functional behavior …
SEA Group
19
When
- during the system’s lifetime. Many stakeholders …
- Does this mean run time? Not necessarily
- It is related with the Static vs Dynamic issue
SEA Group
20
What/Who?
» The How, i.e. the mechanisms to achieve the
change
- It can be a configuration manager or it can be the
system itself
- Involves monitoring, evaluation, decision making
about the change alternatives etc.
It concerns the self *-issues
SEA Group
21
Few Examples
- Synthesis
- Performance
- Graph Grammars -- Le Metayer
- ArchJava
SEA Group
22
EVOLUTION
1
SYNTHESIS
SEA Group
23
CBSE-Synthesis
Problem: The ability to establish properties on
the assembly code by only assuming a
relative knowledge of the single components
properties.
SEA Group
24
A software architecture represents the
reference skeleton used to compose
components and let them interact:
interactions among components are
represented by the notion of software
connector.
Problem description
» Given a set of components C and a set of properties P
automatically derive an assembly A of these components
which satisfies every property in P.
» Basic ingredients:
- the type of components we refer to (COTS, black-box);
- the type of properties we want to check (functional,
interaction behaviors);
- the type of systems we want to build (component-based).
SEA Group
25
Basic idea
» A simple software architecture structure which exploits
the separation between functional behavior and
Integration/Communication behavior.
» Extra information at component level: component actual
behavior and assumptions.
» Our approach:
- detect software anomalies;
- remove software anomalies;
SEA Group
26
- guarantee a given coordination policy.
Modeling the system
» Partial behavioural specification of the composed system:
- bMSCs (basic Message Sequence Charts)
> a bMSC describes a single scenario as a set of finite interactions between a
set of components;
- HMSCs (High-level Message Sequence Charts)
> a HMSC provides the means for composing bMSCs as a directed graph whe
nodes represent bMSCs and edges indicate their possible continuations.
» Specification of the behavioural properties to be enforced:
- LTL (Linear-time Temporal Logic)
> is a formalism for describing sequences of transitions between states in
reactive system;
> operators are provided for describing events along a single computation path
SEA Group
27
Connector Free Architecture
Component 1
Component 2
channel
channel
Component 3
A Connector Free Architecture (CFA) is a set of
components directly connected in a synchronous way.
In CCS :
SEA Group
28
(C1 | C2 | ... | Cn) \ Ui=1..n Acti
Connector Based Architecture
top
REQUEST
bottom
channel 1
top
Connector
channel 2
channel 3
bottom
top
top
Component 2
NOTIFICATION
Component 1
Component 3
bottom
bottom
In CCS:
» differences from C2 style:
(C1[f1] | C2 [f2] | ... | Cn[fn] | K) \U i=1..n Acti[fi]
- synchronous message passing;
is the synthesized
connector, fi are suitable relabelling
- K
connectors
cannot directly communicate;
such
fi(devices,
a)=ai, forwithout
all aAct
- functions
connectors are
only that
routing
anyi filtering policies;
SEA Group
29
- connectors have a strictly sequential input-output behavior.
Approach description: 3-step method
Connector Free Architecture
Component 1
Component 3
Component 2
local views of each component
Component
Component
11 1
Component
Component33
Component
Component 3
Deadlock-free
Connector
Failure-free
Connector
Connector
SEA Group
30
Component22
Component
Component 2
Deadlock-free
Connector
Connector
Based
Based
Architecture
Architecture
Failures-free
Connector
Based
Architecture
Connector code
deadlock-freeness
Behavioral
property
(assembly code)
The four Ws: Synthesis
*
the four Ws:
- Why
there is the need to change?
> To correct functional behavior. E.G. Avoid deadlock
- What
does (not) change ?
> The topological structure and the interaction behavior
- When
does the change happen?
> At Assembly time but also …
- What/Who
how the change is managed?
> An external entity: Synthesis
SEA Group
31
EVOLUTION EXAMPLES: 2
PERFORMANCE
SEA Group
32
Ex. 2 - PERFORMANCE : system reconfiguration
Caporuscio-Di Marco-Inverardi
Reconfigure it dynamically
We want to …
Monitor its
performance
Running
software application
a framework
SEA Group
33
Non
We reach our
aims by means
of …
Decide its next running configuration
The Adaptation process
2
1
Plan
Changes
monitor
I1:C1
Deploy
change
description
Evaluate
and Monitor
Observations
Adaptation
Management
data
I2:C2
I3:C3
I5:C2
Current application
configuration
RP1
2
I4:C4
RPk
Perf. Model
Alt1
Enact changes and
Collect observations
Perf. Model
Altk
Perf. Model
Altn
Results
Results
Other
factors
RPk
1
Performance
Model of the SA
Evolution
Management
Decider
Implementation
I1:C1
I2:C2
I3:C3
3
Maintain Consistency
and System Integrity
(a) The Processes
34
Reconfiguratio
RPn n policies
Solver
Results
SEA Group
Performance
model of SA
New application
configuration
3
I4:C4
New
performance
model of SA
(b) Flow of the activities in an adaptation step
1
Issues to address
» What is the relevant data to collect? And how to use it?
- Data collected is more fine-grained than the performance model
parameters.
» When should we reconfigure the application? Which are the
reconfiguration alternatives?
- It depends on the application.
» Models have to be modified and evaluated online (fast solution
techniques).
- Which performance model should we use?
- How do we take the decision on the next configuration?
SEA Group
35
- Different aspects should be considered (security, resources
availability,…)
The four Ws: Performance
*
the four Ws:
- Why
there is the need to change?
> To correct non- functional behavior. i.e. Adjust
Performance
- What
does (not) change ?
> The topological structure
- When
does the change happen?
> At run time …
- What/Who
how the change is managed?
> An external entity: the configuration framework
SEA Group
36
EVOLUTION EXAMPLE: 3
GRAPH GRAMMARS
SEA Group
37
Describing Software Architecture Styles Using Graph
grammars (Daniel Le Métayer)
» Software architecture as graphs: nodes =
components, interactions only through arcs (links)
» architecture style = graph grammar i.e. a class of
architectures
» The dynamic evolution of an architecture is defined
by a “coordinator” (creating and removing entities
and links).
» The rules governing the coordinator behavior are
SEA Group
38
statically checked for conformance wrt the graph
grammar
SEA Group
39
» The architecture represented by the above graph
involves two clients c1 and c2, two servers s1 and
s2, a manager m0 and x0. It is formally defined as
the set D:
» {CR(c1, m0), CA(m0, c1), C(c1), CR(c2, m0),
CA(m0, c2), C(c2), SR(m0, s1), SA(s1, m0), S(s1),
SR(m0, s2), SA(s2, m0), S(s2), X(x0), M(m0)}
SEA Group
40
» The client-server architecture style:
» HCS = [{CS, CS1}, {M, X, C, S, CR, CA, SR, SA}, R,
CS]
» with R :
» CS  CS1(m)
» CS1(m)  CR(c, m), CA(m, c), C(c), CS1(m)
» CS1(m)  SR(m, s), SA(s, m), S(s), CS1(m)
» CS1(m)  M(m), X(x)
SEA Group
41
» the coordinator CooCS which applies to a clientserver architecture:
» X (x) M(m)  X(x ) M(m) CR(c m) CA(m c) C(c)
» CR( c m) CA (m c) C (c)  Ø
» The two rules describe, respectively, the introduction
of a
new client in the architecture and its departure.
SEA Group
42
The four Ws: Le Metayer
*
the four Ws:
- Why
there is the need to change?
> Topological evolution
- What
does (not) change ?
> The topological structure
- When
does the change happen?
> At run time …
- What/Who
how the change is managed?
> An external entity and the coordinator
SEA Group
43
EVOLUTION EXAMPLE: 4
ARCHJAVA
SEA Group
44
Software Architecture
» The motivation for ArchJava is the following:
- Using an ADL for specifying the architecture causes
problems since there could be inconsistencies
between the implementation and the specification
- This becomes a bigger problem as the software
changes
» ArchJava extends Java with constructs for
specifying the architecture of the software
- Using ArchJava software developers specify the
architecture of the software within the program.
SEA Group
45
- The architecture and the program are always
consistent
Checking the Architectural
Constraints
» A program which implements an architectural
specification must obey communication integrity:
- Communication integrity means that the
components only communicate directly with the
components they are connected to in the
architecture.
» ArchJava guarantees communication integrity
between the architecture and its implementation
SEA Group
46
The ArchJava Language
» ArchJava adds new language constructs to support
- Components
> Classes with architectural constraints
- Ports
> Definition of the communication interfaces of the
components
> Declares the methods required and provided for
communication
- Connections
> Connect different ports
SEA Group
47
> Components can only communicate with the components
that they are connected to and their subcomponents
Communication Integrity
» A component can only communicate with the
components it is connected to in the architecture
» ArchJava enforces integrity for control flow
» No method calls are permitted from one component
to another except
- From a parent to its immediate subcomponent
- Through connections in the architecture
SEA Group
48
Communication Integrity
» ArchJava allows
- Calls between connected components
- Calls from a parent to its immediate subcomponents
- Calls to shared objects
» ArchJava forbids
- External calls to subcomponents
- Calls between unconnected subcomponents
- Calls through shared objects
Compiler
Scanner
Parser
out
SEA Group
49
in
Codegen
out
in
ArchJava Type System
» ArchJava Type system enforces the following
invariant
- Components can only get a typed reference to
subcomponents and connected components
» It is not possible to cast a component to an Object
and avoid the restrictions on communication
between components
- This will cause an exception
SEA Group
50
Dynamic Architectures
» It is possible to establish dynamic architectures
using ArchJava
» Instances of components can be dynamically
created using new syntax as with ordinary objects
» At creation time each component records the
component instance that created it as its parent
component
» Communication integrity puts restrictions on how
component instances can be used
- Typed references to subcomponents should not
escape the scope of their parent component
SEA Group
51
- This requirement is enforced by putting restrictions
Dynamic Connections
» Connections can be formed dynamically using a
connect expression
» A connect expression must match a connect pattern
declared at the enclosing component
» A connection pattern is used to describe a set of
connections that can be instantiated at run time
» A connect expression matches a connection pattern
if the connected ports are identical and each
connected component instance is an instance of the
type specified in the pattern
SEA Group
52
The four Ws: ARCHJAVA
*
the four Ws:
- Why
there is the need to change?
> Topological evolution
- What
does (not) change ?
> The topological structure and the behavior
- When
does the change happen?
> At run time …
- What/Who
how the change is managed?
> It is self managed. The application steers it
SEA Group
53
Mobile and ubiquitous systems
» Open systems accounting for
- changes in the context
- user needs
» Context
- network context conditions
- execution environment characteristics
» User needs as dependability requirements
- availability, reliability, safety, and security
- e.g., availability as performance indexes
> responsiveness, throughput, service utilization
SEA Group
54
The role of the SA in an open world
» Changes in both the context and user needs might imply
architectural configuration changes
- e.g., addition/arrival, replacement, removal/departure of
components
» The closed world assumption does not hold anymore
» Dependability cannot be deduced only by composition anymore
- it can be unfeasible to fix a priori the SA and, then, deduce
dependability
- the experienced dependability might be not the wished one
» The role of the SA is inverted
» Composition induced by dependability
- a priori specification of a wished dependability degree
SEA Group
55
- dynamic induction of the SA that fulfills as best as possible the
specified dependability
Composition induced by user-level dependability requirements 1/2
» Promising technologies
- service mash-up
- widget Uis
> SAMSUNG Widgets
> Win Vista, Yahoo, MAC OS Gadgets
» They shift composition from the
developer-level to the end-user-level
- to ease the consideration of user-level
dependability requirements
» However, they are still conceived to be used with the closedworld assumption in mind
SEA Group
56
Composition induced by user-level dependability requirements 2/2
» While keeping a high-level composition mechanism,
suitable technologies should
- allow the user to specify dependability requirements
- propose the architectural configuration enabling the
composition that fulfills dependability
- dependability should be kept despite of possible
context changes
> dynamic induction and evolution of the system SA
SEA Group
57
Widget UIs in e-learning
» Two possible scenarios illustrating
(a) how, in an open world, a SA fixed a priori can
imply, a possibly, unexpected dependability
(b) how, instead, dependability specified a priori can
imply the “best possible” SA
SEA Group
58
e-Learning scenario (a)
GPR
S
SEA Group
59
GPR
S
WiFi
e-Learning scenario (b)
GPR
S
COS Feature
T
s
High Full
Low Limited
SEA Group
60
GPR
S
WiFi
A completely open scenario: CONNECT
» Ubiquitous systems: components travel around willing to
communicate with only their own knowledge
» Exploit the process: discover-learn-mediate-communicate
» No global SA assumed
» The SA in terms of components and connectors results from
the completion of the process
» and dependability … ? It is built in the composition e.g.
embedded in the connectors (ref. Synthesis, de Lemos08).
SEA Group
61
CONNECT
Emergent Connectors for Eternal Software
Intensive Networked Systems
FET ICT Forever yours
7FP-Call 3 - ICT-2007
Coordinated by Valerie Issarny INRIA
http://connect-forever.eu/
SEA Group
62
CONNECT scenario
SEA Group
63
CONNECT process
SEA Group
64
Introduction
» Challenge 3
- the automated synthesis of CONNECTors according to
the interaction behaviors of networked systems seeking
to communicate.
Main Objectives:
» to devise automated and compositional approaches to
the run-time synthesis of connectors that serve as
mediators of the networked applications’ interaction at
both application- and middleware-layer
- synthesis of application-layer conversation protocols
- synthesis of middleware-layer protocols
- model-driven synthesis tools
SEA Group
65
65
Synthesis of application-layer conversation protocols
» To support the automated construction of applicationlayer connector models
- 1: identifying the conditions on the networked
applications interaction and composition that enable runtime connector synthesis
> SA and connector patterns
- 2: the synthesis process is seen as a behavioral model
unification process
> ontologies
> modeling notations
> unifying know and unknown information
» The challenge
SEA Group
66
66
- compositionality and evolution
synthesis process steps
Env
model
Env
model
ontology
desc.
ontology
desc.
connector model
Env
model
ontology
desc.
SEA Group
67
67
Env
model
ontology
desc.
synthesis process steps
ontology
desc.
ontology
desc.
connector model
ontology
desc.
SEA Group
68
68
ontology
desc.
synthesis of middleware-layer protocols
» Developing protocol translators
- to make heterogeneous middleware interoperate
- w.r.t. required non-functional properties
» The challenges
- interoperability of both data transfer protocols and
interaction schemes
- ensuring, at run-time, end-to-end properties
> availability, reliability, security, timeliness
SEA Group
69
69
The interoperability problem in ubiquitous
environments
» Ubiquitous computing vision
» Interoperability: concerns the observable/visible behavior of the
applications at interface level
» Possible solution: automated mediators
» Mediator concept has been introduced
- to integrate heterogeneous data sources
- as design pattern
- in semantic web and web services
» Automated mediation still remains a challenge
SEA Group70
70
Mediating connectors (aka Mediators)
» In modern networked systems many heterogeneity dimensions
arise and need to be mediated
- mediation of data structures
> data level mediators
> ontologies
- mediation of functionalities
> functional mediators
> logic-based formalism
- mediation of business logics
> application-layer protocol mediators
> process algebras, finite state machines, LTSs
- mediation of message exchange protocols
> middleware-layer protocol mediators
SEA Group
71
71
> composition of basic mediation patterns
CONNECTor synthesis
» To devise automated and compositional approaches to the run-time
synthesis of CONNECTors that serve as mediators of the networked
applications’ interaction at both application- and middleware-layer
-
SEA Group72
72
Synthesis of application-layer conversation protocols
Towards the goal
» Preliminary theory of mediators between mismatching protocols at the
application level
» Theory of mediators (at the application level)
- Definition and formalization of protocol matching and mapping
relationships over application-level protocols
- CONNECTor synthesis algorithm
SEA Group73
73
Foundations for the automated mediation of heterogeneous
protocols
» Modeling notation used to abstract the behavior of the
protocols to be bridged
- finite state machines
» Matching relationship between the protocol models
- necessary (but non-sufficient) conditions for protocol
interoperability
> e.g., “sharing the same intent”
- data and functional mediations are assumed to be provided
» Mapping algorithm for the matching protocol models
- sufficient (and “most permissive”) conditions for protocol
interoperability
> e.g., “talking, at least partly, a common language”
- a concrete mediator as final output
SEA Group
74
74
The instant messaging example
do they “share the same
intent"?
SEA Group
75
75
Application Level (AL) Interoperability
Assumptions:
» Two applications with known interaction protocols, i.e. visible
behavior
» Two known ontologies + ontology mapping
» A specification of what is the purpose of the conversation
(initial and final states)
- Notion of coordination policies
» Protocol compatibility expressed via equivalence on the
coordination policies
SEA Group76
76
Interoperability problem: An example
P
Q
OP
OQ
LQ={msg,…}
LP={message,ack,…}
SEA Group
77
Interoperability problem: The proposed
solution
Protocol
P
OP
Abstracted
SEA Group
78
AP
C
?

Q
OQ
AQ
Formalization of the solution (1/4)
Protocol
OP
SEA Group
79
P
Formalization of the solution (2/4)
To build the abstracted…
Protocol
P
OP
Abstracted
SEA Group
80
AP
Formalization of the solution (3/4)
Abstracted
SEA Group
81
AP
equivalent?
Do they share common conversations?
AQ
Formalization of the solution (4/4)
Protocol
P
Q
C
||
||
||
||
SEA Group
82
Discussion on the mismatches coverage
§ Extra send mismatch
§ Extra receive mismatch
§ One send - many receive mismatches
§ Many send - one receive mismatch
§ Signature mismatch
§ Ordering mismatch
 Mismatch coverage: all the 6 + combinations (e.g., mismatch
5 combined with the remaining mismatches)
SEA Group83
83
Related work
»
Basic and complex mismatches, automatic mediation:
- Web services and semantic Web
> Solutions are discussed informally and have quite vague definition of adopted
mapping
> Semi-automated approaches
»
Theory to characterize and solve the application interoperability
- Augmented interfaces
> Semi-automated (interface mapping)
> Assume same messages ordering
»
Services interoperability problem
- Social applications in Web2.0
> Semi-automated (identification of mismatches and adaptors)
SEA Group
84
Conclusion
» first formalization of mediating connectors in the
direction of the on the fly interoperability
» The approach partially covers the existing
mismatches
» Assumptions:
- partial structural similarities
- data is not considered
SEA Group
85
85
Future work
» Automation
» Compositionality
» Model-driven techniques for the synthesis of the
mediator actual code
» Evolution
» Non-functional characteristics of the protocol behavior
» Dependability assurances
SEA Group
86
86
References
Betty H. C. Cheng, Rogério de Lemos, Holger Giese, Paola Inverardi, Jeff Magee:
Software Engineering for Self-Adaptive Systems [outcome of a Dagstuhl Seminar]
Springer 2009
Patrizio Pelliccione, Paola Inverardi, Henry Muccini: CHARMY: A Framework for
Designing and Verifying Architectural Specifications. IEEE Trans. Software Eng. 35(3):
325-346 (2009)
Paola Inverardi, Massimo Tivoli: The Future of Software: Adaptation and
Dependability. ISSSE 2008: 1-31
Massimo Tivoli, Paola Inverardi: Failure-free coordinators synthesis for componentbased architectures. Sci. Comput. Program. 71(3): 181-212 (2008)
Marco Autili, Paola Inverardi, Alfredo Navarra, Massimo Tivoli: SYNTHESIS: A Tool for
Automatically Assembling Correct and Distributed Component-Based Systems. ICSE
2007: 784-787
Mauro Caporuscio, Antinisca Di Marco, Paola Inverardi Model-Based System
Reconfiguration for Dynamic Performance Management, Elsevier Journal of
Systems and Software JSS, 80(4): 455-473 (2007).
»
SEA Group
87
Patrick H. S. Brito, Rogério de Lemos, Cecília M. F. Rubira: Development of FaultTolerant Software Systems Based on Architectural Abstractions. ECSA 2008: 131-147
R. Allen and D. Garlan. A formal basis for architectural
connection. ACM Trans. Softw. Eng. Methodol., 6(3):213{249,
1997.
G. R. Andrews. Paradigms for process interaction in
distributed programs. ACM Comput. Surv., 23(1):49{90, 1991.
M. Autili, P. D. Benedetto, and P. Inverardi. Context-aware
adaptive services: The plastic approach. In Proc. of
Fundamental Approacches to Software Enginneering
(FASE'09), volume 5503 of LNCS, pages 124{139. Springer,
2009.
L. Bass, P. Clements, and R. Kazman. Software Architecture
in Practice. Addison Wesley, 1998.
SEA Group
88
P. H. Brito, R. Lemos, and C. M. Rubira. Development of faulttolerant software systems based on architectural abstractions.
In ECSA '08, pages 131{147, Berlin, Heidelberg, 2008.
Springer-Verlag.
D. Garlan. Formal modeling and analysis of software architecture:
Components, connectors, and events. In M. Bernardo and P.
Inverardi, editors, SFM, volume 2804 of Lecture Notes in Computer
Science, pages 1{24. Springer, 2003.
D. Garlan, J. M. Barnes, B. R. Schmerl, and O. Celiku. Evolution
styles: Foundations and tool support for software architecture
evolution. In WICSA/ECSA,2009.
V. Issarny and A. Zarras. Software architecture and dependability. In
in Formal Methods for Software Architecture, M. Bernardo, P.
Inverardi (Eds.), LNCS 2804, 2003.
M. Autili, P. Di Benedetto, P. Inverardi, D. A. Tamburri. Towards selfevolving context-aware services. In Proc. of Context-aware Adaptation
Mechanisms for Pervasive and Ubiquitous Services DisCoTec'08,
volume 11, 2008. http://eceasst.cs.tu
berlin.de/index.php/eceasst/issue/view/18.
R. Spalazzese, P. Inverardi, and V. Issarny. Towards a formalization
of mediat- ing connectors for on the fly interoperability. In Proceedings
WICSA/ECSA 2009, pages 345{348, 2009.
SEA Group
89
References
N. Aguirre and T. Maibaum. A temporal logic approach to the specification of reconfigurable
component-based systems. In Proc. of the 17th Int. Conf. on Automated Software Engineering
(ASE 2002), pages 271–274, 2002.
R. Allen, R. Douence, and D. Garlan. Specifying and analyzing dynamic software architectures. In
Proc. of the 1st Int. Conf. on Fundamental Approaches to Software Engineering (FASE’98), 1998.
J. Andersson. Issues in dynamic software architectures. In Proc. of the 4th Int. Software
Architecture Workshop (ISAW-4), pages 111–114, 2000.
SEA Group
90
»
J. S. Bradbury. Organizing definitions and formalisms for dynamic software architectures.
Technical Report 2004-477, Queen’s University, 2004.
»
C. Canal, E. Pimentel, and J. M. Troya. Specification and refinement of dynamic software
architectures. In Proc. of the Working IFIP Conf. on Software Architecture (WICSA’99), pages
107–126. Kluwer, 1999.Woss proceedings
»
I. Georgiadis, J. Magee, and J. Kramer. Self-organising software architectures for distributed
systems. In Proc. of the 1st Work. on Self-Healing Systems (WOSS’02), pages 33–38. ACM Press,
2002.
»
D. Hirsch, P. Inverardi, and U. Montanari. Graph grammars and constraint solving for software
architecture styles. In Proc. of the 3rd Int. Software Architecture Workshop (ISAW-3), pages 69–
72. ACM Press, 1998.
SEA Group
91
»
J. Magee and J. Kramer. Dynamic structure in software architectures. In Proc. of the 4th
ACM SIGSOFT Symp. On Foundations of Software Engineering (FSE-4), pages 3–14.
ACM Press, 1996.
»
J. Magee and J. Kramer. Self organising software architectures. In Joint Proc. of the 2nd
Int. Software Architecture Work. (ISAW-2) and Int. Work. on Multiple Perspectives in
Software Development (Viewpoints ’96) on SIGSOFT ’96 Workshops, pages 35–38. ACM
Press, 1996.
»
D. L. M´etayer. Software architecture styles as graph grammars. In Proc. of the 4th ACM
SIGSOFT Symp. On Foundations of Software Engineering (FSE-4), pages 15–23. ACM
Press, 1996.
»
D. L. M´etayer. Describing software architecture styles using graph grammars. IEEE
Trans. Software Engineering, 24(7):521–533, 1998.
»
B. Schmerl and D. Garlan. Exploiting architectural design knowledge to support selfrepairing systems. In Proc. of the 14th Int. Conf. on Software Engineering and Knowledge
Engineering (SEKE 2002), pages 241–248. ACM Press, 2002.
»
G. Taentzer, M. Goedicke, and T. Meyer. Dynamic change management by distributed
graph transformation: Towards onfigurable distributed systems. In Proc. of the 6° In
Workshop on Theory and Application of Graph Transformation (TAGT’98). LNCS 1764,
Springer, 1998.
»
Luciano Baresi, Reiko Heckel, Sebastian Thöne, Dániel Varró: Style-Based Refinement of
Dynamic Software Architectures. WICSA 2004: 155-166
» J. Vera, L. Perrochon, and D. C. Luckham. Event-based
execution architectures for dynamic software systems. In Proc.
of the Working IFIP Conf. on Software Architecture
(WICSA’99), pages 303–318. Kluwer, 1999.
» M. Wermelinger. Towards a chemical model for software
architecture reconfiguration. IEE Proceedings - Software,
145(5):130–136, 1998.
» M. Wermelinger and J. L. Fiadeiro. Algebraic software
architecture reconfiguration. In Proceedings of the 7° European
Software Engineering Conference and 7th ACM SIGSOFT
Symposium on Foundations of Software Engineering
(ESEC/FSE’99), pages 393–409. LNCS 1687, Springer-Verlag,
1999.
» M. Wermelinger, A. Lopes, and J. L. Fiadeiro. A graph based
SEA Group
92
architectural (re)configuration language. In Proc. of the 8°
European Software Engineering Conference and 9th ACM
SIGSOFT Symposium on the Foundations of Softw
Engineering (ESEC/FSE 2001). Software Engineering Notes,
26(5):21-32, ACM, 2001.
References
David Garlan, Shang-Wen Cheng, and Bradley Schmerl Increasing
System Dependability through Architecture-based Self-repair in
Architecting Dependable Systems, R. de Lemos, C. Gacek, A.
Romanovsky (Eds), Springer-Verlag, 2003.
»
»
»
SEA Group
93
Paola Inverardi, Daniel Yankelevich, Alexander L. Wolf Static Checking of
Systems Behaviors Using Derived Component Assumptions
ACM TOSEM vol. 9, n.3, July 2000, pp.239-272.
Jeremy S. Bradbury, James R. Cordy, Juergen Dingel, Michel Wermelinger
A Survey of SelfManagement in Dynamic SoftwareArchitecture
Specifications, ACM Proc. Woss’04
P. Oreizy, M. M. Golick, R. N. Taylor, D. Heimbigner, G. Johnson, N.
Medvidovic, A. Quilici, D. S. Rosenblum, A. L. Wolf, An architecture-based
approach to self-adaptive software, IEEE Intelligent Systems 14 (3)
(1999) 54–62.