DOMAIN ENGINEERING The intent of domain engineering is to identify, construct, catalog, and disseminate
27.3 DOMAIN ENGINEERING The intent of domain engineering is to identify, construct, catalog, and disseminate
a set of software components that have applicability to existing and future software a set of software components that have applicability to existing and future software
Domain engineering includes three major activities—analysis, construction, and “Domain engineering
dissemination. An overview of domain analysis was presented in Chapter 21. How- is about finding
ever, the topic is revisited in the sections that follow. Domain construction and dis- commonalities
among systems to semination are considered in later sections in this chapter. identify components
It can be argued that “reuse will disappear, not by elimination, but by integration” that can be applied
into the fabric of software engineering practice [TRA95]. As greater emphasis is placed to many systems,
on reuse, some believe that domain engineering will become as important as soft- and to identify
ware engineering over the next decade. program families
that are positioned to take fullest
27.3.1 The Domain Analysis Process
advantage of those In Chapter 21, we discussed the overall approach to domain analysis within the con- components.”
text of object-oriented software engineering. The steps in the process were defined
Paul Clements
as:
1. Define the domain to be investigated.
2. Categorize the items extracted from the domain.
3. Collect a representative sample of applications in the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects. It is important to note that domain analysis is applicable to any software engineer-
ing paradigm and may be applied for conventional as well as object-oriented devel- opment.
Prieto-Diaz [PRI87] expands the second domain analysis step and suggests an eight-step approach to the identification and categorization of reusable components:
1. Select specific functions or objects.
? 2. Abstract functions or objects.
How can we
identify and categorize 3. Define a taxonomy.
reusable
4. Identify common features.
components?
5. Identify specific relationships.
6. Abstract the relationships.
7. Derive a functional model.
8. Define a domain language.
A domain language enables the specification and later construction of applications within the domain.
Although the steps just noted provide a useful model for domain analysis, they provide no guidance for deciding which software components are candidates for reuse. Hutchinson and Hindley [HUT88] suggest the following set of pragmatic ques- tions as a guide for identifying reusable software components:
• ? Is component functionality required on future implementations?
Which
components
• How common is the component's function within the domain?
identified during domain analysis
• Is there duplication of the component's function within the domain?
will be candidates
• Is the component hardware dependent?
for reuse?
• Does the hardware remain unchanged between implementations? • Can the hardware specifics be removed to another component? • Is the design optimized enough for the next implementation? • Can we parameterize a nonreusable component so that it becomes reusable? • Is the component reusable in many implementations with only minor
changes? • Is reuse through modification feasible? • Can a nonreusable component be decomposed to yield reusable components? • How valid is component decomposition for reuse?
An in-depth discussion of domain analysis methods is beyond the scope of this book. For additional information on domain analysis, see [PRI93].
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more