Ï-Method: A Model-Driven Formal Method for Architecture ... - CiteSeerX

ACM SIGSOFT Software Engineering Notes

Page 1

May 2006

Volume 31

Number 3

π-Method: A Model-Driven Formal Method for Architecture-Centric Software Engineering Flavio Oquendo University of South Brittany VALORIA – Formal Software Architecture Group B.P. 573 – 56017 Vannes Cedex – France [email protected] Abstract Software systems have become increasingly complex and are often used in highly dynamic, distributed and mobile environments. Formal development of such software systems in order to guarantee their completeness and correctness is a large research challenge. This article presents the π-Method, a novel formal method that has been designed in the ArchWare European Project to address model-driven development of safe software systems. It is a well-founded theoretically method relying on formal foundations: its formal language for architecture description is based on the πcalculus, for architecture analysis on the µ-calculus, and for architecture transformation and refinement on the rewriting logic. The π-Method, like formal methods such as B, FOCUS, VDM, and Z, aims to provide full support for formal development of software systems. However, unlike these methods that do not provide any architectural support, the π-Method has been built from scratch to formally support architecture-centric component-based modeldriven development. Furthermore, a major impetus behind defining formal languages and method is that their formality renders them suitable to be manipulated by software tools. Indeed, a comprehensive toolset supporting formal model-driven engineering has been developed.

In order to address these issues, a novel formal method, called the π-Method, has been designed in the ArchWare European Project1. It supports formal model-driven development of software systems having highly dynamic architectures. In fact, a holistic formal development approach is needed that does not concentrate on oneshot specification and analysis of a software system as a whole, but rather on continuous specification, verification, and transformation of a software system as an architected composition of components. Indeed, the π-Method relies on a formal architecturecentric model-driven engineering approach.

Why Formal? In software engineering, formal methods refer to mathematically based techniques for the specification, analysis and development of software systems. Indeed, correctness of software systems can be improved by formalising different products and processes in the life-cycle. Among the reasons to apply formal foundations to the languages and processes of the π-Method are: to improve documentation and understanding of specifications, to enable rigorous analysis of the system properties, to be as certain as possible that the transformations and implementation are property-preserving and error-free, to improve rigour and quality of the whole development process, and to provide a firm foundation during the evoKeywords: Formal Methods, Model-Driven Development, Archi- lution process. tecture-Centric Software Engineering, Component-Based Software Engineering, Architecture Description Languages, Architecture Why Architecture-Centric? Analysis Languages, Architecture Transformation/Refinement Software architecture has emerged as an important subdiscipline Languages, Software Architectures of software engineering. A key aspect of the design of any software system is its architecture [6][75], i.e. the fundamental organi1. Introduction sation of the system embodied in its components, their One of the major challenges in software engineering is to guaran- relationships to each other, and to the environment, and the princitee the completeness and correctness of software systems, espe- ples guiding its design and evolution. Software architecture forms cially as they have become increasingly complex and are often the backbone for building successful software-intensive systems. used in highly dynamic, distributed and mobile environments. In Architecture descriptions provide thereby the conceptual abstracorder to reach this goal, the following open issues need to be ad- tion for modelling complex software systems during development and then during deployment and evolution [1]. dressed: • • • •

to support the formal specification of software systems whose architecture can change, on-the-fly, at run-time; to support their automated analysis w.r.t. functional as well non-functional properties; to support their property-preserving transformations and application synthesis, by stepwise refinement from abstract to concrete specifications and full code generation; to support compliance w.r.t. application requirements, i.e. if requirements change, enable the software system to safely evolve to cope with new requirements.

Why Model-Driven Engineering? All forms of engineering rely on models to design real-world systems. Models are used in many ways: to understand specific system aspects, predict system qualities, reason about impact of changes, and communicate major system features to stakeholders. In a model-driven approach, i.e. the system models have sufficient 1

The ArchWare European Project is partially funded by the Commission of the European Union under contract No. IST-2001-32360 in the IST Framework Program.


Page 2

May 2006

Volume 31

Number 3

detail to enable the generation of a full system implementation from the models themselves. Indeed, “the model is the code” [29], i.e. the focus is on modelling and code is mechanically generated from models. In an architecture-centric model-driven engineering approach, models are component-based architectural (run-time) models. They support analysis, property-preserving transformations, and application synthesis.

son about and refine the structure and behaviour of dynamic software systems (in terms of architectural components and connectors) and support their dynamic evolution.

The remainder of this article is organised as follows. Section 2 introduces the underlying approach of the π-Method. Section 3 presents the triad of its formal architecture languages for description, analysis, and refinement. Section 4 briefly presents application domains and industrial applications where the π-Method has been used in practice. Then in section 5 we compare the π-Method and its languages with related work. To conclude, in section 6, we briefly outline the π-Method toolset for supporting formal architecture-centric model-driven engineering.

The π-Method follows a formal architecture-centric model-driven development approach. Indeed, models are at the heart of the πMethod. They are used in many ways: e.g. to communicate major system features to stakeholders, understand specific system aspects, predict system qualities, transform towards concrete platforms, and reason about impact of changes. Moreover, models have sufficient detail to enable the generation of full system implementations from the models themselves.

The focus in the definition of the π-Method is therefore on languages and tools for the formal modelling of dynamic software systems (evolvable at design, build and runtime), and for the computer-aided formal analysis and transformation/refinement of these More precisely, the π-Method consists of an integrated set of for- models. Thereby, one can use the π-Method to formally model the mal architecture-centric languages and tools for the model-driven architecture of a complex software system in terms of its compodevelopment and evolution of software systems based on the π- nents and connectors, then transform and refine the model in a incremental way to generate the end-user system that, once decalculus and related theories. It comprises: ployed, can evolve based on the π-Method itself. • formal architecture description, analysis, and transformation languages for specifying the architecture of evolvable soft- The novelty of the π-Method lies in its holistic view of formal ware systems, verifying their properties and expressing their software development. It involves the capture of key design decirefinements; sions about “how” the software is to function in terms of expected • tools to support architecture description, analysis, and refine- behaviours, “what” is its structure in terms of components and their connectors, and “which” qualities are to be guaranteed. Furment as well as code generation; • enactable processes [5] for supporting model-driven engineer- thermore, an appropriate refinement process (describing “how to build” the software) is also to be effectively supported. ing .

Figure 1 illustrates the model-driven approach adopted by the πMethod. It which shows a variety of architecture-centric model2. Approach driven activities and stakeholders that may be used when developThe π-Method applies an innovative approach to the formal archi- ing applications using the π-Method. tecture-centric model-driven engineering of software systems that sets the “ability to safely evolve models” as its central characteristic. It comprises a triad of novel languages for describing dynamic define style architectures, analysing architecture structural and behavioural style properties, and transforming architecture descriptions: architecture •

• •

π-ADL [2][70][21]: an architecture description language based on the π-calculus in order to support the formal specification of software architecture models that can change, onthe-fly, at run-time; π-AAL [71][72]: an architecture analysis language based on the µ-calculus in order to support automated model analysis w.r.t. functional as well non-functional properties; π-ARL [3][4][69]: an architecture refinement language based on the rewriting logic in order to support property-preserving transformations and application synthesis, by stepwise refinement from abstract to concrete model specifications and full code generation, as well as their subsequent evolution.

architect

style

describe architecture application architect

refine architecture application engineer

instance of architecture description and analysis refinement of

generated from application

