(Draft for: Object Magazine, Sep 97)

Martin L. Griss, Laboratory Scientist, Software Technology Laboratory,
Hewlett-Packard Company, Laboratories, Palo Alto, CA
griss@hpl.hp.com

John Favaro, Senior Software Engineering Consultant
Intecs Sistemi, Pisa - Italy
favaro@pisa.intecs.it

Massimo d'Alessandro, CASE Methodologist
Intecs Sistemi, Pisa - Italy
dalex@pisa.intecs.it

In this month's extended column for the reuse special issue, I have asked my long-time colleague, John Favaro, to join me with his lead methodologist Massimo d'Alessandro in talking at length about something we have touched on before, but has never occupied center stage: features. Informally, when we examine different applications in the same application family or problem domain, we often compare or distinguish these applications based on their features. Some features are directly related to application functionality and offered services, perhaps expressed as use cases; other distinguishing features might relate to the application to window system, style of menus, operating system, etc. When developing an architecture and component systems for reuse, it is important to understand which features should be provided by which parts of the set of reusable assets, and how features relate.

But let's start with a bit of context. As we've said before in this column, Domain Engineering (DE) is a key part of preparing a reliable architecture and components for reuse[1]. Domain Engineering starts with Domain Analysis (DA). DA has at its heart a systematic analysis of commonality and variability in a family of systems across a domain. Most ordinary OO methods do not support this variability in either notation or method. In [1,2], we described the essence of the Reuse-driven Software Engineering Business (RSEB); more details can be found in the RSEB book[3]. We have used the Unified Modeling Language (UML)[4], with specific extensions to model and specify application systems, reusable component systems and layered architectures. Another UML extension expresses system variability in terms of variation points and attached variants. We defined several model-driven software development processes used to design and construct application systems, component systems and layered architecture, optimizing for robustness and reuse..

In the RSEB, we subscribe to the "4+1 View" approach to architecture popularized by Rational methodologist Philippe Kruchten [5]: develop several models (analysis, design, etc.) that represent important architectural views, plus one model that ties them all together. In the RSEB this unifying role is played by the use case model[3,6].

Domain Analysis methods use a different model to play this unifying role for optimizing asset reuse across a family of systems. In the RSEB, we distributed DA-like activities across the various processes that develop the system architecture and create component systems. The RSEB uses the concept of features, related to use cases or parts of use cases, and also related to implementation details or operating constraints. But the RSEB doesn't consider features to be a cerntral concern, nor does it contain an explicit DA process. As a partial result, there is no single model in the RSEB that becomes the reference (that is, the "+1" model) for directly recording information about features and their commonality and variability in a domain. DA methods often provide such a feature model, and we'll talk about one in this article and about the relationship it might usefully have to the other models of the RSEB.

John and his colleagues at Intecs Sistemi have been early users of the RSEB in a project led by Telesoft S.p.A. for the telecom authority Telecom Italia. In their work, they increased the focus on explicit domain analysis, and have extended RSEB's treatment of features. Like many other telecom organizations around the world, Telecom Italia has adopted a process-oriented vision of its business in order to escape the rigidity of its existing software applications and enhance its agility in the marketplace. As described in [2], RSEB supports this process-oriented view of services and supporting information systems by employing a combination of both OO Systems Engineering[6] and OO Business Engineering[7]. RSEB application and systems modeling offers us not only the use case and object modeling that is essential to support this vision, but also offers several key improvements, particularly in the form of variation points, that support the development of flexible and robust use case and object models.

However, telecom services can require very large numbers of use cases for their descriptions; and when the use cases are parameterized with variation points describing all manner of extensions, alternatives, and options, then the domain engineer can easily lose his way when architecting new systems. So we have introduced the feature model from the popular Feature Oriented Domain Analysis (FODA) method [8] as a concise synthesis of the variability and commonality represented in the other models (especially the use case model). It is the "+1" model of the domain engineer. In this column we're going to look at some work that John and Massimo have been doing with their colleagues at Telesoft and Telecom Italia over the past year in the FODAcom project, applying the concepts of RSEB in a customization of FODA for the telecom domain.

In [1] we described the key goals and steps in domain engineering. Domain engineering is a systematic process that incorporates some of the business criteria, and produces some supporting rationale, models and architectures that enable better decisions to be made, recorded and revisited for further revision, and for process improvement based on learning. The subsequent application engineering process is driven not only by the resulting components, but also by selected models and documentation. Domain engineering is a key process needed for the systematic design of an architecture and set of reusable assets (components and other workproducts) that can be used to construct a family of related applications or subsystems. Example systems, user needs, domain expertise and technology trends are analyzed to identify and characterize elements that are common to all family members, and also to deal with elements that vary between family members.

