Feature-Based Reusable Architectures for Families of Systems
Hassan Gomaa
Department of Information and Software Systems Engineering
George Mason University
Fairfax, Virginia, 22030-4444
hgomaa@isse.gmu.edu
Position Paper
October 1996
1. Introduction
At George Mason University, a project is underway to support software engineering lifecycles, methods, and environments to support software reuse at the requirements and design phases of the software lifecycle, in addition to the coding phase. A reuse-oriented software lifecycle, the Evolutionary Domain Lifecycle [Gomaa89, Gomaa91], has been proposed, which is a highly iterative lifecycle that takes an application domain perspective allowing the development of families of systems.
2. Evolutionary Domain Life Cycle
The Evolutionary Domain Life Cycle (EDLC) Model is a highly iterative software life cycle model that eliminates the traditional distinction between software development and maintenance. Furthermore, because new software systems are often outgrowths of existing ones, the EDLC model takes an application domain perspective facilitating the development of families of systems [Gomaa95]. The EDLC consists of the following major activities:
1) Domain engineering. During domain engineering, the following activities take place resulting in artifact that are stored in the domain reuse library:
a) Domain analysis and modeling, which involves developing a reusable specification for the family of systems.
b) Domain architectural design, which involves developing a reusable architecture for the family of systems.
c) Implementation of domain specific reusable component types.
2) Target system generation. During target system generation, the following activities take place resulting in artifacts that are stored in the target system library:
a) Target system specification generation. Given the requirements of an individual target system (one of the members of the family), the target system specification is generated by tailoring the reusable specification.
b) Target system architecture generation. Given the target system specification and the reusable architecture, the target system architecture is generated by tailoring the reusable architecture.
c) Target system configuration. Based on the target system architecture, the component types to be included in the target system are selected from the domain reuse library. Given, the target system configuration parameters, an instance of the target system is then composed by instantiating the target system components, interconnecting them and mapping them onto a hardware configuration.
3. Domain Analysis and Modeling
In a domain model, an application domain is represented by means of multiple views, such that each view presents a different aspect of the domain [Gomaa95]. The different views are developed iteratively.
a) Aggregation Hierarchy. The Aggregation Hierarchy is used to decompose complex aggregate object types into less complex object types eventually leading to simple object types at the leaves of the hierarchy. Objects types are either kernel, i.e., required in every target system, or optional, i.e., only required in some target systems. The Aggregation Hierarchy supports the IS-PART-OF relationship.
b) Object communication diagrams. Objects in the real world are modelled as concurrent tasks, which communicate with each other using messages. Dynamic relationships between objects, in the form of messages passed between objects, are shown by means of object communication diagrams.
c) State transition diagrams. Since each object is modeled as a sequential task, an object may be defined by means of a state transition diagram, whose execution is by definition strictly sequential.
d) Generalization / Specialization Hierarchy. As the requirements of a given object type are changed to meet the specific needs of a target system, the object type may be specialized by adding, modifying or suppressing operations. In domain modeling, the variants of a domain object type are stored in a Generalization / Specialization Hierarchy (GSH), which supports the IS-A relationship.
e) Feature / Object dependencies. This view relates the end-user’s perspective of the domain, namely the features supported by the domain, to the object types in the domain model. It shows for each feature (domain requirement) the object types required to support the feature. Also defined are any prerequisite features required and any mutually exclusive features. This view is particularly important for optional features, since it is the selection of the optional features, and the object types required to support them, that determine the nature of the desired target system.
4. Generation of Target System Specification
A Target System Specification is a problem-oriented architecture for an individual target system, i.e., a member of the family of systems that constitute the domain. It is a tailored instance of the Domain Model. Requirements are reused by selecting those features required in the target system and then tailoring the domain model, subject to the appropriate feature object dependency constraints, to generate the target system specification.
5. Domain Modeling Environment
A proof-of-concept experiment has also been carried out to develop a prototype domain modeling environment [Gomaa94, Gomaa96a], which consists of an integrated set of software tools that support domain modeling and target system requirements elicitation. The environment uses commercial-of-the-shelf software as well as custom developed software. The graphical editors supported by the Software Through Pictures CASE tool are used to represent the multiple views of the domain model, namely the Aggregation Hierarchy, the Object Communication Diagrams, the Generalization / Specialization Hierarchies and the State Transition Diagrams. However, the multiple views are semantically interpreted according to the domain modeling method. The information in the multiple views is extracted, checked for consistency, and mapped to an object repository. The feature / object dependencies are defined using a Feature / Object Editor.
A knowledge based tool is used to assist with target system requirements elicitation and generation of the target system specification [Gomaa92a]. The tool, implemented in NASA’s CLIPS shell, conducts a dialog with the human target system requirements engineer, prompting the engineer for target system specific information. The output of this tool is used to adapt the domain model to generate the multiple views of the target system specification.
The prototype environment is a domain independent environment. Thus it may be used to support the development of a domain model for any application domain that has been analyzed, and to generate target system specifications from it.
6. Current Status
The domain modeling environment has been used for modeling several different application domains. In addition to NASA’s Payload Operations Control Center (POCC) and Transportable Payload Operations Control Center (POCC) domains [Gomaa92b], two other application domains, a manufacturing domain [Gomaa93, Gomaa95] and a banking federation domain have been modeled. This demonstrates that the environment is indeed domain independent.
The wide ranging nature of the approach was shown when the environment was used to model a software process modeling domain. The Spiral Model encompasses other life cycle models such as the Waterfall Model, the Incremental Development model, and the Evolutionary Prototyping Model. The key characteristics of a given project, referred to as process drivers, are determined during risk analysis. The process drivers are used to tailor the spiral model to generate a project specific process model. A domain model was developed of the spiral model and then the domain modeling environment was used as a process model generator.
The proof-of-concept prototype described in this paper has shown the viability of having a domain independent environment for developing domain models and generating target systems from them. However currently, the environent is limited to the specification phase of the lifecycle. Thus a multiple view domain specification is developed from which target system specifications are generated.
Most recently, we have been investigating the design and implementation phases of the EDLC, with the goal of configuring executable distributed applications from a reusable software architecture and a library of predefined component types [Gomaa96b]. The full paper will describe this aspect of the research in more detail.
7. Acknowledgements
The author is indebted to his research colleagues and students L. Kerschberg, R. Fairley, C. Bosch, E. O’Hara-Schettino, V. Sugumaran, I. Tavakoli, and G. Farrukh for their invaluable assistance throughout. This work was sponsored in part by NASA Goddard Space Flight Center, the Virginia Center of Innovative Technology and DARPA. The Software Through Pictures CASE tool was donated to GMU by Interactive Development Environments.
8. References
[Gomaa 89] Gomaa H, R Fairley and L Kerschberg, “Towards an Evolutionary Domain Life Cycle Model”, Proc. Workshop on Domain Modeling for Software Engineering, OOPSLA’89, New Orleans, October 1989.
[Gomaa 91] Gomaa H and L Kerschberg, “An Evolutionary Domain Life Cycle Model for Domain Modeling and Target System Generation”, Proc. Workshop on Domain Modeling for Software Engineering, International Conference on Software Engineering, Austin, May 1991.
[Gomaa 92a] Gomaa H, L. Kerschberg, V. Sugumaran, “A Knowledge- Based Approach for Generating Target System Specifications from a Domain Model”, Proc. IFIP World Computer Congress, Madrid, Spain, September 1992.
[Gomaa 92b] Gomaa H, L. Kerschberg, V. Sugumaran, “A Knowledge- Based Approach to Domain Modeling: Application to NASA’s Payload Operations Control Centers”, Journal of Telematics and Informatics, Vol. 9, Nos 3/4, 1992.
[Gomaa 93] Gomaa H, “A Reuse-Oriented Approach for Structuringand Configuring Distributed Applications”, Software Engineering Journal, March 1993.
[Gomaa 94] Gomaa H, L. Kerschberg, C. Bosch, V. Sugumaran, I Tavakoli, “A Prototype Domain Modeling Environment for Reusable Software Architectures”, Proc International Conference on Software Reuse, Rio de Janeiro, Brazil, November 1994.
[Gomaa 95] H. Gomaa, “Reusable Software Requirements andArchitectures for Families of Systems”, Journal of Systems and Software, April 1995.
[Gomaa 96a] H. Gomaa, L. Kerschberg, V. Sugumaran, C. Bosch, I. Tavakoli, and L. O’Hara, “A Knowledge-Based Software Engineering Environment for Reusable Software Requirements and Architectures,” Journal of Automated Software Engineering, Vol.3, Nos. 3/4, August 1996.
[Gomaa96b] H. Gomaa and G. Farrukh, An Approach for Generating Executable Distributed Applications from Reusable Software Architecturesś, To be presented at the IEEE International Conference on the Engineering of Complex Computer Systems, Montreal, Canada, October 1996.