Be Advised: Classified, FOUO, and PII Content is Not Permitted
This is a reprint (with minor edits for brevity) of a conversation between John Watson, Jim Ciarcia and David Fields in June of 2018 on the SysML Allocation relationship:
From: Ciarcia, James S CIV AIR-4.11.7.5
To: Watson, John
Cc: Fields, David S CIV AD, 4.1.2.1
Subject: Allocation Issues
John,
So I've been trying to really grapple with the Allocate relationship and how useful it really is. I have 2 concerns about Allocate, can you straighten me out where I'm missing the real value add?
1. A big part of SysML is understanding cause and effect when something changes. The standard rule is that the Client side of a relationship is "dependent" on the Supplier side. With Allocate this seams backward. It's the Supplier that is being "AllocatedTo" the Client, which means if the Client changes, we should re-analyze the Supplier of the Allocate relationship?? Doesn't make sense. When allocating Logical Functions to Physical structures, if the physical structure changes, we don't go re-evaluate the logical functions. Maybe we evaluate if the logical function can still be done by the structure... either way, I thought that is what operations and methods assigned to those operations were for.
2. Both Friedenthal, ect. Al. and Deligatti both state that allocate is used as an initial relationship prior to a more defined relationship later. Maybe allocate is equivalent relationship to a 2 step relationship, and a "system reasoner" could automate the creation of the allocation if/when the refinements are added, or create the refinements from the allocations. Aka... create operations and assign methods when an activity allocation to a block has been declared, or visa-versa. Same goes for item flow on connectors. This way you don't have to choose one modeling method over the other.. you get both either way you initially model it. Otherwise this whole concept of allocation may not be worth all the extra effort to train people in it and use it as part of actual architectures, just create the more refined modelling relationships declared in UML. Allocate is not simulatable, executable, and has very weak semantics. Specialization is much stronger and provides similar allocation assignment, like logical to physical architecture mappings. Operation methods and Item Flows on Connectors all are pre-existing in UML and express the same allocation concepts.
Jim Ciarcia
From: John Watson
To: Ciarcia, James S CIV AIR-4.11.7.5
Subject: RE: Allocation Issues
Jim,
This type of question about the allocation relationship has come up often over the years, including by myself. So, here’s how I rationalized it and I hope it helps in this case. This rationalization does get a bit wordy, but I wanted to base it on facts that exist in the specifications and other works, such as Sandy’s book.
The bottom line is allocation is not a true dependency; it is an extension of the UML metaclass called “abstraction”; therefore because of the semantics of abstraction, it does not have to have the client/supplier semantics. It therefore depends on the definition provided in the SysML specification which does not state that it has the client/supplier semantic.
The text below provides a more detailed explanation and better understanding.
1. The supporting UML Semantic Definitions
a. The allocation relationship is defined within SysML and is not part of UML.
b. Although we say the allocation relationship is a dependency it is not directly a dependency, it is an actually derived from the UML metaclass called abstraction. In UML this metamodel element is a specialization of dependency and in the SysML specification the stereotype allocation is an extension of abstraction.
c. The definition of Abstraction is interesting in that it softens the “client/supplier” semantic. Here’s the UML semantics definition for Abstraction:
i. Relates two NamedElements or sets of NamedElements that represent the same concept at different levels of abstraction or from different viewpoints. The relationship may be defined as a mapping between the suppliers and the clients. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. (UML Spec 2.5, section 7.7.3.3)
ii. The notable items from this definition are: (1) An abstraction may or may not be a client/supplier mapping, (2) it may be bi-directional and (3) it may be less formal, for example the mapping between elements and may or may not be computable.
d. One more thing that is worth noting, an example of a UML abstraction is the trace relationship that extends abstraction just as allocation does. The trace relationship’s definition leverages all three notable items. The refine relationship is another example. Here is the UML trace stereotype description. Note it does not use the client/supplier concept.
i. Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal. (UML Spec 2.5, section 22.3)
2. Allocation Relationship in SysML
a. In Systems Engineering we have used the concept of allocation for years. So, the intent of the allocation relationship in SysML is to provide the foundation to capture this basic allocation concept.
b. In general, allocation is a technique of “roughing” out a solution early in the development by simply relating one entity to another. When the allocation is done, it can be verified that all the elements in one view are mapped to another without orphans. Then a process of refinement and iteration can be used to derive a more formal and exact solution.
c. When and where an allocation process is used, and if it is used at all, is dependent on the methodology selected by the program. If the development team feels they have significant experience in a solution or a special tool can automate the process, then they can decide not to use the allocation concept.
d. When the refinement process of the initial allocation is complete, the initial cut of allocation can be kept for historical purposes (via a snapshot of the model), or the initial cut may have morphed into the final solution, or it can be discarded because it has been replaced with the actual solution and there is no longer a need to maintain it.
e. The “Allocate” stereotype definition from the SysML 1.5 specification
i. Allocate is a dependency based on UML::Abstraction. It is a mechanism for associating elements of different types, or in different hierarchies, at an abstract level. Allocate is used for assessing user model consistency and directing future design activity. It is expected that an «allocate» relationship between model elements is a precursor to a more concrete relationship between the elements, their properties, operations, attributes, or sub-classes.
ii. Allocate is directional in that one NamedElement is the “from” end (no arrow), and one NamedElement is the “to” end (the end with the arrow). The Allocate stereotype specializes DirectedRelationshipPropertyPath to enable allocations to identify their sources and targets by a multi-level path of accessible properties from context blocks for the sources and targets.
iii. Notable items: The definition does not mention client/supplier but does mention source and target, i.e. allocation from a source to a target. Also, that allocation is a mechanism for associating elements for future design activity and assessing model consistency, i.e. have all the elements in one view been associated to another or are some not accounted for.
f. The types of allocation presented in SysML relate elements in one abstraction view to another, such as allocation of behavior to structure, or logical structure to a physical structure or allocation of object flows (in behavior) to connectors (in structure). In each case:
i. The concept of allocating a model element in one view to an element to another view is satisfied.
ii. When the relationship is shown on a diagram, the direction of allocation is intuitive from the direction of the arrow.
iii. In the compartment and callout notations it explicitly lists the the elements that are “allocated to” and “allocated from” an element.
iv. If one end of the allocation changes then the element at the other end may or may not be impacted.
g. It is important to note that depending on the specific methodology selected the allocation relationships may or may not be replaced with a stronger relationship as the architecture/design matures. In some methodologies it may be good enough to establish a preliminary allocation allowing for the flexibly of establishing a more detailed constraint later in the development process.
John Watson
To: John Watson
Thank you for the very though and well thought out answer. It definitely weakens my hypothesis about allocations. I think this is perfect for a SysML reasoner to come in and create more refined relationships automatically from allocate as well as reverse engineer more refined patterns into the allocate relationship. The weakening of the allocate relationship directionality needs to be made very clear since a lot of teachers make dependency tracing one of the big selling points of SysML and traversing the arrow backwards is something taught from day 1. Thanks!
From: Fields, David S CIV AD, 4.1.2.1
To: Ciarcia, James S CIV AIR-4.11.7.5; John Watson
John/Jim
We may also want to make sure that this concept, plus it's uses and limitations, are taught in way that doesn't led to more confusion down the road.
One of the first things that caught me off guard when first using SysML was the lack of operations (w/ methods) as way of understanding what parts of the systems performed what functions. Our old tool, via a plugin, automatically created those operations as we developed activity diagrams so I didn't expect to have to go back and manually "allocate" them. It's good to know that's still an option but I don't believe our training covered that at all. I'm not even sure I've seen it in any of the models I've looked at.
David Fields
To: Fields, David S CIV AD, 4.1.2.1; Ciarcia, James S CIV AIR-4.11.7.5
David,
Just to your point about methods in operations, it is all very much up to the methodology you define and the experience level of the folks doing the work. But defining methods in a operation can certainly be done. For example:
1. Define a behavior
2. Initially allocate it to a block. After a number of things have been allocated you may conduct a review to determine if the rest of the team agrees.
3. Later, after some refinement, decide to define an operation in the block and allocate the behavior to it.
4. Later, after more refinement, assign the behavior as the method to an operation. In MD, if there are any input or output activity parameters on the behavior activity, they will appear as parameters on the operation with the correct direction.
5. At this point you could remove any of the previous allocations because they have been replaced by a more formal relationship removing the need to maintain the allocation.
There are a number of alternatives to the above example. For example:
1. Either Step 2 or step 3 could be eliminated
2. If you are very familiar with this type of behavior and structure, you may jump to step 4 without any allocation steps.
3. You may decide that you stop at step 2 because you don't want to overly restrict more detailed design teams later in the development process
Anyhow, again just an example, your methodology should guide you through the steps that would be mandatory and operational.
Hope this helps,