These languages, all together, support compliance w.r.t. applicaFigure 1. Architecture-centric formal development tion requirements, i.e. if requirements change, they enable the software system models and the system itself to safely change to Typical architecture-centric activities are “define style”, “describe architecture”, and “refine architecture” (the last refinement is code continuously cope with requirements. generation). Typical stakeholders are “style architects”, “applicaIndeed, these languages provide features to formally model, rea- tion architects”, and “application engineers”.


Page 3

May 2006

Volume 31

Number 3

modelling and transformation languages, i.e. π-ADL and π-ARL respectively, in order to support the modelling of software processes [8] that guide software development. Thereby, unlike most methods that prescribe a particular software process model, the πMethod is proscriptive. That is, it proscribes that completeness and correctness properties, expressed in π-AAL, be violated during architecture model specification and transformation, without prescribing particular software process models. Indeed, in the framework of the π-Method, different fine-grain software process can be defined and enforced, e.g. for specific domains or classes of applications such as the Tower Process Model [74] and the Grid “Describe architecture” activities, whose principal actors are the Process Model [19]. “application architects”, may use the domain specific styles de- Therefore, the π-Method enforces completeness and correctness of fined by the style architect to describe a specific software architec- model specification and transformation, while not prescribing ture. An architecture description, in terms of a model, conforms to fine-grain software process models. Completeness and correctness the properties and constraints defined by its style and can repre- are defined as semantic properties in π-AAL. Thereby, model sent a system at various levels of abstractions, e.g. w.r.t. target transformations expressed in π-ARL are enforced to be correct platforms, thereby supporting the expression of platform inde- refinements if preconditions of transformation actions are satisfied pendent models as well as platform specific models. Architecture and proof obligations discarded. A transformation engine runs the description models are expressed in π-ADL, complemented by transformation models expressed in π-ARL. When applied, they additional properties in π-AAL if needed. refine architecture models described in π-ADL outputting new refined architecture models also in π-ADL as shown in Figure 2. “Refine architecture” activities, whose principal actors are the Code is generated, targeting different implementation platforms “application engineers”, support transformations from abstract to and programming languages, from refined (concrete) architectures more concrete architecture descriptions. Thus, an abstract, platform independent model can be refined to a concrete, platform in π-ADL. specific model of a specific application. The role of the application engineer is to derive that concrete model by applying correctness 3. Formal Languages preserving transformations, i.e. refinements, that conform to the As cited so far, the π-Method comprises a triad of mathematicallyconstraints defined by the application architect and by the adopted based languages: architecture styles. These transformations can be themselves expressed by architecture refinement models in π-ARL, and as such • π-ADL [2][70][21]: an architecture description language based on the higher-order typed π-calculus; applied in a systematic way. • π-AAL [71][72]: an architecture analysis language based on Indeed, as depicted in Figure 2, applying an architecture refinethe µ-calculus; ment model expressed in π-ARL on an “abstract” architecture de• π-ARL [3][4][69]: an architecture refinement language based scription expressed in π-ADL yields a “more concrete” on the rewriting logic. architecture description also expressed in π-ADL. This triad of languages, depicted in Figure 3, are at the core of the π-Method. They provide the features for model description, analyabstract sis, and transformation, as well as for their automation. “Define style” activities, whose principal actors are the “style architects”, represent the top level inception of a family of software architectures. An architecture style defines a domain specific architecture description “profile”, including formal definitions of what architectural elements are, and what their invariant properties (including qualities) are, how elements can be combined, which constraints apply, and which processes can be applied to architecture elements and whole architecture descriptions (notably w.r.t. refinement and evolution). Architecture styles are expressed in πADL for architectural abstractions and π-AAL for architectural properties on these abstractions.

architecture description in π-ADL

Model description

Model analysis

π-ADL

π-AAL

architecture refinement actions in π-ARL

π-ARL Model transformation

result: more concrete architecture description in π-ADL

Figure 3. The triad of formal languages 3.1 The Architecture Description Language: π-ADL

In the π-Method, architecture description encompasses two aspects: the expression and verification of architectural styles (typiIt is worth noting that the π-Method provides enactable process cally carried out by style architects) and of software architectures Figure 2. Model transformations with π-ARL


Page 4

May 2006

Volume 31

Number 3

completeness (i.e. where a type may be used in a construct, any type is legal without exception), there are properties possessed by The π-ADL provides the core structure and behaviour constructs all values of all types that constitute their civil rights in the lanfor describing dynamic software architectures. It is a formal speciguage. In π-ADL they are: fication language designed to be executable and to support automated analysis and refinement of dynamic architectures. • the right to be declared, • the right to be assigned, The π-ADL has as formal foundation the higher-order typed πcalculus [63], a higher-order calculus for communicating and mo- • the right to have equality defined over them, bile systems. The π-ADL is itself a formal language defined as a • the right to persist. themselves (typically carried out by application architects).

domain-specific extension of the higher-order typed π-calculus: it Additionally, π-ADL provides an extension mechanism, i.e. new is a well-formed extension for defining a calculus of communicat- constructs can be defined on top of the language using usering and mobile architectural elements. defined mixfix abstractions. This extension mechanism provides the basis for providing style-based definitions. The π-ADL takes its roots in previous work concerning the use of π-calculus as semantic foundation for architecture description lan- In the π-Method, a style notation, built on the π-ADL, provides guages [31][30]. Indeed, a natural candidate for expressing dy- the style constructs from which the base component-and-connector namic (run-time) behaviour would be the π-calculus as it is [55], style and other derived styles can be defined. Conceptually, an which provides a general model of computation and is Turing- architectural style includes: complete. This means that in π-calculus “every computation is possible but not necessarily easy to express”. In fact, the classical • a set of abstractions for architectural elements, π-calculus is not suitable as an architecture description language • a set of constraints (i.e. properties that must be satisfied) on architectural elements, including legal compositions, since it does not provide architecture-centric constructs to easily • a set of additional analyses that can be performed on architecexpress architectures in particular w.r.t. architectural structures. ture descriptions constructed in the style. Therefore, a language encompassing both structural and behavioural architecture-centric constructs is needed. The π-ADL is this The π-Method provides a novel ADL that is general-purpose and encompassing language, defined as a domain-specific extension of Turing-complete. The advantage w.r.t. other ADLs is that the πthe higher-order typed π-calculus. It achieves Turing completeness ADL supports user-defined architectural component-andand high architecture expressiveness with a simple formal nota- connector abstractions (instead of being obliged to use hard-coded tion. abstractions provided by particular ADLs that very often do not meet architect needs). It can be seen as a second generation ADL: in first generation ADLs, languages were not complete and archiformality: π-ADL is a formal language: it provides a formal tectural (run-time) concepts were hard-coded as language consystem, at the mathematical sense, for describing dynamic structs; in second generation, languages should be complete and software architectures and reasoning about them; architectural (run-time) concepts should be customisable. run-time viewpoint: π-ADL focuses on the formal description of software architectures from the run-time viewpoint: the For more details on π-ADL see [2]; for the formal definition of π(run-time) structure, the (run-time) behaviour, and how these ADL see [70]; for a tutorial introduction see [21]. may evolve over time; executability: π-ADL is an executable language: a virtual ma- 3.2 The Architecture Analysis Language: π-AAL chine runs specifications of software architectures; In the π-Method, architecture analysis encompasses two aspects: user-friendliness: π-ADL supports different concrete syntaxes the expression and verification of properties of architectural styles – textual and graphical (including UML-based) notations – to (typically carried out by style architects) and of software architecease its use by architects and engineers. tures themselves (typically carried out by application architects).

