Software architecture



Yüklə 445 b.
tarix08.01.2019
ölçüsü445 b.
#91996



Software architecture

  • 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


(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.

  • Performance indices evaluation for QN



  • Abstractions of real systems: Design stage

  • Computations => Components

  • Abstraction over :

  • Interactions => Connectors

  • ++++ Static & Dynamic Description ++++



Closed Software Architectures: components + connectors

  • 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.



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.
    • It concerns the self *-issues


Few Examples

    • Synthesis
    • Performance
    • Graph Grammars -- Le Metayer
    • ArchJava


EVOLUTION 1



CBSE-Synthesis

  • 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:

  • {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)}



  • 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)



  • the coordinator CooCS 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.



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


EVOLUTION EXAMPLE: 4

  • ARCHJAVA



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.
    • 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



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
      • 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


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


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


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
    • 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


Promising technologies

  • 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



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
      • ontologies
      • modeling notations
      • unifying know and unknown information
  • The challenge

    • compositionality and evolution






Developing protocol translators

  • 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


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

  • 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).

  • 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.




Yüklə 445 b.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2022
rəhbərliyinə müraciət

    Ana səhifə