The Use of Behavioral Diagrams in Sysml CSER 2007
Total Page：16
File Type：pdf, Size：1020Kb
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