The following general principles guided the design of π-ADL: • •

• •

Based on these general principles, the design of π-ADL followed The π-AAL provides a uniform framework for specifying relevant the following language design principles [59][66][67]: properties of styles and architectures. These properties have different natures: they can be structural (e.g. cardinality of architec• the principle of correspondence: the use of names are consistural elements, interconnection topology) or behavioural (e.g. tent within π-ADL, in particular there is a one to one corre- safety, liveness, and fairness defined on actions of the system). spondence between the way of introducing names in The π-AAL complements the π-ADL with features allowing archideclarations and parameter lists; tects to express and verify properties of software architectures and • the principle of abstraction: all major syntactic categories styles in a natural way. Analysis is intended to be performed achave abstractions defined over them (in π-ADL, it includes cording to three approaches: model-checking, theorem proving abstractions over behaviours and abstractions over data), and specific external tools. • the principle of data type completeness: all data types are The π-AAL is a formal property expression language designed to first-class without any restriction on their use. support automated verification. Thereby, one can mechanically In first-class citizenship, i.e. in addition to rights derived from type check whether an architecture described in π-ADL satisfies a


Page 5

May 2006

Volume 31

Number 3

property expressed in π-AAL.

ment relation for architectural elements.

The π-AAL has as formal foundation the modal µ-calculus [47], a calculus for expressing properties of labelled transition systems by using least and greatest fixed point operators. π-AAL is itself a formal language defined as an extension of the µ-calculus: it is a well-formed extension for expressing structural and behavioural properties of communicating and mobile architectural elements.

A refinement relation in the π-Method, from an external or internal point of view, comprises four forms of refinement:

The π-AAL takes its roots in previous work concerning the extension of modal operators with data-handling constructs [53], the use of regular expressions as specification formalism for value-passing process algebras [36], and the extension of fixed point operators with typed parameters [42].

• • • •

behaviour refinement, port refinement, structure refinement, data refinement.

In behaviour refinement, the underspecification may concern the external (observable) behaviour or the internal behaviour of an architectural element. The external behaviour of an architectural element is the behaviour that its environment can observe, i.e. its behaviour from an external point of view. The internal behaviour concerns the internal expression of behaviour within the scope of the architectural element. The structure of an architectural element is its internal structure in terms of sub-architectural elements and their connected ports, i.e. the structure within the scope of the architectural element from an internal point of view. The ports of an architectural element provide the interaction points (i.e. connections) between the element and its environment, i.e. its ports from an external point of view.

Indeed, a natural candidate for pure behavioural properties would be the modal µ-calculus, which is a very expressive fixed pointbased formalism subsuming virtually all temporal logics defined so far in the literature [64]. However, since π-AAL must also provide features for expressing structural properties of architectures, the modal µ-calculus is not sufficient. Therefore, a formalism encompassing both the predicate calculus and the modal µ-calculus is needed. The π-AAL is, thereby, this encompassing formalism, defined as a domain-specific extension of the µ-calculus. The most fundamental notion of refinement in the π-Method is The π-AAL combines predicate logic with temporal logic in order behaviour refinement. The other forms of refinement imply behavto allow the specification of both structural and behavioural prop- iour refinement modulo port, structure and data mappings.

erties. It enables automated verification of property satisfaction by In general, architectural refinement is a combination of the four model checking and theorem proving techniques. forms of refinement. For instance, an architect can define an abFor more details on π-AAL see [71]; for the formal definition and stract architecture, then “data” refine that architecture in order to introduce base and constructed data types, then “port” refine the a tutorial introduction of π-AAL see [72]. architecture to have ports with finer grain connections carrying data of different types, then “structure” refine its composite behav3.3 The Architecture Refinement Language: π-ARL iour by adding new finer grain connectors, and so on. Software applications are usually developed in several steps. Indeed, the concrete architecture of a software system is often de- The π-ARL provides constructs for defining refinements of the veloped through vertical and horizontal transformations, enforcing four forms cited so far, according to external or internal points of refinements of related architectures that differ respectively w.r.t. view. Composite refinements can be defined in terms of refinement primitives and composite refinements themselves. Refineabstraction and partition dimensions. ment primitives comprise: Horizontal refinement is concerned with transforming an architecture by partition. For instance, partitioning an abstract component • adding, removing, replacing or further transforming data type declarations of an architecture, in its parts at the same abstraction level, e.g. w.r.t. platform inde• adding, removing, replacing or further transforming ports of pendence. an architecture, Vertical refinement is concerned with transformation steps to add • adding, removing, replacing or further transforming output more and more details to abstract models until the concrete archiand input connections of ports of an architecture, tectural model is described. A vertical refinement step typically • further transforming the behaviour of an architecture or the leads to a more detailed architecture description, e.g. w.r.t. platbehaviour of a component or connector in an architecture, form dependence. Moreover, it increases the determinism while • adding, removing, replacing or further transforming compoimplying properties of the abstract description. Generally, an abnents or connectors in an architecture, stract architecture is smaller and easier to understand and a con• exploding or imploding components or connectors in an archicrete architecture reflects more implementation, platform specific, tecture, concerns. • unifying or separating connections of ports in an architecture. The π-Method supports both horizontal and vertical refinements. These primitives, applied step by step, allow the incremental transIn the π-Method, the underlying approach for architectural refineformation of an architecture description. These transformations are ment is underspecification, i.e. at a high-level of abstraction, when enforced to be refinements if preconditions of refinement primispecifying an architectural element, certain aspects can be left tives are satisfied and proof obligations discarded. A refinement open. The decrease of this underspecification establishes a refineengine based on rewriting logic [52][28] runs the refinement de-


Page 6

May 2006

Volume 31

Number 3

Besides using the π-Method to develop specific applications, domain-specific integrated development environments have been developed based on the π-Method and the model-driven engineering approach, called π-model driven engineering environments. They are implemented by customisation of the ArchWare customThe π-ARL is a formal (executable) refinement language providisable environment [11][73]. ing architecture-centric refinement primitives and supporting refinement compositions in both vertical and horizontal dimensions, Furthermore, the ArchWare customisable environment itself, that from external or internal points of view. When applied, they refine supports the π-Method, is a validation of the π-Method and its architectural models described in π-ADL outputting new refined languages and tools since it has been developed using the πarchitectural models also in π-ADL. Method itself.

scriptions expressed in π-ARL generating further refined architectures. Code is generated, targeting different implementation platforms and programming languages, from refined (concrete, platform specific) architectures.

π-ARL provides the required key features for supporting architecture-centric model-driven formal development. By addressing software development as a set of architecture-centric model refinements, the refinements between models become first class elements of the software engineering process. This is significant because a great deal of work takes places in defining these refinements, often requiring specialized knowledge on source and target abstraction levels, for instance knowledge on the source application logics and on the targeted implementation platforms. Efficiency and quality of software systems can be improved by capturing these refinements explicitly and reusing them consistently across developments. Thereby, user-defined refinement steps can be consistently defined, applied, validated, and mechanically automated.

In the sequel different applications of the π-Method are briefly presented. 4.1 Software Systems targeting J2EE Platforms The ArchWare European project has set up pilot projects to validate in a real set π-ADL, π-AAL, and π-ARL and their associated tools. The pilot project at Engineering Ingegneria Informatica aimed to architect, refine, generate, and evolve software systems whose the target programming language is Java and the target platform J2EE.

