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 modeling and for non-software system The definition of behavior in 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 . The defining a system's behavior, without proposed purposes are as follows: defining compromising the flexibility of the process. It 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 (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 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 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 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 <> extension. for the 'Get Fuel' uc. These are 'Obtain Authorization', 'Pump Fuel',

Fuel Pump - Use Case diagram 'Behavior Package' {1/1}

'Gas Pump'

'Obtain Authorization'

<> Operator

'Get Fuel' <> 'Pump 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 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 <> Figure 3. Get Fuel Activity Diagram uc's from the Use Case Diagram in Figure 2 If an ad models the flow of activity through a map to activities in this high-level diagram. series of states, it maybe viewed as the The 'Select Fuel Grade' activity has not been "inverse" of a smd, in which the ad designated a uc due to its simplicity. emphasizes transitions between states, while There are different ways of viewing ad's. the smd emphasizes states. In reality, the ad Establishing an ad viewpoint can assist the SE may elicit behavior within a state as well as in effective use of the ad in a particular behavior between states. context. If an ad models a workflow, it

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 <> independently elicit the flow of activity for a Enable Metering uc by showing only those transitions exercised for one instance of the use case. However, this would forfeit the power of the smd to Yes No clearly communicate a series of related information within the same visual space. Moreover, independent elicitation using a smd Meter Flow may contain ambiguities if the same state in {stream } Valve the smd is reached more than once for a Position = 0 particular uc instance. By combining the <> natural ability of the ad or sd to show an Valve Position intended flow with the smd's ability to depict potential transitions, an overall picture of activity flow has been obtained in an efficient manner. Though Figure 3 and Figure 4 define the <> intended flow and all the possible flows at the Pumping system level, they don't dictate which flow variations will be realized for a particular uc Valve Closed instance. These flow variations depend on the 's behavior at each point in the uc. This will be demonstrated using sequence diagrams Release Handle in the "Defining Interactions" section. Figure 5. Pump Activity Diagram Defining System Control The dashed line in Figure 5 represents an Activity flow definition would not be interruptable region; releasing the Fuel Nozzle complete without addressing the activities causes immediate exit of the Pump state. performed by internal controllers. For the SysML's rate is applied to indicate Fuel Pump, the discrete aspects of control Pumping as a <> activity. (such as sending an activation signal to the SysML's <> stereotype is remote fuel tank pump), are easily addressed applied to the Enable Metering Activity, as part of the lower-level sequence diagrams which determines whether or not metering of to follow. The continuous aspect of control, the flow is required. The in which a metering valve is progressively <> is continuous per closed upon nearing a prepaid amount, may be SysML convention (OMG 2006). If metering addressed by elaborating the "Pump" state is required, the Meter Flow activity calculates with an activity diagram. Figure 5 shows an the appropriate Valve Position; otherwise activity diagram for the "Pump" state. Valve Position is set to 0, or wide open. The

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 <> Enable Metering. If the Prepaid Amount minus the Dollars Pumped is less than $1.00, the Control Value is set to Prepaid Amount enable; otherwise, it is disable. This causes Flow Meter the flow to be metered only when nearing the Prepaid Amount.

Dollars Pumped

<> act Enable Metering Calculate Valve Position : 1 - (PrepaidAmount - 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

<> <> Defining Interactions enable disable

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 . 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 <> system Eliciting continuous interaction is W o 'Fuel Pump' and actors as lifeline blocks awkward. indicates this sd elicits external interactions. Activity Diagrams The "alt" construct is used to • Shows interactions in the context differentiate between the 'Clerk Activated' of activities being performed. transition, and the 'Credit/Debit Card' S • Continuous interaction maybe transition. The similarity of the 'Credit Card' demonstrated using {stream} and 'Debit Card' transitions in the smd allow stereotype. them to be addressed together here. The "alt" o Requires usage of swimlanes to construct is also used to differentiate a identify source & recipient successful versus unsuccessful Card elements, which can make spatial Authorization, and two different Clerk arrangement of complex flow Activation alternatives. W awkward. State Symbols are used on the sd to o Requires use of additional object show the connection to the smd. As all the blocks and lines to show item alternatives begin in the Idle State, the "Idle" flow, which can clutter a diagram. state symbol is shown as the first state on the 'Gas Pump' lifeline. At each point in the flow Both sequence and activity diagrams can where a change of state occurs, the new state serve to define interaction as well as activity is indicated on the lifeline. A successful flow, but the sd defines interactions more instance of the 'Obtain Authorization' uc naturally. Sequence Diagrams cleanly define results in the 'Authorized' State. a sequence of interactions as time marches The 'Credit/Debit Card' alternative vertically down the page. They also cleanly begins with the 'Fuel Pump' in the Idle state define messages or operations along sending a message to the Operator to swipe horizontal lines. On the other hand, activity their credit or debit card. The operator diagrams require Swimlanes (to allocate transfers their card information to the FP by behavior) and Data Flow Objects (to show swiping the card, and the FP forwards the messages or operation calls) to define information to a Financial Institution. interactions (Long, 1995). Swimlanes in ad's Depending on the status of the card account, interfere with the ability to cleanly split a flow the Financial institution returns an "approved" for alternate or concurrent activity. If each of or "disapproved" message to the Pump. If the split flow paths include activities "approved", the FP requests the Operator to

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'

<> <> <> Finance Ins t Operator Fuel Pump Clerk

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 «» Authorized Car Authorized

Disapproved Disapproved() Sorry, Inactive Account

Idle

alt Clerk Activated «»<> Prepaid Amt

alt Prepay Pay ment( ) Prepaid Amt

alt Trust Activated Please activate my Pump Activate()

«» Please select fuel grade <> Clerk Authorize Authorized

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 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 <>

<> <> <> CardReaderInterface CardAuthorization Environment <> «» «» Text= "The fuel pump shall Text= "The fuel pump shall 'Text="The CardReader allow self-service operations operate from -20 to 110 shall interface to the degrees Fahre nheit." through the use of a credit or Motherboard." debit card. <> <>

<> <> MagneticReader DigitalConverter

«» 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."

<> <>

<> <> Magnetic Reader Digital Converter_

<> <> CardReader

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 <> construct. Also shown activity. Sd's are preferred for defining is traceability of derived requirements to interactions with actors and internal system requirements. The "Obtain components. Sd's cleanly allocate behavior to Authorization" uc has been used to structural parts and identify messages flow, <> the Card Authorization setting the stage for structural block diagrams, requirement. Modeling of the uc resulted in internal block diagrams, and interface the MagneticReader <> specifications. requirement, and a CardReader <> which <> this derived requirement. References Generation of the Card Reader and Motherboard components led to the creation Bennett, Simon; Skelton, John; Lunn, Ken, of the CardReaderInterface Schaum's Outlines UML Second Edition. <>. This led to the McGraw-Hill Intl, 2001. DigitalConverter derived requirement, and a Booch, Grady; Rumbaugh, James; Jacobson, DigitalConverter component of the Card Ivar, The Unified Modeling Language Reader to satisfy the new requirement. The User Guide. Addison-Wesley, 1999. Card Reader block is also shown as needing to Friedenthal, Sanford; Moore, Alan; Steiner, satisfy a system-wide environmental Rick, "OMG Systems Modeling Language requirement. Tutorial", Object Management Group, July 11, 2006. Conclusions Long, James E., "Relationships Between Common Graphical Representations Used Behavioral Diagrams are a key Pillar of in ", NCOSE the SysML language. Utilizing common Symposium, 1995. visual constructs, they provide a means of OMG SysML Specification, Object visualizing behavior from an actor's Management Group, May 4, 2006 perspective down through a detailed design Overgaard, Gunnar; Bran, Selic; Bock, perspective. They lay the framework for Conrad, "Object Modeling with UML: defining the structure of the system which can Behavioral Modeling Powerpoint execute the intended behavior. Due to the Tutorial", Object Management Group, wide variety of systems which may be 1999. addressed using SysML, no fixed methodology of applying behavioral diagrams Biography is likely to work for all systems. An understanding of the strengths and weakness Larry Zdanis currently works at Northrop of each diagrams should guide the SE in Grumman AEW/EW in Bethpage New York achieving the purposes of the Behavioral as a Systems Software Engineer. He has Pillar. completed the requirements for a M.S. in The Use Case Diagram is primarily Systems Engineering from Stevens Institute of useful in managing complexity by focusing Technology, Hoboken, NJ. In 1997, he

obtained a M.S. in Mechanical/ 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, , and 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 Department Industry Advisory Board.