Domain Analysis

1. Domain Analysis Monday, September 17, 2007 CIS 673

2. Domain Engineering Establish and Maintain • Body of Knowledge • Technical Infrastructure To effectively develop and maintain a family of applications within a problem domain.

3. 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.

4. 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).

5. 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”.

6. 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.

7. Domain Model • Domain Definitions. • Commonalities. • Variabilities. • Rules and Constraints. • Environmental Boundaries. • Requirements. • Decision Models.

8. 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.

9. Processes for Domain Scoping • Stepwise Inclusion, starting from empty set. Increasing variability. • Stepwise Exclusion, starting from set of all applications. Increasing commonality.

10. 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.

11. Domain versus Application Requirements • Tension between domain requirements and application requirements. • Requirements Traceability. • Non Functional Requirements. • Requirements Gathering.

12. 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.

13. 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.

14. DA Methodologies: FODA • Feature Oriented Domain Analysis • Developed by SEI in 1990. • Characterizes a domain by its features.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. RLPM Domain Analysis • Domain Knowledge Acquisition • Classification and keyword analysis. • Developing functional models. • Developing domain architectures.

22. 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.

23. 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.

24. DSSA • Domain Specific Software Architecture. • Developed by DARPA in 1992. • Geared towards command and control systems. • Emphasis on deliverables, rather than processes.

25. 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.

26. 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.

27. 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.

28. 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).

29. 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.

30. 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.

31. 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.

32. Two Recent Methodologies • FAST (David M Weiss), Avaya Labs. • Pulse (Fraunhofer Institute)