Object Technology, Architectures, and Domain Analysis - What's the Connection?

Sholom Cohen

Software Engineering Institute Carnegie Mellon University
Pittsburgh, PA 15217
Tel: (412) 268-5872
Fax: (412) 268-5758
Email: sgc@sei.cmu.edu

Abstract:

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. Can we move towards a more unified (to reuse a term) view to understand how to make best use of these new approaches?

Keywords: Domain analysis, architecture, object technology

Workshop Goals: Developing a unified approach for domain engineering and architecture-based development

Working Groups: Unified approaches, domain engineering, product lines

Background

Software reuse has been the primary focus of my development work for over ten years. As a developer of the Common Ada Missile Packages program from 1984-1988, I began looking at the issues of domain analysis, design and implementation that we now call domain engineering. We also dealt with reuse libraries and component finding and composition tools. My work at the Software Engineering Institute has concentrated on domain engineering including the development of the Feature-Oriented Domain Analysis method and its application with several organizations. I am currently working on product line concepts, including domain engineering, architecture evaluation, and management for product line development.

Position

Anecdotal evidence of the application of object technology is that over time, an organization produces more subclasses with each new application rather than reusing existing classes. These subclasses become the "property" of each project and are not shared. [1] cites this symptom as the "expansionary phase", when class hierarchies no longer match any problem domain. The classes "will define many unrelated operations and instance variables." What causes this proliferation and prevents systematic reuse? How can we address this problem?

Domain analysis, architecture and object technologies each offer approaches to help bridge the gap between product line expectations and the current reality. The basic premise of this position is that the proper role of domain analysis is to supplement object-based or other development technologies. Domain analysis considers commonalities and differences within a related class of systems and provides a systematic approach for dealing with commonality. Domain analysis must now move from a specialized area within reuse to embrace emerging object technology.

By providing a focus on the structural issues of a system, software architecture captures the essential design decisions about a system [2]. For complex systems, there are multiple structural perspectives to consider. Software architecture supports consideration of these perspectives, such as functionality, physical allocation, or interprocess communication. For large-scale systems, these structural views are essential for managing complexity [3]. In addition, the concepts of design patterns and frameworks from object technologies can support the generic design and architectural aspects of domain engineering.

Object technologies overlap those of domain analysis and the broader areas of domain engineering. The same may be said of architecture. However, both domain analysis and architecture look at issues not covered explictly by object technology such as causes for differentiation within a product line or architecture representation and analysis. An approach that unifies object, architecture and domain analysis technologies should reduce the proliferation of classes and offer support for systematic reuse.

This approach must use a codified base of engineering knowledge to support analysis of customer needs and synthesis of solutions. Both the analysis and synthesis will be based on recognized commonalities or on variations from previous solutions. The approach must also adopt a new process for software development. This architecture-based process must be firmly grounded in existing methods for engineering design, recognizing and exploiting commonality among systems in the same application domain and in patterns of software design that cross application areas.

Comparison

Domain analysis products supplement object-based technology by explicitly modeling commonalities and differences within a related class of systems. This can support product evolution in object-oriented systems. The use-case approach of Object-Oriented Software Engineering [4] has a primary focus on "system changes". In this way, reapplication of the models may occur throughout a product's life or in new products. This reuse of models is an important goal of OOSE.

Domain analysis can also provide a systematic approach to identifying sources for differentiation among related systems within application frameworks, called "hot spots" in [5]. Under this approach, developers look for areas of commonality requiring flexibility for reuse. They use essential framework principles to fashion domain-specific design patterns for development of applications.

The concept of "refactoring" discussed in [1] is similar to the use of domain analysis in developing assets for reuse. Refactoring tries to restructure classes when they have expanded beyond their ability to support any specific problem domain and classes have become inflexible due to their need to address specific system requirements.

While we generally think of the architecture of a specific system, architecture concepts are now routinely applied to classes of problems or systems. Current activity in design patterns and frameworks provides object technology support in the direction of common architecture and design. Architecture is a major concern of refactoring as it tries to identify frameworks by restructuring flat class hierarchies. The overlap of object technology and architecture will help define the structural properties for a product line and make component definition, integration and reuse a consistent part of an architecture-based development.

References

References

1
E. Gamma, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley Publishing Co., 1995.

2
P. C. Clements and L. M. Northrop, ``Software Architecture: An Executive Overview,'' Tech. Rep. CMU/SEI-96-TR-003, Software Engineering Institute, 1996.

3
P. B. Kruchten, ``The 4+1 View Model of Architecture,'' IEEE Software, vol. 12, pp. 42-50, November 1995.

4
I. Jacobson, M. Christerson, and L. Constantine, ``The OOSE Method: A Use-Case-Driven Approach,'' in Object Development Methods (A. Carmichael, ed.), pp. 247-270, SIGS Books, 1994.

5
W. Pree, Design Patterns for Object-Oriented Software Development. Reading, MA: Addison-Wesley Publishing Co., 1994.

Biography

Sholom Cohen is is a Senior Member of the Technical Staff of the Software Engineering Institute (SEI). Mr. Cohen is currently team leader of SEI's Domain Engineering activities. As leader, Mr. Cohen has co-authored two major technical reports on domain analysis and domain engineering methods and an annotated bibliography of domain analysis. He was also the author of a study on the implications of software reuse for the Ada 9X project and reports on C4I Product Lines for the Air Force Electronic Systems Center. Besides domain engineering, Mr. Cohen's current research activities include software product line practices and product line introduction.

Prior to joining the staff of the SEI, Mr. Cohen was a member of the software engineering technology branch of the McDonnell Douglas Astronautics Company. In that position, he was a key developer of the Common Ada Missile Packages components and tools.

On a lighter note, Mr. Cohen is the author of two children's books in the Yitz Berg from Pittsburgh series, published by Jewish Readers Press: Yitzy and the G.O.L.E.M. about a pre-teen computer hacker and The Lopsided Yarmulke. Mr. Cohen is currently working on the third novel in the series.

Mr. Cohen received his BS from the Massachusetts Institute of Technology, an MA in Library and Information Science from the University of Michigan, and an MS in computer science from Columbia University (New York).