Several different domain engineering methods have been developed (see the survey by Arango[9]). They vary in how they identify the domain effectively, and make maximum use of available domain, architecture and systems expertise. Some methods focus on how to select existing examples for detailed analysis, while others focus on how to collect, represent and cluster feature sets.

Feature Oriented Domain Analysis (FODA) is one of the most popular DA methods. It was developed at the Software Engineering Institute[8]. The choice of FODA for our work is no accident. Telecom companies, with their heavily "feature-oriented" services, have always gravitated naturally to FODA. In fact, much of the work on FODA since its definition has been carried on by telecom companies-for instance, by FODA pioneer Kang with the Korean telecom authority, and by Bell Northern Research in Canada and the United States. [10]

Domain engineering involves specific requirements analysis, architecture, component development and packaging steps. Steps 1-3 are referred to as domain analysis, and the remainder as asset or component engineering. In RSEB, activities similar to these 7 steps are distributed into the various RSEB processes. FODA deals primarily with the domain analysis steps, 1-3. FODA is quite compatible with the RSEB: it is also a model-driven approach, with domain information captured in several different models reflecting different points of view of the domain.

1. Domain identification and scoping - most applications consist of several recognizable or distinct subsystems or sub-problems, only some of which seem to be usefully exploitable from a reuse perspective. Thus it is important to decide which parts are worth further treatment. In FODA, a context model is constructed. In the RSEB, it is most closely related to decomposition into component systems, and the high-level use case model (use cases and actors) that describe the system architecture and context.
2. Selection and analysis of examples, needs and trends - there is a delicate balance between reactive and proactive reuse. To be useful, a set of reusable components must anticipate future needs. But since it is difficult to do so reliably, and more expensive to build reusable software than regular software, the reuse process has to help find the essential commonality and variability, and help prioritize which parts should be processed to which depth. Most approaches suggest selecting key examples, and extracting their essential feature sets. The selection of examples is obviously related to domain scoping and assessment of user needs, market, technology and business trends.
3. Identification, factoring and clustering of feature sets - using analysis models, tables and/or graphical means, requirements or implementation features that appear together (AND) or are variants to be selected from (OR) are structured into a decision framework. Domain terminology is accumulated. In FODA, an information model describes the domain entities and the structural relationships among them, whereby in the RSEB a use case and analysis object model is built. In FODA, a behavioral model describes the dynamic relationships among the entities of the domain, corresponding roughly to RSEB sequence and interaction diagrams. The FODA functional model-related to the RSEB object models-describes the data flows among domain entities. The FODA feature model, ties all of these models together by structuring and relating feature sets.
4. Development of 'domain' or 'generic' model and architecture - from these feature sets, a robust architecture relating core mechanisms, features, subsystems and variants is developed, using some appropriate architecture modeling and description. The architecture shapes the resulting applications or subsystems, defines core services, and specifies interfaces precisely. This serves as a reference architecture and a functional blueprint. The FODA architectural model describes domain architecture and is clearly related to the overall RSEB layered architecture.
5. Representation of usable commonality and variability - generalized subsystems, modules and functions are identified, and related to each other as generalizations, specializations or alternatives.
6. Exploitation of commonality and variability - several notations and mechanisms are used specify in detail several (classes of) generic or parameterized workproducts, some of which will be engineering into reusable components.
7. Implementation, certification, and packaging of reusable components - the 'most important' subset of the candidate reusable assets and workproducts are implemented and released as certified, reusable components, under configuration management. These components use several kinds of technologies, ranging from components to generators, languages and kits. Other reusable assets will be implemented as needed.

We use FODA as the basis for the introduction of explicit feature models and process steps into the RSEB, extending the informal treatment of features as described in the book[3]. Here is how FODA describes feature analysis: "The purpose of feature analysis is to capture in a model the end-user's (and customer's) understanding of the general capabilities of applications in a domain." Sound a bit like use cases? That should come as no surprise. When FODA appeared on the scene in 1990, use case modeling had not yet become the widely accepted approach to OO requirements analysis that it is today, or as central a model for OO software engineering as it is in the landmark book on Object-Oriented Software Engineering[6].

