From Use Cases to Domains and Architecture

Sholom Cohen

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

Tel: (412)268-5872, fax: (412)268-5758

Email: sgc@sei.cmu.edu

URL: http://www.sei.cmu.edu/plp

Establishing a product line in software involves solving significant business and technical problems:

• establishing the business goals
• scoping the product line
• recognizing domains within the product line
• defining a suitable architecture
• establishing a production system for products in the product line

In addressing these problems, we must consider the goals of the product line organization, the needs of potential users of product line systems, the development of product line assets, and the creation of individual systems within the product line. The payoff for investment in product lines is the production of new products quickly and with high quality.

The appropriate application of use cases can provide major support for product line development. The conceptual foundation of this process is a single evolving model of the developing product line. Use cases help explore various stakeholders' views representing a particular evolution of that underlying model. The initial version of the model describes product lines in general, while the resultant version describes the particular product line being developed.

Object technology has long been proffered as the solution to software reuse, but it still has not delivered the "knock out punch." Object technology recognizes the need for examining groups of related applications but does not provide direct, formal guidance for that examination. In addition, products of analysis of single systems differ from those needed for multiple systems; inheritance, polymorphism, and encapsulation are not sufficient to address the requirements for systematic reuse[Griss98]. Patterns give us support across applications, but it is up to the analyst to recognize the appropriateness of a pattern for solving the problem at hand. The concept of frameworks begins to address a multi-system perspective. Frameworks embody an abstract design for a family of related problems in the form of a set of classes. They may be created over development of several related systems through evolution to an object-oriented framework for the family [Roberts96]. Some framework development approaches recommend a priori examination of future needs[Cohen97].

Domain analysis has also been promoted as a means to address reuse. Methods for domain analysis have existed as an identified set of techniques for almost twenty years, but there is no standard, or even community agreement, on the scope or approach to domain analysis. New object-oriented approaches in scenarios, use cases, frameworks, and design patterns have blurred many of the distinctions between domain and object-oriented analyses. Neither domain analysis nor object-oriented analysis has yielded the desired reuse track record. Can we move toward approaches that use the best practices of domain and object-oriented analysis to produce what might be called "software reuse that's worth it?" The approach described below utilizes use cases and other scenario descriptions to sort out the potential commonalities and variations and lead to systematic reuse through domain engineering.

The modeling process is based on obtaining stakeholder information through a series of use cases. Use cases are developed in phases corresponding to specific stakeholders. Successive phases model that stakeholder's view. The stakeholders we are concerned about are:

• Business Unit Manager: To obtain an understanding of the product line and the product line organization's goals; current product line assets; related products that are currently produced by the organization.
• User: Define potential end users of systems in the product line; establish the services that will be provided to those users.
• Domain modeler: Identify domains will be part of the product line; relate domains to the services provided to the user; establish the commonalties and variabilities inherent within those domains.
• Architect: What are the requirements for the product line architecture and components?

The product line views of each stakeholder may change over time. For example, the organization's business goals may change as a result of a customer or competitor action or the introduction of a new technology. These views will also change as a result of greater understanding gained from subsequent phases. During development of the domain modeler view, for example, the model developed for the user view may change. Domain engineering msut maintain these views and models as systems in the product line are fielded.

For each view, the modeling process includes elicitation, representation, and refinement of information relevant to the key stakeholder for that view. Modeling includes verification of the correctness, completeness and consistency of the representation. New information acquired for a particular view may affect that gathered previously; other views may require changes. Modeling a particular view produces a collection of work products. For each view these products are:

• Object Model - This captures the objects visible to the stakeholder.
• Use Case Model - This captures detailed information (elicited by use cases) about specific interactions between the objects in the Object Model.
• Feature Model - For each stakeholder, this captures their perspective on capabilities and reasons for variation within the product line.
• Results List. This captures feedback discovered during the current phase of information for the models of other views. This allows refining the prior models as a result of greater insight. The results list also captures information for the architecture style analysis phase.

This set of products is common for all product lines. This abstract version of the model describes product lines in general. The resultant version, capturing the results of specific analyses, describes the particular product line being developed.

Use cases provide a meaningful way to explore the product line from each of the stakeholder views. The level of detail captured expands, moving from product level interactions (business unit manager's view) to scenarios involving module interactions (architectect's view). It is from these use cases that we are able to capture a more comprehesive view of the product line, identifying domains, domain features, causes of variation, and architectural characterisitics.

The business unit manager is primarily concerned with the whole product to be delivered from the product line to the user. The scenarios captured in use cases focus around the use of the product: who are the typical users, how they will use the product, whether different classes of users may need different capabilities. From a business perspective, the manager is also concerned with product differentiation and how the product line will help the organization achieve its overall business mission: shorter time-to-market, less costly products, expanded customer base, etc.

The user views the product from the perspecitive of services that are available. From this starting point, the modeling explores the service hierarchy, or structure of related services and the information that must be shared between services in the product line. Use cases explore services in terms of service users (actors) and information required of or provided by the service. Features are expressed in terms of these services and we begin to establish the cause of variation at the service level.

The domain modeler view moves through several levels of analysis. Starting with services and service interactions, modeling for this view begins to establish product line domains. These domains may cross service boundaries, so that a single domain will include several related services. In other cases, a domain may provide only partial support for a service. Use cases center around domains and domain interactions. By collecting the use cases involving each domain, we are able to establish the information model for that domain, express domain responsibities in terms of features, and establish the nature and causes of variations within and across domains. From this point, use cases explore detailed interactions within a domain. This may result in the identification of subdomains, each with its own set of responsibilties. The resulting domain models feed the architect's view.

The architect is concerned with the structure of product line systems, comprised of software components, externally visible properties of those components and the relationships among them. The use cases are concerned with the dynamic relationships between domains and may be modeled using use case maps [Buhr96]. The nature and scope of the domains helps establish classes/objects as components and provides guidance in defining the architectural style: patterns of cooperation and coordination of components within the architecture. Features of concern to the architect may be non-functional requirements including the performance of systems in the product line, security concerns, reliability, and modifiability. The last is critical in a product line that must undergo significant changes over time.

The following table summarizes the application of use cases to support the product line domain analysis and architecture development.

[Buhr96] Buhr, R. J. A., Casselman, R.S. Use case maps for object-oriented systems Upper Saddle River, N.J. : Prentice Hall, c1996.

[Cohen98] Cohen, S. and Northrop, L. Object Oriented Technology and Domain Analysis.Proceedings Fifth International Conference on Software Reuse '98. Victoria, Canada. IEEE Press

[Dionisi98] Dionisi Vici, A.; Argentieri, N.; Mansour, A.; d'Alessandro, M.; and Favaro, J. FODAcom: An Experience with Domain Analysis in the Italian Telecom Industry. Proceedings Fifth International Conference on Software Reuse '98. Victoria, Canada. IEEE Press

[Griss98] Griss, M.; Favaro, J.;and d'Alessandro, M. Integrating Feature Modeling with the RSEB. Proceedings Fifth International Conference on Software Reuse '98. Victoria, Canada. IEEE Press

Sholom Cohen is a Senior Member of the Technical Staff of the Software Engineering Institute (SEI) and has been at the SEI for over ten years. Mr. Cohen is a member of the Product Line Systems Program and has authored major technical reports and conference papers on domain analysis and domain engineering methods and an annotated bibliography of domain analysis. He is also the author of reports on product lines for the Air Force Electronic Systems Center, the National Reconnaisance Office, and DoD test and training ranges. Besides domain engineering, Mr. Cohen's current research activities include object technology, 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.

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