Carmela Occhipinti et al. defined and developed architectural styles, refinement models, and an application generator for Java/J2EE. They designed, implemented and applied the customised π-model driven engineering environment for software sysFor more details on π-ARL see [3][4]; for the formal definition tems targeting J2EE platforms. Using that software environment, and a tutorial introduction of π-ARL see [69]. they were able to develop a federated knowledge management system fully generated in Java/J2EE. 4. Application Domains Application domains of the π-Method are characterised by the need of architecture description, analysis, and refinement languages powerful enough, in terms of expressiveness, to model highly dynamic architectures, including support for modelling the structure, behaviour and qualities of distributed, mobile, and context-aware systems.

4.2 Enterprise Application Integration Systems Industry is increasingly seeking effective ways of accessing larger geographically distributed information coming from heterogeneous applications in order to control its production system. The emergence of Enterprise Application Integration (EAI) middleware is a step in this direction, but it is only part of the solution. The π-Method, and its associated languages π-ADL, π-AAL, and Several issues remain to be solved w.r.t. integration of heterogeneous enterprise applications in a global and consistent solution. π-ARL, have been applied in the following application domains: This requires extensive support in order to model, generate, and • software systems targeting J2EE platforms, evolve on-the-fly the EAI-based integrated systems. • enterprise application integration systems, Thésame and Agilium have developed an EAI middleware which • grid computing systems, can be used to track processes and products for a variety of pur• human-computer interfaces for monitoring systems, poses. Its modelling notation can describe different applications by • mobile agent systems, taking into account product and process descriptions, relationships • sensor-actuator networks, between activities, and execution traceability (product transforma• service-oriented architectures, tion by a process activity). This EAI middleware is suitable to • ambient intelligence. large-scale production management systems cutting across differThe different applications of the π-Method are broad and general ent organisations. enough to demonstrate their adequacy and relevance for As cited above, the ArchWare European project has set up pilot developing innovative industrial software systems. projects to validate in a real set π-ADL, π-AAL, and π-ARL and Furthermore, a major impetus behind defining formal languages their associated tools. The pilot project at Thésame aimed to archiand method is that their formality renders them suitable to be ma- tect, refine, generate, and evolve on-the-fly agile integrated indusnipulated by software tools. Indeed, a comprehensive toolset sup- trial process systems based on EAI middleware. porting the π-Method has been developed.

Régis Dindeleux et al. defined and developed a novel architectural style, architecture description and refinement models, and applica-


Page 7

tion generator [9]. They designed, implemented and applied the customised π-model driven engineering environment for agile integrated industrial process systems based on their EAI middleware. Using that software environment, they were able to develop a family of agile integrated industrial process systems for SMESMIs.

May 2006

Volume 31

Number 3

Olivier Ratcliffe et al. defined a novel architectural style with πADL and π-AAL in order to formalise all the rules defined at that method and used them to construct a domain-specific software development environment for designing and generating monitoring software systems, including their HCIs [10][15]. This software environment, based on ArchWare, called SEAM (Software for the Engineering of Accelerator Monitoring), guides the design of the HCIs and generates the code of particle accelerator monitoring software systems. SEAM has numerous benefits, such as the ability to reuse efficiently previous design experience and the possibility to use architectural tools to perform analyses on the HCI architectures. It supports the generation of monitoring applications that comply at best with the user requirements and can evolve whenever user requirements evolve, thereby exploiting ArchWare features for supporting compliant evolution [13][41].

4.3 Grid Computing Systems The Grid paradigm is described as a distributed computing infrastructure for advanced science and engineering that can address the concept of coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations. This coordinated sharing can provide direct access to computers, software, files, data and other system resources. Grid applications bundle different services using a heterogeneous pool of resources in virtual organization. This makes Grid applications very difficult to 4.5 Mobile Agent Systems model and to implement. Mobile agents form one of the most promising approaches to face It is a commonly recognized statement that Grid applications have the problems encountered in the decentralised systems, including seldom been designed using formal techniques although from past ambient intelligence systems. However, the use of mobile agents experience such techniques have shown major advantages. is still unsafe. This is due to the lack of formal methods for modelThe π-Method is the basis of a formal engineering approach to ling and developing mobile agent systems. Grid application development. It addresses quality of service and Using the π-Method, Selma Azaiez et al. defined and developed a cross platform developments by applying the model-driven enginovel architectural style, refinement models, and application genneering paradigm to formal architecture-centric engineering. This combination benefits from the formal modelling of the Grid appli- erator. They designed, implemented and applied the customised πcation in addition to model-based transformations. It significantly model driven engineering environment for mobile agent systems [12]. The architecture style is based on the Mobile Agent System eases application development in Grid computing. Interoperability Facility (MASIF) OMG Standard. From the geDavid Manset et al. defined and developed a novel architectural neric architecture, the system architect derives by refinement the style, refinement models, and application generator [19]. They concrete architecture, from which the code is generated. The referdesigned, implemented and applied the customised π-model driven ence architecture is formalized with π-ADL and the refinement engineering environment for Grid computing systems. Applying models with π-ARL. The software environment was applied to π-ARL, they address the challenge of designing, optimizing and design and generate a decentralised deployment system where adapting Grid-abstract architectures, w.r.t. different criteria, in mobile agents move to different remote hosts in order to update order to automatically refine and generate a complete set of Grid deployed applications. services to be deployed on a physical grid of resources. The implemented software environment has been applied to the develop- 4.6 Sensor-Actuator Networks ment of the MammoGrid application, which aims to develop a Sensor-actuator networks are comprised of sensor and actuator European-wide database of mammograms used to support effec- nodes that communicate among each other using links to perform tive co-working between healthcare professionals throughout the distributed sensing and actuation tasks. In these applications, senEuropean Union. sors are engaged in gathering information about the physical environment, while actuators are involved in taking decisions and then 4.4 Human-Computer Interfaces for Monitoring Systems performing appropriate actions in the area of interest. They are As in lots of industrial processes, particle accelerators at CERN, part of most ambient intelligence systems. the European Organization for Nuclear Research, are composed by a large amount of heterogeneous systems. These heterogeneous Intelligent instruments are composed of networks of sensors and systems are monitored using customised Human Computer Inter- actuators that are able to provide complex services such as diagnostic, validation, communication, learning, in order to jointly faces (HCIs), intermediate databases, and numerous sensors. control a physical system. The design of such intelligent instruThe CERN’s Technical Control Room has defined a design ments needs multidisciplinary skills, comprising skills in physics, method used to architect the HCIs of monitoring systems in order mechanics and computing sciences. Most of the time, the system to efficiently restart a particle accelerator after a major breakdown. architect in charge of designing the embedded software for such At CERN, this design method is the basis for the development of a instruments is a domain expert but not a software engineer. Morefamily of HCIs for monitoring systems, HCIs that must follow over, strong constraints coming from the hardware are imposed at accurate rules in order to be easily understood and efficiently used the software level. by the control room operators. One way of addressing this problem is to define an architecture


Page 8