FODAcom updates FODA by providing side-by-side use case models and explicit feature models, and integrates explicit domain analysis and RSEB elements to work together effectively. As mentioned above, features can include more than just service requirements as described by use cases-and as we shall see, features are often less than full use cases too.

As shown in Figure 1, the use case model and the feature model serve different purposes: The use case model is user oriented; the feature model is reuser oriented.

Use case modeling relieves feature modeling of the "double duty" it was having to perform previously in plain vanilla FODA. Use cases take over the task of gathering and describing user requirements on system functionality, and they do a better job of it. Now we can use the feature model to focus on what it does best: organize the results of commonality and variability analysis in preparation for domain engineering and reuse access. The feature model provides an abstract and concise syntax for expressing commonality and variability in the domain.

The feature model may be best thought of as a catalog of feature commonality and variability. One property of a catalog is that it is as concise as possible. The feature model contains a well-organized collection of items that have been selected according to a process that includes deciding what should become a feature of systems in the domain. Whereas the use case model has to cover all of the requirements of systems in the domain, the feature model need not (and should not) include all possible features, but only those which the domain analyst deems important. This represents considerable added value for the domain engineer. This is similar to the more familiar systems engineering data dictionary. Distilled from many sources, it is an organized, selective, and normalized catalog of terms that becomes the reference for terminology used by project developers. For domain engineering, the data dictionary corresponds closely to the domain terminology dictionary.

Let's consider how the reuser approaches this catalog of features when he wants to build a new system in the domain. He has a complete specification of the domain given by the RSEB use case model of the domain (using uses and extends relationships and variation points). The feature model gives him something more: a "configuration roadmap" through the use case model, which can guide him through an understanding of what can be combined, selected, and customized in his system. This schematic roadmap also expresses semantic constraints that can't be found in any of the other domain models-for example, "this operating system can't be selected together with that hardware." And the feature model references characteristics that are hard to express directly as simple use cases, such as performance constraints, etc.

Let's consider now a notation to represent features. The original FODA has three kinds of features: mandatory, alternative, and optional. Why not just use a use case for each feature, and the basic uses and extends relationships to connect them? Just as we have used other mechanisms for variability in RSEB, we must use richer and different mechanisms for features in FODAcom. Uses and extends applied to use cases do not necessarily have the same meaning for features. For example, if use case B extends A, is it an "optional" feature of A? The question doesn't even make sense, because A doesn't know about B. Furthermore, not all features are automatically related to complete (or even partial) use cases; in other cases, the whole use case may be optional. A much better match is the idea of variation points that we introduced in RSEB[1]. Variation points reflect parameterization in the domain in an abstract manner, and appear in, and are traceable across, several RSEB models, not just the use case model. The feature model reflects variability and commonality explicitly. We use variation points as the starting point for our notation for features.

The following sketch of a preliminary feature model for telephone service provision will illustrate the flavor. It is inspired by an article by Bernard Ku of telecom giant MCI[11]. An easy-to-use feature model is particularly important for "rapid creation of new services", leading to decreased cycle time in creating and deploying such systems. There is a group of basic features that the user sees as capabilities.

Not all of these features would appear in use cases; some come from detailed implementation and configuration choices in deployable telecom systems; others from domain experts and others from analysis of typical switch and network configurations. While some features can be associated with use cases and variations, others must be associated with types of actors, or details such as included or omitted subsystems, parameters in objects, choice of target platform, etc. These only appear in later design or implementation models.

In the telecom domain, quite a few of the features are already known by domain experts, explaining how different kinds of systems differ. These can be used to build an initial feature model. Or, some of them might exist a priori, such as a PABX switch. Likewise, some common and variant services described by use cases are also known early. Thus a rudimentary requirements model or initial use case model might exist even before serious domain engineering has begun. Both of the models provide concepts and terminology for describing, analyzing and structuring the other sources of information as domain engineering proceeds.

The set of features can be specified and structured using :

