Domain Modeling for Software Reuse and Evolution
Hassan Gomaa and Larry Kerschberg
Center for Information Systems Integration and Evolution
Department of Information and Software Systems Engineering
George Mason University
Fairfax, Virginia, 22030-4444
Abstract
This paper describes a prototype domain modeling environment
used to demonstrate the concepts of reuse of software requirements and software
architectures. The prototype environment,
which is application-domain independent, is used to support the development
of domain models and to generate target system specifications from them.
The prototype environment consists of an integrated set of commercial-off-the-shelf
software tools and custom developed software tools.
1: Introduction
At George Mason University, a research and development project is investigating software engineering lifecycles, methods, and environments to provide software reuse at the requirements and design phases of the software lifecycle, in addition to the coding phase.
Figure 1. Evolutionary Domain Life Cycle Model
A reuse-oriented software lifecycle, the Evolutionary Domain Lifecycle (EDLC) , is a highly iterative lifecycle that takes an application domain perspective allowing the development of families of systems. Current emphasis is on the domain analysis and specification phase of the EDLC for developing an application domain model, which captures the similarities and variations of the domain.
This paper describes a domain modeling method and a prototype domain modeling environment. The paper also describes their application to software process modeling and in particular to the Spiral Process Model for project specific process model generation.
2: Domain Modeling
2.1: Evolutionary domain life cycle
The Evolutionary Domain Life Cycle (EDLC) Model [5, 6] 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 allowing the development of families of systems [17, 18], i.e., systems that share common characteristics. The EDLC consists of the following major activities (Figure 1):
1) Domain modeling. Domain modeling deals with developing the reusable requirements, reusable specification and reusable architecture for the family of systems that constitute the application domain . Domain specific reusable components are developed and stored in an object repository.
2) Target system generation. Given the requirements of an individual target system, the target system specification is generated by tailoring the reusable specification and the target system architecture is generated by tailoring the reusable architecture. Based on the target system architecture, the component types to be included in the target system are selected.
A Domain Model is a problem-oriented architecture for the application domain that reflects the similarities and variations of the members of the domain. Given a domain model of an application domain, an individual target system is created by tailoring the domain model given the requirements of the individual system. The concept of generating target systems from a generic specification and/or architecture has been investigated by several researchers [1, 14, 15, 19].
2.2: Domain modeling method:
Since it is considered that the object-oriented model of
software development is more conducive to evolution and change, the domain
modeling approach takes an object- oriented perspective. The goal is to
apply object-oriented concepts and extend them to application domains.
The domain modeling method is similar to other object-oriented methods when used for analyzing and modeling a single system [e.g., 20, 21]. Its novelty, and where it differs from other methods, is the way it extends object-oriented methods to model families of systems. Thus the method allows the explicit modeling of the similarities and variations in a family of systems.
In a domain model, an application domain is represented by means of multiple views, such that each view presents a different perspective on the application domain. Four of the views, the aggregation hierarchy, the object communication diagram view, the generalization/specialization hierarchy, and the state transition diagram view have similar counterparts in other object-oriented methods used for modeling single systems.
However in our domain modeling method, the aggregation hierarchy is also used to model optional object types, which are used by some but not necessarily all members of the family of systems. Furthermore, the generalization / specialization hierarchy is also used to model variants of an object type, which are used by different members of the family of systems. The fifth view, the feature/object dependency view, is used to model explicitly the variations captured in the domain model; each feature - optional domain requirement - is associated with the optional and variant object types needed to support it. This provides the basis for defining which target systems can be generated from the domain model.
The multiple views in the domain modeling method [8, 9] are given below:
a) Aggregation Hierarchy: The Aggregation Hierarchy (AH) is used to decompose complex aggregate object types into less complex, component object types eventually leading to simple object types at the leaves of the hierarchy. Object types are kernel, i.e., required in all target systems, or optional, only required in some target systems. At the upper levels of the hierarchy, aggregate object types represent subsystems. An example aggregation hierarchy from the Payload Operations Control Center Domain (POCC) is shown in Figure 2.
Figure 2. Aggregation Hierarchy from Payload Operations Control Center
Figure 3: Level 0 Object Communication Diagram from Payload Operations Control Center Domain
b) Object communication diagrams: Objects in the real world are modeled as concurrent tasks [13], which communicate with each other using messages. Messages between objects may be loosely coupled or tightly coupled [11]. The object communication diagrams (OCDs), which are hierarchically structured, show how objects communicate with each other. The levels of decomposition of OCDs correspond to the levels of the Aggregation Hierarchy. An example object communication diagram from the POCC domain is shown in Figure 3.
c) State transition diagrams: Since each object is modeled as a sequential task, an object may be defined by means of a finite state machine, and represented by a state transition diagram, whose execution is by definition strictly sequential. An example state transition diagram from the POCC domain for the Earthbound Command Load Verifier object is shown in Figure 4.
d) Generalization/Specialization Hierarchies: As the requirements of a given kernel or optional object type are changed to meet the specific needs of a target system, the object type may be specialized [16, 23]. The variants of a domain object type are specified in a Generalization/Specialization Hierarchy (GSH). An example Generalization / Specialization hierarchy from the POCC domain is shown in Figure 5.
e) Feature/Object dependencies: This view shows for each feature (domain requirement) the object types required to support the feature. In domain analysis, domain requirements are analyzed and categorized as kernel requirements, those that must be supported in all target systems, optional requirements (only required in some target systems), and mutually exclusive requirements. Additionally, some requirements need others as prerequisites. This view emphasizes 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. Example inter-feature and feature-object dependencies from the POCC domain are shown in Figure 6.
Figure 5: Generalization/Specialization Hierarchy from Payload Operations Control Centers
Example feature-object dependencies: (Sending Real Time Commands Feature supported-by Real-Time_Command_Data_Store_OS optional) Sending Real Time Commands Feature supported-by Satellite_Bound_Command_Problem_ Sending Real Time Commands Feature supported-by Satellite_Bound_Real_Time_Command_ Example inter-feature dependency (Verifying Real Time Commands Feature requires Sending Real Time Commands Feature) |
Figure 6: Example Feature/Object and Inter-Feature Dependencies from Payload Operations Control Center Domain
2.3: Domain modeling environment
An environment which allows the generation of target systems from a domain model is referred to in this paper as a domain modeling environment. Such environments are also called application generators and software system generators [1]. These generators are usually highly domain-specific as they have the structure and code for the application domain built into them. In addition, they provide a means of adapting the code to generate a specific target system, either by means of parameterization or a by a user program written in a domain-specific language. A goal of this research is to have an application-domain-independent domain modeling method and environment to support the specification of a family of systems. An overview of the environment is provided in the next section.
3: Overview of Prototype Domain Modeling Environment
3.1: Objectives of prototype
Figure 4: State Transition Diagram from Payload Operations Control Center Domain
The EDLC and the domain modeling concept represent a radically different paradigm for software development compared to the traditional waterfall model. The objectives of the prototype domain modeling environment are: a) provide application-domain-independent tool support to represent the multiple graphical views supported by the domain modeling method, b) provide a consistency checking capability across the multiple views, c) map the multiple views to an integrated underlying representation, stored in an object repository, and d) generate target system specifications automatically from the domain model.
Since limited resources were available for prototype construction,
the proof-of-concept experiment was constrained as follows: a) for domain
modeling, we provide support for the domain analysis and specification phases
of the EDLC, and b) for target system generation we support the generation
of the target system specification phase. This phase was a good candidate
for a knowledge-based approach, as the procedures for target system generation
could be expressed as rules which could be prototyped rapidly.
3.2: Tool support for the prototype
Because of limited resources and the desire to focus on
the innovative aspects of the domain modeling environment, commercial-off-the-shelf
(COTS) software was used whenever possible. We believe that the tools discussed
below represent another important aspect of reuse, and feel that open architectures
and standards are essential to fostering large-scale reuse of software.
User Interface Management System.
An existing user interface management system is desirable to support a windows,
menu and icon based user interface. NASA's TAE User Interface Management
System was selected to provide an integrated interface to the prototype
environment [22].
CASE Tool. A survey of CASE
tools indicated that there are several that support the popular Structured
Analysis and Real-Time Structured Analysis methods [24]. It was decided
that the domain modeling method should use a graphical notation similar
to that used by Real-Time Structured Analysis, but with a radically different
semantic interpretation of the diagrams supported by the domain modeling
method. Another key requirement was that the CASE tool support an open system
architecture, so that the information contained in the multiple views could
be extracted and processed by custom software tools developed as part of
this project. Interactive Development Environment's (IDE) Software Through
Pictures (StP) was selected, as it satisfies the above two requirements.
Knowledge Based Expert System Shell. NASA's CLIPS expert system shell serves as a basis for implementing
the Knowledge-Based Requirements Elicitation Tool for generating the target
system specifications by tailoring the domain model based on selected features.
Object-Oriented Programming Environment. An object-oriented programming environment is needed to store integrated object specifications in the object repository. Although initially, we considered using an object-oriented database management system, we decided that for the proof-of-concept prototype, it was simpler and sufficient to implement the object repository using the Eiffel object-oriented programming language and system [16], which supports a persistent object store.
4: The Domain Modeling Environment
4.1: Introduction
The scope of the prototype environment includes two major phases: 1) development of a domain model specification (Figure 7) and 2) target system specification generation (Figure 8). The tools supporting domain model specification are: a) The Domain Model Graphical Editing tool, b) Domain Model Relations Extractor, c) Domain Model Consistency Checking Tool, d) Domain Object Repository Generator, and e) Feature/Object Editor.
The tools supporting target system specifications generation from the domain model (Figure 8) are as follows: a) Domain-Dependent Knowledge Base Extractor, b) Knowledge-Based Requirements Elicitation Tool (KBRET), and c) Target System Specification Generator.
4.2: Tools for creating and integrating multiple views
In this section we discuss each custom-developed
software tool.
Domain model graphical editing tool. This tool allows the graphical editing of the multiple views of
a domain model. The views are the object type aggregation hierarchy, the
object communication diagrams, state transition diagrams, and object type
generalization/specialization hierarchies. This tool was developed by customizing
the Software through Pictures (StP) CASE tool to support the specification
of the multiple views according to the domain modeling method.
Domain model relation extractor tool. This tool extracts the information contained in the multiple views
of the domain model from StP's TROLL relational data base, interprets the
data semantically according to the domain modeling method, and stores it
in a common underlying relational representation. These relations represent
the data needed by the other environment tools.
Domain model consistency checking tool. The graphical views represented by the OCDs, the AH, the GSHs, and the STDs, each focus on one aspect of the domain being modeled. Although StP provides consistency checking within one particular view, additional consistency checking is required among the multiple views.
The Domain Model Consistency Checker (DMCC) uses a set of scripts written in the Troll/USE query language that check the underlying relations for inconsistencies based on rules defined by the domain modeling method outlined in section 2.
4.3: Object repository
The object repository provides an integrated object-oriented
specification of each object type, the Aggregation Hierarchy, Object Communication
Diagrams, Generalization/Specialization Hierarchies, etc. This repository
is a single composite object that is composed of other objects representing
domain object types, features, and the relationships among them which serve
to define a domain model [4].
Domain object repository generator. The Domain Object Repository Generator tool takes the information captured in the relational representation and creates corresponding objects according to the object repository's schema.
Figure 7: Development of Domain Model Specification
Figure 8: Generation of Target System Specification
For example, if the domain analyst had created eight object
communication diagrams using StP, the Domain Object Repository Generator
tool would create eight instances of class OCD, the class defining object
communication diagrams. Similarly, this tool will create objects representing
the aggregation hierarchy, generalization/specialization hierarchies, and
state transition diagrams, as well as the domain object types, external
object types, and messages which are represented in these diagrams.
Feature/object editor. After
the object repository representing a domain model has been created, the
domain analyst can use this tool to define the optional features by: 1)
giving each feature a unique name, 2) entering an informal annotation for
each feature, 3) specifying domain object types supporting the feature being
defined, and 4) specifying other prerequisite features required by the feature
being defined. In addition to defining new features, the domain analyst
can use this tool to browse features previously defined for a given domain
model, delete features from the domain model, or modify the definition of
features in a domain model. The Feature/Object Editor can also be used to
establish relationships among sets of features.
Domain-dependent knowledge base extractor. The Domain-Dependent Knowledge Base Extractor tool extracts information
about the domain model from the object repository, formats that information
as facts, in CLIPS, which can then be processed by the Knowledge-Based Requirements
Elicitation Tool (KBRET), and stores those facts in a file for use by that
tool. Facts are created for each domain model object type, feature, and
feature annotations, as depicted in Figure 9. Similarly, facts corresponding
to dependencies among features, dependencies between features and domain
object types, as well as the aggregation and generalization/specialization
hierarchies, are also created.
4.4: Target system specification generation
A target system specification is derived by tailoring the
domain model according to the features desired in the target system. During
the generation of the target system specification, the feature-object dependencies
have to be enforced in order to ensure a consistent specification. A knowledge-based
system called the Knowledge-Based Requirements Elicitation Tool (KBRET)
has been developed to automate the process of generating the specifications
for the target systems. This tool has been implemented in NASA's CLIPS expert
system shell.
Knowledge-based requirements elicitation tool. The major components of KBRET are 1) the domain-dependent knowledge base, 2) the domain-independent knowledge base and 3) the inference engine. The domain-dependent knowledge base is derived from the object repository through the KBRET-Object Repository Interface, and contains domain-specific information which characterizes the multiple views, object specifications, features and dependencies of a particular domain model for which a target system is desired.
The domain-independent knowledge base contains the procedural and control knowledge required to generate target system specifications from a domain model. This separation between the domain-independent and domain-dependent knowledge is essential for providing scale-up and maintainability. Clearly, the domain-independent knowledge base can be applied to different domain models regardless of their application domain. The knowledge bases consist of knowledge modules (KMs). Each domain-dependent KM consists of a set of related facts derived from the object repository, while each domain-independent KM consists of rules to support its functionality. The inference engine is the underlying forward-chaining production system provided by CLIPS. The KMs are invoked and executed by the inference engine, based on the rules in the domain-independent knowledge base.
Figure 9: Domain Dependent Knowledge Base for the POCC
KBRET accomplishes the task of target system specification
generation in several phases: Browsing, Target System Requirements Elicitation,
Dependency Checking, and Target System Specification Generation. The various
components of KBRET are schematically shown in Figure 10. KBRET is described
further in [9].
Figure 10: Knowledge-Based Requirements Elicitation Tool
Target system specification generator tool. The graphical views of a target system can be generated automatically from those of the domain model by tailoring the domain model views based on KBRET's output. The specification of a target system is defined in terms of the object types that are to be included in the target system. Using this information, the Target System Specification Generator tool performs the following tasks: 1) Derives the set of object types that are not included in the target system and hence must be removed from the domain model, 2) Generates the graphical views for the target system using the domain model views and the list of the object types to be deleted. The two relations output by KBRET are used in tailoring the StP "picture files" of the domain model to create the target system picture files to be displayed using StP. (StP creates a picture file for each diagram describing the pictorial layout of the diagram), and 3) Modifies the object type names by appending the word Variant to the name of those object types for which a variant, i.e., a specialization, has been selected and the word Variants to those object types for which more than one variant object type has been selected.
The target system engineer may then view the multiple views of the target system using the StP graphical editors.
5: Domain Modeling of the Spiral Process Model
5.1: The spiral process model
Figure 11: Aggregation Hierarchy for Spiral Life Cycle Domain
The Spiral Model is a process model conceived by Boehm [2] to address known problems with earlier process models of the software life cycle, in particular the Waterfall Model. In the spiral model, the radial coordinate represents cost and the angular coordinate represents progress in completion of a cycle of the model. Each cycle involves traversing through four quadrants. The first quadrant is to determine objectives, alternatives, and constraints for the cycle. The second quadrant is a risk analysis and evaluation of alternatives for the cycle. The third quadrant is to develop and verify the next level product. The fourth quadrant involves planning for the next cycle.
The Spiral Model is intended to encompass other life cycle models such as the Waterfall Model, the Incremental Development model, and the Throwaway Prototyping Model. During Risk Analysis, the key characteristics of the project are determined, referred to as process drivers. The process drivers are used to determine which process model is most appropriate for the project. Thus the process drivers are used to tailor the Spiral Model to generate a project-specific process model. In this way, the Spiral Model can be considered a process model generator [3].
5.2: Applying domain modeling to the spiral process model
As the Spiral Model encompasses several process models, an intriguing problem is to what extent the application domain modeling concept can be applied to the domain of process models. In particular, a domain model of the Spiral Process Model (SPM) could be developed to encompass the other process models. By selecting the appropriate process drivers for a given project, the SPM domain model would then be adapted to generate a process model specifically tailored for the project.
As a proof-of-concept, a domain model of an example SPM spiral has been developed. This proof-of-concept domain model is an abstraction of the spiral model, so it does not reflect every aspect of it. Its main goal is to demonstrate how a domain model of the spiral model could be used as a process model generator.
Figure 12. Level 0 Object Communication Diagram for Spiral Life Cycle Domain
In developing the SPM domain model, an important issue is how to represent the cycles and quadrants of the SPM. First it was decided that an object in the domain model would represent an activity in the SPM. Furthermore an aggregate object would represent an aggregate activity, i.e., a composition of several activities. Next, a decision was made to represent each quadrant by means of an aggregate object. The aggregate object for a given quadrant can then be decomposed further at one or more levels of detail to show the activities in that quadrant. Finally features are used to represent process drivers.
5.3: Support for spiral model cycles, quadrants and activities
The first level of decomposition of the SPM domain model is shown as the top level of the Aggregation Hierarchy (Figure 11) and Object Communication Diagrams (Figure 12). There are four aggregate objects, one for each of the quadrants of the spiral model. These are Defining Objectives, Alternatives, and Constraints; Analyzing Risks; Developing and Verifying Product; and Spiral Planning.
The notational suffixes in figures 11 and 12 and the table below, K, O, A, S, and V refer to characteristics of the object types, respectively, Kernel, Optional, Aggregate, Simple and Variant. These labels indicate the possibly multiple roles an object type may have in the domain model.
The goal of the spiral model is to be risk driven, so that the risks in a given cycle are determined during the Analyzing Risks quadrant. In order to manage these risks, certain additional project-specific activities may be planned to address the risks, such as Requirements Prototyping, if the risk analysis indicates that the software requirements are not clearly understood. These project specific risks are termed process drivers. For any process driver, one or more project specific activities need to be performed to manage the risk.
At the first level of decomposition, the spiral model activities corresponding to the four quadrants are not cycle specific, i.e., they are carried out in each cycle. At lower levels of decomposition, additional cycle specific activities are depicted, the concept being that these activities are performed when the appropriate cycle is being enacted. Thus Developing and Verifying Product is decomposed further to give four aggregate objects that correspond to each of the specific products that is developed during a given cycle.
The first cycle is a project-level planning cycle, whose main product is a project plan. The second cycle is a software requirements cycle whose main product is the software requirements specification. The third cycle is a preliminary design cycle whose main product is a preliminary design (also referred to as architectural design) specification. The fourth cycle is a construction and test cycle whose main output is an operational system. The decomposition of each of the cycle aggregate objects gives the activities within that cycle.
By iterating through one or more of the cycles, the spiral model can encompass several more cycles. In the fourth phase of the SPM, Spiral Planning, a decision is made about what plan to pursue for the next cycle through the Spiral Model. Spiral Planning is decomposed into cycle specific planning activities, including:
a) Planning for Incremental Development, which leads to an iteration through the Preliminary Design and Construction and Test cycles, reflecting a phased approach to software development.
b) Planning for Evolutionary Development, which leads to an iteration through all four cycles, reflecting an evolutionary approach to software development, in which the software requirements are expected to evolve.
In the domain model, there are kernel objects and optional objects. Kernel objects correspond to activities that are required in every process model generated from the SPM domain model. Optional objects correspond to activities that are only required in some generated process models. In the domain model of the SPM, the kernel of the domain corresponds to a Waterfall Process Model. This process model would be adopted for a project with minimal risk, for example re-implementing an existing well-understood system.
Figure 13. Generalization/Specialization Hierarchy for Design Method Selection
A kernel or optional object type can be specialized to reflect a variation on an activity that is only carried out in some process models. For example, Requirements Analysis and Specification is a kernel object, as it is assumed that every software project would include this activity. However, Requirements Prototyping is an optional object, as this activity is only required if there is a poor understanding of requirements (a process driver).
An example of specialization is Design Method Selection - the generalization / specialization hierarchy for Design Method Selection is shown in Figure 13. This object type can be specialized to reflect the different kinds of method selection that can be carried out, reflecting the characteristics of different projects. These specialized object types are Object-oriented Design Method Selection, Ada-based Design Method Selection, Real-Time Design Method Selection, and Distributed Design Method Selection.
5.4: Support for process drivers
The SPM domain model is tailored according to a particular project's process drivers to generate a specific process model for that project. The way this is achieved in the domain modeling method is by defining feature / object dependencies, where the features correspond to optional requirements and the objects are optional or variant objects.
Applying this to the SPM domain model, the features correspond to process drivers. The objects in the feature / object dependencies reflect optional or variant activities. Thus by selecting a process driver, the activities required to support it are chosen, as shown in Table 1.
For example, the process driver "Low understanding of requirements" is supported by the activity "Requirements Prototyping". This means that if the requirements are not understood, then the Requirements Prototyping activity needs to be carried out for this project and so is included in the generated process model for this project. Some process drivers are supported by more than one activity. For example the process driver "Performance Requirements" is supported by three activities, Design Performance Analysis, Design Prototyping, and Performance Testing.
Table 2: Risk-Related Process Driver Relationships
Process Driver |
Requires |
| Real time system | Performance Requirements |
| Design method need | Design method training need |
| Lack of development method | Design method need |
There may also be driver / driver dependencies, as shown in Table 2. Thus the process driver "Real-Time system" requires the driver "Performance requirements", since every real-time system has performance constraints.
5.5: Applying the KBSEE to the spiral process model
A domain model of the Spiral Process Model has been developed using the prototype KBSEE. In this application of the KBSEE, the KBSEE is used as a process model generator. The version of the Knowledge Based Requirements Elicitation Tool for process model generation is called PROGEN (Process Model Generator).
PROGEN interacts with the project manager, presenting the
process drivers (features) available for selection. The project manager
selects the drivers relevant to the project. PROGEN then tailors the SPM
domain model to generate a project specific process model containing the
kernel process activities, together with the optional and variant activities
included to satisfy the selected process drivers.
6: Conclusions
This paper has described a domain modeling method and prototype domain modeling environment for software reuse and evolution. The application-domain-independent prototype environment supports the development of domain models and the generation of target system specifications. The environment consists of an integrated set of commercial-off-the-shelf software tools and custom-developed software tools. It has demonstrated the viability of the EDLC approach for developing reusable software architectures from which target systems can be generated. Currently the project is addressing the design and implementation phases of the EDLC model as well as scaleup issues [10, 11].
Table 1: Risk-Related Process
Drivers
and Supporting Activities
| Process Driver | Supported by Activity |
Node |
| Significant project risk | Project Level Prototyping Requirements Prototyping |
3.1.6 3.2.2 |
| Lack of development method | Selection of Development Method | 3.1.2 |
| Need for CASE tool | Selection of CASE Tool | 3.1.5 |
| Low understanding of requirements | Requirements Prototyping | 3.2.2 |
| Changing requirements | Requirements Prototyping Evolutionary Development OOD Method Selection |
2.3.3 4.4 3.1.3v |
| Operational life cycle | Incremental Development Evolutionary Development OOD Method Selection |
4.5 4.4 3.1.3v |
| Performance requirements | Design Performance Analysis Design Prototyping Performance Testing |
3.3.3 3.3.2 3.4.6 |
| Maintenance/support requirements | Requirements Prototyping Preparation for Enhanced Documentation |
3.2.2 3.4.2 |
| Complex system interfaces | Design Prototyping | 3.3.2 |
| Early capability | Requirements Prototyping Incremental Development Evolutionary Development |
3.2.2 4.5 4.4 |
| Phased development | Incremental Development | 4.5 |
| Complex user interface | Requirements Prototyping | 3.2.2 |
| Real time system | Real Time Design Method Selection | 3.1.3v |
| Design method need | Selection of Design Method | 3.1.3 |
| Design method training need | Design Method Training | 3.1.4 |
| Existing hardware/software constraint | Local Design Tailoring | 3.3.4 |
| Reuse library exists | Select or Adapt Reusable Components | 3.4.3 |
| Spiral process | Defining Objectives, Alternatives, and Constraints Analyzing Risks Planning for Requirements Cycle Planning for Architectural Design Cycle Planning for Construction and Test Cycle |
1 2 4.1 4.2 4.3 |
The domain modeling method and environment have been used
for modeling several different application domains. This paper has also
described an application of domain modeling to software process modeling
and in particular to the Spiral Process Model. A proof-of-concept domain
model of the SPM has been developed. Its main goal has been to demonstrate
how a domain model of the SPM can be used as a process model generator.
Research is continuing to investigate this approach in more detail.
7: Acknowledgments
The authors gratefully acknowledge the contributions of C. Bosch, E. O'Hara-Schettino, V. Sugumaran, and I. Tavakoli, in developing the prototype Knowledge Based Software Engineering Environment, and the contributions of F. Carr and J. Yoon in its application to process modeling. The domain modeling research and development of the Knowledge Based Software Engineering Environment was sponsored primarily by NASA Goddard Space Flight Center with additional support from the Virginia Center of Innovative Technology. Portions of the work were sponsored by an ARPA grant, administered by the Office of Naval Research under grant number N0001492J4038. The application of the domain modeling technology to process modeling was sponsored by the Virginia Center of Excellence in Software Reuse and the Software Productivity Consortium. We also gratefully acknowledge the Consortium for providing us with information on the Spiral Model. The Software Through Pictures CASE tool was donated to GMU by Interactive Development Environments, Inc.
8: References
[1] Batory D and S. O'Malley, "The Design and Implementation of Hierarchical Software with Reusable Components," ACM Transactions on Software Engineering Methodology, 1(4), pages 355-398, October 1992.
[2] Boehm B., "A Spiral Model of Software Development and Enhancement," IEEE Computer, May 1988.
[3] Boehm B. and F. Belz, "Experiences with the Spiral Model as a Process Model Generator," Proc. 5th International Software Process Workshop, 1989.
[4] Bosch, C., H. Gomaa, and L. Kerschberg, "Design and Construction of a Software Engineering Environment: Experiences with Eiffel," in IEEE Readings in Object-Oriented Systems and Applications, D. Rine, Ed. IEEE Computer Society Press, 1994.
[5] 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.
[6] 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.
[7] Gomaa H, L. Kerschberg, C. Bosch, V. Sugumaran, I Tavakoli, "A Prototype Software Engineering Environment for Domain Modeling and Reuse," Proc Sixteenth Annual Software Engineering Workshop, NASA Goddard Software Engineering Laboratory, December 1991.
[8] Gomaa H, L. Kerschberg, V. Sugumaran, "A Knowledge-Based Approach for Generating Target System Specifications from a Domain Model," Proc. NASA Goddard Conference on Space Applications of Artificial Intelligence, May 1992. Also in Proc. IFIP World Computer Congress, Madrid, Spain, September 1992.
[9] 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.
[10] Gomaa H, "Software Design Methods for Concurrent and Real-Time Systems," Addison Wesley, 1993.
[11] Gomaa H, "A Reuse-Oriented Approach for Structuring and Configuring Distributed Applications," Software Engineering Journal, March 1993.
[12] Gomaa H, L. Kerschberg, V. Sugumaran, C. Bosch, I Tavakoli, "A Prototype Software Development Environment for Reusable Software Architectures". Proc IEEE International Conference on Software Reuse, Rio de Janeiro, Brazil, November 1994.
[13] Jackson M., "System Development," Prentice Hall, 1983.
[14] Kang K.C. et. al., "Feature-Oriented Domain Analysis," Technical Report No. CMU/SEI-90-TR-21, Software Engineering Institute, November 1990.
[15] Lubars M.D., "Domain Analysis for Multiple Target Systems," Proc. Workshop on Domain Modeling for Software Engineering, OOPSLA'89, New Orleans, October 1989.
[16] Meyer B, "Reusability: The Case for Object-Oriented Design," IEEE Software, March 1987.
[17] Parnas D, "On the Criteria for Decomposing a System into Modules," Communications ACM, December 1972.
[18] Parnas D, "Designing Software for Ease of Extension and Contraction," IEEE Transactions on Software Engineering, March 1979.
[19] Pyster A., "The Synthesis Process for Software Development," in System and Software Rquirements Engineering, Edited by R. Thayer & M. Dorfman, IEEE Computer Society Press, 1990.
[20] Rumbaugh, J., et al., "Object-Oriented Modeling and Design," Prentice Hall, 1991.
[21] Shlaer, S. and S. Mellor, "Object Oriented Systems Analysis," Prentice Hall, 1988.
[22] Szczur M. R., "A user interface development tool for space science systems," AIAA/NASA Symposium on Space Information Systems, September 1990.
[23] Wegner P, "Concepts and Paradigms of Object-Oriented Programming," OOPS Messenger (ACM SIGPLAN), Vol.1, No. 1, August 1990.
[24] Yourdon E., "Modern Structured Analysis," Prentice Hall, 1989.