Hidden feature of SysML – Activity Trees
It is very well unknown and I know only a single modeling tool that explicitly supports it: the SysML activity tree. Although it is very useful and supports common systems engineering practice.
What am I talking about? You may know use cases and activities to describe the use case flows. Simply spoken they describe the functions of the system from the user perspective. The following figure shows a use case and the activity of a forest fire detection system (FFDS), The FFDS is the example I often use in this MBSE blog.
 Use case "Detect and report fire" (click to enlarge) |  Use case activity "Detect and report fire" (click to enlarge) |
The activity is a behavioral view of the usage of system functions in a specific context. It is possible that one of the functions is also used in another context, e.g. the function “Warn operator” is also part of the use case “Simulate FFDS operation”.
What’s missiing is a structural view of the system function definitions like the block definition diagram for system parts. And the SysML activity tree is exactly the missing piece. The following figure shows the activity tree of our use case activity.
SysML activity tree (click to enlarge)
The boxes are the activities and the relationship between the boxes describes that an activity is called in the context of the upper activity. Attention: The tree shows a call hierarchy and not a ownership hierarchy. The tree does not show the control flow information you can see in the activity diagram.
Activities vs. Actions
Activities and actions are different model elements in SysML. The activity tree shows the activities (that’s why it is called so). The steps in an activity diagram are actions. A CallBehaviorAction is an action that calls an activity. You find detailed information about the language SysML in my book “Systems Engineering with SysML”.
To get trees of all steps modeled in activities you must create an activity for each action. All actions are CallBehaviorActions. Most modeling tools provide a good workflow to create these elements.
You could extend the SysML activity tree by adding information about the input and output data of the activities. The type of the data is associated with activity in the tree. You can’t differentiate input and output and can’t see the object flow.
SysML activity tree with object nodes (click to enlarge)
The SysML activity tree gives you a very good structural overview about the system functions. Functions are the core of each system. So it is of value to know them well. The FAS method (functional architectures for systems) also uses the SysML activity trees. You find more about FAS on the website www.fas-method.org.
Comments and Questions are welcome.
8 Responses
Hello Mr. Weilkiens,
in Systems Engineering (SE) we call this kind of analysis “Functional Analysis” or “Functional Decomposition” and it is (shall be) an essential step during the design of the system. If properly done (e.g. rule: only one level of decomposition at time), it is able to well describe the functional boundary between the system and its context and drives significantly the physical solution architecture development (functional allocation).
The proven “work horse” of SE in this domain was (and still “is” in some industries) the IDEF0 modeling language. The SysML provides “out of the box” only some limited set of features posessed by IDEF0. In my opinion, IDEF0 provides a mix of semantics of Block Definition Diagram, Internal Block Diagram and Activity Diagrams in respect to functional modeling.
The approach described here is an atempt to conceptually create a “bridge” between the semantics of BDD, IBD and AD to get closer to the level of expression maturity known from IDEF0 diagrams.
Who ever said, that SysML has been already completed?
Mr. Weilkiens, thanks for your continuous contribution to this development!
Best Regards
Piotr Malecki
Hi Malecki,
You may want to look into Vitech’s CORE or GENESYS tools. They will generate an IDEF-0 diagram from the Activity models, or you can model IDEF directly. Stevens Institute of Technology teaches IDEF as part of their Systems Engineering curriculum. http://www.vitechcorp.com/
Hello Mr. Weilkiens,
I am wondering if activity trees could be generated from the set of activity diagrams. Assuming I approach my system top-down, I am starting with use cases (if I need them at the end is a different aspect) and detail them using activity diagrams. As I understand it, activity trees are just a different view to give an overview over functional structure. If I have to create this tree manually, I produce some redundancy that I have to keep up-to-date, don’t I?
I guess that at some point of time, I will start to work in this overview, e.g. when identifying duplicate activities etc.
Have you already tried to automate the creation of activity trees?
A second aspect: when refining the actions with activities, I will also get deeper in system structure. At the some point of time, I will allocate the activities to system components. The view of system breakdown will also grow. Somehow, these two trees are “living” in parallel without 1:1-mapping of nodes (in most cases).
Your blog really is useful input to (my) systems engineering. Thanks for that.:)
Best regards,
Vanessa Klaas
Dear Ms. Klaas,
Yes, you can generate activity trees from activities. All necessary data is already in your repository when you’ve modeled activities. The modeling tool MagicDraw has a so called “Activity Decomposition Hierarchy Wizard” that generates activity trees. As far as I know unfortunately other modeling tools doesn’t support it yet. However I think it is easy to develop a script that does the work for you.
There is one small formal problem with activity trees. The composite association relationship in the trees should be just the notation for the call hierarchy, i.e. there should be NO such association in the repository. If you create the association relationship in the repository it is nearly impossible in practice to keep them in sync with changes in the activity structure.
Your second aspect hits a good point. When refining actions with actitivities you will get at a point where you can’t refine them without architectural/design decisions. You’ll cross a significant border of abstraction levels. You should avoid a 1:1 mapping of your activities to system components on the same abstraction level. See my post about the zigzag pattern to understand what I mean with abstraction levels in this context.
Best regards,
Tim Weilkiens
This is an unrelated question, as I stumbled upon this web page by typing “what is the difference between a behavior and an activity in SysML?” Thus, I will pose the question here. As you mention, there is such a thing as a “Call Behavior”, which ‘calls’ an activity. I think my confusion stems from terminology – why call it a “call behavior” instead of a “call activity” or a “call action”? Behavior is a general term, but this particular SysML entity specifically calls an activity.
Another point of confusion for me is that I often want to draw multiple activity diagrams for a single activity, typically because the behavior is complicated enough to warrant multiple diagrams. I typically want an activity in a high-level diagram to “unfold” into a lower-level activity diagram. Does this mean that I need to make the sub-activities into separate activities and call them from Call Behaviors within the main activity? Or is there a mechanism to link to a “Sub Activity Diagram” that simply opens into a lower-level diagram as opposed to a separate activity?
I realize that some of my questions may be driven by the particular tools I’ve used (Rhapsody, MagicDraw, Astah).
Thanks,
-Jamie
Hi Jamie,
Sorry for the late response. I hadn’t spot your comment in this old post before.
In SysML behavior is a general concept. The SysML activitiy is a special kind of a behavior. As well as the statemachine or an interaction. The CallBehaviorAction typically calls an activity, but could also call a statemachine or interaction.
To decompose a complex activity you typically use CallBehaviorActions. For instance the high level activitiy includes three CallBehaviorActions CBA1, CBA2, and CBA3. Each CallBehaviorAction calls an activitiy that is depicted in another activity diagram.
Does this makes sense to you?
Best regards,
Tim
In the examples above, how did you use the Activity Decomposition Hierarchy Wizard? In other words, for step 1 what did you select: an existing activity, a use case, or did you have to make an “empty” activity called “Detect and report fire” before you started the wizard?
First, the decomposition of activities as shown above are a SysML feature. The wizard you refer to exists for example in the MagicDraw/Cameo modeling tool and can be started on an activity. A few settings can be made below to end up with a bdd with the decomposition.