Reporter: Sholom Cohen, Software

Engineering Institute (sgc@sei.cmu.edu)

Participants:

Sholom Cohen (SEI/CMU), Fred Maymir-Ducharme (Lockheed-Martin), Anil Midha (AT&T Labs), Walker Land, Jr. (Binghamton Univ.), Bob Mathis (Pithecanthropus), Youwen Ouyang (LSU), Lee White (Case Western Reserve Univ.), Mark Simos (Organon Motives), Patrick Steyaert (Vrije Universitet Brussel), Krzysztof Czarnecki (Daimler-Benz), Rafael Capilla (University of Seville), Pia Maria Maccario (CSELT), Larry Latour (Univ. of Maine)

1.0 Overview

Domain analysis and architecture make a necessary contribution to object technology: a focus on understanding the common capabilities of software applications within a product line and on ways to structure and evaluate solutions. At one time, these technologies seemed to be headed in different directions. New approaches in scenarios, use cases, frameworks and design patterns have blurred many of the distinctions.

This working group will explore issues involved in moving towards a more unified (to reuse a term) view. We will try to understand the differences between the various technologies and how to make best use of these new approaches by looking at the following issues:

• how do object oriented methods address reuse?
• what do the various ``new'' concepts (e.g., use cases, hot spots, frameworks) add?
• what can domain analysis contribute?
• what can software architecture contribute?
• should these techniques be unified?
• how can these techniques be unified?

The working group established the following goals:

• identify work products of object technology, domain analysis, and architecture.
• use work products to integrate techniques
• determine means to deal with variability
• understand how domain analysis contributes to architectural views; how architecture technology helps structure object-oriented solutions

The working group continued the efforts of previous WISR working groups including ``Systematic OO Reuse - A Tale of Two Cultures'' from WISR-7. Two years later, many of the same barriers reported by that working group still exist.

The products of the working group included:

• lists of contributions from each of the technology areas: domain analysis, architecture, and object technology
• a list of trends in process and construction techniques
• an agenda for future discussion

2.0 Work Products

The Working Group adopted some basic definitions to establish consistency in terminology:

• Domain
• Class or set of systems; an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. (UML 1.0)

• Domain model
• Representation of common and variant aspects of a domain; rationale for variation

• Architecture
• Description of the structural properties and elements; rules of composition and control

• Feature
• Aspect of a domain that makes sense to a user

While these are far from perfect, they allowed the discussion to concentrate on the relationships of these areas to object technology.

2.1 Multiple Viewpoints

Work products convey different viewpoints and depth of understanding within a domain. Different products represent the degree of enterprise knowledge and perspectives on that knowledge; the degree of formality of the work products suggests our level of understanding:

• higher levels are more informal - we may characterize the enterprise or product line based on customer or market needs; domains may be linked but we have only an informal notion of their interrelationships.
• semantic domains as class hierarchy - semantic descriptions of the problem space capture the information and capabilities within an area of expertise. The analysis steps help refine those descriptions into a domain model.
• lower levels at object model level - in implementation, the work products become operational. We can construct object models for reuse across the domain.

In architecture, these viewpoints similarly suggest abstractions reflecting different levels of knowledge. A reference architecture helps us characterize the system structure for software in a domain or product line. Components capture deeper knowledge, but are based on the reference architecture.

2.2 Engineering Levels of Abstraction

Systematic software reuse crosses various engineering boundaries. Reuse is not an end in itself, but rather a means to satisfy the needs of engineering within an organization. We may classify engineering into several levels, depending on the types of activities involved. Each has its own life cycle:

• enterprise - at this level, reuse looks at all engineering within the organization, all of the products created by the enterprise and the varied work products that exist within the organization. These work products will include enterprise data and information architecture models, product line definitions, and business models.
• domain - at this level, reuse looks within the product lines to uncover commonality across and within product lines. These work products will include information models that may be in the form of object models, behavior models, architectures, composition/generation tools and class libraries.
• application engineering - at this level, the organization is producing products for delivery using assets created through enterprise and domain engineering. The work products here are integration architectures and delivered software products.

The enterprise and parts of the domain engineering levels are the purview of product lines; the discussion of issues at this level was left to the Product Lines and Reuse working group. The Object-Domain-Architecture group dealt with the issues raised in domain and application engineering, specifically building and using assets.

3.0 Using Work Products to Integrate techniques

Work products within the Object-Domain-Architecture areas support different levels of engineering and of understanding. These cover the enterprise, domain and application engineering activities. How may these products work together to support systematic reuse?

3.1 Contribution of Domain Models

Domain models represent our understanding and classification of information within the domain. They characterize the problem space vs. the solution space of architectures, class hierarchies and object models. Domain models also represent a separation of concerns - the domain model is used to show abstractions and variability of parts from which reusable components may be built.

Domain models may be exploited for dealing with commonality and variation. They provide information for handling options; not currently dealt with in OO technology. Among the approaches discussed in the Working Group were variability vectors, coming form the notion of context features in the Feature Oriented Domain Analysis method. This vector would contain information about how and why variation occurs in a domain, such as types of users, modes of operation, system factors, etc. They may determine selections among alternative capabilities and provide guidance for choosing options. They may also be used to document where change is likely to occur, how and why it will be made, and what the impact will be.

Scope and domain definition are important aspects of the domain model. In single system OO analysis, the scope is a given; for domain analysis, the analysts must work to agree on scope. Domain understanding will be captured in the domain model through addressing the following issues:

• what is done - operations (mandatory, alternative, or optional)
• how, what, where - variability vector
• what it looks like - representation

Domain features may also be captured architecturally as a framework. Domain information captured as an object model together with domain features (relationships and context) is used together with pervious application designs to form the framework, as in Figure 1.

