7. Object Technology, Architectures, and Domain Analysis: What’s the Connection? Is There a Connection?

Moderator:

Sholom Cohen (Software Engineering Institute)
sgc@sei.cmu.edu

Participants:

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

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 explored issues involved in moving towards a more unified (to reuse a term) view. We tried 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:

• To identify work products of object technology, domain analysis, and architecture.
• To examine how work products can be used to integrate techniques.
• To determine means to deal with variability.
• To understand how domain analysis contributes to architectural views, and 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.

Work Products

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

• Domain—a 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—a representation of common and variant aspects of a domain; a rationale for variation.
• Architecture—a description of the structural properties and elements; rules of composition and control.
• Feature—an aspect of a domain that makes sense to a user.

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

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 form a 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 correspond to an object model—during 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.

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.

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?

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 from 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. It may determine selections among alternative capabilities and provide guidance for choosing options. A variability vector may also be used to document where change is likely to occur, how and why it will be made, and what impact it will have.

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, and 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 previous application designs to form the framework, as shown in Figure 3.



Figure 3: Relationship of Domain Model to Framework

Architecture Technology Contribution

Architecture provides a set of composition and abstraction concerns within the solution space of large-scale systems. Composition may involve integrating 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 resolve the conflict between structural and OO designs. Abstractions include the key design decisions about a system. Abstractions within a domain include reusable 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/support/techpapers/ieee/) 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 evolve 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)
• A reference architecture (technical)
• Platforms and interfaces (systems)

OO Technology Contribution

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

Several specific approaches in use 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.

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 through 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.
• The variability vector covers features that affect choices or configuration.
• The 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 for the future of the 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 of extensions to OO methods documents feature interaction.

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. Encapsulation may be an answer here.
• Terminology conflicts abound among the Object-Domain-Architecture areas:
• "Domain" in the OO world may also refer to a subsystem.
• "Feature" may have different meanings.
• The "application framework" in OO captures the 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 the same way "domain-specific" is used in the reuse community.
• 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.

Trends

The group saw a 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.

Table 1 reflects some of these trends.

Table 1: Emerging Interest in A Priori Approaches to OO
	Inductive	A priori
Process	Ad hoc process Incremental Empirical (Johnson, see: "Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks" http://st-www.cs.uiuc.edu/users/droberts/evolve.html) Document solution	Domain analysis: separation of concerns (Aksit, see: ftp://ftp.cs.utwente.nl/pub/doc/TRESE/ecoop96adws/aksit.ps.Z; Kiczales, see: http://www.parc.xerox.com/spl/projects/aop/) Commonality and variability analysis (Copelien, see: http://www.bell-labs.com/user/cope/Patterns/OOFuture.html) Analysis of patterns (M. Fowler: Analysis Patterns: Reusable Object Models)
Construction Techniques	Patterns Frameworks Application framework (common layer below all applications in domain)	Domain model Generic architecture (COE in IEEE Software, Nov. 96) Use cases for variability (Jacobson, Griss, Jonsson: Software Reuse)

Agenda

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

• Develop technical exchanges. These should address the different levels of reuse activity within organizations:
• Building from ground zero (rare).
• Reengineering from legacy systems.
• On-going OO development with forward reuse and time-to-market demands.
• Address areas of controversy:
• Resolve terminology conflicts—the reuse community should speak the language of the OO community and vice versa.
• Show where benefits have occurred.
• Demonstrate general value to overcome points of resistance.
• Make a 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.