Synthesis Leveraged Domain Engineering

PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.2.2.1 Decision Model

Getting Started

The Decision Model Activity is an activity of the Domain Specification Activity for producing a Decision Model. A Decision Model defines the set of requirements and engineering decisions that an application engineer must resolve to describe and construct a deliverable application engineering work product. A Decision Model is an elaboration of a domain's variability assumptions and is the abstract form (i.e., concepts and structures) of an Application Modeling Notation for a product family. These decisions, and the logical relationships among them, determine the variety of products in the domain. To construct a product, these decisions must be sufficient to distinguish the product from all other members of the family. The decisions establish how work products of application engineering, including software and documentation, can vary in form and content.

Objectives

The Decision Model Activity defines a set of decisions that are adequate to distinguish among the members of an application engineering product family and to guide adaptation of application engineering work products.

Required Information

The Decision Model Activity requires the Domain Definition.

Required Knowledge and Experience

The Decision Model Activity requires domain and software knowledge and experience in:

Conceptual modeling skills similar to those needed to create a database conceptual schema; see, for example, Kent (1978) and Borgida (1985)
The issues that experienced engineers resolve when constructing systems in the domain

PRODUCT DESCRIPTION

Name:

Decision Model

Purpose:

A Decision Model specifies the decisions that the Application Modeling Notation must allow an application engineer to make in describing a system in the domain. These decisions determine the extent of variation in form and content that is possible in the work products that compose the products in the domain.

To interpret fully the effects of decisions (i.e., to understand all properties of the family member identified by a set of decisions) requires both a Decision Model and a Product Requirements. The Decision Model specifies only the variations among members of a family. It does not specify their common properties. Product Requirements state the common properties, plus the effects of the decisions in a Decision Model.

Content:

The Decision Model work product consists of three components:

Decision Specifications. Specifications of the set of decisions that suffice to distinguish among systems in the domain.
Decision Groups. A structuring of the decision specifications into logical groups, based on domain-related criteria.
Decision Constraints. A set of constraints on the resolution of interdependent decisions.

Form and Structure:

A Decision Model can be represented by one of the following forms:

List of questions
Tabular format

In the question-list format, each decision is phrased as a question and a non-empty set of valid answers. The question identifies the decision that an application engineer must make. The set states all permissible answers to that question.

In the tabular format, each horizontal row in the table expresses a decision specification. The horizontal row is divided into columns. A column identifies either the decision that an application engineer must make, the permissible answers for that decision, or a brief description of the decision.

Each decision and each decision group must have a unique identifier. Domain engineers use this identifier when they define adaptable work products. Each decision group has one list or table that is labeled with a mnemonic appropriate to the group. The group is a set of related decisions. Each entry is an independent decision that has its own distinct mnemonic label, a specification of allowed values that can resolve the decision, and a short explanation of the meaning of the decision.

If a set of related decisions is always resolved as a unit, you can define the set to be a composite decision. Composite decisions are shown in tabular form using a combination of the composite of indicator and indentation. If the application engineer can choose to resolve one (and only one) decision from a set of alternatives, you can define the set to be an alternative decision. Alternative decisions are shown in tabular form using a combination of the alternative of indicator and indentation.

You can also use a tabular format to specify constraints on decision making. Decision constraints may be either structural or dependency. In both cases, a decision group (the Decision Group column) is specified as the focus of the decision constraint. A structural constraint is a decision constraint that limits the number of instances of a decision group in an Application Model. Valid entries include exactly-one, one-or-more, zero-or-one, zero-or-more, and one-for-each X, where X corresponds to other identified decision groups. A dependency constraint is a decision constraint that specifies how decisions made by an application engineer affect subsequent decisions.

Example DE.2.2.1-1 Fragment of TLC Decision Model illustrates a fragment of a Decision Model for the TLC domain. The figure portrays decision groups (e.g., Street, Lane_Group) and their corresponding decisions, along with appropriate constraints.






