domain analysis
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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)