style that is specific to the design of intelligent instruments, including the specification of all structural and behavioural properties that must be satisfied by architectures that conform to this style, and define transformation models to automatically refine this design to target platforms, including code generation of the full application. To solve this problem, Jérôme Revillard et al. used the π-Method to define and develop a novel architectural style, refinement models, and application generator [16][17]. They designed, implemented and applied a customised π-model driven engineering environment for sensor-actuator networks to generate software to control a robot with a glove, the 18-sensor CyberGlove. The robot is a Lego Mindstorm, which comprises an autonomous programmable microcomputer, using a Hitachi H8/3932 microcontroller that can be used to control actuators, like a sound generator, lights, and motors, and read input from various sensors, like light sensors, pressure sensors, rotation sensors, and temperature sensors. It has an infrared transceiver for downloading software components and communicating with other robots. 4.7 Ambient Intelligence Ambient intelligence stems from the convergence of three key technologies: ubiquitous computing, ubiquitous communication, and intelligent user friendly interfaces. Ubiquitous computing means integration of microprocessors into everyday objects. Ubiquitous communication enables these objects to communicate with each other and the user by means of possibly wireless, possibly ad-hoc, networks. An intelligent user friendly interface enables the inhabitants of the ambient intelligence environment to control and interact with the environment in a natural and personalised way (e.g. preferences, context). On convergence humans will be surrounded by intelligent interfaces supported by computing and networking technology that need to be properly integrated with business and social structures.

May 2006

Volume 31

Number 3

continually influence and adapt the software system, whilst continuing to guarantee fitness of purpose and the integrity of service of the whole system in terms of safety and liveness properties. Because continuous compliance is an open-ended commitment in the light of unpredictable requirements and context-aware systems, everything must be designed for dynamic and sustainable change. The π-Method has been from its inception designed to address the architecture-centric formal development of systems with emergent behaviour, which can be dynamic, open, mobile, context-aware and ubiquitous, being able to evolve on the fly. Some of the applications of the π-Method presented so far address different aspects of ambient intelligence environments, e.g. sensor-actuator networks and mobile agents. 4.8 Service-Oriented Architectures Service-oriented architecture is an emerging paradigm where services are understood as autonomous, platform-independent computational entities that can be described, published, discovered, and dynamically assembled for developing distributed, interoperable, and evolvable software systems. A typical service-oriented architecture comprises an orchestration or choreography of web services that interact through standard messaging protocols. From an architecture viewpoint, a serviceoriented architecture is an architectural style that is intended to promote flexibility and agility through encapsulation and loose coupling.

Frédéric Pourraz et al. used the π-Method to architect, validate [14] and develop a Manufacturing Execution System as a serviceoriented architecture. A Manufacturing Execution System is a system that tracks and manages all aspects of a manufacturing job in real time. It may include resource management, capacity scheduling, maintenance management, statistical quality control, laboratory information management, process management, data The ambient intelligence landscape is a world in which there are collection, plant wide document management, and process optimialmost uncountable interoperating devices. Most will be wireless, sation, and it links to ERP software for higher level planning and some wired, many will be mobile, and many will be fixed. The control tasks. networks will thus be configurable on an ad hoc basis according to a specific perhaps short-lived task with variable actors and com- Besides developing this service-oriented architecture, Frédéric ponents. This ubiquitous computing must also be pervasive. These Pourraz et al. demonstrated through this application how the πdevices will use ‘peer to peer’ mechanisms to communicate with Method, supported by ArchWare tools, can be used to support oneach other, and with the surrounding infrastructure (e.g. a local the-fly evolution of a service-oriented architecture by dynamically intranet or Internet). In a mobile ad hoc network, since the nodes reconfiguring the system, replacing web services and modifying are mobile, the network topology may change rapidly and unpre- and regenerating new orchestration models. dictably over time. The network is thereby decentralized. 4.9 Other On-going Applications The π-Method is a holistic response to the design challenge posed In addition, to those applications, the π-Method is currently being by ambient intelligence on the development of systems exploiting used in the following cases: ambient intelligence technologies. It is holistic in the sense that it considers the software system and the application that it supports • Nadeem Akhtar et al. are defining an architectural style and transformation models for formally developing multi-agent to be a single entity. Thus, this entity is constructed to remain dysystems applied to swarm robotics; namically compliant to the needs of the application as it changes and evolves in the context of an ambient environment. It is not a • Di Wu et al. are defining an architectural style and transforclassical autonomic system in the sense that it is it does not atmation models for formally developing distributed simulation tempt to limit itself to being a completely self-managing environsoftware systems based on the High Level Architecture [IEEE ment. Rather it seeks to allow the human user and its context to Standard 1516-2000], a general purpose architecture for simu-


Page 9

May 2006

Volume 31

Number 3

power. Moreover, the extension of µ-calculus modalities with higher level constructs such as regular formulas inspired from early dynamic logics like PDL [35] facilitates the specification task of the practitioners, by allowing a more natural and concise description of properties involving complex sequences of actions. The extension of fixed point operators with data parameters also provides a significant increase of the practical expressive power, These applications are supported by π-model driven engineering and is naturally adapted for specifying behavioural properties of environments. value-passing languages such as the π-ADL.

•

lation reuse and interoperability; Zaheer Khan et al. are formalizing the Role Activity Diagram (RAD) notation, a business process modelling notation, with π-ADL, and will define, with π-ARL, transformation models to support the automatic transformation of business process models expressed as RADs into service-oriented architectures.

5. Related Work The π-Method is a language-based method, encompassing the triad of architecture-centric languages for architecture description, analysis, and property-preserving transformation. 5.1 Architecture Description Several architecture description languages (ADLs) have been proposed in the literature [54][49], including: ACME/DynamicACME [39][40], AESOP [38], AML [68], ARMANI [56], CHAM-ADL [44][45], DARWIN [51], META-H [27], PADL [25], RAPIDE [61][50], SADL [57][58], σπ-SPACE [31][48], UNICON-2 [33], and WRIGHT/Dynamic-WRIGHT [23][24]. ADLs provide both a concrete syntax and a formal, or semiformal, semantics. Typically, they embody a conceptual framework reflecting characteristics of the domain for which the ADL is intended and/or a specific architectural style [54].

In the context of software architectures, several attempts at using classical process algebras and generic model-checking technology have been reported in the literature. In [43], various architectural styles (e.g., repository, pipe-and-filter, event-action) are described in LOTOS, by using specific communication patterns and constraints on the form of components, and verified using the CADP toolbox [34][37]. In [62], several variants of the pipe-and-filter style are described in LOTOS and analysed using CADP. In [46], the transformation of software architectures specified in LOTOS and their verification using the XTL model-checker [53] of CADP are presented. Finally, an approach for checking deadlock freedom of software architectures described using a variant of CCS is described in [26]. All these works provide rather ad-hoc solutions for a class of software architectures limited to static communication between architectural elements, and can be subsumed by the more general framework provided by π-ADL and π-AAL, and verification tools.

