The Domain Analysis Process

21.2.2 The Domain Analysis Process

Firesmith [FIR93] describes software domain analysis in the following way: Software domain analysis is the identification, analysis, and specification of common require-

ments from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Object-oriented domain analysis is] the identification, analy-

sis, and specification of common, reusable capabilities within a specific application domain, Reuse is the

XRef

in terms of common objects, classes, subassemblies, and frameworks . . .

cornerstone of component-based

The “specific application domain” can range from avionics to banking, from multi- software engineering, a

media video games to applications within an MRI device. The goal of domain analy- topic discussed in Chapter 27.

sis is straightforward: to find or create those classes that are broadly applicable, so that they may be reused.

Technical literature Class taxonomies Existing applications

Sources of

Customer surveys Domain domain

Reuse standards

Functional models analysis knowledge

Domain

Expert advice

model Domain languages Current/future requirements

analysis

F I G U R E 21.1 Input and output for domain analysis

Using terminology that was introduced earlier in this book, domain analysis may

be viewed as an umbrella activity for the software process. By this we mean that domain analysis is an ongoing software engineering activity that is not connected to any one software project. In a way, the role of a domain analyst is similar to the role of a master toolsmith in a heavy manufacturing environment. The job of the tool- smith is to design and build tools that may be used by many people doing similar but not necessarily the same jobs. The role of the domain analyst is to design and build

“If an organization is reusable components that may be used by many people working on similar but not to make a major

necessarily the same applications. investment in

Figure 21.1 [ARA89] illustrates key inputs and outputs for the domain analysis software reuse, it

process. Sources of domain knowledge are surveyed in an attempt to identify objects needs to know what

components to that can be reused across the domain. In essence domain analysis is quite similar to consider in the

knowledge engineering. The knowledge engineer investigates a specific area of inter- development of such

est in an attempt to extract key facts that may be of use in creating an expert system

a model.” or artificial neural network. During domain analysis, object (and class) extraction

David Rine

occurs. The domain analysis process can be characterized by a series of activities that begin with the identification of the domain to be investigated and end with a speci- fication of the objects and classes that characterize the domain. Berard [BER93] sug- gests the following activities:

Define the domain to be investigated. To accomplish this, the analyst must first isolate the business area, system type, or product category of inter-

XRef

A complete domain est. Next, both OO and non-OO “items” must be extracted. OO items include

analysis strategy must specifications, designs, and code for existing OO application classes; support consider architecture as

classes (e.g., GUI classes or database access classes); commercial off-the- well as components. A

detailed discussion of shelf (COTS) component libraries that are relevant to the domain; and test

software architecture is cases. Non-OO items encompass policies, procedures, plans, standards, and presented in Chapter

guidelines; parts of existing non-OO applications (including specification,

14. design, and test information); metrics; and COTS non-OO software. Categorize the items extracted from the domain. The items are orga-

nized into categories and the general defining characteristics of the category are defined. A classification scheme for the categories is proposed and nam- nized into categories and the general defining characteristics of the category are defined. A classification scheme for the categories is proposed and nam-

Collect a representative sample of applications in the domain. To accomplish this activity, the analyst must ensure that the application in ques- tion has items that fit into the categories that have already been defined. Berard [BER93] notes that during the early stages of use of object-technologies, a soft- ware organization will have few if any OO applications. Therefore, the domain analyst must “identify the conceptual (as opposed to physical) objects in each [non-OO] application.”

Analyze each application in the sample. The following steps [BER93] are followed by the analyst:

• Identify candidate reusable objects. • Indicate the reasons that the object has been identified for reuse. • Define adaptations to the object that may also be reusable. • Estimate the percentage of applications in the domain that might make

reuse of the object. • Identify the objects by name and use configuration management

techniques (Chapter 9) to control them. In addition, once the objects have been defined, the analyst should estimate what percentage of a typical application could be constructed using the reusable objects.

Develop an analysis model for the objects. The analysis model will serve as the basis for design and construction of the domain objects.

WebRef

In addition to these steps, the domain analyst should also create a set of reuse

A worthwhile tutorial on guidelines and develop an example that illustrates how the domain objects could be domain analysis can be

used to create a new application. found at

www.sei.cmu.edu/

Domain analysis is the first technical activity in a broader discipline that some call

str/descriptions/

domain engineering. When a business, system, or product domain is defined to be

deda.html

business strategic in the long term, a continuing effort to create a robust reuse library can be undertaken. The goal is to be able to create software within the domain with

a very high percentage of reusable components. Lower cost, higher quality, and improved time to market are the arguments in favor of a dedicated domain engi- neering effort.

21.3 G E N E R I C C O M P O N E N T S O F T H E O O A N A LY S I S MODEL

The object-oriented analysis process conforms to the basic analysis concepts and principles discussed in Chapter 11. Although the terminology, notation, and The object-oriented analysis process conforms to the basic analysis concepts and principles discussed in Chapter 11. Although the terminology, notation, and

Analysis . . . is concerned with devising a precise, concise, understandable, and correct model of the real world. . . . The purpose of object-oriented analysis is to model the real world so that it can be understood. To do this, you must examine requirements, analyze their implications, and restate them rigorously. You must abstract real-world features first, and defer small details until later.

To develop a “precise, concise, understandable, and correct model of the real world,”

a software engineer must select a notation that implements a set of generic compo- nents of an OO analysis model. Monarchi and Puhr [MON92] define a set of generic representational components that appear in all OO analysis models. 6 Static compo- nents are structural in nature and indicate characteristics that hold throughout the operational life of an application. These characteristics distinguish one object from other objects. Dynamic components focus on control and are sensitive to timing and event processing. They define how one object interacts with other objects over time. The following components are identified [MON92]:

Static view of semantic classes. A taxonomy of typical classes was identi-

? fied in Chapter 20. Requirements are assessed and classes are extracted (and

What are the

key components of an represented) as part of the analysis model. These classes persist throughout

OOA model?

the life of the application and are derived based on the semantics of the cus- tomer requirements.

Static view of attributes. Every class must be explicitly described. The attributes associated with the class provide a description of the class, as well as a first indication of the operations that are relevant to the class.

Static view of relationships. Objects are “connected” to one another in a variety of ways. The analysis model must represent these relationships so that operations (that affect these connections) can be identified and the

Static components do

design of a messaging approach can be accomplished.

not change as the Static view of behaviors. The relationships just noted define a set of application is executed.

behaviors that accommodate the usage scenario (use-cases) of the system. Dynamic components

are influenced by These behaviors are implemented by defining a sequence of operations that timing and events.

achieve them. Dynamic view of communication. Objects must communicate with one

another and do so based on a series of events that cause transition from one state of a system to another

Dynamic view of control and time. The nature and timing of events that cause transitions among states must be described.

6 The authors [MON92] also provide an analysis of 23 early OOA methods and indicate how they address these components.

De Champeaux, Lea, and Faure [CHA93] define a slightly different view of OOA representations. Static and dynamic components are identified for object internals and for interobject representations. A dynamic view of object internals can be char- acterized as an object life history; that is, the states of the object change over time as various operations are performed on its attributes.