UML/SysML provides four diagrams that express the functional and dynamic behavior of a system:
• Use Case Diagram
• Activity Diagram
• Sequence Diagram and
• Statechart Diagram
Although each diagram focuses on a specific behavioral aspect, the information provided by these diagrams overlap each other. For instance, both the sequence diagrams and the activity diagrams describe interactions. There may also be an overlap between the behavior captured in activity diagram and the statechart diagram, since SysML extended the UML activity diagrams by adding the notation of dynamic behavior (control of actions).
In order to minimize the overlap between the different behavioral diagrams, decisions should be made upfront, which role the individual diagrams should play in the context of the modeling workflow. The next step should be to “standardize” the usage of diagram elements by filtering-out in each diagram those elements that are considered essential.
ParD_TotalMass
itsNewtonLaw:NewtonLaw
1 «ConstraintProperty,ConstraintBlock»
force = mass * acceleration
force:Newtons mass:Kg acceletation:MetersPerSec^2 force «Attribute» mass «Attribute» acceleration «Attribute» BDD_MassConstraints NewtonLaw «ConstraintBlock» Constraints
force = mass * acceleration
Attributes
mass:Kg force:Newtons
Fundamentals of Harmony for Systems Engineering
2.3.3.1 Use Case Diagram
A Use Case Diagram captures the functional requirements of a system
by describing interactions between users of the system and the system itself. Note that as a system is decomposed, users of a given system could be external people or other systems. A use case diagram comprises a system boundary that contains a set of use cases. Actors lie outside of the system boundary and are bound to use cases via associations.
A use case describes a specific usage (“operational thread”) of a
system:
• the behavior as perceived by the users (actors) and
• the message flow between the users and the use case.
A use case does not reveal or imply the system’s internal structure (“black-box view”).
Fig.2-25 Use Case Diagram
When use cases get too complex, dependencies between use cases
may be defined:
• <<include>>
One use case includes another
• <<extend>>
One use case provides an optional extension of another
2.3.3.2 Activity Diagram
An Activity Diagram is similar to the classic flow chart. It describes a
workflow, business process, or algorithm by decomposing the flow of execution into a set of actions and sub activities joined by transitions and various connectors. An activity diagram can be a simple linear sequence of actions or it can be a complex series of parallel actions with conditional branching and concurrency.
NOTE: In Harmony for Systems Engineering the terms activity, action
and operation are synonymous.
Actions may be grouped and assigned to objects – e.g. subsystems. In this case, the activity diagram is split into swim lanes that depict the
respective responsibilities.
NOTE: Harmony for Systems Engineering uses a SysML activity pin stereotyped ActorPin to visualize the interaction of an action/operation
with the environment. The name of the pin is the name of the associated actor, the arrow in the pin shows the direction of the link.
Fig.2-26 Activity Diagram
UCD_SuD SuD pSS1_3 A2 A1 Uc2 Uc1 SuD pSS1_8 A2 A1 Uc2 Uc1 SuD A2 A2 A1 A1 AD_Uc2 op1 A1 [C1] op2 [C1] op3 op4 [else] [else] op7 A2 op6 op5
Fundamentals of Harmony for Systems Engineering
2.3.3.3 Sequence Diagram
Sequence Diagrams elaborate on requirements specified in use cases
and activity diagrams by showing how actors and blocks collaborate in some behavior. A sequence diagram represents one or more scenarios through a use case.
A sequence diagram is composed of vertical lifelines for the actors and blocks along with an ordered set of messages passed between these entities over a period of time.
• Messages are shown as horizontal lines with open arrows between
the vertical object lines (lifelines).
NOTE: UML/SysML differentiates between synchronous and asynchronous messages. In Harmony for Systems Engineering the message-based communication is described via asynchronous
messages (two-line arrowhead).
• Operations are depicted as reflexive (synchronous) messages (full
arrowhead) at associated lifelines.
• Quality of Service (QoS) requirements may be added as comments
and/or constraints.
2.3.3.4 Statechart Diagram
A Statechart Diagram describes the state-based behavior of a block.
In the Harmony for Systems Engineering workflow it is considered the most important behavior diagram, as it aggregates the information from both the activity diagram (functional flow) and the sequence diagrams (interactions with the environment), and adds to it the event- driven block behavior. As the “language” of statecharts is formally defined, the correctness and completeness of the resulting behavior can be verified through model execution.
Statechart diagrams are finite statemachines that are extended by the notation of
• Hierarchy
• Concurrency
Basically, a statechart diagram is composed of a set of states joined by transitions and various connectors. An event may trigger a transition from one state to another. Actions can be performed on transitions and on state entry/exit
Fig.2-28 Statechart Diagram
SCD_Uc1Ctrl S1 op1 S2 S213 A21 S211 tm(5)/op4 [C1==true]/op3 ev2 S212 [else]/op5 ev1 setStatus to pA1 S22 tm(10) /op2 reqDeactivateS2 reqActivateS2 ev1 tm(5)/op4 [C1==true]/op3 ev2 [else]/op5 tm(10) /op2 reqDeactivateS2 reqActivateS2 SD_Uc1_Sc1 parallel parallel parallel itsA1 itsUc1 C1==true op1() reqActivateS2() op2() setStatus() op3() op4() reqDeactivateS2() op1() 5 ms op1() op1() 10 ms Interaction Operator