The focus of π-ADL is on the formal modelling of highly dynamic Regarding structural analysis, ACME, ARMANI, CHAM-ADL, DARWIN, RAPIDE, SADL, WRIGHT and others addressed software architectures. mainly properties like completeness and consistency of software But how does π-ADL compare with related work? Comparing architectures. Most of those approaches propose a less or more ADLs objectively is a difficult task because their focuses are quite sophisticated language for describing properties to analyse. different. Most ADLs essentially provide a component-andconnector built-in model of architecture description and formalise The main limitation of most of these approaches with regard to πtopological constraints. The reason for this is probably that struc- AAL is that they address either structural or behavioural properture is certainly the most understandable and visible part of an ties, but not both as in π-AAL. architecture. But behavioural and quality aspects are not completely neglected. They are often taken into account (even if par- 5.3 Architecture Transformation and Refinement tially) in most ADLs. They are certainly an essential part of Regarding property-preserving architecture transformations, i.e. architecture description. refinements, with the exception of a variant of FOCUS [65], i.e. FOCUS/DFA [60], RAPIDE and SADL, there is no proposal for a π-ADL is the most general among studied ADLs. Defined as a rigorous refinement calculus based on architectural terms. In the domain-specific extension of the higher-order typed π-calculus, it case of SADL, the refinement is only structural. In the case of achieves Turing completeness and high architecture expressiveRAPIDE, it is only behavioural (supported by simulations). In ness with a simple formal notation. It encompasses both structural both cases, clear architectural primitives for refining architectures and behavioural architecture-centric constructs. are not provided and the refinement supported is only partial. πARL, like the B [22] and Z [32] formal methods, provides opera5.2 Architecture Analysis tions to transform specifications. However, unlike FOCUS, B and π-AAL provides the language to express properties of architec- Z, π-ARL has been specially designed to deal with architectural tures described in π-ADL. elements of any architectural style. Unlike SADL, π-ARL supports π-AAL combines predicate logic with temporal logic in order to underspecification. In FOCUS/DFA, refinement is essentially allow the specification of both structural properties and behav- logical implication. In SADL, it is restricted by faithful interpretaioural properties concerning architecture descriptions obtained by tion. In RAPIDE, it is defined by simulations. In π-ARL, it is based on property implication, where the properties to be preinstantiating a given style. served are defined by the architect. Regarding behavioural properties, the choice of modal µ-calculus as the underlying formalism provides a significant expressive The π-ARL provides a novel language that on the one side has been specifically designed for architectural transformation taking


Page 10

into account refinement of behaviour, port, structure, and data from an architectural perspective and on the other side is based on preservation of properties. The core of π-ARL is a set of architecture transformation primitives that support refinement of architecture descriptions. Transformations are refinements when they preserve properties of the more abstract architecture. Core properties are built-in. Style-specific or architecture-specific properties are user defined. The underlying foundation for architected behaviours is the higher-order typed π-calculus. Satisfying proof obligations in π-ARL, expressed using π-AAL, is supported by analysis tools, which comprises a model checker, a prover and specific evaluators.

May 2006

Volume 31

Number 3

however this is not enforced. Unlike MDA, that is based on UML and related technologies, the π-Method is independent of UML. However, it provides a UML Profile, i.e. the UML Profile for π-ADL [7][20], for supporting UML as a concrete modelling notation. Using that profile, a software system architect or engineer can seamlessly use the πMethod through a UML Modeller, without knowing the formal languages of the π-Method, while taking advantage of its formal foundation for verification and transformation. 6. Conclusion and Future Work

The keystone of the π-Method is recognising that architecturecentric model-driven approaches, supported by adequate, compoThe π-Method, like formal methods such as B [22], FOCUS [65], sitional, formal languages and tools, are needed to cost-effectively VDM [76], and Z [32], aims to provide full support for formal develop and evolve software systems while guaranteeing their description and development of software systems. Unlike these completeness and correctness. formal methods that do not provide any architectural support, the Besides providing the triad of languages for formal architectureπ-Method has been built from scratch to support architecture- centric model-driven engineering, i.e. π-ADL, π-AAL, and πcentric formal software engineering. Besides the approach, unlike ARL, the π-Method is supported by a comprehensive toolset, those formal methods, the π-Method is based on a process algebra, called the π-Toolkit. Indeed, as cited so far, a major impetus bethe higher-order typed π-calculus. hind developing formal languages for architecture description, The novelty of the π-Method lies in its holistic view of formal analysis, and refinement is that their formality renders them suitdevelopment, encompassing languages for formal specification, able to be manipulated by software tools. The usefulness of i.e. π-ADL, formal verification, i.e. π-AAL, and formal transfor- architecture description, analysis, and refinement languages is thereby directly related to the kinds of tools it provides to support mation, i.e. π-ARL. It goes beyond existing formal methods in architectural description, analysis, refinement, and code generasupporting architecture-centric model-driven engineering of softtion. The π-Toolkit comprises: ware systems. 5.4 Formal Methods

• 5.5 Model-Driven Engineering Model-driven engineering (or model-driven development) is a style of software engineering where the primary software artefacts are models from which code and other artefacts are generated • through model transformations. The most well know realisation of model-driven engineering is the • OMG Model Driven Architecture (MDA) [77]. At the core of MDA are the concepts of models, of metamodels defining the abstract languages in which the models are captured, • and of transformation specifications that take models and produce other models from them. MDA strongly relies on UML and related technologies. Model transformations form a key part of MDA. A model trans- • formation specification determines how a set of output models results from a set of input models. The input to a transformation is a platform independent model (PIM) and a model transformation specification. The output is a platform specific model (PSM) and • the record of transformation. The π-Method is a different realisation of model-driven engineering. Like MDA, models are the primary software artefacts and model transformation the primary mechanism for refining models • from abstract to more concrete ones. However, unlike MDA, that is semi-formal, the π-Method is formal, and thereby supports formal specification, verification, and transformation of models. The • refinement criteria can be, like in MDA, platform dependence,

UML-based π-Modeller: a tool to support visual description of software architectures in UML (using the UML profile for π-ADL) – it is implemented as an extension of the Objecteering UML Modeller; π-Modeller: a tool to support visual description of software architectures in π-ADL – it is implemented using GME – Generic Modelling Environment; π-Animator: a tool to support graphical animation of software architectures described in π-ADL – it is implemented using Java and XSB Prolog; π-Analyser: a tool to support verification of structural and behavioural properties specified in π-AAL against software architectures described in π-ADL – it is implemented using MMC – Mobility Model Checker – and XSB Prolog; π-Refiner: a tool to support refinements of software architectures described in π-ADL where transformations are modelled and automated in π-ARL – it is implemented using the Maude rewriting logic system; π-Synthesiser: a tool to support code generation from concrete architecture descriptions in π-ADL – a π-ADL-to-Java code generator tool has been synthesized – it is implemented in the PBase language; π-ADL Compiler and Virtual Machine: a π-ADL callable compiler and persistent virtual machine, implemented in the PBase language; π-TraceChecker: an online model checking tool based on CADP – it checks if traces produced by the π-ADL virtual


Page 11

machine satisfy properties specified in π-AAL.

May 2006

Volume 31

Number 3

vited Paper, Lecture Notes in Computer Science, Springer Verlag, St Andrews, UK, May 2004.

These tools can be used as stand-alone tools or can be integrated to build π-model driven engineering environments through en- [12] Azaiez S., Oquendo F.: GAMA: Towards Architecture-centric Software Engineering of Mobile Agent Systems. Proceedings of the actable software process models using the Tower Browser Third International Workshop on Software Engineering for Large[74][41], a process-driven browser for managing architecture deScale Multi-Agent Systems (SELMAS 2004) at the IEEE/ACM Inscriptions created in the persistent store of the π-ADL virtual maternational Conference on Software Engineering (ICSE 2004), Edinchine – implemented in π-ADL itself. burgh, UK, May 2004.

