Synthesis Opportunistic 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 draft 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 work product family. These decisions, and the logical relationships among them, determine the variety of work products in the domain. To construct a work product, these decisions must be sufficient to distinguish the work 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. The Decision Model Activity is performed for each targeted work product family in the domain. Consequently, there will be a Decision Model (i.e., decisions and logical relationships among them) for each targeted work product family. The work product family's Decision Model is viewed as a partition of the domain's Decision Model. The focus of the interactions with other Synthesis activities occurs at the work product family's Decision Model.

Objectives

The Decision Model Activity defines a set of decisions that are adequate to distinguish among the members of an application engineering work product family and to guide adaptation of Adaptable Components that are composed to form 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 an instance of a work product. These decisions determine the extent of variation in form and content that is possible in the work product belonging to the family.

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 members of a work product family.
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 for the System/Segment Work Product Family illustrates a fragment of a Decision Model for a work product family of the TLC domain. The figure portrays decision groups (e.g., Street, Lane_Group) and their corresponding decisions, along with appropriate constraints.






TLC_SSS: composed of 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} 
     HW_Platform: composed of 
          Platform: one of (TLC1, TLC2, TLC3)     {hardware platform the software will execute on} 
          Interface: one of (TL-A, TL-B)          {type of interface to traffic light indicators} 
     .... 

Street: composed of 
     Through_Lanes: Lane_Group                    {characteristics for the thru lanes} 
     Left_Turn_Lanes: Lane_Group                  {characteristics for the left-hand turn lanes} 
     Right_Turn_Lanes: Lane_Group                 {characteristics for the right-hand turn lanes} 
     Pedestrian_Lane: PL_Group                    {characteristics of a pedestrian lane} 

Lane_Group: composed of 
     Trip_Mechanism: one of (yes, no)             {designates whether the lanes have a trip mechanism} 
     Turn_Light: one of (yes, no)                 {designates whether the lanes have a separate turn light} 
     .... 


PL_Group: composed of 
     Push_Button_Mechanism: one of (yes, no)      {designates whether the pedestrian lanes have a push 
          button mechanism} 
     .... 
     ______________________________________________________________________________________________________________ 


Constraints 

  -  A Through_Lanes group must be specified for each Street. 

  -  .... 



Example DE.2.2.1-1. Fragment of TLC Decision Model for the System/Segment Work Product Family

Verification Criteria:

Every decision must be an elaboration of one or more variability assumptions or reflect variations that are characteristic of existing work product family members.
All Domain Assumptions pertinent to the work product family must be elaborated in at least one decision.

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 work product of a system in the domain.
Input:: Variability assumptions
Result:: Decision specifications
Heuristics:: Derive decisions directly from variability assumptions. You will likely derive multiple decisions from a single variability assumption; each decision is an elaboration of some aspect of the basic variability.
Derive decisions by examining relevant work products of existing systems. Even when you derive decisions from variability assumptions, you should examine these work products to help you understand how to express decision specifications in a form that is natural to the domain (e.g., data types, units).
When you derive decisions by examining existing work products, use domain concepts to express the value space of the answers. This will help application engineers resolve decisions. In other words, if you have three work products that are members of the same family, identify values for answers that suggest differences among the work products.
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 work product family differ, rather than on ways in which a member varies its behavior at run-time. However, if members of a work 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 with respect to the work product family you are analyzing. 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.
Create a separate Decision Model for each application engineering work product family. However, you will probably want to share decision specifications across the models, especially for work product families of the same types (e.g., families of code).
When you examine existing work products, you sometimes gain a fuller understanding of differences by analyzing and comparing their structure. Structural analysis is part of the Product Architecture Activity. Verify the completeness of your Decision Model using the knowledge gained from performing the Product Architecture Activity.
Derive at least one decision from every variability assumption that the Domain Plan says you are to support. You need not elaborate the answers for a decision if you do not fully understand its range. Instead, you can choose an answer that arbitrarily fixes the decision. The Decision Model, therefore, contains the normal set of decisions an application engineer expects to make when building a work product in the domain. Thus, he can follow a familiar decision-making process.

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 work products and specify constraints that omit these members from the Decision Model.

Risk Management

Risk:

The Decision Model is inadequate for descriptions of existing application engineering work products.

Implication:

The domain will not provide effective support for the targeted project.

Mitigation:

Try to describe one or more existing work products in terms of the Decision Model. Review these descriptions with experienced engineers from the targeted project 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.
Introduce an indexing scheme into the decision groups (or use a more sophisticated one).

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