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
Abstract
Establishing a product line for software clearly has great appeal to an organization. Once a product line is established, new products in the product line can be produced quickly and with high quality. Key factors in the success of a product line include proper scoping, domain identification, and architecture. This paper proposes a process based on use cases to address these factors.
Keywords: Use Cases, Domain Analysis, Architecture, Product Lines
Workshop Goals: Establish role of use cases and related work products within reuse technology.
Working Groups: product lines, feature-based methods, architecture
1 Background
Establishing a product line in software involves solving significant business and technical problems:
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.
2 Position
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.
3 Approach
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.
3.1 Product Line Views
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:
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:
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.
3.2 Use Case Application
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.
View\Content | Use Case | Object | Feature | Lessons Learned |
Business Unit Manager | Product level interactions | Typical product users | Capabilities at product line level. Variations from similar or competing products | Goals to be achieved by instituting a product line: shorter time-to-market, less costly products, expanded customer base. Scope of product line. |
User | Services user expects in systems in the product line | Internal and external actors and their relationships; information shared bewteen services | Service list or hierarchy | Information exchanges between services |
Domain Modeler | Domain interactions | Information model at product line level and at domain level | FODA feature model for each domain | Specification of domains |
Architect | Dynamic interactions. Map of use case responsibilities | Components, component attributes, methods, etc. | Architectural attributes, non-functional requirements | Evaluation of architecture and its ability to meet product line requirements expressed in domain models |
4 Comparison
The integration of analysis methods for development of product lines is just emerging. Most organizations evolve existing systems to product lines and have not attempted to abstract product line assets through an analysis approach[SEI1, SEI2]. [Griss98] and [Dionisi98] are the best examples to date of the analysis of product lines based on use case methods. Workshops at OOPSLA and at previous WISRs have also explored these issues.
References
[Buhr96] Buhr, R. J. A., Casselman, R.S. Use case maps for object-oriented systems Upper Saddle River, N.J. : Prentice Hall, c1996.
[Cohen97] Cohen, S. "Object Technology, Architectures, and Domain Analysis - What's the Connection? - Is there a connection? WISR Working Group.
[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
[Roberts96] Roberts, D.; Johnson, R. "Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks." http://st-www.cs.uiuc.edu/users/droberts/evolve.html.
[SEI97] Bass, L.; Clements, P.; Cohen, S.; Northrop, L.; Withey, J., Product Line Practice Workshop Report (CMU/SEI-97-TR-003)
[SEI98]Bass, L; Chastek, G; Clements, P; Northrop, L; Smith, D; &Withey, J. 2nd Product Line Practice Workshop Report (CMU/SEI-98-TR-015, ESC-TR-98-015). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, 1998.
Biography
Sholom Cohen(sgc@sei.cmu.edu) Software Engineering Institute http://www.sei.cmu.edu/plp
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).