Chapter 5 described feature modeling in software product lines in which the common, optional, and alternative features are determined. Chapter 6 described static modeling in software product lines, in which kernel, optional, and variant classes are determined. This chapter describes feature/class dependency modeling, in which the relationship between features and classes in the software product line are developed. In particular, the discussion covers how the features that address the functional requirements of the product line relate to the software classes that realize the product line's functionality.
In software product lines, feature/class dependency modeling shows the classes required to support each product line feature. During feature modeling, features are analyzed and categorized as common features (required by all members of the product line), optional features (required by only some members of the product line), and alternative features (a choice of features exists). Feature/class dependency modeling emphasizes optional and alternative features because the selection of these features, and the classes required to realize them, are what determine the nature of the specific members of the product line.
Section 9.1 focuses on classes and variation points, describing how variability can be introduced in two ways—first, through abstract classes and subclasses; and second, through parameterization. Section 9.2 describes class reuse categorization for software product lines and how this is depicted with stereotypes. Section 9.3 discusses feature/class dependencies, and Section 9.4 continues the discussion by describing how these dependencies can be determined by means of feature-based impact analysis. Section 9.5 describes feature/object and feature/class modeling in UML using feature-based communication diagrams and feature-based class diagrams, respectively.
In modeling software product lines, it is very important to anticipate where change can be introduced into the product line, thereby permitting evolution of the product line after initial deployment. Variation point modeling provides a systematic approach for addressing change.
A variation point identifies a location at which change will occur in a software product line. The variation point also identifies the mechanism by which changes can be made (Webber and Gomaa 2002, Gomaa and Webber 2004). In Chapter 4, variation points were described with respect to use cases. In this chapter, variation points are described in regard to classes. The two main variation point mechanisms provided are abstract classes and parameterization. With an abstract superclass, the inheritance mechanism is used to specialize the superclass differently for various members of the software product line. With parameterization, a product line class has configuration parameters, which are assigned different values for different members of the product line.
An abstract class is a class with no instances. Because an abstract class has no instances, it is used as a template for creating subclasses instead of as a template for creating objects. Thus, it is used only as a superclass and defines a common interface for its subclasses. An abstract operation is an operation that is declared in an abstract class but not implemented. An abstract class must have at least one abstract operation.
An abstract class defers all or some of its operation implementations to operations defined in subclasses. Given the interface provided by the abstract operation, a subclass can define the implementation of the operation. Different subclasses of the same abstract class can define different implementations of the same abstract operation. An abstract class can thus define an interface in the form of abstract operations. The subclasses define the implementation of the abstract operations and may extend the interface by adding other operations.
Some of the operations may be implemented in the abstract class, especially in cases where some or all of the subclasses need to use the same implementation. Thus the abstract class may define a default implementation of an operation. A subclass may choose to override an operation defined by a parent class by providing a different implementation for the same operation. This approach can be used when a particular subclass has to deal with a special case that requires a different implementation of the operation.
The abstract class captures common properties for all related classes in the superclass. Although abstract classes are often used to represent kernel classes of the product line, they can also represent optional classes. A subclass inherits the common properties from the abstract class and then extends it with variant properties, which could be in the form of new attributes, new operations, or alternative implementations of abstract operations. Thus the subclasses are variant classes.
Variability can be introduced at the abstract class level or at the abstract operation level. At the abstract class level, a class can be specified consisting entirely of abstract operations. The variant subclass must therefore provide the implementation of all the operations. In such a case, the variation point applies at the class level—that is, to the entire class. At the abstract operation level, an abstract class can be designed such that only one of its operations is abstract and variability is introduced through implementation of this operation. In that case, the variation point applies at the abstract operation level.
With the abstract class approach, a variant subclass is used for each variation to the abstract class. This approach has the advantage of isolating each variation in one variant class. It provides separation of concerns by ensuring that a variant class is affected by only one feature. However, a potential disadvantage in product lines with a large degree of variability is that isolating each variation in one variant class could lead to a combinatorial explosion of variant classes.
The software product line example of abstract classes and subclasses is for a banking product line, in which different banks provide different kinds of accounts. Initially checking accounts and saving accounts are provided, although later other types of accounts, such as money market accounts, could be added.
An abstract class is designed called Account, which represents a variation point because variability is introduced by specialization of the class. Account is designed to have two generalized attributes that are needed by all accounts: account Number and balance. Because it is necessary to be able to open and close accounts, read the account balance, and credit and debit the account, the following generalized operations are specified for the Account class:
Initially the banking product line handles two types of accounts: checking accounts and savings accounts. Account is a good candidate for using inheritance, with a generalized account superclass and specialized subclasses for checking account and savings account. Questions we need to ask at this stage are: What should be the generalized operations and attributes of the account superclass? What are the specialized operations and attributes of the checking account and savings account subclasses? Should the account class be an abstract class; that is, which of the operations should be abstract, if any?
Before we can answer these questions, we need to understand in what ways checking and savings accounts are similar and in what ways they differ. First consider the attributes. It is clear that both checking and saving accounts need account Number and balance attributes, so these attributes can be generalized and made attributes of the Account class, to be inherited by both the Checking Account and Savings Account subclasses. One requirement for checking accounts is that it is desirable to know the last amount deposited in the account. Checking Account thus needs a specialized attribute called last Deposit Amount. On the other hand, in this bank, savings accounts accrue interest but checking accounts do not. We need to know the accumulated interest on a savings account, so the attribute cumulative Interest is declared as an attribute of the Savings Account subclass. In addition, only three debits are allowed per month from a savings account without a bank charge, so the attribute debit Count is also declared as an attribute of the Savings Account subclass.
Two additional static class attributes are declared for Savings Account; these are attributes for which only one value exists for the whole class, which is accessible to all objects of the class. The static attributes are max Free Debits (the maximum number of free debits, which is initialized to 3) and bank Charge (the amount the bank charges for every debit over the maximum number of free debits, which is initialized to $2.50).
Both Checking Account and Savings Account will need the same operations as the Account class—namely, open, close, read Balance, credit, and debit. The interface of these operations is defined in the Account superclass, so the two subclasses will inherit the same interface from Account. The open and close operations are done in the same way on checking and savings accounts, so the implementation of these operations can also be defined in Account and then inherited. The credit and debit operations are handled differently for checking and savings accounts. For this reason, the credit and debit operations are designed as abstract operations with the interface for the operations specified in the superclass but the implementations of the operations deferred to the subclasses.
In the case of the Checking Account subclass, the implementation of the debit operation needs to deduct amount from balance. The implementation of the credit operation needs to increment balance by amount and then set last Deposit Amount equal to amount. For Savings Account, the implementation of the credit operation needs to increment balance by amount. The implementation of the debit operation must, in addition to debiting the balance of the savings account, increment debit Count and deduct bank Charge for every debit in excess of max Free Debits. There is also a need for an additional clear Debit Count operation, which reinitializes debit Count to zero at the end of each month.
At first glance, the read operations for checking and savings accounts appear to be identical; however, a more careful examination reveals that this is not the case. When we read a checking account, we wish to read the balance and the last deposit amount. When we read a savings account, we wish to read the balance and the accumulated interest. The solution is to have more than one read operation. The generalized read operation is the read Balance operation, which is inherited by both Checking Account and Savings Account. A specialized read operation, read Cumulative Interest, is then added in the Savings Account subclass; and a specialized read operation, read Last Deposit Amount, is added to the Checking Account subclass.
The design of the Account generalization/specialization hierarchy is depicted in Figure 9.1 and described here. This figure uses the UML convention of depicting abstract class names in italics.
Design of the Checking Account subclass
Attributes:
Inherits the attributes
account Numberandbalance. Both attributes are declared as protected in theAccountsuperclass; hence they are visible to the subclasses.Adds the attribute
last Deposit Amount.
Inherits the specification and implementation of the operations
open,close, andread Balance.Inherits the specification of the abstract operation
credit; defines the implementation to addamounttobalanceas well as to setlast Deposit Amountequal toamount.Inherits the specification of the abstract operation
debit; defines the implementation to deductamountfrombalance.Adds the operation
read Last Deposit Amount () : Real.
Design of the Savings Account subclass
Attributes:
Inherits the attributes
account Numberandbalance.Adds the attributes
cumulative Interestanddebit Count.Adds the static class attributes
max Free Debitsandbank Charge. Static attributes are underlined in UML, as shown in Figure 9.1.
Inherits both the specification and implementation of the operations
open,close, andread Balance.Inherits the specification of the abstract operation
debit; defines the implementation to deductamountfrombalance, incrementdebit Count, and deductbank Chargefrombalanceifmax Free Debitsis greater thandebit Count.Inherits the specification of the abstract operation
credit; defines the implementation to addamounttobalance.Adds the following operations:
add Interest (interest Rate : Real), which adds interest on a daily basisread Cumulative Interest () : Realclear Debit Count (), which reinitializesdebit Countto zero at the end of each month
One way to avoid the potential problem of a combinatorial explosion, caused by a large number of variant classes, is to use parameterized classes instead of specialized subclasses.
With parameterized classes, a product line class has configuration parameters, which are assigned different values for different members of the product line. In a parameterized class with multiple parameters, different parameters can be associated with different features. The main advantage of this approach is simplification in that there is one parameterized class instead of many variant classes. The disadvantage is the potential loss of separation of concerns in that a parameterized class can be affected by more than one feature.
Parameterized classes can be kernel, optional, variant, or default classes. In each case, the configuration parameters need to be set by the product line member. This is done either at configuration time or at runtime during system initialization.
One example of a parameterized class comes from the microwave oven product line. The class is an entity class called Oven Data, which contains all the parameters that need to be set for cooking food. Several parameterized variables are maintained for the microwave oven, many of which relate to optional features.
The Oven Data class can be designed as one class with several attributes or as a composite class with an internal class for each parameterized attribute. The class is designed as a parameterized kernel class because it is easier to manage than having one class for each parameter. For each optional attribute of the class, a constraint defines the feature that applies to this attribute. The attribute is relevant for a given product line member only if the feature is selected as indicated by the feature constraint.
«kernel-param-vp» «entity»Oven Data
Kernel attribute:
cookingTime. Remaining time to cook food.
Optional attributes, which are relevant only if the named feature is selected:
selectedPowerLevel {feature = Multi-level Heating}. Possible values of this variable are: High, Medium, and Low; the initial value is High. If this feature is not selected, the power level is a constant set to High.itemWeight {feature = Analog Weight}. This Real variable is used only with analog weight and records the actual weight of the item.selectedRecipe {feature = Recipe}. Initialized to “none selected”.TODvalue {feature = TOD Clock}. Time variable initialized to 12:00.TODmaxHour {feature = TOD Clock}. Parameterized constant set at system configuration to 12:00 or 24:00 to indicate maximum hour on clock.
The attributes held by the parameterized Oven Data class are depicted in Figure 9.2, which shows the variable name, the type of variable, the range for the variable, permitted values for configuration parameters, and the feature constraint if the attribute is optional. Configuration parameters, such as TOD max Hour, are depicted as static variables because once the value of the parameter is set at configuration time, it cannot be changed and is the same for all object instances.
As pointed out in Chapter 6, multiple UML stereotypes may be used to depict different aspects of the modeler's problem. For software product lines, two different kinds of stereotypes are used, depicting two orthogonal (i.e., independent) ways of categorizing a class: categorization by role and categorization by reuse. A stereotype is used to identify the role played by the class in the product line. Class role stereotypes are used for the same purpose as in single systems (Gomaa 2000). Examples of class role stereotypes are «entity», «interface», «control», and «application logic»; these are described in more detail in Chapter 6.
A second stereotype is used to identify the reuse category for the class in the software product line. A class reuse category is used to identify how the class is to be reused in a specific member of the product line. Chapter 6 described the main kinds of class reuse categories—namely, kernel, optional, and variant classes. This section describes the full set of class reuse categories, which are depicted in UML with the stereotype notation. In particular, some product line classes are always used without change, some provide variation points through abstract classes, and some provide variation points through parameterized classes. When an abstract or parameterized class is designed to be a source of variability, it defines a variation point, which is explicitly identified in the name of the stereotype, abbreviated vp.
The class reuse categories are described in the list that follows and depicted as class reuse stereotypes in Figure 9.3. Examples of class reuse categorization from the microwave oven software product line are given in Figure 9.4.
Main class reuse categories:
«kernel» (kernel class). A class provided by every member of the product line and used without change by every member. An example of a kernel class with no variants is the input device interface class
Door Sensor Interface, as shown in Figure 9.4:«optional»(optional class). A class provided by some members of the product line but not all. When used, it is used without change. An example of an optional class is the output device interface classLamp Interface, as shown in Figure 9.4:«optional» «output device interface»Lamp Interface
«variant»(variant class). One of a set of similar classes, which have some identical properties but others that are different. Different variant classes are used by different members of the product line. An example of a variant class is the output device interface classMulti-line Display Interface, as shown in Figure 9.4:«variant» «output device interface»Multi-line Display Interface
«default»(default class). The default class among a set of variant classes, which is provided by some members of the product line. An example of a default class is the output device interface classOne-line Display Interface, as shown in Figure 9.4:«default» «output device interface»One-line Display Interface
Parameterized class reuse categories:
«kernel-param-vp»(kernel parameterized class). A parameterized class that is provided by every member of the product line. The values of the configuration parameters need to be set by the individual product line member. This class represents a variation point, as explicitly identified by “vp” in the stereotype name, because product line variability is introduced at this point through parameterization. An example of a kernel parameterized class is the state-dependent control classMicrowave Oven Control, as shown in Figure 9.4:«kernel-param-vp» «state dependent control»Microwave Oven Control
«optional-param-vp»(optional parameterized class). A parameterized class provided by some members of the product line but not all. The values of the configuration parameters need to be set by the individual product line member, making this class a variation point. An example of an optional parameterized class is the timer classTOD Timer, as shown in Figure 9.4:«optional-param-vp» «timer»TOD Timer
«variant-param-vp»(variant parameterized class). One of a set of variant parameterized classes, which is provided by some members of the product line. The values of the configuration parameters need to be set by the individual product line member, making this class a variation point.«default-param-vp»(default parameterized class). The default class among a set of variant parameterized classes, which is provided by some members of the product line. The values of the configuration parameters need to be set by the individual product line member, making this class a variation point.
Abstract class reuse categories:
«kernel-abstract-vp»(abstract kernel class). An abstract class provided by every member of the product line. The abstract class cannot be instantiated; instead it provides a standard interface for its subclasses. This class represents a variation point, as explicitly identified by “vp” in the stereotype name, because product line variability is introduced at this point through specialization. An example of an abstract kernel class is the output device interface classDisplay Interface, as shown in Figure 9.4:«optional-abstract-vp»(abstract optional class). An abstract class provided by some members of the product line but not all. The abstract class provides a standard interface for its subclasses and represents a variation point because product line variability is introduced at this point through specialization.Concrete class reuse categories:
«kernel-vp»(concrete kernel class). A concrete class provided by every member of the product line. The class provides a standard interface for its subclasses. This class represents a variation point, as explicitly identified by “vp” in the stereotype name, because product line variability is introduced at this point through specialization. This category is different from the abstract kernel class in that the class can be instantiated.«optional-vp»(concrete optional class). A concrete class provided by some members of the product line but not all. This class provides a standard interface for its subclasses and represents a variation point because product line variability is introduced at this point through specialization. This category is different from the abstract optional class in that the class can be instantiated.«variant-vp»(concrete variant class). One of a set of concrete variant classes. This class provides a standard interface for its subclasses, which are also variant. It also represents a variation point because product line variability is introduced at this point through specialization.
For every feature in the software product line, certain classes realize the functionality specified by the feature. Because a common feature is provided by every member of the product line, the classes that support or realize a common feature are always kernel classes. Because common features, by definition, are provided by every member of the product line, it follows that kernel classes are always present in all product line members. If an optional or alternative feature is selected for a given member of the product line, then the optional or variant classes that realize this feature are also selected.
Depending on the feature analysis, different variants of the same abstract class might or might not be permitted to coexist in the same product line member. Figure 9.5 depicts the variant subclasses of the kernel abstract Workstation Controller class from the factory automation product line. To see whether these variants can coexist or not, it is necessary to understand the feature analysis. In the case of an exactly-one-of feature group or a mutually exclusive feature group, the variants are not permitted to coexist in the same product line member. The Line Workstation Controller, Receiving Workstation Controller, and Shipping Workstation Controller variant classes all support the High-Volume Manufacturing feature and can therefore coexist. However, Flexible Workstation Controller supports the Flexible Manufacturing feature, and Factory Monitoring Workstation Controller supports the Factory Monitoring feature. The High-Volume Manufacturing, Flexible Manufacturing, and Factory Monitoring features are members of an exactly-one-of feature group. Hence the subclasses that support these features are mutually exclusive state-dependent control classes that exist in different kinds of factories, as described in detail in Chapter 15.
In the case of a common or optional feature, variant classes are permitted to coexist in the same product line system. For example, Receiving Workstation Controller, Line Workstation Controller, and Shipping Workstation Controller all coexist in High-Volume Manufacturing members of the factory automation product line.
An effective approach to determining the feature/class dependencies is to perform an impact analysis of each feature. The goal of feature-based impact analysis is to determine what optional, parameterized, or variant classes depend on each new feature. Feature-based impact analysis is best addressed through object interaction modeling, as a step on the way to determining the feature/class dependencies.
As described in Chapter 7, the analysis begins with the kernel first approach and continues with the product line evolution approach. Applying the kernel first approach to the microwave oven product line results in the kernel classes being identified as described in Chapter 7 and depicted in Figure 9.6.
After feature-based impact analysis is applied as described in Section 9.4.1 for optional features and Section 9.4.2 for alternative features, feature/class dependencies can be depicted on feature-based class diagrams (as described in Section 9.5.2) or feature/class dependency tables (as described in Section 9.5.3).
After the kernel first approach has been applied, the product line evolution approach (see Chapter 7) is applied to determine the impact of optional and alternative features on the kernel communication diagram. This overall approach, called feature-based impact analysis, systematically analyzes the impact of each feature on the kernel communication diagram. If there are cascading feature dependencies (e.g., feature B depends on feature A), then the order of feature analysis is to
Analyze the impact of feature A on the kernel communication diagram and create a modified communication diagram depicting this impact
Analyze the impact of feature B on the kernel communication diagram modified by feature A
For optional features, analyze the impact of each feature on the kernel communication diagram. Determine what optional objects need to be added to provide the functionality needed by the feature. Also determine what objects are affected by the feature—that is, objects whose behavior needs to change as a result of the impact. When a new optional object is added, often an existing object needs to be modified to communicate with the new object. It is then necessary to decide whether the affected object should be designed as an instance of a parameterized class or an instance of a specialized class. In the latter case, it will be necessary to replace a default class with a variant class, both of which could be subclasses of an abstract class.
As an example, consider the optional features from the microwave oven software product line. In the case of the Light, Turntable, and Beeper optional features, each feature needs to have an optional output device interface object added. These are Lamp Interface, Turntable Interface, and Beeper Interface, respectively. However, these features also affect the state-dependent control object, Microwave Oven Control, because this object has to trigger the actions, which are executed by the output device interface objects. The decision is made to design Microwave Oven Control as a parameterized class because the alternative of introducing a variant class for each feature would result in a combinatorial explosion of variant classes to keep track of. The classes are defined as follows:
«optional» «output device interface»Beeper Interface«optional» «output device interface»Light Interface«optional» «output device interface»Turntable Interface«kernel-param-vp» «state dependent control»Microwave Oven Control
On the other hand, the Minute Plus optional feature does not require any optional object to be added, but it does affect three kernel objects: Keypad Interface (because it needs to read the input from the extra input key for Minute Plus), Microwave Oven Control (because it needs additional capability to deal with the Minute Plus feature), and Oven Timer (which has to increment the cooking time by 60 seconds when the Minute Plus key is pressed). For the same reasons as for Microwave Oven Control, the decision is made to design the Keypad Interface and Oven Timer classes as parameterized classes:
«kernel-param-vp» «input device interface»Keypad Interface«kernel-param-vp» «timer»Oven Timer
In short, the goal of feature-based impact analysis is to determine what optional, parameterized, or variant objects depend on the new feature. From this information, the classes from which the objects are instantiated can easily be determined.
For alternative features, it is necessary to analyze the impact of each alternative feature on the kernel communication diagram. For each of the alternatives, consider whether any additional optional objects are needed to satisfy the feature, whether any replacement of default object with variant objects resulting from the feature is needed, and whether there is any impact on existing kernel objects that communicate with the new objects.
As an example, consider the alternative features from the microwave oven software product line. Consider the «exactly-one-of feature group» for Display Language. Because one of the software product line requirements is to be able to display prompts in different languages, a separate Display Prompts abstract class is designed that is specialized to support the prompts for the specific language. The default language is English. The alternative languages are French, Spanish, German, and Italian. The default class is English Display Prompts, and an instance of this class is depicted on the kernel communication diagram. If a different language is required—for example, French—only this class is affected, and the French Display Prompts variant class replaces the English Display Prompts default class:
Abstract kernel class:
«kernel-abstract-vp» «entity»Display Prompts
Default variant class:
«default» «entity»English Display Prompts
Alternative variant classes:
Feature/class dependencies and feature/object dependencies can be modeled in UML with the package notation, where a package is a grouping of model elements (Booch et al. 2005). A UML package is used to depict the modeling elements that are grouped into a feature. During requirements modeling, the package notation is used to depict the use cases that are reused together in a feature. During feature-based interaction modeling, a UML package is used to depict the objects that are reused together in a feature. Finally, the feature package can be used to depict the classes that support the feature, and from which the objects in the feature-based communication diagram are instantiated.
Examples of the different usage of feature packages to depict reusable use cases, objects, and classes are given in the factory automation software product line. For example, the High-Volume Manufacturing feature is depicted as a package with the stereotype «feature», which groups the three variant classes that support this feature: Receiving Workstation Controller, Line Workstation Controller, and Shipping Workstation Controller.
Whereas a communication diagram depicts the objects required to support a use case, a feature-based communication diagram depicts the objects required to support a feature. Because a feature can support one or more use cases, a feature-based communication diagram can also support one or more use cases. When a feature supports one use case, it might seem that the feature-based communication diagram and use case–based communication diagram should be identical. In fact, however, a feature-based communication diagram must clearly delineate the objects that provide the functionality specified by the feature.
A feature-based communication diagram shows the objects required to realize that feature. In particular, it assumes the presence of objects in other prerequisite features, including common features. Thus, if one of the objects in the use case–based communication diagram already appears in a prerequisite feature, that object needs to be depicted as belonging to the prerequisite feature. A feature-based communication diagram can be drawn in one of two ways: The first approach is to show only the objects that support the feature. The second approach is to show one or more feature packages in which each package depicts the objects that support the feature. Note that for parameterized objects that support more than one feature, only the former approach can be used.
For a feature supported by more than one use case, the objects required by the feature are determined by analysis of the objects from each use case that supports the feature. Thus the feature-based communication diagram is the synthesis of the use case–based communication diagrams for the use cases that support the feature. As before, any object in the use case–based communication diagram that already supports a prerequisite feature is shown inside the package of the prerequisite feature on the feature-based communication diagram. The interconnected objects that support one feature depend on objects in prerequisite feature packages. They can communicate with those objects in the prerequisite feature-based communication diagrams.
A feature-based communication diagram is a generic UML communication diagram, which means that it depicts all possible interactions between the objects (see Section 7.1.5). Because it does not depict a specific scenario, message sequence numbers are not used. Furthermore, because generic communication diagrams depict generic instances (which means that they depict potential instances rather than actual instances), they use the UML 2.0 convention of not underlining the object names.
As an example, consider the communication diagrams for the factory automation product line. The common feature Factory Kernel consists of four use cases. During dynamic modeling, the objects supporting each use case are depicted on a communication diagram, as follows:
View Alarms. This use case is realized by theOperator InterfaceandAlarm Handling Serverobjects.View Workstation Status. This use case is realized by theOperator InterfaceandWorkstation Status ServerobjectsGenerate Alarm and Notify. This use case is realized by theWorkstation Controller,Alarm Handling Server, andOperator Interfaceobjects.Generate Workstation Status and Notify. This use case is realized by theWorkstation Controller,Workstation Status Server, andOperator Interfaceobjects.
On the basis of these four use cases, a first attempt at modeling the objects supporting the Factory Kernel common feature identifies the Alarm Handling Server, Workstation Status Server, Workstation Controller, and Operator Interface objects. However, another consideration is that there is a need for the product line to support automated factories without a user interface. This means that only the first three objects are needed to support the Factory Kernel feature, and the Operator Interface object should be assigned to an optional feature called Factory Operations User. Another issue is that each factory automation system supports a different type of Workstation Controller object and must be represented by an alternative feature. For example, factory monitoring systems need the Monitoring Workstation Controller object. Thus a factory monitoring system would need at least the following features, as depicted here in the feature notation:
«common feature»Factory Kernel«optional feature»Factory Operations User{prerequisite = Factory Kernel}«alternative feature»Factory Monitoring{prerequisite = Factory Kernel}
Figure 9.7 shows the feature-based communication diagram in which these three features from the factory automation product line are depicted as packages, with the objects supporting the features depicted inside the packages. The optional Operator Interface object in the Factory Operations User optional feature communicates with the Alarm Handling Server and Workstation Status Server kernel objects in the Factory Kernel feature package. The variant Monitoring Workstation Controller object is depicted inside the Factory Monitoring alternative feature package and also communicates with the kernel objects.
Once the feature-based communication diagrams have been developed, it should be relatively straightforward to develop feature-based class diagrams. For each object on the feature-based communication diagram, the class from which it is instantiated is depicted on the feature-based class diagram. If more than one feature is depicted on the feature-based class diagram, then the features are depicted as packages with the classes that support the feature depicted inside the package.
For each communication link between objects on the feature-based communication diagram, an association is depicted between the corresponding classes on the feature-based class diagram. The direction of navigability is depicted on the association. It is determined by consideration of which class provides the operation and which class uses the operation. The direction of navigability on the class diagram should correspond to the direction of the messages sent between objects on the communication diagram. Because the direction of navigability shows the direction of the dependency, the class dependencies should correspond to the feature dependencies. The direction of the association is from the dependent class to the class that it requires the presence of (i.e., depends on). Thus if feature X depends on feature Y, then a class supporting feature X requires the presence of a class supporting feature Y.
When the decision is made to use variant classes, the generalization/specialization hierarchy depicting the abstract superclass and the subclasses is depicted on the feature-based class diagram. A superclass can support one feature while the subclass supports a different feature. The feature supported by the subclass should depend on the feature supported by the superclass.
An example of a feature-based class diagram is given in Figure 9.8. This class diagram depicts the same features shown in the feature-based communication diagram of Figure 9.7. Thus the Operator Interface class in the Factory Operations User optional feature package uses the Alarm Handling Server and Workstation Status Server classes in the Factory Kernel feature package. Because this is a class diagram, abstract superclasses can also be depicted. The abstract Workstation Controller superclass, originally depicted in Figure 9.5, is a kernel superclass and is therefore allocated to the Factory Kernel feature package, while its subclass Monitoring Workstation Controller belongs to the alternative Factory Monitoring feature package. Because there are never any instances of the Workstation Controller superclass, it can never be depicted on a communication diagram.
Note in Figure 9.8 that the dependency of the optional feature Factory Operations User on the common feature Factory Kernel corresponds to the optional Operator Interface class being a client of, and hence depending on, the kernel Alarm Handling Server and Workstation Status Server classes. Similarly, the dependency of the alternative feature Factory Monitoring on the common feature Factory Kernel corresponds to the dependency due to the specialization of the variant Monitoring Workstation Controller subclass from the kernel abstract Workstation Controller superclass.
A concise way of depicting feature/class dependencies is to use a table to show the features and classes that realize the functionality described by the feature. The feature/class dependency table is particularly useful for depicting the relationship between features and parameterized classes because the individual parameters can be explicitly shown. Such a feature/class dependency table has the following columns:
An example of a feature/class dependency table is given for a subset of the microwave oven product line in Table 9.1. For example, Light is an optional feature. It is supported by two classes: Lamp Interface and Microwave Oven Control. Lamp Interface is an optional class. Microwave Oven Control is a kernel parameterized class. The feature condition is stored as a Boolean class attribute of Microwave Oven Control called light, which is set to true or false, depending on whether the feature is selected (light = True) or not selected (light = False).
Table 9.1. Example of feature/class dependencies: microwave oven software product line
This chapter described feature/class dependency modeling, in which the relationships between features and software classes in the software product line are developed. In particular, the discussion covered how the features that address the functional requirements of the product line relate to the software classes that realize the product line's functionality.
In the software product line method, for each feature, feature/class dependency modeling shows the classes required to support each product line feature. This approach emphasizes optional and alternative features because it is the selection of these features, and the classes required to realize them, that determines the nature of the specific members of the product line.
This chapter described classes and variation points, discussing how variability can be introduced in two ways—first, through abstract classes and subclasses; and second, through parameterization. The chapter also described how product line classes are categorized according to their reuse characteristics and how this categorization is depicted with stereotypes. The discussion included a description of feature/class dependencies and how they can be determined by feature-based impact analysis. Feature/object and feature/class modeling in UML using feature-based communication diagrams and feature-based class diagrams, respectively, was introduced.