All these tools are available as open source software at [13] Morrison R., Graham K., Balasubramaniam D., Mickan K., Oquendo F., Cimpan S., Warboys B., Snowdon B., Greenwood M.: Support http://www.architecture-ware.org as part of the ArchWare OSS for Evolving Software Architectures in the ArchWare ADL. Pro(Open Source Software) release, under the π-Toolkit distribution. References [1] Oquendo F., Warboys B., Morrison R. (Eds.): Software Architecture, Springer-Verlag, LNCS 3047, May 2004. [2] Oquendo F.: π-ADL: An Architecture Description Language based on the Higher Order Typed π-Calculus for Specifying Dynamic and Mobile Software Architectures. ACM Software Engineering Notes, Vol. 29, No. 3, May 2004. [3] Oquendo F.: π-ARL: An Architecture Refinement Language for Formally Modelling the Stepwise Refinement of Software Architectures. ACM Software Engineering Notes, Vol. 29, No. 5, September 2004. [4] Oquendo F.: Formally Refining Software Architectures with π-ARL: A Case Study. ACM Software Engineering Notes, Vol. 29, No. 5, September 2004. [5] Derniame J-C., Oquendo F.: Key Issues and Future Directions in Software Process Technology. Novática Journal, Special Issue on Software Process Technologies (invited paper), No. 171, SeptemberOctober 2004 and co-printed at the European Journal: CEPIS Upgrade, Vol. V, No. 5, October 2004. [6] Oquendo F.: Les architectures logicielles. Encyclopédie de l’informatique et des systèmes d’information, Editions Vuibert (In French) (To appear in 2006, In French). [7] Oquendo F.: Formally Modelling Software Architectures with the UML 2.0 Profile for π-ADL. ACM Software Engineering Notes, Vol. 31, No. 1, January 2006. [8] Alloui I., Oquendo F.: Describing Software-intensive Process Architectures using a UML-based ADL. Proceedings of the Sixth International Conference on Enterprise Information Systems (ICEIS’04), Porto, Portugal, April 2004. [9] Blanc-Dit-Jolicoeur L., Braesch C., Cimpan S., Leymonerie F., Oquendo F.: Towards a Business Process Formalisation based on an Architecture-centred Approach. Proceedings of the Sixth International Conference on Enterprise Information Systems (ICEIS’04), Porto, Portugal, April 2004. [10] Ratcliffe O., Cimpan S., Oquendo F., Scibile L.: Formalization of an HCI Style for Accelerator Restart Monitoring. Proceedings of the First European Workshop on Software Architecture (EWSA’04), Lecture Notes in Computer Science, Springer Verlag, St Andrews, UK, May 2004. [11] Oquendo F., Warboys B., Morrison R., Dindeleux R., Gallo F., Garavel H., Occhipinti C.: ArchWare: Architecting Evolvable Software. Proceedings of the First European Workshop on Software Architecture (EWSA’04), European Projects in Software Architecture – In-

ceedings of the Fourth Working IEEE/IFIP International Conference on Software Architecture (WICSA’04), Oslo, Norway, June 2004.

