Be Advised: Classified, FOUO, and PII Content is Not Permitted
You are currently reviewing an older revision of this page.
SysML 101 classes usually do not cover UML operations in the depth they deserve. I quickly put together a Cameo model to show how this feature is extremely useful for implementing behavioral abstraction, such as Activities, just like the Generalization relationship does for structures, such as Blocks. People familiar with object oriented programming are very familiar with this concept and understand that it is the key to how software was able to scale and modularize to be as ubiquitious as it is today. Each new software program did not have to recode every line, programs were written using the equivalent of UML operations to allow other programs to reuse and adapt existing code. That is what it can do for SysML model reuse as well.
Operations are a feature of a UML class that can be invoked in much the same way that behaviors, such as Activities, can be. The biggest difference is that Activities can be called in any Context, where Operations can only be called in the Context of the Class they are declared on. In the example model, TestNormalDispatch, TestDynamicDispatch, and PotentiallyDispatchingCalls are all plain vanilla activities. TestNormalDispatch and TestDynamicDispatch, since they don't have input parameters can be invoked directly by CameoSimToolkit or any fUML based simulation engine. PotentiallyDispatchingCalls can not be, since it requires an input parameter of type "General".
In our model there are actually 2 classes that are of type "General", the General class and the Specific class, since Specific specializes General.
What does it mean for the Specific class to specialize the General class using the Generalization relationship? The General class has 3 features, 1 structural property and 2 behavioral properties. The Specific class inherits all of these features via the Generalization relationship. In fact, if Specific did not "redefine" them, then Specific would be an exact copy of General. Not only does Specific redefine the y value property, it also redefines the Hello and Goodbye operations, which is called method overriding and is required for dynamic dispatching to work.
https://en.wikipedia.org/wiki/Method_overriding
The PotentiallyDispatchingCalls activity invokes the Hello and Goodbye operations, called CallOperationAction. Since the General class has methods assigned to these Operations, when an Instance of a General class has Hello operation invoked, then the method assigned, HelloGeneric, gets invoked. But why go through this complicated process? Why not just perform a CallActivityAction on the HelloGeneric activity directly? This is where the power of dynamic dispatching comes into play. Since Specific is a specialization of General, and it redefines the Hello operation with a different method, HelloSpecific, when Hello is invoked on an instance of Specific, HelloSpecific will be called instead of HelloGeneral. This is exactly what happens when TestDynamicDispatch gets run instead of TestNormalDispatch.
https://en.wikipedia.org/wiki/Dynamic_dispatch
GoodbyeGeneric and GoodbyeSpecific work in exactly the same way, but this time actually read the "y" structural feature. In fact, GoodbyeSpecific is even able to reuse GoodbyeGeneric in order to access the "y" property. Note that "spam" is printed when an instance of Generic is passed to PotentiallyDispatchingCalls, but "ham eggs" is printed when specific is passed to PotentiallyDispatchingCalls. So not only were we able to change the behavior invoked, we also changed the data that was returned from the read of "y" because we redefined it.
We now have a reusable class, Generic, that defines which activities can be executed by any subtype of Generic. We can leave the details of how those activities are executed to the more Specific classes. All the invoking behavior cares about is whatever actual class is used in the higher level activity is able to perform.
As we model more taxonomies of aircraft and other military materiel systems, we will find that we want to show our customers different levels of fidelity of the descriptions of each system. Generalization lets use do this not only for structural features( value properties, parts, ports and reference properties), but behavioral features (operations and signal receptions) as well but only if we use operations and calloperationactions! This is why operations are in UML/SysML and behavioral reuse can not be modelled correctly any other way.