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 Qo. S 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/wg 10. 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 Qo. S attributes » 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 Focus is on models 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 C 1 C 2 C 3 (a) (b) » Removal/addition of connector instances by referring to (a), removing the connector between C 2 and C 3 produces the SA shown in (b). The vice versa concerns the addition of a connector instance. SEA Group 12
Variability dimensions in SA C 1 C 2 C 1 C 3 C 3 (a) (c) » Removal/addition of both component and connector instances by referring to (a), removing the component C 2 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 C 1 C 2 2 1 K C 3 3 C 3 (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) 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 C 1 C 3 (c) (e) R 1 R » Removal/addition of component instances in (c), removing the SEA Group 15 component C 3, 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 C 1, the connector, the component abstraction specified by the role R 1, 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 R 1. 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 R 1, has to satisfy the requirements of R 1.
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 preparing 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 Arch. Java 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; guarantee a given coordination policy. SEA Group 26
Modeling the system » Partial behavioural specification of the composed system: b. MSCs (basic Message Sequence Charts) > a b. MSC 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 b. MSCs as a directed graph whe nodes represent b. MSCs 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 Component 3 A Connector Free Architecture (CFA) is a set of components directly connected in a synchronous way. In CCS : (C 1 | C 2 |. . . | Cn) Ui=1. . n Acti SEA Group 28
Connector Based Architecture top REQUEST bottom channel 1 top Connector top channel 2 Component 2 channel 3 bottom top NOTIFICATION Component 1 Component 3 bottom In CCS: » differences from C 2 style: (C 1[f 1] | C 2 [f 2] |. . . | Cn[fn] | K) U i=1. . n Acti[fi] synchronous message passing; K is the synthesized connector, fi are suitable relabelling connectors cannot directly communicate; functions such that fi(a)=ai, for all aÎActi connectors are only routing devices, without any 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 1 Component 3 Deadlock free Connector Failure free Connector SEA Group 30 Component 2 Connector Based Architecture Deadlock free Connector Based 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 SEA Group 34
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 SEA Group 37 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 SEA Group 38 statically checked for conformance wrt the graph grammar
SEA Group 39
» The architecture represented by the above graph involves two clients c 1 and c 2, two servers s 1 and s 2, a manager m 0 and x 0. It is formally defined as the set D: » {CR(c 1, m 0), CA(m 0, c 1), C(c 1), CR(c 2, m 0), CA(m 0, c 2), C(c 2), SR(m 0, s 1), SA(s 1, m 0), S(s 1), SR(m 0, s 2), SA(s 2, m 0), S(s 2), X(x 0), M(m 0)} SEA Group 40
» The client server architecture style: » HCS = [{CS, CS 1}, {M, X, C, S, CR, CA, SR, SA}, R, CS] » with R : » CS 1(m) CR(c, m), CA(m, c), C(c), CS 1(m) » CS 1(m) SR(m, s), SA(s, m), S(s), CS 1(m) » CS 1(m) M(m), X(x) SEA Group 41
» the coordinator Coo. CS which applies to a client server 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 Arch. Java 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 » Arch. Java extends Java with constructs for specifying the architecture of the software Using Arch. Java 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. » Arch. Java guarantees communication integrity between the architecture and its implementation SEA Group 46
The Arch. Java Language » Arch. Java 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 » Arch. Java 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 » Arch. Java allows Calls between connected components Calls from a parent to its immediate subcomponents Calls to shared objects » Arch. Java forbids External calls to subcomponents Calls between unconnected subcomponents Calls through shared objects Compiler Scanner SEA Group 49 Parser out in Codegen out in
Arch. Java Type System » Arch. Java 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 Arch. Java » 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 closed world 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 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 Wi. Fi
e-Learning scenario (b) GPR S COS Feature T s High Full Low Limited SEA Group 60 GPR S Wi. Fi
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 Lemos 08). SEA Group 61
CONNECT Emergent Connectors for Eternal Software Intensive Networked Systems FET ICT Forever yours 7 FP-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 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 > ontologies > modeling notations > unifying know and unknown information » The challenge SEA Group 66 66 compositionality and evolution
synthesis process steps Env model ontology desc. connector model Env model ontology desc. SEA Group 67 67 Env model ontology desc.
synthesis process steps 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 Group 70 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 1. 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 1. Synthesis of application layer conversation protocols SEA Group 72 72
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 Group 73 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 Group 76 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 Group 83 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 Web 2. 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 www. informatik. uni trier. de/~ley/db/indices/a tree/p/Pelliccione: Patrizio. html, 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 component based 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 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. SEA Group 88 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 Dis. Co. Tec'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 17 th 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 1 st Int. Conf. on Fundamental Approaches to Software Engineering (FASE’ 98), 1998. J. Andersson. Issues in dynamic software architectures. In Proc. of the 4 th Int. Software Architecture Workshop (ISAW-4), pages 111– 114, 2000. » » I. Georgiadis, J. Magee, and J. Kramer. Self-organising software architectures for distributed systems. In Proc. of the 1 st Work. on Self-Healing Systems (WOSS’ 02), pages 33– 38. ACM Press, 2002. » 90 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 » SEA Group J. S. Bradbury. Organizing definitions and formalisms for dynamic software architectures. Technical Report 2004 -477, Queen’s University, 2004. D. Hirsch, P. Inverardi, and U. Montanari. Graph grammars and constraint solving for software architecture styles. In Proc. of the 3 rd Int. Software Architecture Workshop (ISAW-3), pages 69– 72. ACM Press, 1998.
» » D. L. M´etayer. Software architecture styles as graph grammars. In Proc. of the 4 th 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 14 th 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. » 91 J. Magee and J. Kramer. Self organising software architectures. In Joint Proc. of the 2 nd 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. » SEA Group J. Magee and J. Kramer. Dynamic structure in software architectures. In Proc. of the 4 th Luciano Baresi, Reiko Heckel, Sebastian Thöne, Dániel Varró: Style Based Refinement of Dynamic Software Architectures. WICSA 2004: 155 166 ACM SIGSOFT Symp. On Foundations of Software Engineering (FSE 4), pages 3– 14. ACM Press, 1996.
» 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 7 th 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 9 th 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 Self. Management in Dynamic Software. Architecture 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.
Скачать презентацию Assessing dependability for mobile and ubiquitous systems Is
6eb75a518e8543df0c6f9c97193e7ffc.ppt