[14] Azaiez S., Pourraz F., Verjus H., Oquendo F.: Validation by Animation: Animating Software Architectures based on the π-Calculus. Proceedings of the Third Workshop on System Testing and Validation (SV'04), Paris, France, December 2004. [15] Ratcliffe O., Scibile L., Cimpan S., Oquendo F.: Towards an Inductive Definition and Evolution of Architectural Styles. Proceedings of the Seventeenth International Conference on Software and Systems Engineering and their Applications (ICSSEA’04), Paris, France, December 2004. [16] Revillard J., Benoit E., Cimpan S., Oquendo F.: Architecture-Centric Development for Intelligent Instrument Design. IEEE International Conference on Computational Intelligence for Measurement Systems and Applications (CIMSA 2005), Giardini Naxos, Italy, July 2005. [17] Revillard J., Benoit E., Cimpan S., Oquendo F.: Intelligent Instrument Design with ArchWare ADL. Proceedings of the Fifth Working IEEE/IFIP International Conference on Software Architecture (WICSA’05), Working Session Track, Pittsburgh, USA, November 2005. [18] Ratcliffe O., Cimpan S., Oquendo F.: Case Study on ArchitectureCentered Design for Monitoring Views at CERN. Proceedings of the Fifth Working IEEE/IFIP International Conference on Software Architecture (WICSA’05), Working Session Track, Pittsburgh, USA, November 2005. [19] Manset D., McClatchey R., Oquendo F., Verjus H.: “A ModelDriven Approach for Grid Services Engineering”, Proceedings of the Eighteenth International Conference on Software and Systems Engineering and their Applications (ICSSEA’05), Paris, France, December 2005. [20] Oquendo F.: UML 2.0 Profile for the ArchWare Architecture Description Language. Deliverable D1.8, ArchWare European RTD Project, IST-2001-32360, June 2005. [21] Oquendo F.: Tutorial of the ArchWare Architecture Description Language. Deliverable D1.9, ArchWare European RTD Project, IST2001-32360, June 2005. [22] Abrial J.-R.: The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [23] Allen R.: A Formal Approach to Software Architectures. PhD Thesis, Carnegie Mellon University, 1997. [24] Allen R., Douence R., Garlan D.: Specifying and Analyzing Dynamic Software Architectures. In Fundamental Approaches to Software Engineering, LNCS 1382, Springer Verlag, 1998. [25] Bernardo M., Ciancarini P., Donatiello L.: Architecting Systems with Process Algebras. Technical Report UBLCS-2001-7, July 2001.


Page 12

May 2006

Volume 31

Number 3

[26] Bernardo M., Ciancarini P., Donatiello L.: Detecting Architectural Mismatches in Process Algebraic Descriptions of Software Systems, Proceedings of the 2nd Working IEEE/IFIP Conference on Software Architecture, Amsterdam, IEEE-CS Press, August 2001.

don R., Warboys B., Zirintsis E.:Process Support for Evolving Active Architectures, Proceedings of the 9th European Workshop on Software Process Technology, LNCS 2786, Springer Verlag, Helsinki, September 2003.

[27] Binns P., Engelhart M., Jackson M., Vestal S.: Domain-Specific Software Architectures for Guidance, Navigation, and Control. International Journal of Software Engineering and Knowledge Engineering. 1996.

[42] Groote J. F., Mateescu R.: Verification of Temporal Properties of Processes in a Setting with Data. Proceedings of the 7th International Conference on Algebraic Methodology and Software Technology, Amazonia, Brazil, LNCS 1548, January 1999.

[28] Bolusset T., Oquendo F.: Formal Refinement of Software Architectures Based on Rewriting Logic, ZB2002 International Workshop on Refinement of Critical Systems: Methods, Tools and Experience, Grenoble, Janvier 2002.

[43] Heisel M., Levy N.: Using LOTOS Patterns to Characterize Architectural Styles, Proceedings of the International Conference on Theory and Practice of Software Development, LNCS 1214, Springer Verlag, 1997.

[29] Brown A.W.: An Introduction to Model Driven Architecture – Part I: MDA and Today’s Systems. The Rational Edge, February 2004.

[44] Inverardi P., Wolf A.: Formal Specification an Analysis of Software Architectures using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995.

[30] Chaudet C., Greenwood M., Oquendo F., Warboys B.: ArchitectureDriven Software Engineering: Specifying, Generating, and Evolving Component-Based Software Systems. IEE Journal: Software Engineering, Vol. 147, No. 6, UK, December 2000. [31] Chaudet C., Oquendo F.: A Formal Architecture Description Language Based on Process Algebra for Evolving Software Systems. Proceedings of the 15th IEEE International Conference on Automated Software Engineering (ASE’00). IEEE Computer Society, Grenoble, September 2000.

[45] Inverardi P., Wolf A., Yankelevich D.: Static Checking of System Behaviors using Derived Component Assumptions. ACM Transactions on Software Engineering and Methodology, Vol. 9, No. 3, July 2000. [46] Kerschbaumer A.: Non-Refinement Transformation of Software Architectures. Proceedings of the ZB2002 International Workshop on Refinement of Critical Systems: Methods, Tools and Experience, Grenoble, Janvier 2002.

[32] Davies J., Woodcock J.: Using Z: Specification, Refinement and Proof. Prentice Hall International Series in Computer Science, 1996.

[47] Kozen D.: Results on the Propositional µ-Calculus. Theoretical Computer Science 27:333-354, 1983.

[33] DeLine R.: Toward User-Defined Element Types and Architectural Styles. Proceedings of the 2nd International Software Architecture Workshop, San Francisco, 1996.

[48] Leymonerie F., Cimpan S., Oquendo F. : Extension d'un langage de description architecturale pour la prise en compte des styles architecturaux : application à J2EE. Proceedings of the 14th International Conference on Software and Systems Engineering and their Applications. Paris, December 2001 (In French).

[34] Fernandez J-C., Garavel H., Kerbrat A., Mateescu R., Mounier L., Sighireanu M.: CADP (CAESAR/ALDEBARAN Development Package) – A Protocol Validation and Verification Toolbox, Proceedings of the 8th International Conference on Computer-Aided Verification, New Brunswick, USA, LNCS 1102, Springer Verlag, August 1996. [35] Fischer M.J., Ladner R.E.: Propositional Dynamic Logic of Regular Programs. Journal of Computer and System Sciences Vol. 18, 1979. [36] Garavel H.: Compilation et Vérification de Programmes LOTOS. Thèse de Doctorat, Univ. Joseph Fourier (Grenoble), November 1989. Chapter 9: Vérification (In French). [37] Garavel H., Lang F., Mateescu R.: An Overview of CADP 2001. European Association for Software Science and Technology (EASST) Newsletter, Vol. 4, August 2002. [38] Garlan D., Allen R., Ockerbloom J.: Exploiting Style in Architectural Design Environments. Proceedings of the ACM SIGSOFT Symposium on Foundations of Software Engineering, New Orleans, 1994. [39] Garlan D., Monroe R., Wile D.: ACME: An Architecture Description Interchange Language. Proceedings of CASCON'97, Toronto, November 1997. [40] Garlan D., Monroe, R., Wile D.: ACME: Architectural Description of Component-Based Systems. Foundations of Component-Based Systems, Leavens G.T, and Sitaraman M. (Eds.), Cambridge University Press, 2000. [41] Greenwood M., Balasubramaniam D., Cimpan S., Kirby N.C., Mickan K., Morrison R., Oquendo F., Robertson I., Seet W., Snow-

[49] Leymonerie F., Cimpan S., Oquendo F., État de l'art sur les styles architecturaux : classification et comparaison des langages de description d'architectures logicielles. Revue Génie Logiciel, No. 62, September 2002 (In French). [50] Luckham D.C., Kenney J.J., Augustin L.M., Vera J., Bryan D., Mann W.: Specification and Analysis of System Architecture Using RAPIDE. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995. [51] Magee J., Dulay N., Eisenbach S., Kramer J., Specifying Distributed Software Architectures. Proceedings of the 5th European Software Engineering Conference, Sitges, Spain, September 1995. [52] Martí-Oliet N., Meseguer J., Rewriting Logic: Roadmap and Bibliography. Theoretical Computer Science, 2001. [53] Mateescu R., Garavel H., XTL: A Meta-Language and Tool for Temporal Logic Model-Checking. Proceedings of the 1st International Workshop on Software Tools for Technology Transfer, Aalborg, Denmark, July 1998. [54] Medvidovic N., Taylor R.: A Classification and Comparison Framework for Architecture Description Languages. Technical Report UCI-ICS-97-02, Department of Information and Computer Science, University of California. Irvine, February 1997. [55] Milner R.: Communicating and Mobile Systems: The π-Calculus. Cambridge University Press, 1999.


Page 13

May 2006

Volume 31

Number 3

[56] Monroe R.: Capturing Software Architecture Design Expertise with ARMANI. Technical Report CMU-CS-98-163, Carnegie Mellon University, January 2001.

[69] Oquendo F.: The ArchWare Architecture Refinement Language. Deliverable D6.1b, ArchWare European RTD Project, IST-200132360, December 2003.

[57] Moriconi M., Qian X., Riemenschneider R.A.: Correct Architecture Refinement. IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995.

[70] Oquendo F. et al.: The ArchWare Architecture Description Language: Abstract Syntax and Formal Semantics. Deliverable D1.1b, ArchWare European RTD Project, IST-2001-32360, December 2002.

[58] Moriconi M., Riemenschneider R.A.: Introduction to SADL 1.0: A Language for Specifying Software Architecture Hierarchies. Computer Science Laboratory, SRI International, Technical Report SRICSL-97-01, March 1997. [59] Morrison R.: On the Development of S-algol. PhD Thesis, University of St Andrews, 1979. [60] Philipps J., Rumpe B.: Refinement of Pipe and Filter Architectures. Proceedings of FM’99, LNCS 1708, 1999. [61] RAPIDE Design Team: Guide to the RAPIDE 1.0. Language Reference Manuals, Stanford University, July 1997. [62] Rongviriyapanish S., Levy N.: Variations sur le Style Architectural Pipe and Filter. Actes du Colloque sur les Approches Formelles dans l'Assistance au Développement de Logiciels (AFADL'00), Grenoble, France, January 2000. [63] Sangiorgi, D., Expressing Mobility in Process Algebras: First-Order and Higher-Order Paradigms. PhD Thesis, University of Edinburgh, 1992. [64] Stirling C.: Modal and Temporal Properties of Processes. Springer Verlag, 2001. [65] Stolen K., Broy M.: Specification and Development of Interactive Systems. Springer Verlag, 2001.

[71] Mateescu R., Oquendo F.: π-AAL: An Architecture Analysis Language for Formally Specifying and Verifying Structural and Behavioural Properties of Software Architectures, ACM Software Engineering Notes, Vol. 31, No. 2, March 2006. [72] Alloui I., Garavel H., Mateescu R., Oquendo F.: The ArchWare Architecture Analysis Language: Syntax and Semantics. Deliverable D3.1b, ArchWare European RTD Project, IST-2001-32360, January 2003. [73] Warboys B.C., Snowdon R., Greenwood R.M., Seet W., Robertson I., Morrison R., Balasubramaniam D., Kirby G., Mickan K.: An Active Architecture Approach to COTS Integration. IEEE Software, Special Issue on Incorporating COTS into the Development Process. Vol. 22, No. 4, 2005. [74] Warboys B.C., Greenwood R.M., Robertson I., Morrison R., Balasubramaniam D., Kirby G., Mickan K.: The ArchWare Tower: The Implementation of an Active Software Engineering Environment using a π-calculus based Architecture Description Language. Proceedings of the Second European Workshop on Software Architecture (EWSA’05), Pisa, Italy, Springer-Verlag, LNCS, 2005. [75] IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, October 2000.

[66] Strachey C.: Fundamental Concepts in Programming Languages. Oxford University Press, Oxford, 1967.

[76] Fitzgerald J., Larsen P.: Modelling Systems: Practical Tools and Techniques for Software Development, Cambridge University Press, 1998.

[67] Tennent R.D.: Language Design Methods based on Semantic Principles. Acta Informatica 8, 1977.

[77] Miller J., Mukerji J.: MDA Guide Version 1.0.1, Document Number: OMG/2003-06-01, Object Management Group, June 2003.

[68] Wile D.: AML: An Architecture Meta Language. Proceedings of the 14th International Conference on Automated Software Engineering, pp. 183-190. Cocoa Beach. October 1999.

Ï-Method: A Model-Driven Formal Method for Architecture ... - CiteSeerX

Ï-Method: A Model-Driven Formal Method for Architecture ... - CiteSeerX

Suggest Documents