• Figure 1: Relationship of Domain Model to Framework

3.2 Architecture Technology Contribution

Architecture provides a set of composition and abstraction concerns within the solution space of large-scale systems. Composition may involve integration of frameworks, structuring implementation interfaces, or guiding partitioning. At the enterprise level, an organization may need to integrate OO and non-OO components; architecture provides the means to deconflict structural vs. OO designs. Abstractions include the key design decisions about a system. Abstractions within a domain include reuse business objects, data access objects, and data sources. For the telecommunications sector, these abstractions include the user interface, service process, data, and network.

Architecture viewpoints are a popular way to characterize the composition and abstraction concerns. Kruchten (http://www.rational.com/media/whitepapers/Pbk4p1.pdf) identifies four different viewpoints: development, physical, logical, and process. These viewpoints can help reuse through:

• controlling different attributes of a common architecture based on view
• enhancing changeability by separating effects of change among the different views
• measuring performance by seeing effects of design in each view

In developing an architecture for reuse, there are several approaches currently employed. Organizations go through many iterations as a system evolves or as designs evolves across systems. Some organizations use these iterations to evolve existing structures into frameworks through abstraction. (Roberts, http://st-www.cs.uiuc.edu/users/ droberts/evolve.html). Other organizations discover frameworks within an application. Domain models may be used to identify key abstractions and scenarios to support design. Finally, standards organizations are proposing architectures for domains or product lines. These may provide views of:

• capabilities (operational)
• reference architecture (technical)
• platforms and interfaces (systems)

3.3 OO Technology Contribution

Object technology provides abstractions and representations to support domain models and architectures. A domain information hierarchy may be represented by a class hierarchy; architecture as a collection of frameworks or patterns.

Several specific approaches are in use to support reuse:

• use cases support refinement of requirements
• abstract classes represent a common starting point for refinement, resolved with concrete classes
• specialized filters address adaptability of methods

Object-oriented techniques may provide specific architectural support within a domain. Refinement of methods may involve preserving of structure through:

• refinement of behavior
• refinement of design
• extension
• factorization

They may also modify structure through breaching:

• abstraction
• fixes
• optimization
• recombination

A new trend within object technology is the concern: a specific domain used as a further modeling criterion for a system or second domain. A concern may be used during analysis, design, or refactoring. During these phases a domain will have several relevant concerns. e.g., error handling, interfaces,etc. These concerns may be shared between domains; thus, the concern of error handling will provide criteria for an analysis of many domains. An aspect is a realization of a concern, the classes that are shared to enable the handling of the concern. Recent work in the area of aspect-oriented programming which looks at cross-cutting issues that affect multiple domains and must broach the encapsulation of objects, offers a contrast to domain analysis as another a priori approach to commonality. This approach is similar to domain interaction, within the reuse community. A feature model, especially a variability vector, could provide the basis for a useful concern across several domains.

3.4 Integrating the Approaches

Integration among the Object-Domain-Architecture areas is necessary. If the only asset is the framework, i.e., all information is captured in that asset, the framework may be difficult to reuse. A priori methods will capture what is known implicitly in inductive approaches. Architecture methods will help determine the role frameworks in large-scale system structures.

Analysts can and should take steps to connect the variability vector and other domain model information to frameworks or patterns. Some issues raised by the group include:

• capabilities from the domain determine what is in the framework
• use cases do not cover options and rationale
• variability vector covers features that affect choices or configuration
• extent and limit of variability is covered in a framework
• interactions within a pattern may be tailored by vector settings

Innovation can come through exploring the domain beyond the scope of existing frameworks or patterns. Integrating the feature space with input from informants, stakeholders and exemplars can help considerations of the future for architecture and of the assets

Integration is also valid since not all domains may be suited to strict OO approaches. Pia Maria Maccario mentioned her experience in service orientation which cuts across objects. In this case, the use extensions to OO methods documents feature interaction.

4.0 Issues

The group identified several issues that will challenge the move to integration.

• Many reuse efforts are built on legacy systems. Conflicts exist in the use of shared data vs. encapsulation of data. In addition, there are problems of integrating legacy systems with objects. An answer here may be encapsulation.
• Terminology conflicts abound among the Object-Domain-Architecture areas:
• domain in OO world may also refer to subsystem
• feature may have different meanings
• the application framework in OO captures shared platform on which related applications are built; in domain engineering the term may refer to the architecture for applications
• application-specific may be used in the OO community as domain-specific is used in reuse

• Tools are needed to make the connections, but most commercial products are still geared towards single-system analysis and design.
• To make the case for reuse, we need metrics for reuse work products. There are no suitable metrics for domain models nor for frameworks or patterns.

5.0 Trends

The group saw an growing movement of OO techniques toward a priori methods. There are also several examples of OO methods that are beginning to promote domain analysis and architecture concepts:

• coupling domain analysis, architecture, and OO within Fusion
• connections within UML, including process extensions and extensions for variability (Griss & Jacobson)
• OO notations for multiuse

The following table reflects some of these trends. Table 1.

6.0 Agenda

To advance the connections among the Domain-Architecture-Object areas the group proposed the following:

• Need for technical exchanges. These should address the different levels of a reuse activity within organizations
• building from ground-zero (rare)
• reengineering from legacy
• on-going OO with forward reuse and time-to-market demands

• Addressing areas of controversy
• terminology conflicts - reuse community should speak the language of OO and OO the language of reuse
• show where benefits have occurred
• demonstrate general value to overcome points of resistance

• make business case, i.e., where are various approaches worthwhile and how worthwhile? Produce a checklist to help make selections
• Plan working groups for major gatherings - WISR, ICSR, OOPSLA

Last Modified: 15 May 1997