Formalizing software architectures

.. 0 ii:: Formalizing Software Architectures: An Industrial Experience Petre Dini, Amina Belkhelladi, and Walc6lio L. Melo Centre de recherche informatiquede Mont&l 1801,McGill College Street, #800 Montreal,(Qc), H3A 2N4. Canada (dini I abelkhel I wmelo) @crim.ca P I, , ‘/;k Introduction . A software architecture identifies collections of functional modules shared by a fandy ofprod~crs, but does not analyze the specific algorithms used into such modules. To offer a formal basis for describing software architectures, system descriptions must provide useful documentation adapted to architectural views, e.g. conceptual, modules interconnection, execution, and code [2]. The conceptual view of a software architecture (CSA) is made at the early phases of a software system life-cycle, providing a high-level description of a software system [5]. A CSA, once well-defined and documented, can be useful for software engineers for communicating with each other, for deriving the remaining architectural views, or for V&V (Verification and Validation) purposes. The CSA is also useful in checking the consistency and completeness of the software architecture, and thus, taking corrective actions before low level design and implementation activities are performed [I]. Conceptual view helps us derive a static configuration of the system, leading to the execution architecture. In order to document and specify different aspects of software architectures, we have proposed a combination of informal object-oriented analysis and design methods, model-oriented formal languages, and already existing S/W specification languages. The rationale is to combine a graphical representation, which is intuitive and user friendly, with constraints expressed as first-order predicates to precise the interfaces of objects involved in different types of interactions. We have used a multiparadigm approach which combines concepts from OMT [6], Object-Z, and Conic [4], called MODL. MODL extends OMT with notions of pre-conditions, post-conditions, and invariants offered by Object-Z. Additionally, MODL integrates the concept of ports and configuration families (subsystems) provided by Conic. We have used MODL to describe the architecture of a data emulation software. The main purpose is to define a precise documentation, identify commonalities between similar products, and combine these commonalities to build a generic architecture. By doing so, we intend to enhance the reuse at the earlier phases of the software development lifecyle. The validation work was done within the project EPAC that is a two years long R&D project involving 2.5 man/year. EPAC has defined different research and development topics with the goal of enhancing the quality of emulation software systems, such as reusability, maintainability, and extensibility. An Overview of MODL We will present in the following the process to produce the desired software architecture in a sequential way. Obviously, the different steps may be performed iteratively because of refinement and reworking between each of them, according to the knowledge acquisition process. Based on knowledge from domain engineering, conceptual and execution architectures are inferred. ._; b 528 1. Based on the analysis of several products of the same family, their appropriate documentation, public information on similar products, discussions with domain cxpcrts, users of such products, vendors and manufactures, a collection of data is gathered. So, we arc able to identify relevant information of a family of products. At this point, the distinction bctwccn objects, operations, and attributes is not yet clarified. We use the Object-Z type spcciflcation technique to declare discovered information. This approach allows us to know in a prccisc way the domain-specific vocabulary (terms), and to continuously add other terms or types. STEP Classify identified information in objects, attribute, operations, abstract types, prcdicatc constraints, or invariants. The goal is to identify potential object classes, attributes spcciftc to certain classes, as well as the distribution of operations to objects. At this point, it is possible that certain operations or properties will not be identified as belonging to already classified terms. STEP1 can be re-applied to reclassify some terms, or it can be iterated in order to highlight missing concepts and terms. The information obtained from this step are specified using OMT or STEP 2. Object-Z. i . ,. ., .’ ,.. ! * -_ .I .I . ._ _ ’ .! *. -. ,i, f ‘I .: STEP 3. Represent graphically the conceptual architecture, using decisions derived from STEPZ. We use information from STEPZ, and the documentation of existing legacy systems of the considered product family. The main goal of this step is the identification of object relationships, such as the inheritance, specializations, aggregations, and ,particular views on the potential objects. 4. Specify the structure and behavior for each component. Document each component identified as a class (type) in STEP 3. The operations must be properly assigned to these types, It is suitable to prescribe pre- and post-conditions, as welt as several invarlants or Icxtual denotations.’ It is important that activation conditions for all operations identified at STEP 3 bc defined for each operation. An Object-Z schema is specified for each class built in STEP3. Some schemes can be designed for only capture some aspects, which are not necessarily objects. Then, schemes can be composed to obtain an appropriate OMT class. STEP Identify different interaction scenarios within a subsystem, the object interfaces through these scenarios take place, as well as constraints on these interactions. The purpose is to identify activation conditions of all operations identified in STEP 2, and behavioral dependencies between objects identified and specified in the previous steps. This implies the idcntifcation of sources of all activation events discovered,in STEP 4. We represent interaction scenarios by cooperation relations [3], as introduced below, to obtain a more precise expression than OMT. However, OMT graphical representation diagrams can be used. OMT allows this representation in a graphical manner, but it is difficult to represent other types of constraints, i.e, invarlants or state instances. We use Object-Z to specify more precisely these aspects. STEP5 ., 6. Specify detailed scenarios between subsystems through inter-system events, This allows to extend the system on well-defined interactions interfaces, detect dependcncics between subsystems, and favors the reuse of already identified components. Scenarios arc built using OMT, since in Object-Z it is difficult to prescribe event dependencies. We use the notion of typed interface which has been previously introduced, and create particular ‘types .of interactions according to these interfaces between. Systems are clusterized in subsystems, which communicate with each other or with their environment across boundary objects. STEP Lessons learned During our work several information favoring the derivation of generic architccturcs have been identified. In addition, we have been able to identify reusable concepts for a family of data emulation modules. Common operations, interactions, and scenarios (interaction patterns), which can be considered as commonalities of all emulation types, have also been identified. The resulting specification seems to be more rigorous, allowing one ensuring a better and safer transition to the implementation. _-- : I. - -. 529 However, the marriage between Object-Z, Conic, and OMT is not so straightforward. First, OMT favors the graphical representation, but several problems related to object composition, especially when considering subsystems, remain. It is difficult to build scenarios in Object-Z, and an external operation (e.g. NOTIFY) will be useful to express notifications sent to the emulation managers. The training and learning formal languages, i.e. Object-Z, is effort consuming. However, to improve the system specification, a trade-off between informal and formal requirements is necessary. Some weaknesses are due to the immaturity of the language Object-Z, which was not concerned to cover all aspects related to object-oriented architecture requirements. Conic is object-based, and does not provide neither compositions of interactions, nor inheritance. Consequently, the issues related to the object composition must be enhanced to capture dynamic properties in the object-oriented approach. References Ul Courtois, P.-J., Pamas, D.L. 1995. Documentation for Safetv Critical Software, Baltimore, Proceedings of 15th International Conference on Sofrware Engineering, Maryland, May 1993. pp. 3 15-323 PI Dini, P.. Ramazani. D., Bochmann. v. G. 1995. Formal and Informal in Balanced Svstem Specifications. The International Conference on Balanced Systems, BASYS’95, Vitoria, Brasil, June 1995. r31 Dini, P. 1997. Automatic Reconfimnation Management in Networks and Distributed Systems, Ph.D. Thesis, University of Montreal, January 1997. [41 Mapee. J. et al.1989. Constructing Distributed Systems in Conic. IEEE Tr. on SE, vol. 15, no, 6, June 1989. pp. 663-675. 151 PI Shaw. M. 1994. Making Choices: A Comparison of Stvles for Software Architecture, PA, May 1994. School of Computer Science, Carnegie Mellon University, Pittsburg Rumbaugh, J.. Blaha, M., Premerlani. W.. Eddv. F., Lorensen, W. 1991. ObjectOriented M odeling and Design, Prentice-Hall, Inc., 1991. f