home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
gomaa.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
10KB
|
236 lines
Metho ds and Tools for Domain Specific Software Architectures
Hassan Gomaa
Department of Information and Software Systems Engineering
George Mason University
Fairfax, Virginia, 22030-4444
Tel: (703) 993-1652
Email: hgomaa@isse.gmu.edu
Abstract
At George Mason University,a pro ject isunderway 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 [1, 2 ], has been proposed, which 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.
Keywords: domain specific software architectures, evolutionary domain lifecycle,system fam-
ilies.
Workshop Goals: To understand how others are approaching the domain specific software
architecture development problem.
Working Groups: reuse process models, domain analysis/engineering.
Gomaa- 1
1 Position
1.1 The Evolutionary Domain Life Cycle
The Evolutionary Domain Life Cycle (EDLC) Model is a software life cycle model that eliminates
the traditional distinction between software development and maintenance. Instead, systems evolve
through several iterations. Furthermore, because new software systems are often outgrowths of
existing ones, the EDLC model takes an application domain perspectiveallowing the development
of families of systems. The EDLC model incorporates two related sub-life cycles, domain mo deling
and target system generation. Domain modeling deals with developing the reusable requirements
and domain specific software architecture for a family of systems, while target system generation
deals with generating target systems from the domain model.
A Domain Model is a problem-oriented architecture for the application domain that reflects the
similarities and variations of the members of thedomain. Given a domain model of an application
domain, an individual target system (one of the members of the family) is created by tailoring the
domain model given the requirements of the individual system.
1.2 Domain Mo deling
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 [3]. The different views are developed iteratively.
1. Aggregation Hierarchy. The Aggregation Hierarchy is used to decompose complex aggregate
ob jecttypes 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 targetsystem,
or optional, i.e., only required in some target systems. The Aggregation Hierarchy supports
the IS-PART- OF relationship.
2. Ob jectcommunication diagrams. Ob jects 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.
3. State transition diagrams. Since each ob ject 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.
4. Generalization / Specialization Hierarchy. As the requirements of a given ob ject 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
ob jecttype are stored in a Generalization / Specialization Hierarchy (GSH), which supports
the IS-A relationship.
5. Feature / Object dependencies. This view relates the end-user'sp erspective 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
Gomaa- 2
features, and the ob ject types requiredto supp ortthem, that determine the nature ofthe
desired target system.
1.3 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.
1.4 Domain Modelling Environment
A proof-of-concept experiment has also been carried out to develop a prototyp e domain mo deling
environment [Gomaa91b], 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 develop ed software. The graphical editors supported by the Software
Through Pictures CASE tool are used to representthe multiple views of the domain model, namely
the Aggregation Hierarchy, the Ob jectCommunication Diagrams, the Generalization / Specializa-
tion 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 / ob ject
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 [4]. The tool, implemented in NASA's CLIPS shell, conducts
a dialog with the human target system requirementsengineer, 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 independentenvironment. 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.
1.5 Current Status
A major issue in the domain modeling approach to developing domain specific software architectures
concerns how effectively it addresses scaleup. The problem is not so much the size of the domain
(which is a "common" software engineering problem) but the degree of variability and volatility
in the domain. A relatively stable well understood application domain is likely to be the best
candidate for domain modeling. The method has been applied to a real-world problem, NASA's
Payload Operations Control Center (POCC) domain.
There is likely to be some tradeoff between scaleup and the amount of variation allowed in a
domain model. Too much variation is liable to lead to acombinatorial explosion. We are currently
exploring the concept of feature packages as an approach to scaleup, where features are grouped
and treated as one super feature. The current approach is oriented towards concurrent systems,
Gomaa- 3
including real-time and distributed systems. We are also adding an information modeling view,
to address more information intensive applications. Also under investigation are the design and
implementation phases of the EDLC [5].
1.6 Acknowledgements
The author is indebted to his research colleagues and students L. Kerschberg, R. Fairley, C.Bosch,
E. O'Hara-Schettino, V. Sugumaran, and I. Tavakoli, for their invaluable assistance throughout.
This work was sponsored in part by NASA Goddard Space Flight Center and the Virginia Center
of Innovative Technology. The Software Through Pictures CASE tool was donated to GMU by
Interactive Development Environments.
References
[1] H. Gomaa, R. Fairley, and L. Kerschberg, "Towards an evolutionary domain life cycle model,"
in OOPSLA'89,New Orleans, Oct. 1989.
[2] G. H. and L. Kerschberg, "An evolutionary domain life cycle model for domain modeling and
target systemgeneration," in Proceedings of the Workshop on DomainModeling for Software
Engineering, International Conference on Software Engineering, Austin, TX, May 1991.
[3] H. Gomaa, "An object-oriented domain analysis and modeling method for software reuse," in
Proceedings of the Hawaii International Conference on System Sciences, Jan. 1992.
[4] L. Gomaa H., Kerschberg and V. Sugumaran, "A knowledge-based approach for generating
target systemsp ecifications from a domain model," in Proceedings of the IFIP World Computer
Congress, Madrid, Spain, Sept. 1992.
[5] H. Gomaa,"A reuse-oriented approach for structuring and configuring distributed applications,"
Software Engineering Journal, Mar. 1993.
Gomaa- 4