Traffic_Light_Controller: composed of 
     Schedule: one of (Fixed_Schedule, Programmable) {designates the type of traffic light sequence scheduling 
                                                       the TLC system must accommodate} 
     Geometry: one of                             {intersection geometry} 
          X: list length 4 of Street              {street characteristics for an X intersection} 
          T: list length 3 of Street              {street characteristics for a T intersection} 

Fixed_Schedule: composed of 
     Start_Time: (0:00 .. 23:59)                  {start time for this traffic light sequence schedule} 
     Stop_Time: (0:00 .. 23:59)                   {stop time for this traffic light sequence schedule} 
     .... 

Street: composed of 
     Name: identifier                             {street name} 
     Right_Turn_Lanes: Lane_Group                 {characteristics for the right-hand turn lanes} 
     Left_Turn_Lanes: Lane_Group                  {characteristics for the left-hand turn lanes} 
     Through_Lanes: Lane_Group                    {characteristics for the through lanes} 
     Pedestrian_Crosswalk: one of (Xwalk, NO_Xwalk) {designates the presence of a pedestrian crosswalk 
                                                       for this street} 
     Crosswalk_Button: one of (CB, NO_CB)         {designates the presence of a pedestrian crosswalk 
                                                       pushbutton for this street} 
     .... 

Lane_Group: composed of 
     Number_of_Lanes: numeric(1..2)               {number of traffic lanes in this Lane_Group} 
     Sensor: one of (Sensor, NO_Sensor)           {indicates whether there is a traffic monitoring 
                                                       device for each lane in this Lane_Group} 
     .... 

Project_Information: composed of 
     Name: identifier                             {name for the TLC system} 
     Mnemonic: identifier                         {TLC system mnemonic} 
     .... 
     ______________________________________________________________________________________________________________ 


Constraints 

  -  The number of through lanes for Street(1) must be the same as for Street(3). 

  -  There can be at most 4 different schedules in the Fixed_Schedule. 

  -  A Through_Lanes group must be specified for each Street. 

  -  .... 


Example DE.2.2.1-1. Fragment of TLC Decision Model

Verification Criteria:

Every decision must be an elaboration of one or more variability assumptions.
The Decision Model must accommodate all variability assumptions.

PROCESS DESCRIPTION

The Decision Model Activity consists of three steps shown in Figure DE.2.2.1-1 Decision Model Process

Procedure

Follow these steps for Decision Model Activity.

Step: Identify Decisions

Action:: Identify the decisions that application engineers can make to resolve all of the variations for a system in the domain.
Input:: Variability assumptions
Result:: Decision specifications
Heuristics:: Derive decisions directly from variability assumptions. You must have (at least) one decision for each variation specified in the assumptions. You will likely derive multiple decisions from a single variability assumption; each decision is an elaboration of some aspect of the basic variability.
Keep in mind that the relevant decisions are those concerning system generation time, rather than run-time variation. If you followed a similar heuristic in identifying Domain Assumptions, run-time decisions should not be an issue here. Your focus now should be on how members of a product family differ, rather than on ways in which a member varies its behavior at run-time. However, if members of a product family have variable run-time behavior, then a valid decision may concern whether or how a particular member varies its behavior.
If a variability assumption asserts that a certain characteristic of systems in the domain is variable without saying exactly how it varies, you must determine exactly how the characteristic can vary. Specify the precise type of information that will resolve a decision.
Avoid routinely providing decisions that dictate arbitrary implementation limits (e.g., maximum number of users) unless those limits reflect a policy decision. Optimization of a system requires adequate flexibility.

Step: Structure Decisions

Action:

Organize decisions into logically-related and interconnected groups.

Input:

Decision specifications

Result:

Decision groups

Heuristics:

