Task: Define Decision Model
Synthesis task

Task sourced from Synthesis
Purpose
This task aims to define the decisions that lead to expected differences among the members of a family.

It is an extended version of the original Synthesis task that includes an additional step for dealing with a Decision Models in a tabular format and including new information, like the binding time.

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    		Optional:
      Outputs
        Process Usage
        Main Description

        This task 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.
        Steps
        Identifying Decisions

        Identify the decisions that should be made to resolve all of the variations for a system in the domain.

        You may consider the following heuristics when performing this step:

        •   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.
        •    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.
        •  Keep in mind that the relevant decisions are those concerning system generation time (e.g compile-time, load-time), rather than run-time variation. Your focus 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 runtime behavior, then a valid decision may concern whether or how a particular member varies its behavior.For instance, in MAS we can state that a particular organization can be or not reorganized or auto-reorganized during MAS runtime, as allowed in MOISE.
        •  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.
        Structuring Decisions

        Organize decisions into logically-related and interconnected groups. The goal here is to identify and organize a set of concepts without redundancy or inconsistency.

        You may consider the following heuristics when performing this step:

        •     Each decision group should represent a coherent and cohesive concept. For example, create a decision group for decisions that correspond to features of single and distinct entities. See decision group example in the Decision Model work product.
        •    Group together decisions that repeat. For example, if you need to describe multiple types of a particular device, one  may make similar decisions for each type. You can group these decisions to create a single concept as a focus for decisions.
        •   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.

         
        Identifying Decision Constraints

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

        A structural constraint is a decision constraint that limits the number of instances of a decision group in a product. In other words, it represents instance cardinality. 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.

        You may consider the following heuristics when performing this step:

        • Define a structural constraint for each decision group; specify limits on when the group can validly occur in a product.
        • 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 that imply family members that do not exist. You should examine existing systems and specify constraints that omit these members from the Decision Model.

         
        Extending Decision Model in a Tabular Notation

        Specify decision group; specify decision binding time


        Illustrations
        Examples
        Key Considerations
        The purpose of this Medee Task Variability is to extend  Synthesis task in order to define Medee Basic role. Moreover, it replaces original work products by the related Medee Work Products.
        More Information
        Supporting Materials