Page 236 - DCAP405_SOFTWARE_ENGINEERING

Unit 13: Building the Analysis Model

Requirements Domain Analysis Notes

When there is sufficient confidence that a stream of products can be produced, one may want to
factor out the commonalities in the multiple analyses that must be done for each product. Thus
one may want to do a conceptual domain analysis that yields ordinary ground for each specific
analysis. OO analysis notions lend themselves for capturing generic concepts at multiple levels
of granularity. Ensembles, subensembles, classes, and generic relationships are all candidates
for describing an application domain.
While we can use the notions and notations from an OO analysis method for requirements
domain analysis, we have to adjust the process dimension. We cannot rely on a system-specific
requirements document as input to the process. Instead, we have to take in any relevant features
from the documentation that explains the commonality of the products. Experts and customers
may be tapped, as suggested in the generic diagram. Though, the situation differs from the
diagram in that people have to be primed for more specific and detailed information. The
output side differs as well because the process stops earlier; no model is to be constructed.
Instead, generic classes, relationships, ensembles, etc., are produced. These may be organized
into one or more OO frameworks that may be specialized to the needs of particular systems.

Example: Many of the ATM examples in previous units are not geared to any specific
system. To the extent to which these descriptions are realistic, they are contributions to an OO
domain analysis of “ATMs for banks”.
Our model of the OOA process in unit represents an even better instance of this form of domain
analysis. This model abstracted across different development styles and contexts. It did not
culminate in a particular target model, but only those model components forming a basis for
any OOA process.

Domain Engineering

A requirements domain analysis may lead to an OO domain engineering effort. This entails the
construction of design fragments of the generic elements identified by a requirements domain
analysis. These designs can be implemented and added to a domain-specific code library.

Generator Domain Analysis

When a stable domain serves as the basis of a product line or market segment, one may consider
constructing a generator for a particular domain. This generator may then be used to automatically
build (parts of) any of a series of related products. Relational database systems are an example
of a mature, stable domain where it is quite conceivable to perform a generator type domain
analysis. The query language, platform, operating system and windowing environment would
be main parameters for such a relational database builder.

The analysis performed for the construction of such a meta-program may be seen as a third
version of the notion of domain analysis. One may assume for such an enterprise not only that
the domain is stable and well understood, but also that domain specific design and/or code
libraries are available. One may even step one level higher. ‘

Example: The Rose system (Reuse of Software Elements) was an experimental meta-
meta-program that assisted in capturing domain knowledge and design know-how for the
domain.

LOVELY PROFESSIONAL UNIVERSITY 229