Paper 108 The Use of Behavioral Diagrams in SysML CSER 2007
Larry Zdanis Robert Cloutier, Ph.D. 1526 Oxford Road, Wantagh, NY 11793 Stevens Institute of Technology [email protected] [email protected]
UML, SysML tailors UML’s basic constructs Abstract to facilitate use of the language for system modeling and for non-software system The definition of behavior in Systems modeling. Modeling Language (SysML) presents special As a language specification, the SysML challenges to systems engineers, as Specification intentionally avoids defining a overlapping functionality exists among process for applying the language. However, a SysML behavioral diagrams. This paper aims SE new to UML and SysML is likely to face to guide the System Engineer (SE) through the confusion during the flexible process of challenges faced in defining a system's defining system behavior for the following behavior via SysML by (1) identifying a set of reasons: (1) a complete set of purposes for purposes for behavior definition, (2) defining system behavior have not been identifying criteria to help the SE decide defined, and (2) overlapping functionality which diagrams to use to satisfy these exists among the behavioral diagrams. purposes, and (3) demonstrating realization of This paper aims to guide the SE in fully these purposes for a sample use case. The defining a system's behavior, without proposed purposes are as follows: defining compromising the flexibility of the process. It activity flow, tracking system state, defining does so by (1) identifying a set of purposes for system control, defining interactions, and behavior definition, (2) identifying criteria to allocating responsibility. help the SE decide which diagrams to use to satisfy these purposes, and (3) demonstrating Introduction realization of these purposes for a sample use case. The Object Management Group (OMG) First presented is a brief overview of the first introduced the Unified Modeling various SysML diagrams to show the context Language (UML) in 1997. UML models of Behavior Diagrams in SysML. An example consist of diagrams which address static and system is characterized to equip the SE to dynamic aspects of a software design. The make good modeling decisions. Six purposes models aid in the design and evolution of the of the behavioral diagrams are defined as software. In 2003 Systems Modeling follows: Narrow Problem Focus, Define Language (SysML) Partners was formed to Activity Flow, Track System State, Define extend the OMG’s UML to address system System Control, Define Interactions, and engineering concerns. SysML v. 1.0a Allocate Responsibility. Achievement of each specification was submitted in 2005 and of purposes is addressed in the remaining adopted in May 2006. As an extension to sections.
Context of Behavior Diagrams
The structure of SysML is shown in Figure 1.
SysML Diagram
Requirement Structure Behavior Diagram Diagram Diagram
Legend Use Block Internal Package Case Diagram New Diagram Definition Block Diagram Type Diagram Diagram Activity Diagram Modified from Parametric UML 2 Diagram Sequence State Same as Diagram Machine UML 2 Diagram
Figure 1. Structure of SysML (Reference: OMG 2006)
The usage of each diagram in Figure 1, Table 1. Usage of SysML Diagrams along with its SysML abbreviation is shown in Table 1. The Requirement Diagram and Diagram Abr Usage Parametric Diagrams are new diagram types Requirements Pillar that don't exist in UML 2. The Activity Defines what the Diagram, Block Definition Diagram, and system should do. May Internal Block Diagrams have been modified include decomposition from UML 2. Requirement and traceability of req The Requirement Diagrams define "What" Diagram requirements, and the system should do. The Structure and allocations of structure Behavior Diagrams communicate "How" the and tests to system will perform the "What". SysML requirements. diagrams provide for traceability of the visual "How" specification to the textual "What" specifications via relationship lines. Requirements Diagrams also express non- behavioral requirements, which are most likely to impact the Structure Diagrams.
Structure Pillar Characterizing System Behavior Defines structure of elements of various A wide variety of behavior exists among Block types, often in systems that can be modelled with SysML. Definition bdd hierarchical form. Understanding these differences will assist the Diagram Elements maybe SE in choosing SysML diagrams and physical or logical. mechanisms that clearly communicate Internal Defines the interfaces behavior. As a first step, the SE should Block ibd and item flows between identify the essential behavioral characteristics Diagram elements. of the system. At a minimum, the SE should Defines equations consider the following: which constrain system Parametric par performance and links • Is the system behavior continuous or Diagram internal parameters to discrete? these equations. Provides a flexible • Will operation of the system involve Package pkg method of grouping significant human interaction? Diagram SysML diagrams. Behavior Pillar • Does the system include controllers? Narrows the focus of If so, are the controllers continuous or Use Case system modeling to a discrete? uc Diagram single scenario at-a- time. • Does the system involve Defines the flow of concurrency? Activity act activity through the Diagram system. • May the system or parts of the system Defines transitions of be characterized as exhibiting state State the system or parts of behavior? Machine smd the system through Diagram discrete states. Providing examples for all system types is Defines a flow of beyond the scope of this paper. Therefore, a Sequence sd messages between single example is used to provide continuity Diagram elements. and to demonstrate the integration of multiple diagrams. This example is a typical Fuel The Structure Diagrams communicate a Pump (FP), operating at retail Gasoline framework which can execute the system's Stations around the world. Using the intended behavior. The Structure of a system considerations presented above, some key FP is defined by its parts, the interfaces between system characteristics are as follows: its parts, and the parametrics which constrain the system's performance. The Behavior • The FP system is primarily a sequence Diagrams communicate the behavior of the of discrete activities such as Swiping system. Behavior Diagrams demonstrates Card, Selecting Fuel Grade, and how the parts of the structure works together Activating the Pump. Fuel flow during to satisfy behavioral requirements. pumping is continuous.
• The FP system requires significant available diagrams to accomplish these human interaction. purposes. Table 2. Purposes of Behavior Model • The FP system will require continuous and discrete controllers. Purpose Title Purpose Decreasing fuel flow upon nearing 1 Narrow To manage complexity by prepaid amount is assumed to utilize Problem Focus focusing on a single continuous control. Computer scenario at-a-time. 2 Define Activity To define what activities are activation of remote pump utilizes Flow performed by the system in discrete control. what order. *2 Track System To track the state of the • The FP system requires State system. straightforward concurrent activities. *2 Define System To define how a system is The following three activities start and Control controlled. stop together: Squeezing Nozzle, Flow 3 Define To define the flow of items of Fuel, Metering of Fuel Interactions between parts of the system. 4 Allocate To define the parts of the • The following states will exist in the Responsibility structure responsible for FP system: Idle, Authorized, Primed, performing each activity Pumping, and Charging. and interaction. Notes:
* These purposes maybe viewed as part of Defining Activity Flow, but are only relevant if the system has The following section explains which states and/or controllers. purposes of behavioral definition are relevant, depending on the system's characteristics. Narrowing Problem Focus
Identifying the Purposes of the Narrowing problem focus is first Behavioral Model accomplished using Use Case Diagrams. A Use Case (uc) is a "focused" scenario through A complete and accurate system which the system's behavior may be modeled. behavioral model will address all of a system's The Use Case Diagram begins the process of essential behavioral characteristics. The activity decomposition at a high level. A purposes of the behavioral model are sample Use Case Diagram for a typical displayed in Table 2. Tracking System State Gasoline Station Fuel Pump is shown in and Defining System Control may be viewed Figure 2. A SE is only required to include as part of Defining Activity Flow. They are Use Cases relevant to their immediate purpose shown as distinct purposes because they are (Booch, 1999). In Figure 2, several Use Cases relevant only if the system has states and/or that would normally exist for a Fuel Pump, controllers, and because the existence of states such as "Regulatory Inspection", have been or controllers adds an extra dimension to purposely omitted. Similarly, only Actors activity flow definition. relevant to the Use Cases being addressed are The manner in which each purpose is included in the uc diagram. achieved will vary with the system's The system of interest, 'Fuel Pump', is characteristics and SE preferences. The enclosed by the subject box. The entities remainder of the paper will suggest some which interact with the system are outside this guidelines in deciding how to utilize the box, connected to each uc in which they
participate by a solid line. The primary 'Get and 'Pay for Fuel'. At this point we have Fuel' uc is extended by three modular Use provided a context for defining activity flow Cases using the <
Fuel Pump - Use Case diagram package 'Behavior Package' {1/1}
'Gas Pump'
'Obtain Authorization'
<
'Get Fuel' <
'Pay for Fuel' Financial Institution <
Maintain 'Initialize Pump' Maintainer Clerk
Figure 2. Fuel Pump Use Case Diagram
making use of Table 3. We first aim to define Starting Activity Flow Definition a high level activity flow. The ad appears to be the best choice for this, as it provides a Activity Diagrams, State Machine simplified depiction of intended flow, with Diagrams, and Sequence Diagrams may all be auto-triggering of control upon completion of used to define activity flow. The strengths each activity. It also provides explicit visual and weaknesses of these diagrams for defining depiction of complex flow, if needed. We activity flow are shown in Table 3. As true in avoid the state machine diagram, which may "Yin-Yang" theory, each of a diagram's be ambiguous in demonstrating the desired strengths may cause weakness in other areas. sequence of flow. This is why multiple diagrams are more powerful than one. We'll now begin to define activity flow for the 'Get Fuel' uc of the 'Fuel Pump' system,
Table 3. Strengths (S)and Weaknesses (W) maybe viewed as a simplified version of a of Diagrams for Defining Activity Flow statement machine diagram, in which each activity represents a different state, and the Activity Diagrams transition from one state to the next is
• Visually explicit depiction of triggered by completion of the immediate complex flow. activity (Bennet 2001). If an ad models an • Simplified depiction of intended operation, it may be viewed as a flowchart of flow, with auto-triggering of control the operation's actions. S upon completion of immediate activity (no event or message required) Get Fuel activity 'Get {1/1} • Mechanism for a control operator Fuel ad' available in SysML o Generally shows only one of W multiple possible sequences of state Obtain Authorization transitions at-a-time.
State Machine Diagrams • Visually explicit depiction of Select Fuel Grade complex flow. • Clear indication of all possible S transitions from each state of the system, subsystem, or element. Pump Fuel • Exhibits same strengths in eliciting
behavior of a controller. No o Standing alone, the desirable Yes W sequence of state transitions may be Paid Upfront? ambiguous. Sequence Diagrams S • Clear depiction of sequential flow. Pay for Fuel o Less visually explicit depiction of complex flow.
W o Awkward for defining high level flow, as it requires allocation of
activity to element
A high-level ad for the 'Get Fuel' uc is shown in Figure 3. The three <
Upon examination of the Fuel Pump's Interactions will define activity flow between characteristics and the ad, it appears most parts of the system. relevant to view this diagram as the inverse of a smd, which emphasizes the flow through a Tracking System State series of states. Recall that the Fuel Pump's behavior consists primarily of a sequence of Tracking System State is important for all discrete activities and exhibits discrete states. systems with states. If the SE is not aware of With this in mind, the next three sections will the current system state, the flow of activity is continue activity flow definition. Tracking uncertain. States are best tracked through System State will demonstrate a smd State Machine Diagrams (smd's). A smd may consistent with the ad above. Defining be drawn for the system being modeled or for System Control will define control activity for any element in the system which exhibits the continuous controller part of the system. various states. Figure 4 displays a smd for the Finally, the sequence diagrams in Define Fuel Pump in the context of the 'Get Fuel' uc.
Fuel Pump smd statemachine 'Behavior Package' :: {1/1} 'Fuel Pump smd'
Credit Card Approved
Debit Card Approved Idle
Clerk Activated
Timeout - Inaction-1 Account Charged & Authorized Receipt Response (No Pressure) Timeout- Inaction-2 Account Charged & Timeout Valid Fuel Selection Cancel Prior Prepaid Am t and Pump Primed to Pump Reached Timeout - Clerk Activation Primed Charging State (Pressure) Credit or Debit Auth - Timeout (No Pressure)
Credit or Debit Auth - Receipt Response
Release Squeeze Nozzle Nozzle Pumping, (Flow)
Figure 4. Fuel Pump State Machine Diagram Figure 4 displays the following five states: walking through a typical 'Get Fuel' uc Idle, Authorized, Primed, Pumping, and scenario, and identifying discrete stages in Charging. We arrived at these states by which the Fuel Pump is expected to behave
differently from other stages. All of the possible transitions between states are shown Pump act activity 'Pump act' {1/1} and labeled. We arrived at the various transitions by considering all the possible operator, clerk, or internal events which may trigger a transition from each state. {stream } The smd could potentially be used to <
Valve Position object is fed to the Pumping continuous linear fashion as remaining Dollars activity. If the Valve closes completely, the to be pumped falls from $1.00 to $0.00. Pre-paid amount has been reached, causing a transition out of the Pump state. Figure 6 reveals the details of the act Meter Flow <
Dollars Pumped
<
Prepaid A mount Dollars Pumped
{ stream } { stream }
Valve Position Prepaid A mount - Dollars Pumped < $ 1.00 ? Yes No Figure 7. Meter Flow Activity Diagram
<
At this point, we have demonstrated high level activity flow definition, including
tracking a system's state, and defining system
control. For the high level activity flow already demonstrated, it remains to define the Control Value interactions between the actors and the system. It also remains to demonstrate interactions between parts of the system Figure 6. Enable Metering Activity (Overgaard, 1999). Table 4 show the Diagram strengths and weaknesses of sequence and activity diagrams for defining interactions. Figure 7 reveals the details of how the Figure 8 shows a sequence diagram. commanded Valve Position is calculated. The Flow Meter signal has been used to tally the Dollars Pumped. Valve Position = 1 - (Prepaid Amount - Dollars Pumped). This formula reveals that the Valve closes in a
Table 4. Strengths (S) and Weaknesses (S) performed by the same elements, spatial of Behavior Diagrams for Defining arrangement becomes awkward. Activity Interactions diagram Data Flow Objects may also clutter a diagram. Sequence Diagrams For these reasons, sd's have been • Cleanly defines sequence of chosen to define interactions for our example interactions as time marches case. The sd's weakness in eliciting complex vertically down the page. flow is a non-factor in this case, since the Fuel • Cleanly defines messages or Pump state transitions involve non-complex S operations along horizontal lines. sequences of activities. Figure 8 elicits the • Allows for depiction of actions activity flow and interactions for each of the performed in-between interactions. possible transitions between the Idle State and • Allows for depiction of element the Authorized State of the Fuel Pump system. states in-between interactions. The appearance of the <
select a fuel grade and transitions the Pump to In the same manner, sd's may be created for the 'Authorized' state; if "disapproved" the the remainder of the transitions, completing Pump sends a message to the Operator the definition of flow activity and indicating an invalid account. If the card was corresponding interactions at the system level "approved", the FP must store how for the 'Get Fuel' uc. authorization occurred in "memory", to properly control behavior later in the flow.
sd Get Fuel /Authorization sd interaction 'Get Fuel / {1/1} Authorization sd'
<
Idle
alt Credit/Debit Card
'Please sw ipe Credit or Debit Card'()
Sw ipe Card Credit Card Inf or mation
alt Approved Approved() Please select fuel grade «»
Disapproved Disapproved() Sorry, Inactive Account
Idle
alt Clerk Activated «»<
alt Prepay Pay ment( ) Prepaid Amt
alt Trust Activated Please activate my Pump Activate()
«» Please select fuel grade <
Figure 8. Authorization Sequence Diagram
of the system, or an external output to another Allocating Responsibility actor. Defining structure is outside the scope Now that system level behavior has been of this paper. However, a few parts will be defined, the next step is to formulate a defined to allow for demonstration of internal structure for the system. The sequence interactions and allocation. These parts diagrams provide a guide for modeling the include a Computer Motherboard (with a structure. To start, we know that the system built-in Network Card and other I/O ports), a needs a component which is able to handle Transaction Display, and a Card Reader. each interaction between itself and an actor These are the only Fuel Pump parts necessary (Friedenthal, 2006). Furthermore, the system to define the internal interactions for the needs the capacity to transform each Authorization activities for the given level. interaction input into the proper output, whether it is an internal output to another part
sd Internal / Card Authorization sd interaction 'Internal / Card {1/1} Authorization sd'
Transaction Display Card Reader Motherboard
Generate Idle Ms g Pleas e sw ipe Ms g
Dis play Ms g on LCD
Pleas e sw ipe Ms g Sw ipe Card Magnetic
Convert Magnetic to Binary
Sw ipe Card Binary
Encrypt Card Inf o
Encrypted Card Inf o
alt Approved Approved()
Process Receipt
Pleas e select fuel grade Pleas e select fuel grade
alt Disapproved Disapprov ed() Sorry, Inac tiv e Account Sorry, Inac tiv e Account
Figure 9. Card Authorization Sequence Diagram
The same diagrams used to define interactions. Notice that "Action Blocks" such external interactions are used to define as 'Generate Idle Message' and 'Convert internal interactions. Figure 9 displays an Magnetic to Binary' have been included on "internal" sequence diagram which conforms some of the lifelines. Those actions which to the external Authorization sd. This sd is don't map directly to system functional simply a decomposition of the 'Fuel Pump' sd requirements would be classified as Derived in Figure 8. The messages coming in-and-out Requirements, as they are lower-level of the Pump from Figure 8 should match the functions required for the system to messages coming in-and-out of Figure 9. accomplish its system-level behavior. Allocations are implicitly performed as part of the process of defining internal
req Card Authorization packag'Requirements {1/1}
Obtain Authorization <
<
<
«» Text= "The fuel pump shall «»Text= "The CardReader contain a device which reads shall convert the a standard magnetic card magnetic pulses to when the card is inserted and digital ones and zeros". removed swif tly."
<
<
<
Figure 10. Card Authorization Requirements Diagram
Along with allocation of actions to interfaces, until each message or flow between structure, interactions must be allocated to components is realized by an interface structure. Interactions are allocated to specification. By tracing through a complete
set of interaction diagrams, and ensuring that the SE on one scenario at-a-time. Activity each flow input and output is allocated to an flow definition may be accomplished through interface, the SE is assured to capture all the various combinations of act's, smd's, and sd's. interfaces. Act's and smd's are better than sd's for Figure 10 shows a Requirements defining complex flows. For systems with Diagram which demonstrates the allocation of states, smd's play a vital role. Ad's are actions and interactions to structural elements preferred for defining continuous control using the <
obtained a M.S. in Mechanical/Aerospace Engineering at the Joint Institute for the Advancement of Flight Sciences (JIAFS), a collaborative between George Washington University and NASA Langley.
Robert Cloutier received his Ph.D. in Systems Engineering from Stevens Institute of Technology. He currently is a Principal Systems Engineer in Moorestown, NJ. He is responsible for developing and modeling architectures for complex systems, and has over 20 years experience in systems engineering, software engineering, and project management in both commercial and defense industries. Rob also has an M.B.A. from Eastern College, and a B.S. from the United States Naval Academy. He is an Industry Fellow at Stevens Institute of Technology and an Adjunct Professor for Eastern University. He is a member of the International Council on Systems Engineering (INCOSE) and active in the Delaware Valley Chapter, an active member of the Association of Enterprise Architects, and is a member of IEEE. Rob also chairs the Rowan University Electrical and Computer Engineering Department Industry Advisory Board.