\chapter{Evaluation}
\label{chapt:Evaluation}

In this chapter, we first compare our solution to YAKINDU, studying its semantics and overall feature-set. Next, we demonstrate 2 example models, implemented in SCCD and YAKINDU, and discuss the chosen semantic options for those models. Finally, we discuss some generally applicable insights obtained through implementation of the example models.

\section{Comparison study: YAKINDU}

YAKINDU Statechart Tools \cite{yakindu} is a well-known open-source tool for statechart development. It features a graphical interface for editing and simulating statechart models, and can compile models, generate optimized code for Java, C, and C++. It also features an advanced model testing framework.

In this section, we first study YAKINDU's semantics and attempt to describe them as a BSML. We then compare YAKINDU's features to SCCD.

\subsection{YAKINDU's semantics}

YAKINDU features some semantic variation points, although fewer than SCCD. We discuss each of the variation points and map them onto BSML.

\begin{table}
\centering
\small
\begin{tabularx}{\textwidth}{ | X | c | c | }
% \hline
% & \multicolumn{2}{c|}{YAKINDU} \\
\hline
& \textbf{Cycle-based} & \textbf{Event-driven} \\
\hline
Big-Step Maximality & \textsc{Take One} &  \textsc{Take Many} \\
                    & superstep:  \textsc{Take Many}     &           \\
\hline
Combo-Step Maximality & - &  \textsc{Combo Take One} \\
                      &   & superstep:  \textsc{Combo Take Many}           \\
\hline
Input Event Lifeline & \textsc{Present in Whole} & \textsc{Present in First Combo Step} \\
\hline
Internal Event Lifeline &  \textsc{Present in Remainder} &  \textsc{Combo-Queued} \\
\hline
Priority & \multicolumn{2}{c|}{ \textsc{Hierarchical} (\textsc{Source-Parent} or \textsc{Source-Child}),  \textsc{Explicit}} \\
\hline
Order of Small Steps & \multicolumn{2}{c|}{ \textsc{Explicit}} \\
\hline
Memory Protocol & \multicolumn{2}{c|}{ \textsc{Small Step}} \\
\hline
Concurrency & \multicolumn{2}{c|}{ \textsc{Single}} \\
\hline
\end{tabularx}
\caption{Semantics of YAKINDU}
\label{tab:yakindu_as_bsml}
\end{table}

\subsubsection{Cycle-based and event-driven execution}

At the very highest level, the modeler can choose between 2 execution algorithms: \emph{Cycle-based} and \emph{event-driven} execution. From the viewpoint of BSML, each algorithm represents a set of choices for several semantic options.

With \textbf{cycle-based execution}, the statechart responds at regular intervals to a set of simultaneously enabled input events, by performing a \emph{run-to-completion step} (RTC step). During an RTC step, every region (YAKINDU's term for an Or-state) may fire a single transition. Internal events raised during transition execution are simply added to the set of enabled events of the current RTC step, for the remainder of unfired regions to possibly respond to. When no more transitions can be made, the RTC step is complete.

These semantics clearly map onto BSML. An RTC step here is a big-step, if we choose the semantic options Big-Step Maximality: \textsc{Take One}, Input Event Lifeline: \textsc{Present in Whole} and Internal Event Lifeline: \textsc{Present in Remainder}.

With \textbf{event-driven execution}, the statechart performs an RTC step immediately for every raised input event. As a result, during every RTC step, exactly one event is enabled. The semantics of the RTC step itself are similar as with cycle-based execution, as every region is allowed to fire a single transition. Internally raised events, however, are not added to the set of enabled events of the current RTC step, but are put in a FIFO-queue of internally raised events. When the RTC step is over, another RTC step is immediately executed with as input the next event in the queue (giving higher priority to internal events than input events). This is repeated until the queue is empty.

These semantics do not map perfectly onto BSML. A ``close'' semantic configuration is when we treat RTC steps as combo-steps: Big-Step Maximalty: \textsc{Take Many}, Combo Step Maximality: \textsc{Combo Take One}, Input Event Lifeline: \textsc{Present in First Combo Step} and Internal Event Lifeline: \textsc{Present in Next Combo Step}. However, this configuration will accumulate all internally raised events of combo step $n$ into enabled events of combo step $(n+1)$ (combo steps possibly having multiple simultaneously enabled events), as opposed to YAKINDU's semantics of starting a ``combo'' step per enabled event.

SCCD has an Internal Event Lifeline option called \textsc{Queue} which somewhat resembles YAKINDU's event-driven execution. It appends internally raised events to the global (external to the statechart) event queue, but this causes them to be potentially handled after certain input events (if those input events have the same timestamp as the internal events, and pre-existed in the queue). YAKINDU, on the other hand, gives priority to internally raised events, by maintaining a separate queue for them.

Let's invent a new Internal Event Lifeline option for YAKINDU, called \textsc{Combo-Queued}, queueing internal events and handling them in FIFO order, one event per combo step. This option combined with the other options from our ``close'' configuration accurately describes YAKINDU's event-driven execution semantics.

\subsubsection{Superstep semantics}\label{sec:superstep}

Another semantic option, altering the behavior of RTC steps is the \emph{superstep} option (to be included in their next release, version 4.0). Enabling this option allows regions to fire as many transitions per RTC step as they can. We did not test the precise semantics of this option, but from the execution pseudocode in the documentation\footnote{https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/sclang\_definition\_section\#sclang\_superstep}, it seems that RTC steps use \emph{fairness}, giving other regions a chance to fire a transition before the same region is given a chance again.

Mapping this option to BSML, for cycle-based execution, this changes Big-Step Maximality from \textsc{Take One} to \textsc{Take Many} (with fairness). Other semantic options remain the same.

For event-driven execution, we still handle one event per combo step, but a single event may now cause more than one transition to fire in the same region, so \textsc{Combo Take One} becomes \textsc{Combo Take Many} (with fairness). Other semantic options remain the same.

\subsubsection{Child/parent first}

For every statechart in YAKINDU, a choice must be made between the \emph{parent-first} or \emph{child-first} execution. There is no need to explain these options, as they simply map onto BSML's \textsc{Hierarchical} Priority options: \textsc{Source-Parent} and \textsc{Source-Child}.

\subsubsection{Explicit outgoing transition priority}

In order to avoid non-determinism, the outgoing transitions of a state always have an explicit priority relative to each other. If a state has multiple outgoing transitions, this explicit priority is graphically displayed as a number on every transition. The outgoing transitions' relative priorities are part of the syntax, and can be edited for every state. This behavior trivially maps onto Priority: \textsc{Explicit.}

\subsubsection{Explicit region order}

In YAKINDU, regardless of the rest of the execution semantics, regions get a chance on-by-one to fire a transition. Just like the order of outgoing transitions, the order in which regions are allowed to fire transitions, is an explicit part of the syntax, i.e. left-to-right, top-to-bottom in the graphical layout of the statechart. In BSML, this would be considered the option Order of Small Steps: \textsc{Explicit}.

The combination of hierarchical priority, explicit outgoing transition priority, and explicit region order yields a total ordering on all transitions in the statechart, yielding fully deterministic behavior.

\subsubsection{No memory snapshots}

YAKINDU does not feature memory snapshot semantics, like SCCD: Transitions always have direct read/write access to a statechart's variables. 

This behavior maps onto the \textsc{Small Step} options for (Enabledness / Assignment) Memory Protocol of BSML.

\subsubsection{No concurrency}

YAKINDU features no concurrency semantics.

\subsubsection{Summary}

YAKINDU offers only 3 semantic choices, with 2 options for each: cycle-based vs. event-driven execution, superstep semantics (off/on) and parent-first vs. child-first hierarchical priority.

YAKINDU's semantics map well onto BSML, if we invent a new Internal Event Lifeline option \textsc{Combo-Queued}. Table \ref{tab:yakindu_as_bsml} shows the semantic options available in YAKINDU. By implementing the \textsc{Combo-Queued} option in SCCD, it would support all of YAKINDU's semantics.

\subsection{Comparison to SCCD}

Despite its narrower set of semantic options, YAKINDU offers many more features than SCCD currently does. We will give an extensive overview of YAKINDU features NOT (yet) implemented in SCCD. They may serve as inspiration for future development efforts.

\subsubsection{Graphical statechart editor}

Statecharts are a visual, topological language. The inclusion of a graphical editor is a requirement for any serious statechart development. 

YAKINDU includes such a graphical editor. For SCCD, the intention is to eventually include a graphical editor as well, preferably modeled as a statechart itself.

Because of the burden of editing statecharts in XML format, SCCD does include a script (based on the NodeJs script state-machine-cat\footnote{https://github.com/sverweij/state-machine-cat}, which again is based on GraphViz\footnote{https://graphviz.org/}) that renders XML statechart files as SVG images. This has been a great help during development of SCCD, as many test files had to be maintained in XML format. Visualizing them quickly made their state hierarchy apparent.

The quality of the rendered images varies. GraphViz, the rendering backend used, can automatically generate appropriate layouts for graph data (the SCCD XML statechart format contains no layout information), but does not natively work with hierarchical graphs (or higraphs, as Harel \cite{harel1987statecharts} called them), so a workaround is used. This workaround sometimes causes rendered statecharts to look weird. Figure \ref{fig:hit_or_miss} shows 2 examples of rendered statecharts.

\begin{figure}  
  \centering
  \begin{subfigure}[t]{0.5\textwidth}
    \centering
    \includegraphics[width=0.7\textwidth]{statechart_fig9_trafficlight}
    \caption{traffic light}
  \end{subfigure}%
  \begin{subfigure}[t]{0.5\textwidth}
    \centering
    \includegraphics[width=0.7\textwidth]{statechart_priority_hierarchical}
    \caption{test file for hierarchical priority semantics}
  \end{subfigure}
  \caption{Examples of SCCD statecharts automatically rendered from XML}\label{fig:hit_or_miss}
  Quality of the result can be a hit-or-miss.
\end{figure}

It should also be noted that a graphical editor such as YAKINDU's puts somewhat of a burden on the modeler to choose a useful statechart layout. Especially for large statecharts with many transitions, this can be a nontrivial task, as transition labels tend to overlap with each other and with other parts of the statechart. Perhaps a hybrid approach, where the modeler is only concerned with the topology of the statechart, and possibly with layout decisions at the highest level, and the editor assisting by making (small) layout decisions, would work best.

\subsubsection{Interactive debugging}

YAKINDU can simulate and debug statechart models in its graphical editor, highlighting current states and allowing the modeler to enable input events interactively.

\subsubsection{Syntactical constructs}

YAKINDU features some syntactical constructs that SCCD does not have. Some of these can be considered syntactic sugar, while others add features to the language:

\begin{description}
  \item[Synchronizations] There are 2 types of synchronizations:  The first type can be understood a transition with multiple source states, where the sources have to be orthogonal to each other. This type expresses a transition that can only be taken if several orthogonal parts of the statechart are in a specific configuration. The source states are exited, and a the target is entered in a regular fashion.

  The second type can be understood as a transition with multiple target states, where the targets have to be orthogonal to each other. This type expresses a transition that sets up a specific configuration for several orthogonal parts of the statechart. With this type, the source state is exited in a regular fashion, and the target states are entered.

  Figure \ref{fig:synchronizations} shows both types of synchronizations.

  Synchronizations are not syntactic sugar and not supported in SCCD. SCCD does feature the \texttt{in\_state} function (which is also supported in YAKINDU), where e.g. a transition's guard can check if another state (in any region) is part of the configuration. This can replace the first type of synchronization. There is no trivial replacement for the second type.

  This feature also exists in Statemate \cite{harel1996statemate} and Rhapsody \cite{harel2004rhapsody}, where it is called \emph{join} (type 1) and \emph{fork} (type 2).

\begin{figure}  
\centering
\includegraphics[width=\textwidth]{synchronizations}
\caption{Synchronizations in YAKINDU.}\label{fig:synchronizations}
Figure taken from {https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/sclang\_graphical\_elements}
\end{figure}

  \item[Choice-pseudo states] Syntactic sugar: a transition, possibly with a trigger, to a choice-pseudo state splits into several transitions, also with triggers, and actions. The same effect can be achieved by creating separate transitions with the combined triggers and actions from the part before and after the choice pseudo-state. This construct is used a lot in practice, and helps decluttering the visual representation of the statechart.

  \item[Named entry- and exit-points] In YAKINDU, the modeler can specify multiple named ``initial'' states, called named entry points. A transition to a composite state can specify the name of the entry to be taken. Likewise, a transition from a composite state can specify the name of the exit-point that should be taken. Entry- and exit-points are pseudo-states, as they are never part of the configuration. This feature gives composite states an \emph{interface}, making them reusable into different statecharts or different parts of the same statechart. The same functionality can be achieved by setting the source or target of a transition directly to a composite states's inner state, but this breaks the composite state's encapsulation. Currently, YAKINDU does not support composable statecharts (this feature is planned for version 4.0). Reused states would probably be \emph{inlined} in the compiled model. For this reason, this feature can be considered syntactic sugar.

  Another statechart-like formalism that supports (or rather, forces) encapsulation of composite states through explicit entry- and exit-points is ROOMcharts, part of the ROOM modeling language \cite{selic1996real}.

  \item[External variables] As an alternative to input/output events and synchronous function calls (called operations in YAKINDU), a statechart in YAKINDU can interact with its environment by reading or writing external variables, i.e. variables that are readable or writable externally. This feature can be mimicked by writing getter and/or setter operations, but direct access to variables may have a smaller overhead.

  \item[Every-trigger] This is a timed trigger (like an after-trigger). An every-trigger becomes enabled at fixed intervals in time. This construct can be considered syntactic sugar, as it can be modeled with a self-transition with after-trigger as well.
\end{description}

\subsection{Unit-testing framework}

YAKINDU has a very powerful unit-testing framework. YAKINDU has its own textual language for specifying tests. It features white-box testing (checking if certain states are active), and allows the modeler to write multiple scenarios for the same model, each scenario raising events, checking states and waiting at will.

SCCD currently only has a black-box testing framework, where every test includes only a single scenario of timed input events and expected output events. This approach was sufficient for working with artificial statecharts, specifically modeled to show different behavior under different semantics. For serious statechart development however, a framework like YAKINDU's is highly desirable. SCCD tests are also written in an XML format, which is not very convenient (to read or to write).

\subsubsection{Code generation}

An important feature of YAKINDU that our version of SCCD currently does not have, is statechart compilation (code generation). YAKINDU has several code generators, currently supporting C, C++ and Java, and support for more languages is on its way.

According to the documentation, YAKINDU's generated code does not take care of scheduling, timers, input event queueing, thread-safety or memory management. The generated code primarily exposes a function to execute, in BSML terms, a ``big-step''. This is very similar to the implementation of the statechart language part of SCCD. Scheduling and input event queueing are implemented in the Controller; timers and thread-safety are implemented in different classes of the ``realtime''-library. As opposed to YAKINDU's generated code, statechart execution does dynamically allocate memory, as the action language's stack frames are allocated on Python's heap. YAKINDU's action code simply uses the current thread's stack instead for temporary variables. We could do the same if we compiled our action code.

Generated code is well optimized. From studying the generated C code of a simple model, it was observed that YAKINDU stores its set of current states as an array of the configurations of orthogonal regions. The configuration of each region is stored as the state ID (as integer) of the deepest child that is a current state. This is a more compact representation than the bitmap representation used by the SCCD runtime. Transitions are always selected based on the current set of states in the configuration, by switch-case statements over the configuration of each region. The code generator can be configured to inline many types of functions.

YAKINDU's code generation approach may serve as inspiration for a future SCCD code generator. It would be an interesting endeavor to develop a code generator supporting the wide semantic variation of SCCD (or substantial subset thereof).

\section{Example models}
% SIMON: Deze sectie zou wat gedetailleerder mogen. Sowieso zou ik voor Yakindu/SCCD de architectuur van de oplossingen laten zien (verschillende componenten, libraries, execution platforms) en waar de "calls" zitten (function calls, externe events, etc.). Ook de interface van elke component zou beschreven moeten worden. Als er iets toegevoegd werd aan SCCD zou je daar een snippet van moeten laten zien.

% SIMON: Het is omgekeerd: de SCCD modellen waren eerst.
2 ``example'' statechart models are included with the SCCD project: \textbf{Digital watch} and \textbf{chat client}. They were adapted from solutions to homework assignments for the ``Modeling of Software-Intensive Systems'' course\footnote{http://msdl.cs.mcgill.ca/people/hv/teaching/MoSIS/} at the University Of Antwerp. With each assignment, a set of requirements was given, and an interface to interact with a piece of software (also given) implementing/simulating the rest of the system.

Both examples are similar, in that they were both intentionally designed to encourage maximal usage of statechart language constructs, such as timed transitions and history states.

The examples were also implemented in YAKINDU, and the YAKINDU solutions would have the exact same statechart structure, apart from some usage of YAKINDU's syntactic sugar, such as choice-states. In YAKINDU, the same semantics were always used: event-driven execution and parent-first priority. In SCCD, the default semantics (which are similar to YAKINDU's event-driven semantics) would yield a correct model, but for each example, the semantics were manually set to more ``restrictive'' options, which will be motivated.

\subsection{Digital Watch}

The digital watch example\footnote{http://msdl.cs.mcgill.ca/people/hv/teaching/MoSIS/201314/assignments/Statecharts/} is a controller for a (hardware) digital watch with 4 physical buttons, a time display, a chronometer display, an alarm display, an editing mode for setting the time and alarm, and backlighting.

\begin{figure}
\centering
\includegraphics[width=0.25\textwidth]{dwatch}
\caption{Screenshot of digital watch demo application}\label{fig:dwatch}
\end{figure}

\subsubsection{Interface}

The ``hardware'' and some other functionality is implemented as a GUI application in Python/TkInter (Figure \ref{fig:dwatch}). The statechart interacts with the Python code by calling synchronous operations on it, and the Python code may also send events to the statechart.

The Python code / ``hardware'' also has some \textbf{state}, in principle the following ``variables'':
\begin{itemize}
  \item The value of the current time, as hours, minutes and seconds. The current value is this variable is drawn to the display only when requested by the statechart.
  \item The value of the current alarm, as hours and minutes. Similar to the current time.
  \item The value of the chrono, as minutes, seconds and $1/100$ seconds. Similar to the current time.
  \item A flag, shown or not shown on the display, to indicate whether the alarm is active. The flag is only a display property and has no further effect.
  \item Whether the display background light is on or off.
  \item Whether selection mode is active, on what ``variable'' it is active (time or alarm) and the group of digits (hours, minutes, seconds) currently selected. In selection mode, the selected group of digits blinks, and this is the only situation where the Python code \emph{autonomously} updates the display.\footnote{Note that this could have also been implemented nicely in the statechart, by exposing operations to it for setting visibility of individual digit groups, making the display truly ``passive'', and moving all selection-state entirely to the statechart. A possible motivation for not doing so, could have been to make the assignment not too big.}
\end{itemize}
The Python code exposes a set of \textbf{operations} to the statechart. The statechart can call these synchronously from its action code, while making a transition:
\begin{description}
  \item[refreshTimeDisplay()] Redraw the time with the current internal time value. The display does not need to be cleaned before calling this function. For instance, if the alarm is currently displayed, it will be deleted before drawing the time.
  \item[refreshChronoDisplay()] See refreshTimeDisplay()
  \item[refreshDateDisplay()]  See refreshTimeDisplay()
  \item[refreshAlarmDisplay()]  See refreshTimeDisplay()
  \item[increaseTimeByOne()] Increase the time by one second. Note how minutes, hours,  days, month and year will be modified appropriately, if needed (for example, when increaseTimeByOne() is called at time  11:59:59, the new time will be 12:00:00).
  \item[resetChrono()] Resets the internal chrono to 00:00:00.
  \item[increaseChronoByOne()] Increase the chrono by 1/100 second.
  \item[startSelection()] Selects the leftmost digit group currently displayed on the screen.
  \item[increaseSelection()] Increases the currently selected digit group's value by one.
  \item[selectNext()] Select the next digit group, looping back to the leftmost digit group when the rightmost digit group is currently selected. If the time is currently  displayed on the screen, select also the date digits. If the alarm is displayed on the screen, don't select the date digits. (to simplify the statechart).
  \item[stopSelection()] Exits editing mode.
  \item[setIndiglo()] Turn on the display background light.
  \item[unsetIndiglo()] Turn off the display background light.
  \item[setAlarm()] Toggles the alarm flag on the display on or off.
  \item[checkTime()] Checks if the alarm time set is exactly equal to the current clock time. If so, it will broadcast the ``alarmStart'' event to the statechart and return true.  Otherwise, it returns false. Note that checkTime() does not care/check whether the alarm has been set "on".

  Since the current time and the alarm time only change when explicitly requested (by the statechart) through the operations just explained, and statecharts have an \emph{exact} notion of time through the use of simulated time (i.e. transitions do not take time to execute, and timed transition fire after precisely the amount of time specified), the statechart has exact control over the current time (and alarm time), as well as the timings of its calls to checkTime(), and will therefore, if properly designed, never ``miss'' an alarm.
\end{description}
The Python code may send the following \textbf{input events} to the statechart:
\begin{description}
  \item[button press / release events] Events are named `topRightPressed', `topRightReleased', `topLeftPressed', `topLeftReleased', `bottomRightPressed', `bottomRightReleased', `bottomLeftPressed', `bottomLeftReleased', and generated when their respective buttons are clicked by the mouse in the GUI.
  \item[alarmStart] Generated when checkTime() operation is called (see later), and current time == alarm time.
\end{description}

\subsubsection{Requirements}

The requirements for the solution are as follows:

\begin{enumerate}
  % 1. check
  \item The time value should be updated every second, even when it is not displayed (as for example, when the chrono is running). However, time is not updated when it is being edited.

  % 2. check
  \item Pressing the top right button turns on the Indiglo light. The light stays on for as long as the button remains pressed. From the moment the button is released, the light stays on for 2 more seconds, after which it is turned off.

  % 3. check
  \item Pressing the top left button alternates between the chrono and the time display modes. The system starts in the time display mode. In this mode, the time (HH:MM:SS) and date (MM/DD/YY) are displayed.

  % 4. check
  \item When in chrono display mode, the elapsed time is displayed MM:SS:FF (with FF hundreths of a second). Initially, the chrono starts at 00:00:00. The bottom right button is used to start the chrono. The running chrono updates in 1/100 second increments. Subsequently pressing the bottom right button will pause/resume the chrono. Pressing the bottom left button resets the chrono to 00:00:00. The chrono will keep running (when in running mode) or keep its value (when in paused mode), even when the watch is in a different display mode (for example, when the time is displayed).
  Note: interactive simulation (in AToM3) of a model containing time increments of 1/100 second is possible, but it is difficult to manually insert other events. Hence, while you are simulating your model, it is advisable to use larger increments (such as 1/4 second) for simulation purposes.

  % 5. check
  \item When in time display mode, the watch will go into time editing mode when the bottom right button is held pressed for at least 1.5 seconds.

  % 6. check
  \item When in time display mode, the alarm can be displayed and toggled between on or off by pressing the bottom left button. If the bottom left button is held for 1.5 seconds or more, the watch goes into alarm editing mode. This is not an example of good User Interface design, as going to editing mode will also toggle on/off and that may not be desired. It is however how the 1981 Texas Instruments LCD Alarm Chronograph works. %The first time alarm editing mode is entered, the alarm time is set to 12:00:00.

  % 7. check
  \item The alarm is activated when the alarm time is equal to the time in display mode. When it is activated, the screen will blink for 4 seconds, then the alarm turns off. Blinking means switching to/from highlighted background (Indiglo) twice per second. The alarm can be turned-off before the elapsed 4 seconds by a user interrupt (i.e.: if any button is pressed). After the alarm is turned off, activity continues exactly where it was left-off. Note that after the alarm finishes (flashing ends), the alarm is un-set (so it will not go off the next day at the same time).

  % 8. check
  \item When in (either time or alarm) editing mode, briefly pressing the bottom left button will increase the current selection. Note that it is only possible to increase the current selection, there is no way to decrease or reset the current selection. If the bottom left button is held down, the current selection is incremented automatically every 0.3 seconds. Editing mode should be exited if no editing event occurs for 5 seconds. Holding the bottom right button down for 2 seconds will also exit the editing mode. Pressing the bottom right button for less than 2 seconds will move to the next selection (for example, from editing hours to editing minutes).
\end{enumerate}

\subsubsection{Solution}

The solution statechart consists of 5 orthogonal regions at the highest level, named Time, Alarm, Indiglo, Display and Chrono. These regions model (mostly) independent stateful parts of the behavior:

\begin{enumerate}
  \item The ``Time''-region that increases the time, every second, as long as we are not in ``time editing mode'', implementing requirement (1). The entering and exiting of time editing mode is done in another region of the statechart, and signaled to this region with the use of ``time\_edit'' and ``edit\_done'' internal events. It is also this region that calls the ``checkTime''-operation with each increase of the time, but only if we are in the alarm-on-state (in the ``Alarm'' region, see later). Checking if we are in a state from action code is done using the ``in\_state''-function.

\begin{figure}
\centering
\includegraphics[]{sc_dwatch_time}
\caption{Time region of digital watch}
\label{fig:sc_dwatch_time}
Internal events are {\color{myblue}blue}.
\end{figure}

  \item The ``Alarm''-region keeps track of whether the alarm is on or off, and makes the alarm go off (blinking the light) if the ``alarmStart'' input event is received. We use enter- and exit-actions for the symmetric operations of (un)setting the watch's backlight. This way, we can be certain that e.g. the watch's backlight is not forgotten to be turned off, if the Blinking-state is exited. Similary, toggling the displays' alarm flag (operation ``setAlarm()'') is done by enter- and exit-actions of the On-state.

  We partially implement requirement (6), toggling the alarm with the bottom-left button while in time display mode. We also implement requirement (7), interrupting the alarm with any button when the alarm is blinking. This is done with 4 transitions (one for each button), but they are drawn as one transition for clarity.

\begin{figure}
\centering
\includegraphics[]{sc_dwatch_alarm}
\caption{Alarm region of digital watch}
\end{figure}

  \item The ``Indiglo'' region implements requirement (2).

\begin{figure}
\centering
\includegraphics[]{sc_dwatch_indiglo}
\caption{Indiglo region of digital watch}
\label{fig:sc_dwatch_indiglo}
\end{figure}

  \item The ``Display'' region is the largest region, implementing requirements (3), (5), (6) and (8). It controls what is visible on the display (the time, the chrono or the alarm time) and also implements the editing mode, which can be entered from the time or alarm view.

  Note that this region responds to the internal events ``refresh\_chrono'' and ``refresh\_time'' by refreshing the chrono and time view, resp. The region also raises the internal events ``time\_edit'', ``alarm\_edit'' and ``edit\_done'' to signal the beginning and end of time / alarm edit mode.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{sc_dwatch_display}
\caption{Display region of digital watch}
Internal events are {\color{myblue}blue}.
\end{figure}

  \item The ``Chrono'' region implements requirement (4) and contains the logical states of the chrono: Paused and Running. These states are wrapped in a composite state in order to support resetting the chrono from either of these states.

  This region raises the internal event ``refresh\_chrono'' when the chrono display should be updated.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{sc_dwatch_chrono}
\caption{Chrono region of digital watch}
Internal events are {\color{myblue}blue}.
\end{figure}
\end{enumerate}

\subsubsection{Valid semantic choices}\label{sec:dwatch_semantics}

The model has been observed to behave correctly under different semantics. Assuming we only handle 1 input event at a time, there are some observations about the intended behavior:
\begin{itemize}
  \item A reaction to an input event raises at most 1 internal event.
  \item A reaction to an internal event raises no further internal events.
  \item A reaction to an input event fires at most 1 transition in the statechart (with one exception, to be explained).
  \item A reaction to an internal event fires at most 1 transition in the statechart, and in a different region than the reaction that raised the internal event. Every internal event ``flows'' from one region to another:
  \begin{itemize}
    \item refresh\_time: Time $\rightarrow$ Display
    \item refresh\_chrono: Chrono $\rightarrow$ Display
    \item time\_edit: Display $\rightarrow$ Time
    \item edit\_done: Display $\rightarrow$ Time
  \end{itemize}
\end{itemize}
The last observation allows us to choose \textsc{Take One} for Big-Step Maximality. \textsc{Take Many} adds no benefit, and, under both YAKINDU (Section \ref{sec:superstep}) and SCCD (Section \ref{sec:rounds}, Figure \ref{fig:rounds_example}) results in a more complex execution (featuring one more nested loop), making the behavior more difficult to predict for the modeler, and introducing the risk of never-ending big-steps.

If \textsc{Take Many} is chosen anyway, we must choose \textsc{Present in First Small Step} for Input Event Lifeline, to ensure that every input event only causes 1 transition to be made. Otherwise, never-ending big-steps would occur: Several regions contain transitions of the type shown in Figure \ref{fig:sc_takemany_button}. E.g. the Display-region would oscilate endlessly between ChronoView and TimeView when the topleft button is pressed. Similarly, we would also have to choose \textsc{Present in Next Small Step} for Internal Event Lifelife, to ensure every internal event is also only responded to once. Otherwise, e.g. the self-transition with trigger ``refresh\_time'' of Display/TimeView would endlessly repeat.

Choosing \textsc{Present in First Small Step} slightly alters the behavior of the model: When the Alarm-region is in the Blinking-state, a button press may cause the alarm to be interrupted, or cause a transition elsewhere, in another region. (This is the only situation where an input event can be responded to in more than 1 region.) The transition first responding to the input event ``consumes'' it. In order to satisfy the requirements, we must thus give the Alarm-region a higher (\textsc{Explicit}) priority than the other regions. This can be done in both YAKINDU and SCCD. The button press, consumed by the Alarm-region, will no longer cause any other reaction. The requirements are ambiguous here, not mandating or forbidding this ``alternative'' behavior.

\begin{figure}
\centering
\includegraphics[]{sc_takemany_button}
\caption{A statechart that would behave differently under \textsc{Take One} vs. \textsc{Take Many} semantics}
\label{fig:sc_takemany_button}
\end{figure}

Under \textsc{Take One}-semantics, all event input/internal lifeline options are valid (except \textsc{Present in Same}). If Input Event Lifeline \textsc{Present in Whole} and Internal Event Lifeline \textsc{Present in Remainder} are chosen, input and internal events may be simultaneously enabled, but a region would never have to choose between an input and internal event, because in the model, internal events are always responded to in a (different) region that does not respond to the input event.

% Because we know every button press-event is followed by a button release-event at a later point in time (i.e. in a later big-step), it is possible to avoid \textsc{Take Many}'s never-ending big-steps by introducing additional states. For instance, the Indiglo-region could also have been implemented as shown in Figure \ref{fig:sc_dwatch_alt_indiglo}, behaving correctly under \textsc{Take One}, but under \textsc{Take Many}, it would repeat the ``Pushed''-state's self-transition endlessly. The implementation originally demonstrated in Figure \ref{fig:sc_dwatch_indiglo} does not have this problem, due to the explicit ``Released''-state that it enters upon button release.

% This approach still cannot ``fix'' the entire statechart, because there is one type of input event to which we whish to respond with a self-transition, yet has no ``mirror'' event: The after-transition in the Time-region (Figure \ref{fig:sc_dwatch_time}) is implemented in both SCCD and YAKINDU by transparently (to the modeler) requesting the scheduler to generate a future \emph{input event}. With \textsc{Present in Whole} semantics, this input event would allow the transition to repeat itself endlessly under \textsc{Take Many}.
  
% \begin{figure}
% \centering
% \includegraphics[]{sc_dwatch_alt_indiglo}
% \caption{Alternative implementation of Indiglo-region, with fewer states, behaving currectly under \textsc{Take One}, and incorrectly under \textsc{Take Many} semantics}
% \label{fig:sc_dwatch_alt_indiglo}
% \end{figure}

% Choosing Input Event Lifeline: \textsc{Present in First Small Step} would ``fix'' \textsc{Take Many}, and would work with \textsc{Take One} as well. This option would change the behavior slightly, as it would allow only a single region to respond to each input event. There is only one situation where a single input may cause several regions to respond, and this is when the alarm is interrupted, by pressing any button. The same button press will be reacted to in another region, as every button press in the model \emph{always} has some effect. By choosing \textsc{Present in First Small Step}, only a single region will react, ``consuming'' the event. YAKINDU and SCCD let the modeler give regions an \textsc{Explicit} priority, in order to produce fully deterministic behavior. We must give the alarm region the highest priority, otherwise the alarm could not be interrupted, violating the requirements. The button press would have no other effect. Whether this is \emph{correct} behavior, is not stated in the requirements.

% Regions communicate by use of internal events (and the \texttt{in\_state} function). The way the model is designed, internal events can only be raised as reaction to an input event, not as a reaction to another input event. This guarantees terminating big-steps, should we use \textsc{Take Many} and \textsc{Present in Next Small Step} for Internal Event Lifeline. If we use \textsc{Take One}, all causal options for Internal Event Lifeline are valid.

The model does not require combo steps. Combo steps are only useful if the reactions have to be \emph{grouped}, and constraints need to be applied to each group. One case would be when input and internal event reactions are expected to have overlapping regions, but we still want to allow only 1 transition region per set of input/internal events  (i.e. \textsc{Combo Take One}, \textsc{Present in First/Next Combo Step}). This is the default semantic configuration of SCCD, and also resembles the event-driven execution of YAKINDU, and is a valid semantic configuration for our model, but since it adds no value, while increasing execution complexity, there is no reason to use it.

Figure \ref{fig:dwatch_semantics} shows a tree of valid combinations of the semantic options just discussed. \textsc{Take One}-semantics are definitely preferred for the reasons discussed above. Note that also YAKINDU's cycle-based and event-driven semantics are valid semantics, but that for cycle-based semantics, simultaneous input events could occur, which the model doesn't support (and also the requirements don't mention).

\begin{figure}
\centering
\includegraphics[width=\textwidth]{dwatch_semantics}
\caption{8 correct semantic configurations for digital watch}
\label{fig:dwatch_semantics}
\end{figure}

The explicit priority of regions has already been discussed, and only requires us to set a high priority to the Alarm-region if we choose \textsc{Present in First Small Step} for input events.

Any explicit priority for every state's outgoing transitions is a valid one. All transitions have event triggers. For every state, there can be multiple outgoing transitions with different input events as triggers, but simultaneous input events are not expected to occur, and if they would occur (e.g. 2 buttons simultaneously pressed), the requirements do not specify what needs to happen, so any deterministic choice is a good one. Every state never has more than 1 internal event-triggered outgoing transition, which is given the lowest priority, since our chosen semantics always prioritizes input events.

For hierarchical priority, any choice is a correct one, since for every event, only a single transition per region can be selected.

The statechart has no variables, so Memory Protocol options do not apply.

% It is difficult to conclude a ``best'' semantical configuration for our model. We definitely prefer \textsc{Take One} for its simple execution. For input events, we can choose between \textsc{Present in Whole} and \textsc{Present in First Small Step}, depending on the desired behavior as described above. For internal events, the choice really doesn't matter here.

\subsubsection{Concrete implementation}

The SCCD implementation differs from the YAKINDU implementation, because, at the time, SCCD did not support synchronous functions called directly from the statechart. A workaround was applied, using output events instead of synchronous functions. This workaround had no further impact on the statechart's structure or set of correct semantics. If output events are handled in the order that they were raised, there is no real difference between them or synchronous functions, as long as functions don't return data.%\footnote{Strictly speaking, in BSML, the output events of a big-step are simultaneous and have no order, so we deviate here.}

In SCCD, this example makes use of the event loop-integration library. All statechart simulation runs from TkInter's event loop. This way, the entire application runs from a single thread, making it easy to interact with TkInter (which is not thread-safe).

\subsection{Chat Client}

\begin{figure}  
\centering
\includegraphics[width=0.5\textwidth]{chatclient}
\caption{Screenshot of chat client demo application}\label{fig:chatclient}
\end{figure}

The chat client example\footnote{http://msdl.cs.mcgill.ca/people/hv/teaching/MoSIS/assignments/Statecharts} is a keyboard-commanded GUI chat application. The example consists of a client and a server program. The chat client is partially implemented as a statechart. The client-server protocol and the chat server are ad-hoc programmed in Python (Java for the YAKINDU version). The original version of SCCD includes a chat server implemented in statecharts as well, but it relies on multi-instance models, which our version does not yet support.

% The protocol is as follows:
% \begin{itemize}
%   \item Clients may connect to the server, and disconnect.
%   \item After having connected, a client may join a chatroom. Chatrooms are identified by an integer number. Every client can join at most 1 chatroom at the same time. A chatroom may have any number of clients in it.
%   \item After having joined a chatroom, a client may leave the chatroom.
%   \item Clients may send a (textual) message to a server they are connected to. The server will broadcast the message to all clients who are in the same chatroom as the client.
%   \item The requests for joining/leaving and sending a message are acknowledged by the server.
%   \item At any time, clients may send a \emph{ping}-request to a server they are connected to. The server acknowledges ping-requests with an \emph{alive}-response.
% \end{itemize}

\subsubsection{Interface}
% The statechart model implements the chat client, which is a networked GUI-application.
The statechart interfaces with 2 components: A network client, for interacting with a chat server, and a UI window, implementing the chat client's window. Both components are implemented in Python (Java for the YAKINDU version).

The network client exposes the following \textbf{operations}:
\begin{description}
  \item[get\_nr\_of\_servers(): int] Returns the number of (hardcoded) servers in the client
  \item[get\_server(index: int): str] Returns the address of the server with given index
\end{description}

The network client can receive the following \textbf{output events} from the statechart:
\begin{description}
  \item[connect(address: str)] Request the client to connect to the server with given address.
  \item[disconnect] Request the client to disconnect from the server.
  \item[join(room: int)] Request the client to join the chatroom with given index.
  \item[leave] Request the client to leave the current room.
  \item[ping] Request the client to send a `ping' request to the currently connected server.
  \item[send\_message(msg: str)] Request the client to send a message to the server. The server will broadcast the message to other clients in the same chatroom.
\end{description}

The network client may also send the following \textbf{input events} to the statechart:
\begin{description}
  \item[connected] Sent when the client is successfully connected to a server.
  \item[disconnected] Sent when the client is successfully disconnected from a server.
  \item[joined] Sent when the client successfully joins a room.
  \item[left] Sent when the client successfully leaves a room.
  \item[receive\_message: string] Sent when a client receives a message from the server. (another participant in the room sent a message)
  \item[alive] Sent when the client receives an "alive" message. (response to a "ping")
\end{description}

The UI window consists of a scrollable list of logs and received messages, and has an input box on the bottom. It exposes the following \textbf{operations}:
\begin{description}
  \item[add\_message(msg: str, type: str)] Prints out a message to the scrollable list, with the specified type (as a string, either "info", "local", or "remote"))
  \item[append\_to\_buffer(char: str)] Adds a string to the input box and visualizes the change
  \item[remove\_last\_in\_buffer()] Removes the final character from the input box and visualizes the change
  \item[clear\_input()] Clears the input box and visualizes the change
  \item[input\_join()] Colors the input box in the 'join' mode (green)
  \item[input\_msg()] Colors the input box in the 'message' mode (white)
  \item[input\_command()] Colors the input box in the 'command' mode (grey)
  \item[get\_buffer(): str] Returns the current content of the input box
\end{description}

The UI window can also send one type of \textbf{input event} to the statechart:
\begin{description}
  \item[input(char: str)] Sent when a keystroke occured. The parameter of the event contains the input character.
\end{description}

\subsubsection{Requirements}

\begin{enumerate}
  \item The client is either disconnected or connected to a chatserver.
  \item The client has a (hardcoded) list of servers that it can connect to. A server is identified by its IP address (or hostname) and a port.
  \item If the client is disconnected, the user can not enter any input and must wait for a connection to be established.
  \item The client will autonomously connect to a server by sending a connection request. If the server does not respond within a certain amount of time, another server is chosen until one of the connections succeeds.
  \item As soon as the client is connected, the client will continuously ping the server with a certain interval. Should the server not respond after a certain timeout, the client will automatically go to disconnected mode and the user is again unable to enter any input.
  \item After transferring to disconnected mode, the client will automatically try to establish a connection to another server. After a connection is successfully made, the user can again enter input.
  \item All input that was made by the user before a disconnect should remain in memory and visible to the user.
  \item When the user has connected to a server, the user starts without having joined any room. The user can give the input 'j' (Join) to join a specific room. After pressing 'j', the input box is colored green and only numerical input is accepted. Other input is not accepted.
  \item After joining a room, the user starts to receive messages from the server that should be shown in the chat window. The user can either leave the room again by pressing 'l' (Leave), or can send a message by pressing 'm' (Message).
  \item After pressing 'm', the entry box colors white and the user can type a message. The message will be sent after the return key is pressed.
  \item Should a disconnect from the server occur while the user has already joined a room, the same room should automatically be joined after reconnection to the server.
  \item Make sure that backspace also works in every input mode.
  \item Input processing must happen in a way that resembles Finite State Automata.
  \item You should test the above requirements by building a testing harnass that will determine whether your Statechart satisfies the requirements. Do this by using sctunit, the testing framework provided by Yakindu.
\end{enumerate}

\subsubsection{Solution}
First of all, the solution statechart has 3 variables:
\begin{itemize}
  \item \texttt{curr\_server}: Integer, index of the server currently attempting to connect to, or connected to. Initially 0.
  \item \texttt{room\_number}: Integer, number of the chatroom attempting to join, joined, or last joined. Initially 0.
  \item \texttt{reconnecting}: Boolean, whether a previous connection to a server was lost. Initially false.
\end{itemize}
The solution consists of 3 orthogonal regions at the highest level:
\begin{enumerate}
  \item The ``Receiving''-region has only a single sub-state with a self-transition, printing out any received message. No additional checks on server connectedness or chatroom joinedness are required, since we only expect to receive messages when connected and joined.

\begin{figure}
\centering
\includegraphics[]{sc_chat_receiving}
\caption{Receiving-region of chat client}
\label{fig:sc_chat_receiving}
\end{figure}

  \item The ``Pinging''-region starts pinging the server when the input event ``connected'' is received. When no response is received after 2 seconds, the region stops sending pings, and notifies other regions of this through the internal event ``timeout''.

\begin{figure}
\centering
\includegraphics[]{sc_chat_pinging}
\caption{Pinging-region of chat client}
Internal events are {\color{myblue}blue}.
\label{fig:sc_chat_pinging}
\end{figure}

  \item Finally, the ``Main''-region models all user interactions and the main window's state. At the highest level, there are 2 sub-states:
  \begin{itemize}
    \item Connecting: Initial state, attempts to connect in a round-robin fashion to one of the servers hardcoded in the network client. The first connection that succeeds takes us to the Connected-state.
    \item Connected: Contains the client's behavior while connected to a server. When connection is lost (sensed through the ``timeout''-internal event coming from the Pinging-region), we go back to Connecting, while setting the variable \texttt{reconnecting} to True, causing the Connecting-state to connect to the same server as before.
  \end{itemize}

  The most complex feature, is automatically re-joining the chatroom after a restored connection. This is done by dividing the Connected-state into 2 (non-orthogonal) regions: LeavingOrLeft (should not re-join) and JoiningOrJoined (should re-join). At the same level, a history-state records which of those we were in.

\begin{figure}
\centering
\includegraphics[width=102mm]{sc_chat2_main}
\caption{Main-region of chat client}
Internal events are {\color{myblue}blue}. Variables are {\color{mygreen}green}.
\label{fig:sc_chat_main}
\end{figure}

  When going to the Joined-state, we must always send a join-request to the server first. Therefore we always pass through the Joining-state. When joined, another history-state is keeps track of whether we were entering a message, or not.

  When entering a regions that has history, we always enter the history state. If no history for the region exists yet, both YAKINDU and SCCD enter the region's initial state, which is what we want.

  Note that the outgoing transitions of ``EnteringMessage'' are given explicit priorities. The self-transition appending entered characters to the input field buffer is a lower priority than the rest, because it has no guard checking the key that was pressed, and may otherwise ``steal'' events from the other outgoing transitions.

\end{enumerate}

\subsubsection{Valid semantic choices}

% The same observations from  apply to this model: We only expect one input event simultaneously, and every input event causes at most one transition per region to be executed, possibly raising one internal event (the only internal event here is ``timeout'', flowing from region Pinging $\rightarrow$ Main), causing at most one more transition to be executed, in a different region. The exact same tree of semantic options applies (Figure \ref{fig:dwatch_semantics}).

For the same reasons as explained in the digital watch example (Section \ref{sec:dwatch_semantics}), choosing \textsc{Take One} for Big-Step Maximality is appropriate. For Input Event Lifeline, we cannot choose \textsc{Present in First Small Step}, because the input event  ``connected'' needs to be responded to in both the Pinging- and Main-region, so the only option remaining is \textsc{Present in Whole}. For Internal Event Lifeline, any option would be correct (except \textsc{Present in Same}).

Alternatively, SCCD's default semantics (\textsc{Take Many}, \textsc{Combo Take One}, \textsc{Present in First/Next Combo Step}) is also valid, but more complex to execute. No other working set of semantic choices can include \textsc{Take Many}. 

The statechart includes variables, so a choice should be made for Memory Protocol semantics. Any choice is a valid one, because values written to a variable are not read until the next big step. An exception is the transition GettingRoomNumber $\rightarrow$ JoiningOrJoined, which writes a value to the variable \texttt{room\_number}, and subsequently reads it (as the enter-action of Joining). However, SCCD considers this write-read sequence as part of a single transition, and therefore always reads the ``fresh'' value, ignoring memory protocol options. This feature was called ``locally observable writes'' in Section \ref{sec:locally_obs_writes}.

\subsubsection{Concrete implementation}

The YAKINDU solution makes extensive use of choice-pseudo states, which is syntactic sugar to group outgoing transitions with the same event trigger but with a different guard condition, such as for states ``GettingRoomNumber'' and ``EnteringMessage''. This makes the model more readable. SCCD currently does not have this feature, requiring the modeler to model them as separate transitions, which is also the way they were (manually) drawn in Figure \ref{fig:sc_chat_main}.

In order to implement this model, SCCD had to be extended with the ability to call external functions directly from its action code, as certain interactions with e.g. the GUI (such as getting the text entered in the box at the bottom) had to be implemented as synchronous calls. Once this was done, the implementation was trivial, and identical to the YAKINDU-implementation.

In SCCD, like with the digital watch, the event loop integration library is used to run the statechart from the TkInter thread, but the network client library \emph{has} to run separate threads for sending and receiving data, as these are blocking I/O operations on socket-objects in Python. In order to send or receive events from the statechart, thread-safe queues were used.

\section{Meaningful semantics}

Most semantic options of BSML can be arbitrarily combined, but not all combinations are useful. The paper on BSML \cite{sabzali2010deconstructing} lists very few dependencies between options (such as \textsc{Combo Take Many} $\Rightarrow$ \textsc{Syntactic} $\vee$ \textsc{Take Many}) but these dependencies are the bare minimum, technical restrictions for carrying out \emph{some} form of execution. We will now see if we can further delimit combinations of semantic options for statecharts.

\subsection{Maximality, Event Lifeline}

The semantic aspects Big-/Combo-Step Maximality and Input/Internal Event Lifeline are considered ``orthogonal'' in BSML, which is correct from the viewpoint of ``being able to execute them'', but for realistic models, the options chosen for these aspects depend heavily on each other.

Together, these options control 2 things:
\begin{enumerate}
  \item For how long transitions can be made as response to input or internal events.
  \item At what point the effects of input event-triggered transitions begin to influence the remainder of the execution of the big-step, by means of internal events and variable assignments.
\end{enumerate}
For the first property, an input/internal event lifeline spectrum exists from ``short'' to ``long'': For instance, \textsc{Present in Next Small Step} is a ``short'' option, while \textsc{Present in Remainder} is a ``long'' option. For the second property, an internal event lifeline spectrum exists from ``sooner'' to ``later'': For instance, \textsc{Present in Next Small Step} is a ``soon'' option, while \textsc{Queue} (only in SCCD) is a ``late'' option.

\begin{figure}
\centering
\includegraphics[]{late_long}
\caption{Properties of event lifeline options}
\end{figure}

Choosing a ``late'' an event lifeline option helps separate reactions to input events from reactions to internal events. The ``later'' an event lifeline option, the more need for \textsc{Take Many}. The ``longer'' the event lifeline option, the worse it behaves with \textsc{Take Many}, because of never-ending big-steps: The options \textsc{Present in Remainder} and \textsc{Present in Whole} are unlikely to work well with \textsc{Take Many} (e.g. the digital watch example, Section \ref{sec:dwatch_semantics}).

Introducing combo-steps (using \textsc{Combo Take One} with a combo-step event lifeline option) helps to avoid never-ending big-steps with \textsc{Take Many}. Combo-steps are very useful to build a semantic configuration that is ``fool-proof'', such as YAKINDU's event-driven execution, and SCCD's default configuration, which execute input events and internal events in separate rounds. However, many complex models (such as both examples discussed in the previous section) function perfectly fine under \textsc{Take One} semantics, even though they were developed with combo-steps in mind. The simplicity of \textsc{Take One}, both for the modeler and execution runtime (performance-wise) is a good argument for always chosing this option, if possible.

\subsection{Memory Protocol}

Usually, the modeler would want to use the Memory Protocol option that matches the point in time where internally raised events become enabled. This way, the full effect of one transition, consisting of raised events and variable assignments, becomes visible at a single point in time.

The default semantics of SCCD follow this principle, with the \textsc{Combo Step}-option being the default, following the default event lifeline option \textsc{Present in Next Combo Step}. With these semantics, the statechart appears to behave as if the transitions within a combo-step fire concurrently.

When not using combo-step semantics or for any other reason, the modeler may also choose to disable Memory Protocol semantics by choosing \textsc{Small Step} (i.e. variable assignments become visible to the next transition). This is how YAKINDU behaves.

\subsection{Priority}

We consider priority truly orthogonal to other semantic options. In YAKINDU and SCCD, the priority of all transitions is a total ordering, explicitly created by the modeler. In models only responding to single-item sets of input events, usually there is no need for setting an explicit priority, because few transitions will be enabled at any point in time. Such models would still behave deterministically in the absense of priority rule(s). In the case of our example models (digital watch and chat client), we only sporadically had to set a priority. In our example models, there also were no hierarchical conflicts that needed resolution (e.g. ``parent first'').

\subsection{Conclusion}

We agree with \cite{sabzali2010deconstructing} that semantics should be chosen on a model-by-model basis. We advise to start out with a simple, restrictive set of semantics, e.g. \textsc{Take One}, as it is easy to understand, efficient to execute, and has been shown to work even for large and complex models. The default semantics of SCCD and YAKINDU (event-driven) are less restrictive and fairly intuitive, but have a higher runtime overhead due to the use of combo-steps. Combo-steps can also be used to ``simulate'' concurrency, by enabling Memory Protocol semantics. Explicitly assigning priority to regions or transitions to resolve ambiguity, only has to be done sporadically even in large models.

% - Estimated number of combinations as presented in Day & Atlee: very large number!
% - Number can be reduced by finding interactions between semantic choices:
%   general property: effect of one transition on another, one of:
%    1) immediate (synchronous, sooner)
%    2) queueing (asynchronous, later)
%   => IEL: range of options: "Same" (most immediate) -> "Queue" (latest)
%   => Memory protocol: typically want same as IEL
%   => Maximality: the more "immediate" the effect, the less need for "Take Many"
% - SCCD's default semantics: BSM: "Take Many" + IEL: "Next Combo Step" + MP: "Combo step"
%   => rather on the "queueing" end of spectrum, permissive
%   => modeler should restrict semantics more towards immediate if possible