• the composed_of relationship. A feature can be modeled as composed of several subfeatures, following a decomposition/ aggregation abstraction mechanism. In the example, the feature "Phone Service" is composed of "exchange", "type", "billing", "line quality" and "dialling mode". The relationship is represented by drawing a line from the super-features to each of its components.
• the existence attribute (optional or mandatory). A feature can be mandatory or optional. A mandatory feature must be selected in all the configurations of the feature model, while an optional feature may be disregarded in some configurations. An optional feature is represented with a circle above the feature name. A mandatory feature composed exclusively of optional features means that at least one of them has to be selected in all the configurations.
• the variation_point/variants relation. Some features can act as variation points in the model, while other features play the role of its possible variants. This relationship could also be interpreted as inheritance, since the variation point represents an abstract feature with common properties, while the variants are particular instantiations, following an abstraction/refinement abstraction mechanism. In the example, the feature "exchange" is a variation point with "PABX" and "individual" as variants. From an inheritance point of view "exchange" is a more abstract feature with "PABX" and "individual" as two possible refinements. A feature which defines a variation point is represented with a diamond under its name. A line is drawn to each available variant from the diamond. In the textual notation a particular variant v of a variation point vp is vp.v (e.g. "exchange.PABX" or "exchange.individual"). A variation point may also have an empty set of variants, indicating a point of customization for the reuser.
• the requires and mutual_exclusion constraints. These rules define the semantic constraints on optional features and variants, to give the model consistency. It is possible to specify which features must be selected together with a designated one. In the example the feature "P.I.N" requires that the feature "dialing_mode.tone" must be selected as well.

Each feature node in Figure 2 can be expanded into a more complete UML feature element, which we will implement in UML as one of several stereotypes of Class[4], just as we did for the RSEB extensions[1,3]. These include «optional-feature», «mandatory-feature», and «variant-feature». The collapsed or iconic notation for «optional-feature» will be shown with a small circle as in Figure 2, while expanded or full view might show as in Figure 3. The additional fields record rationale, restrictions, and special connections to other features, etc.

It is also possible to specify the incompatibility in the choice of two features. In the previous example the selection of the feature video implies that the "line_quality.POTS" cannot be selected. These constraints can be expressed as separate rules with respect to the diagram, directly in the feature element using the requiresFeatures or excludesFeatures attributes, or as UML constraints attached the feature elements or relationships.

Note that the existence attribute and the other relations are orthogonal. This means that you can have a feature composed of mandatory and optional features where an optional (or mandatory) feature can in turn be a variation point. The variants of a variation point can be structured in turn with all the mechanisms seen above.

Model construction in FODAcom is a concurrent process, just as the RSEB layered architecture, application system and component system engineering processes are concurrent. Figure 4 shows several sources of information, including exemplars, requirements, domain experts, and early domain models, which are fed into a concurrent and continuous cycle of context modeling and scoping; feature modeling; and use case modeling. (The other models are not shown here for simplicity.) Each of the models is gradually built up in parallel with the others.

Let's examine this feature-driven view of the process in more detail. The feature model serves as the backbone for commonality/variability for all the models of the domain, including the use case model, object models and architecture models. In the RSEB all the models use proprietary mechanisms to "express variability in terms of variation points and attached variants". In a domain engineering context we could think of these variation points as dedicated to the parameterization of the domain and therefore under the control of the feature model. The feature model is thus the "+1" model for the Domain Analyst, in the following way: whenever a variation point is being introduced in a FODAcom model, it is first compared with the feature model to see if there is a mapping. If there is, then the creation of the variation point is legal; otherwise the feature model must be extended to include a new variation point or optional feature. In this way the identification and definition of variation points is systematically coordinated across all the models.

The Feature Engineer will have to answer several questions as part of the process steps 3 & 4 above, after collecting information and scoping:

• What constitutes a good feature? As we said before, not everything that could be a feature should be a feature. Furthermore, the analyst has a lot of leeway in creating feature descriptions that are robust and expressive. As we have said, features are used primarily to discriminate between choices, not to describe functionality in great detail; such detail is left to the use case or object models.
• How are features found? The FODAcom guidebook describes some clues that the other models give us for feature identification. As an example, Figure 5 illustrates the kind of guidance offered to the Feature Engineer when extracting features from the use case model.

Since the creation of a variation point must be represented in the feature model, and since the feature model must only contain robust features (that is, features which are significant for the parameterization of the domain), it is a crucial decision in the design of the domain model. The concurrent model building process becomes:

• build a preliminary feature model out of what you know of the domain (domain experts, known analyses, etc.)
• build the use case model of the domain.
• during the construction of the domain use case model, commonalities and variability are analyzed, leading to the definition of variation points.
• Whenever a variation point is added in the domain use case model, a new feature is defined and added to the feature model together with the mapping to the use case model itself.

Upon completion of the domain use case model, the feature model is also completed (as well as the mapping between them), but only in the part regarding the functional requirements of the domain.

