π -Method: A Model-Driven Formal Method for Architecture-Centric Software Engineering

1. π-Method: A Model-Driven Formal Method for Architecture-Centric Software Engineering By Flavio Oquendo Presented by: Sajith Wickramaratne

2. π-Method • This article presents the π-Method, a formal method that has been designed in the ArchWare European Project to address model-driven development of safe software systems. • It is a well-defined theoretical method relying on formal foundations. • It supports formal model-driven development of software systems having highly dynamic architectures. • Its formal language for architecture is based on: Architecture description : π-calculus. Architecture analysis : μ-calculus. Architecture transformation and refinement: Rewriting logic.

3. π-Method vs. Other formal methods • Formal methods such as B, FOCUS, VDM, and Z, aim to provide full support for formal development of software systems. • However, these methods do not provide any architectural support. • π-Method has been built from scratch to formally support architecture-centric component-based model-driven development.

4. Completeness and Correctness of Software Systems • Support the formal specification of software systems whose architecture can change (at run-time). • Support automated analysis: functional as well as non-functional properties. • Support their transformations and application synthesis, by stepwise refinement from abstract to concrete specifications and full code generation. • Support compliance with respect to application requirements (if requirements change, enable the software system to safely progress with new requirements).

5. π-Method • Why Formal? • Improves documentation and understanding of specifications. • Enables rigorous analysis of the system properties. • Improves rigour and quality of the whole development process. • Provides a firm foundation during the evolution process.

6. π-Method Why Architecture-Centric? • A key aspect of the design of any software system is its architecture. • Fundamental organization of the system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. • Provides the conceptual abstraction for modeling complex software systems during development and then during deployment and evolution Why Model-Driven Engineering? • Models are used to understand specific system aspects. • Predicts system qualities. • Reasons about impact of changes. • Indicates major system features to stakeholders.

7. Approach of the π-Method • The novelty of the π-Method lies in its holistic view of formal software development. • It involves: “how” the software is to function in terms of expected behaviours. “what” is its structure in terms of components and their connectors. “which” qualities are to be guaranteed. • Furthermore, an appropriate refinement process (describing “how to build” the software).

8. Architecture-centric formal development

9. Architecture-centric formal development “Define style” activities: • Principal actors are the “style architects”. • Represent the top level inception of a family of software architectures. • What types of architectural elements. • How elements can be combined. • Which constraints apply, and which processes can be applied to architecture elements and whole architecture descriptions. “Describe architecture” activities: • Principal actors are the “application architects”. • Use the domain specific styles defined by the style architect to describe a specific software architecture. • An architecture description, in terms of a model. • Can represent a system at various levels of abstractions. “Refine architecture” activities: • Principal actors are the “application engineers”. • Support transformations from abstract to more concrete architecture descriptions. • Derive concrete models by applying correctness preserving transformations.

10. Model transformations with π-ARL

11. Formal Languages • π-ADL: an architecture description language based on the higher-order typed π-calculus. • π-AAL: an architecture analysis language based on the μ-calculus. • π-ARL: an architecture refinement language based on the rewriting logic.

12. The triad of formal languages

13. The Architecture Description Language: π-ADL • Architecture Description Language encompasses two aspects: expression and verification of architectural styles. • General principles guided the design of π-ADL: • Formality: π-ADL (formal language) provides a formal system, at the mathematical sense, for describing dynamic software architectures. • Run-time viewpoint: π-ADL focuses on the formal description of software architectures from the run-time viewpoint: structure, behavior, and how these may evolve over time. • Executability: π-ADL(executable language) is a virtual machine that runs specifications of software architectures. • User-friendliness: π-ADL supports different concrete syntaxes – textual and graphical notations (including UML-based) .

14. π-ADL Design principles • The principle of correspondence. • The principle of abstraction. • The principle of data type completeness. Civil rights in the language • The right to be declared. • The right to be assigned. • The right to have equality defined over them. • The right to persist.

15. The Architecture Analysis Language: π-AAL Architecture Analysis Language focuses two aspects: • Architectural styles (style architects) • Software Architectures (application architects). Properties of styles and architectures. • structural (e.g. cardinality of architectural elements, interconnection topology) • behavioral (e.g. safety, liveness, and fairness defined on actions of the system). The π-AAL is a formal property expression language designed to support automated verification. • Can mechanically check whether an architecture described in π-ADL satisfies property expressed in π-AAL.

16. The Architecture Refinement Language: π-ARL • The concrete architecture: Vertical and Horizontal transformations. • Horizontal refinement is obtained from transforming an architecture by partition. • Vertical refinement is obtained from transforming steps to add more details to abstract models until the concrete architectural model is described. • The π-Method (ARL) supports both horizontal and vertical refinements. • π- ARL’s four forms of refinement from an external or internal point of view: • behavior refinement • port refinement • structure refinement • data refinement

17. Application domains of the π-Method The π-Method (π-ADL, π-AAL, and π-ARL) have been applied in the following application domains: • software systems targeting J2EE platforms. • enterprise application integration systems. • grid computing systems. • human-computer interfaces for monitoring systems. • mobile agent systems. • sensor-actuator networks. • service-oriented architectures. • ambient intelligence.

18. Related Work for π-Method • Architecture Description (ADLs): ACME, AESOP,AML,ARMANI,CHAM-ADL, DARWIN,META-H,PADL,RAPIDE,SADL, σπ-SPACE, UNICON-2,andWRIGHT/Dynamic-WRIGHT. • Architecture Analysis (AALs): PDL, LOTOS, CADP and CCS. • Architecture Transformation and Refinement(ARLs): FOCUS,RAPIDE, SADL, B and Z.

19. Future Workin π-Method • π-Modeller: a tool to support visual description of software architectures in π-ADL • π-Animator: a tool to support graphical animation of software architectures described in π-ADL. • π-Analyser: a tool to support verification of structural and behavioural properties specified in π-AAL against software architectures described in π-ADL. • π-Refiner: a tool to support refinements of software architectures described in π-ADL. • π-Synthesiser: a tool to support code generation from concrete architecture descriptions in π-ADL. • π-ADL Compiler and Virtual Machine. • π-TraceChecker.

20. Conclusion • π-Method recognizes architecture-centric model-driven approaches, supported by adequate, compositional, formal languages and tools. • It involves π-ADL, π-AAL, and π-ARL to support architectural description, analysis, refinement, and code generation. • π-Method cost-effectively develops and evolves software systems while guaranteeing their completeness and correctness.