Each decision group should represent a coherent and cohesive concept to domain experts. Such concepts usually have recognizable names. A concept may be independent of other concepts, or may be an aggregate concept that unifies other simpler concepts. In other words, a decision group may include both individual decisions and decision groups as elements.
Structure the set of decisions based on the principle of separation of concerns ( Dijkstra, Dahl, and Hoare, eds. 1972). For example, create a decision group for decisions that correspond to features of a single, physically-distinct entity.
Group together mutually-dependent decisions, i.e., those that are unlikely to change independently. Domain experts often rely on a single concept that ties dependent decisions together.
Group together decisions that repeat. For example, if you need to describe multiple types of a particular device, the engineer may make similar decisions for each type. You can group these decisions to create a single concept as a focus for decisions.
Group together decisions if they are derived either from a corresponding single variability assumption or from separate assumptions that were grouped in the Domain Definition. A single assumption that motivates several decisions often represents a single concept, while assumption groupings often suggest how domain experts organize their thoughts about such systems.
The principles of database schema normalization form a valid model for this step. As is the case with normalization, the goal here is to identify and organize a set of concepts without redundancy or inconsistency.
Define explicit logical connections between the decision groups. These define the relationships between the decision groups.

Step: Identify Decision Constraints

Action:

Define structural and dependency constraints that limit how decisions are resolved.

Input:

Decision groups

Result:

Decision Model

Heuristics:

Define a structural constraint for each decision group; specify limits on when the group can validly occur in an Application Model.
Define a dependency constraint whenever one decision narrows the resolution that the application engineer can provide for another decision.
You may sometimes create decision groups where the cross-product of the decision specifications implies family members that do not exist. You should examine existing systems and specify constraints that omit these members from the Decision Model.

Risk Management

Risk:

The Decision Model is inadequate for descriptions of intended systems.

Implication:

The domain will not provide effective support for planned projects.

Mitigation:

Try to describe one or more existing systems in terms of the Decision Model. Review these descriptions with experienced engineers to identify erroneous assumptions or unacceptable limitations.

Risk:

The decision space is too large or complex.

Implication:

Effort required to develop the Decision Model and subsequent adaptable work products will exceed a reasonable level.

Mitigation:

Focus on a set of well-understood decisions and make the assumption, explicitly, that the other decisions have fixed values (i.e., temporarily constrain them to be commonalities). Plan to relax these assumptions in subsequent iterations, or, in extreme cases, suggest that the Domain Definition Activity consider narrowing the domain scope.
Reorganize the decision space to achieve a more effective separation of concerns.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:: The Domain Definition is incomplete, ambiguous, or inconsistent.
Source:: Domain Definition Activity
Response:: Describe the inadequacies in the Domain Definition and suggest appropriate refinements. Proceed with Decision Model, and document any assumptions made regarding the inadequate portions of the Domain Definition.
Contingency:: The Domain Plan cannot be satisfied with available technical capabilities.
Source:: Domain Management Activity
Response:: Propose (alternative) revisions to the Domain Plan that better match available capabilities. Complete a Decision Model that satisfies the Domain Plan as closely as possible.
Contingency:: The practices and procedures specified in the Domain Plan are either ineffective or inefficient.
Source:: Domain Management Activity
Response:: Describe the ways in which the practices and procedures are either ineffective or inefficient. Propose revisions to the practices and procedures to make them more effective.

Feedback From Product Consumers

Contingency:

The Decision Model fails to support all the variation described in the Domain Definition.

Source:

Product Requirements Activity
Product Design Activity

Response:

Refine the Decision Model to be consistent with the Domain Definition.

Contingency:

The Decision Model is incomplete, ambiguous, or inconsistent.

Source:

Product Requirements Activity
Process Requirements Activity
Product Design Activity
Product Implementation Activity

Response:

Refine the Decision Model to correct inadequacies.

Contingency:

The structure or content of the Decision Model conflicts with domain experts' conception of an Application Model.

Source:

Process Requirements Activity

Response:

Refine the Decision Model to support an Application Modeling Notation acceptable to domain experts.