(Physical) Mobility allows a user to move out of his proper context, traveling across different contexts.
(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
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
Context Awareness : Mobility and Ubiquity
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?
the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers ...
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
analysing models: functional and non-functional, several abstraction levels, not a unique model
analysing models: functional and non-functional, several abstraction levels, not a unique model
testing code: various kind of testing e.g. functional-based, 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
System dynamic model (LTS, MSC, etc)
Queuing Network models (+-extended) derived from the dynamic models
Models analysis, e.g. reacheability for deadlocks etc.
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.
Structure:
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
Variability dimensions in SA
(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.
Variability dimensions in SA
(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.
Variability dimensions in SA
(a) (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) and vice versa, although the two systems can be equivalent with respect to the semantics of the provided functionalities.
Variability dimensions in SA
(c) (e)
Removal/addition of component instances in (c), removing the 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.
For closed systems allows for predictive analysis: from the SA dependability properties are deduced
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 pre-preparing the models and the verification strategies
Allows for implementing reusable verification strategies.
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 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
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 …
When
during the system’s lifetime. Many stakeholders …
Does this mean run time? Not necessarily
It is related with the Static vs Dynamic issue
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.
Problem: The ability to establish properties on the assembly code by only assuming a relative knowledge of the single components properties.
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).
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;
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 where 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.
Connector Free Architecture
Connector Based Architecture
differences from C2 style:
synchronous message passing;
connectors cannot directly communicate;
connectors are only routing devices, without any filtering policies;
connectors have a strictly sequential input-output behavior.
Approach description: 3-step method
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
EVOLUTION EXAMPLES: 2
PERFORMANCE
The Adaptation process
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?
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
EVOLUTION EXAMPLE: 3
GRAPH GRAMMARS
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 statically checked for conformance wrt the graph grammar
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:
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
This requirement is enforced by putting restrictions on how component types can be used
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
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
Open systems accounting for
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
Changes in both the context and user needs might imply architectural configuration changes
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
dynamic induction of the SA that fulfills as best as possible the specified dependability
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 closed-world assumption in mind
While keeping a high-level composition mechanism, suitable technologies should
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
Two possible scenarios illustrating
Two possible scenarios illustrating
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
Ubiquitous systems: components travel around willing to communicate with only their own knowledge
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).
Challenge 3
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
To support the automated construction of application-layer connector models
To support the automated construction of application-layer connector models
1: identifying the conditions on the networked applications interaction and composition that enable run-time connector synthesis
SA and connector patterns
2: the synthesis process is seen as a behavioral model unification process
interoperability of both data transfer protocols and interaction schemes
ensuring, at run-time, end-to-end properties
availability, reliability, security, timeliness
Ubiquitous computing vision
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
In modern networked systems many heterogeneity dimensions arise and need to be mediated
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
composition of basic mediation patterns
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
Preliminary theory of mediators between mismatching protocols at the application level
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
Modeling notation used to abstract the behavior of the protocols to be bridged
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
Assumptions:
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
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)
Basic and complex mismatches, automatic mediation:
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)
first formalization of mediating connectors in the direction of the on the fly interoperability
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
Automation
Automation
Compositionality
Model-driven techniques for the synthesis of the mediator actual code
Evolution
Non-functional characteristics of the protocol behavior
Dependability assurances
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
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
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).
Patrick H. S. Brito, Rogério de Lemos, Cecília M. F. Rubira: Development of Fault-Tolerant 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.
P. H. Brito, R. Lemos, and C. M. Rubira. Development of fault-tolerant 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 self-evolving 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.
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.
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.
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 self-repairing 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 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.
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.
