Modeling Cross-Cutting Relationships with Allocations

Allocation = mechanism to relate model elements (build relationships); useful for system of systems (SoS); supports allocation of behavior, structure and properties; functional allocation = allocation of activities to blocks;

Allocation relationship = between any named model elements; Model element A is allocated to Model element B when from-end of allocation relationship is A and to-end is B;

 

Notation

[1] List four ways that allocations can be represented on SysML diagrams. Allocations can be noted using tabular or graphical; graphical notations are: direct notation, compartment notation and callout notation. [2] Which kinds of model elements can participate in an allocation relationship in SysML? These are the 4 types of allocation notations and example model elements:

 

 

Types of Allocations

[4] List and describe three uses of allocation in SysML that rely on the allocate relationship.

[3] Is the allocate relationship appropriate to use when allocating requirements?Requirement Allocation = mapping source requirements to other derived requirements or mapping requirements to other model elements that satisfy the requirement;

Behavioral allocation = segregates behavior from structure; models of behavior (aka models of functions) are separated from models of structure (models of form); allocates elements of behavioral models (activities, actions, states, object flow, messages, etc) to elements of structural models (blocks, properties, parts ports connectors, etc).

Functional allocation = subset of behavioral allocation but specifically for allocating activities or actions to blocks or parts.

Flow allocation = allocate flows (object flows between action nodes on activity diagram or item flows between ports or parts on IBD) between activity diagrams and IBD

Structural allocation = allocates elements of one structural model to another structural model (examples like logical-physical allocations where abstract level blocks are mapped to concrete level blocks; another example is software-hardware allocation).

 

 

Specifying Definition and Usage in Allocation

Definition = model element that is a classifier or type such as a block;

Usage = identifies a defined element in a particular context; common convention is that Usage names are lowercase and Definition names start with uppercase;

  [6]

[6]

[6] For each of the following allocation relationships, indicate whether they are allocation of definition or allocation of usage:

  1. action node (on activity diagram) to part (on internal block diagram) = allocation of usage
  2. activity to block = allocation of definition
  3. object flow to connector = allocation of usage

Allocation of usage = both “from” and “to” ends of allocation relationship relate to usage of elements (parts, actions, connectors)

Allocation of definition = both “from” and “to” ends relate to elements of definition (blocks, activities, assocations)

Asymmetric allocation = when one end is element of definition and other end is of usage; not generally used as it can introduce notational ambiguity;

 

[5] For each of the following kinds of diagrams, indicate whether they are diagrams of usage or diagrams of definition:

  1. activity diagram = diagram of usage
  2. block definition diagram = diagram of definition
  3. internal block diagram = diagram of usage
  4. parametric diagram = diagram of definition

Diagrams of Usage = internal block diagram or activity diagram

 

[7] What is the significance of choosing an allocation of definition instead of an allocation of usage?

 

 

Modeling Functional Allocation of Usage and Functional Allocation of Definition

Functional allocation of usage (action to part) should be used over functional allocation of definition (activity to block) when each action is allocated to parts that are typed by different blocks.

  

 

 

Allocate Activity Partitions = special type of activity partition noted with <<allocate>> in activity diagram; implies an allocate relationship between any action node within the partition and the part represented; explicitly depicts allocation of usage only;

 

 

 

Connecting Functional Flow with Structural Flow using Functional Flow Allocation

Flow between activities can be control or object flow; allocation of control flow depicted similar to allocation of object flow; flow allocation typically an allocation of usage because model elements involved usually context usage.

On BDD there are item flows; can have associated item property; [8] Should an object flow ever be allocated to a block? Explain your answer.

 

 

 

Modeling Allocation between Independent Structural Hierarchies

 

 

Examples show allocation from the logical layer to the physical layer; any item flow on the logical connector should be allocated to multiple item flows in the physical structure. Figure 13.17 is an allocation of usage because its focusing on the connectors; in Figure 13.19 this is allocation of definition as it focusing on the blocks:

 

 

Abstract layer item flow can be common at the concrete / physical level in IBD; Abstract level item flows maybe decomposed into more details at the physical level;

Quality of a model can be assessed in terms of the completeness and consistency of the allocation relationships; in functional allocation – said to be complete when each activity has an allocation relationship to a block elsewhere in the model; consistency involves checking for circular allocations, redundant allocations and removal of inappropriate allocations;

 

[10] The following questions apply to Figure 13.20 :

a Are the item flow names shown on the block definition diagram? Explain.

  1. Why is there no direct allocation shown on the block definition diagram?