During the construction of the other models the same scenario may occur. For example during architectural model construction some analysis may identify variations and commonalities, leading to the definition of variation points. Once again, this must result in an extension of the feature model (or the realization that the variation point can reference an existing feature). This will create features that relate to system structure and configuration rather than to specific function.

In summary, although several models are constructed during FODAcom domain analysis, the process is primarily driven by the construction of the feature model as a result of the "other" analyses, placing it side-by-side with the other models.

It is this way that the feature model functions as a "roadmap" to the other models. The reuser first selects features from the catalog and then can see the related variation points in the detailed models. This roadmap function allows us to identify further guidelines related to feature definition: features not related to any variation point in any model are suspected of not being good features. Conversely, variation points not related to any feature cannot be exploited effectively by reusers.

As components of various kinds are packaged into coherent component systems and released, careful decisions must be made by the Configuration Engineer. Decisions must be made as to what goes into separate elements under Configuration Management (CM) and what does not. In the RSEB, Configuration Items (CI) are used to package together related components and variation; alternatives are packaged into separate CIs. In principle, anything can become a CI: a module, an operation, even a line of code. A good CI is chosen at the right level of abstraction. It's the Configuration Engineer's job to decide what's important and what's only detail. Thus, paradoxically, the value of a CI identification process isn't its completeness with respect to the space of all possibilities, but rather its "incompleteness"-in the sense that it synthesizes only the essential items with respect to the objectives of the model.

Feature models help by providing a concise yet robust expression of commonality and variability that becomes the reference point for domain analysis, component engineering and final CM packaging.

While the "what" and "how" of commonality and variability is expressed in other models such as the use case model, the feature model, provides a "which one" point of view: which features (mandatory, alternative, optional) can belong to systems in the domain, and in which combinations? This is the high-level summary needed to characterize the CI's.

We have found that by starting from the use case based RSEB models which already incorporate variability and some aspects of domain engineering, we have been able to integrate the RSEB and standard FODA processes and models. UML and RSEB provide a natural base, requiring only a few extensions. We have given an explicit representation for the feature model using UML. The resulting FODAcom feature models are simpler than those in original FODA, focusing on the feature-oriented parts for domain-engineering purposes. These feature models act as a convenient catalogue or index into the commonality and variability present in usecase and object models, simplifying the task for the reuser. We have provided an outline of the FODAcom domain analysis process, as an extension to the RSEB process.

Not only does this seem like a natural and robust extension to the simplified treatment of features in RSEB, but more importantly, this RSEB/FODA combination has been applied to the Telecom business in the form of FODAcom. It provides a robust and easy to use way of characterizing the many hundreds of reuse-oriented features and use case variants.

Next steps involve the exploration of appropriate tool support for our feature-extended RSEB models. One route would be to start from a standard UML tool (e.g. Rational ROSE) and add RSEB and FODA extensions using the UML extension mechanisms. Another route would be to create or modify existing toolsets to add more direct support for UML, FODA, and RSEB.

[1] ML Griss, Domain Engineering And Variability In The Reuse-Driven Software Engineering Business, Object Magazine, Dec 1996.

[2] ML Griss, Improved Cycle Time in the Reuse-driven Software Engineering Business, Object Magazine, August 1997.

[3] I Jacobson, M Griss, P Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Addison-Wesley-Longman, May 1997.

[4] G Booch, I Jacobson and J Rumbaugh, The Unified Modeling Language, Version 1.0, Jan 13, 1997, Rational Software Corporation.

[5] P. Kruchten, The 4+1 View Model of Architecture, IEEE Software, 42-50, November 1995.

[6] I Jacobson et al, Object-oriented software engineering: A use case driven approach, Addison-Wesley, Reading, MASS. 1992.

[7] I Jacobson et al, The Object Advantage - Business Process Reengineering with Object Technology, Addison-Wesley, Menlo Park, CA, 1994.

[8] K Kang et al, Feature-Oriented Domain Analysis Feasibility Study, SEI Technical Report CMU/SEI-90-TR-21, November 1990.

[9] G Arango, Domain Analysis Methods, in W. Schäfer et al., Software Reusability, Ellis Horwood, Hemel Hempstead, UK, 1994.

[10] N.S. Zalman, Making the Method Fit: An Industrial Experience in Adopting (FODA), Proc. Fourth International Conference in Software Reuse, IEEE Press, Los Alamitos, CA, 1996, pp 233-235.

[11] B.S. Ku, A Reuse-Driven Approach for Rapid Telephone Service Creation, Proc. Third International Conference in Software Reuse, IEEE Press, 1994.