Domain Analysis

Domain Analysis

Monday, September 17, 2007

CIS 673

Domain Engineering

Establish and Maintain

• Body of Knowledge

• Technical Infrastructure

To effectively develop and maintain a family of applications within a problem domain.

Three Sets of Issues

• Organizing Domain Analysis Activities into Systematic, Controllable Process.

• Integrate Domain Analysis Activities into Normal development processes.

• Specify, design, classify, widely used components, package them to optimize usability.

Two organizational, one technical.

What is a Domain?

• Characterized by its scope, its information, its features and uses, and its behavior.

• Alternative: characterized by set of possible applications and related knowledge.

• Scope can be defined by three criteria: Common Expertise (producer focus); Common Design (product focus); Common Market (consumer focus).

Domain Analysis

Kang et al: “the process pf identifying, collecting, organizing, and representing the relevant information in a domain, based upon the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within a domain”.

Domain Analysis Activities

• Defining a glossary of terms.

• Documenting domain assumptions.

• Identifying domain stakeholders.

• Identifying problems within domain scope.

• Identifying legacy artifacts.

• Identifying commonalities and variabilities.

Product: A Domain Model.

Domain Model

• Domain Definitions.

• Commonalities.

• Variabilities.

• Rules and Constraints.

• Environmental Boundaries.

• Requirements.

• Decision Models.

Domain Scoping

• Scoping: An Economic Decision.

• Factors: scale of development effort, cost of domain engineering activities, amortization conditions.

• Overscoping vs Underscoping: Usefulness vs Usability. Also: DE concerns vs AE concerns. Also: Generality vs Genericity.

Processes for Domain Scoping

• Stepwise Inclusion, starting from empty set. Increasing variability.

• Stepwise Exclusion, starting from set of all applications. Increasing commonality.

Support for Stepwise Inclusion

• Attribute/ Product Matrix. Columns: attributes. Rows: products.

• Coherence, degree of commonality: number, width, impact of common attributes.

• Degree of variability: different values for the same column.

• Deleting outlying rows: improve coherence, reduce scope.

Outcome: define scope by common columns; abstract away specific rows.

Domain versus Application Requirements

• Tension between domain requirements and application requirements.

• Requirements Traceability.

• Non Functional Requirements.

• Requirements Gathering.

Component Attributes

• Usefulness: extent to which a component is needed in a domain. Usefulness is supported by generality, and dependent on scoping (Reifer’s rule). A feature of the specification.

• Usability: extent to which it is easy to use in host applications. Usability is supported by genericity. A feature of the implementation.

Domain Analysis Deliverables

• Background definition of the domain. Terminology, theory, assumptions.

• Reference architecture for domain applications.

• Repository of reusable assets, consistent with the selected architecture.

• Guidelines for developing applications within the domain.

DA Methodologies: FODA

• Feature Oriented Domain Analysis

• Developed by SEI in 1990.

• Characterizes a domain by its features.

FODA

• Context Analysis. Context diagrams and structure diagrams.

• Domain Modeling. Identify commonalities and variabilities. Three parts: feature analysis, information analysis, operational analysis.

• Architecture Modeling. Reference architecture. Defined by: component interfaces, model execution, nature of interconnections.

ODM

• Part of the STARS project (DARPA).

• Introduced by HP and Unisys, 1993.

• Focus on organizational issues and transition to reuse discipline. Three processes: domain analysis, architecture development, asset implementation.

Characteristics of ODM

• Distinction between descriptive/ prescriptive activities.

• Descriptive: legacy systems, artifacts, experiences.

• Prescriptive: features that the domain architecture will support.

• Iterative scoping of the domain.

JODA

• Premise: OO software is more customizable.• Developed by Joint Integrated Avionics Working

Group, in 1992.• Domain models developed using Coad/ Yourdon

OO Analysis techniques.• Domain Models: objects, attributes, services.• Variability: in attributes, services, relationships.• Domain definition: scope, technology

dependency, domain expertise.

JODA: Three Phases

• Preparing the Domain. Collecting domain knowledge. Stability/ maturity of domain technologies.

• Domain Scoping. Domain glossary, services, dependencies. Whole-part, subject, inheritance diagrams.

• Domain Models. Object life histories; operational scenarios; packaging and grouping reusable objects.

RLPM: Reuse Library Process Model

• Developed under STARS in 1991.

• Heavily process based, no emphasis on deliverables.

• Combined top-down and bottom-up process.

• Focused on library functions, based on asset classification.

RLPM Domain Analysis

• Domain Knowledge Acquisition

• Classification and keyword analysis.

• Developing functional models.

• Developing domain architectures.

DADP

• Domain Analysis and Design Process.• Developed by DISA in 1993.• Domain analysis develops generic

requirements to address frequent conditions in the domain.

• Emphasis on preparing for change; evolving requirements in a changing environment.

• Advocates OO approach, Coad/ Yourdon.

DADP: Four Phases

• Identifying the Domain. Business models, system capabilities, domain models, external interfaces, reuse opportunities, current systems, anticipated systems.

• Scoping the Domain.

• Analyzing the Domain.

• Designing the Domain.

DSSA

• Domain Specific Software Architecture.

• Developed by DARPA in 1992.

• Geared towards command and control systems.

• Emphasis on deliverables, rather than processes.

Domain Models in DSSA

• Function and Dynamic Models. Dataflow and control flow diagrams. Hierarchical decomposition of domain functionality.

• Object Models. Developed using OMT. Class diagrams: class attributes, class methods, relationships of generalization and association.

Synthesis

• Developed by the Software Productivity Consortium in 1993.

• Exploits opportunistic and leveraged reuse.

• Scoping and domain definition based on needs of a target project.

Synthesis: Activities, Deliverables

• Activities: Domain definition: applications, their similarities, differences. Domain Specification: process requirements, application requirements, decision models. Domain verification: correctness, consistency, and completeness.

• Deliverables. Domain definition, domain specification.

Synthesis: Domain Definition and Specification

• Domain Definition. Domain synopsis, glossary, assumptions. Legacy products.

• Domain Specification. Decision models. Application engineering requirements. Product requirements. Process requirements (deriving applications). Product Design (generic application design).

Reuse Business Methodology

• Reuse Driven Software Engineering Business.

• Developed by Ivar Jacobson in 1997.

• Provides Guidelines and Models.

• Focus: Large scale, object oriented reuse.

• Coverage/ Scope: Business, process, architecture, organizational issues.

Reuse Business: Three Categories of Processes

• Component Systems Engineering.

• Application Family Engineering.

• Application System Engineering.

No explicit domain engineering process, but activities are divided into AFE and CSE.

Assessment of Domain Engineering Methodologies

• Rationale for Domain Definition.• Process for Domain Definition.• Guidelines for Domain Architecture.• Domain Engineering Deliverables.• Reusable Assets.• Domain Engineering Lifecycle.• Domain Engineering Effort.• Dependencies: with respect to Technology/

Language/ Development Methodology.

Two Recent Methodologies

• FAST (David M Weiss), Avaya Labs.

• Pulse (Fraunhofer Institute)