Design of a Fast-Food Restaurant System Using Statemate Tool

Technical ReportDesign of a Fast-Food RestaurantSystem Using Statemate ToolPrepared forSoftware Engineering SeminarPresented byKamran SartipiNovember, 1995Dept. of Computer ScienceUniversity of WaterlooWaterloo, OntarioCanada N2L 3G1

.

Contents1 Introduction 12 Language of Statemate 32.1 Language of the Statecharts . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.1 Elements of a statechart . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Statechart Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Statechart Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Statechart Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.5 Statechart Synchronization . . . . . . . . . . . . . . . . . . . . . . . . 92.1.6 Statechart Declutter & Merge . . . . . . . . . . . . . . . . . . . . . . 92.2 Language of the Activity-charts . . . . . . . . . . . . . . . . . . . . . . . . . 103 Design Example: Fast-Food Restaurant System 133.1 System Speci�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Functional and Behavioral Design . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Data Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5 User Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Designing of a Reactive System 244.1 Top-Down / Bottom-Up Design . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Concurrency in a Reactive-System . . . . . . . . . . . . . . . . . . . . . . . . 294.2.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.2 Inter-Process Communication . . . . . . . . . . . . . . . . . . . . . . 324.3 Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Evaluation of Statemate 375.1 Data-dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Completeness as a design documentation . . . . . . . . . . . . . . . . . . . . 375.3 Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4 Customization: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.5 Reusability of speci�cation: . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.6 Project management: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.7 Application interface design support (panel): . . . . . . . . . . . . . . . . . . 395.8 Environment modeling support: . . . . . . . . . . . . . . . . . . . . . . . . . 395.9 Customized design documents: . . . . . . . . . . . . . . . . . . . . . . . . . . 395.10 Di�erent views of design: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.11 Traceability: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Conclusion 40i

List of Figures1 The Language of the Statemate consists of three graphical concepts: State-charts, Activity-charts, and Module-charts. . . . . . . . . . . . . . . . . . . . 42 Timing in the Statechart. Delayed transition occurs after n time-units. . . . 73 Hierarchy in the Statechart. State S2 is decomposed into states A and B. . . 84 Concurrency in the Statechart. Each state can be converted to an and statewith many concurrent elements. . . . . . . . . . . . . . . . . . . . . . . . . 85 Synchronization in the Statechart. Several states can be synchronized usingthe joint transition (thick arrow). . . . . . . . . . . . . . . . . . . . . . . . . 96 Putting all details of the hierarchical states in a statechart, makes the chartmessy and di�cult to understand. . . . . . . . . . . . . . . . . . . . . . . . . 107 Decluttering in the Statechart, allows the details of the boxes to be de�ned inthe o�-page charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Activity-chart in Statemate. Edged-boxes are activities and rounded-box isthe control-activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Physical View of the fast-food restaurant with four communicating units andthe management unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410 The Architecture of the restaurant system is shown using the module chartof Statemate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711 Activity-chart of the restaurant system. The boxes with the pre�x of \@" areo�-page charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1912 Statechart of the restaurant system. Concurrent states control the di�erentunits of the restaurant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2113 Panel Graphic-Editor of Statemate. Using a variety of design widgets, sophis-ticated user-interface panels can be easily implemented. . . . . . . . . . . . . 2314 Activity-chart of the assembly-unit. This chart consists of several o�-pagecharts and two instances of the generic-chart asm-generic. . . . . . . . . . . 2615 Activity-chart order-taker-generic consists of all the basic activities requiredfor di�erent tasks in one order-taker station. . . . . . . . . . . . . . . . . . . 2716 The order-taker panel of the fast-food restaurant system. A typical order isshown on the order-screen. This panel consists of many keys and displayswhich interact with the statecharts of the order-taker unit. . . . . . . . . . . 2817 Statechart select-itm-cntl is responsible to monitor the pressing of the item-select buttons on the order-taker panel. . . . . . . . . . . . . . . . . . . . . 2918 Statechart order-taker-generic-cntl is the parent of all of the statecharts inorder-taker unit which provides the concurrent execution environment for them. 3019 Statechart recall-order-cntl. S9 is a reactive-state and is responsible for syn-chronization of the chart operation with other sibling charts. . . . . . . . . 3120 This chart illustrates the typical example of the producer and consumer. Stateput-data-in-buf in the producer chart, and states get-data in the consumercharts are critical sections. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3321 The producer o�-page chart is waiting to enter its critical section. . . . . . . 35ii

22 One of the instances of the generic-chart consumer which is entering itscritical-section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3523 The parent chart producer-consumer provides concurrent execution of the pro-ducer chart and 3 instances of the consumer chart. . . . . . . . . . . . . . . 36

iii

.

iv

A Design Oriented Approach to the StatemateSemanticsKamran SartipiDepartment of Computer ScienceUniversity of WaterlooWaterloo, OntarioCanada N2L 3G1Abstract: This report introduces Statemate as a CASE tool for developing large reactivesystems. Reactive systems perform di�erent actions in response to the input signalsand usually receive a large number of inputs. This characteristic complicates thedesign of the behavior control parts of the system. Statemate provides statecharts asmeans for designing behavior parts and activity-charts for designing functional partsof a system. These tools assist the designer to separate the important design concernswith respect to the system functionality and behavior. This report starts with a briefintroduction to the Statemate's language and continues with description of the designtechniques used for developing a large reactive system with Statemate. The design ofa fast-food restaurant system is used as an example of a large system to illustrate thevarious design aspects such as: di�erent design styles, hierarchical structure, data andcontrol ow, user-interface, managing parallel processes, and instantiation. The lastpart of the report evaluates the Statemate tool against a number of criteria.1 IntroductionStatemate, a CASE tool for designing of large Reactive Systems, is a product of the i-logixincorporation. The term Reactive Systems was �rst used by Dr. Lavi at Israeli Aircraft andlater used in Statemate description by Dr. David Harel. Reactive systems receive a largenumber of external and internal signals of the form Event or Condition, hence they are some-times called event driven systems. The system reacts to the signals and performs di�erenttasks accordingly. The examples of such systems include: avionic systems, telephone andcommunication controller, robots, etc.Statemate provides facilities for Structured Analysis and Design, and is a collection of di�er-ent tools that supports a complete design life-cycle from requirement-analysis to prototyping,designing, and code-generation. It bene�ts from di�erent graphical editors for design taskwhich aid the designer to develop the system using its functional and behavioral models.Statemate provides the following facilities in one package:1

� Graphical Editors are design tools for specifying the system in Activity-Charts, Stat-echarts, and Module-Charts.� Project Management provides an environment for a group of system designers towork in a team for developing a system. It manages the authority to access the shareddata base (Data-Bank) among the design team-members.� Version control keeps track of the changes of each module in the system and generatesdi�erent versions for each.� Check Model checks the data- ow and control- ow diagrams for consistency andcompleteness.� Data Dictionary de�nes the whole elements of the system and searches throughthem.� Data-Base Query o�ers a full spectrum of query models for querying the attributesof the elements in the system.� Simulation simulates the system functionality at di�erent levels of abstraction i.e.prototype and design.� User Interface Design uses a dedicated Panel editor to de�ne the required displaysand buttons for input/output tasks.� Code Generation produces the source code in C or Ada from the designed system.� Document Generation.In this report we are interested in modeling a reactive system using three aspects of the State-mate language: Activity-charts, Statecharts, and Module-charts. A multi-station restaurantsystem with several communicating units is used as our design example. Statemate hasfacilities for designing a system in di�erent levels of abstractions which assists in designing asystem in top-down or bottom-up styles. A precise system speci�cation is required to ensurethe production of a correct system. This speci�cation is created from the initial systemrequirement proposed by the customer and further investigations of the designer. Providedthat a detailed speci�cation is available, the design can be started from bottom. The designof our restaurant system is started by implementing the basic functionalities of various unitsof the system i.e. order-taking, assembling, food-preparation, and inventory. The activity-charts are means for de�ning the system functionalities. De�ning the data-structures andinput/output characteristics of the system are the next design e�orts. The behavior of thesystem in response to the incoming or internal signals is demonstrated by statecharts. Stat-echarts react to the signals and control the functionality of the system manifested by theactivity-charts. This is a typical behavior of reactive systems.Statemate contains the required mechanisms for gathering the small pieces of a design func-tionality in a group to make a higher level of abstraction. The reverse design style i.e.2

top-down, is also feasible. The system is �rst designed in its highest level of abstraction.Then, using functional decomposition of the modules, lower layers of the design are devel-oped.In complex systems such as this restaurant system, several concurrent and communicatingmodules exist. Typical problems in such a systems include: inter-process communication(IPC) and process synchronization. To illustrate the IPC between di�erent charts of a de-sign, a simple example of producer and consumer is provided. Synchronization is anotherissue of the concurrent charts which must be resolved. A synchronization technique whichis employed in our restaurant system is presented. Reusability of the existing modules isa common practice. The concept of generic-chart and instantiation in Statemate allowsthe use of multiple instances of a chart. A simple example describes this feature. Most ofthe units in the restaurant example have several stations which use the instantiation concept.This report is structured as follows: The next section is allocated to a brief description ofthe Statemate's language which consists of statecharts and activity-charts. In section 3,various design aspects such as: system speci�cation, system architecture, data and control ows, data-structure, and user interface are described. Section 4 of the report describesthe design peculiarities of a concurrent reactive system with emphasis on the two designstyles: Top-Down and Bottom-Up. In section 4, the concurrency related issues such assynchronization and interprocess communication are discussed. In section 5 we evaluate theStatemate tool against a number of criteria which are devised for evaluation of graphicaldesign tools. Finally section 6 provides a conclusion to the report.2 Language of StatemateThe language of Statemate consists of three aspects:Activity-charts: These charts manifest the functional decomposition of the system in ahierarchy of charts, each at a di�erent level of abstraction. These charts de�ne thefunctionality of the system and are considered Data-Flow diagrams. Their tasks includetransportation and manipulation of the system variables. They are concerned withwhat tasks the system must execute.Statecharts: Statecharts present the behavior of the system and control its functionality.Statecharts manage the behavior of the system by sequencing the order of execution ofdi�erent functions of the system. These charts are considered Control-Flow diagrams.They illustrate the concepts of causality, concurrency and synchronization in the sys-tem. In general they are concerned with when a particular task should be executed.Statecharts and activity-charts demonstrate the Conceptual Model of the system.Module-charts: These charts de�ne the physical connections among the various modulesin the system and provides the structural view of the system. It answers the question3

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Name:

Description:

MODULE

Name:

Description:

ACTIVITY

ACTIVITY-CHARTS

MODULE-CHARTS

STATECHARTS

Name:

Description:

STATE

Figure 1: The Language of the Statemate consists of three graphical concepts: Statecharts,Activity-charts, and Module-charts.of how di�erent modules of the system are interconnected. The three views of thesystem-model and their relationships are illustrated in Figure 1. Di�erent attributesof each chart in the system are kept in data-dictionary forms which are shown in theFigure.In the following sections the important features of the Statemate semantics are presented.The semantics of the Statemate language is described in its conceptual model: statechartsand activity-charts.2.1 Language of the StatechartsStatecharts to some extent are state-transition-diagrams with increased capabilities, such as,multi-level states, decomposition of states, concurrent states, and synchronization. Below,some important concepts are described.2.1.1 Elements of a statechartThe elements of a statechart consist of: 4

State: A statechart consists of several states which are represented by rounded boxes. Statesshow the distinct con�gurations of the system. Three kinds of states exist: or-stateshave sub-states (hierarchical), and-states have concurrent components (parallel execu-tion), and basic-states have no sub-states. States are used for several purposes:� A state can produce time synchronization by creating unit-delays in the system.In this form we add a state between two states.� A state can be used to start one or more activities in an activity-chart. Afterassigning this task to a state (using data dictionary), its name is su�xed withthe sign \>" (see section 3.3).� A state can be a reactive-state, which has some static-reactions associated to it.Static reactions are reactions of the system to an event within a particular state,The syntax of the reaction is: trigger/action;;trigger/action;;It is a list whose components are separated by two semi-colons. Each one has asyntax of a transition label. Static-reactions are de�ned using a data dictionary.The name of the reactive-state is then followed by a \>" sign. This feature isdemonstrated in section 4.2.1� A state can represent an o�-page chart. In this case, its name is pre�xed by thesign \@" and is called box-is-chart. (see section 2.1.6)� A state can represent an instance of a generic-chart, in which case its name hasspecial format (see section 4.3).Transition: Transition is the movement from one state to another, and is represented byan arrow. The label of the transition has the following format:Event[Condition]/ActionEvents are edge sensitive elements of the system. They are e�ective only at the time-unit when they are triggered, and will disappear at the next time-unit. Various eventsare generated as a result of the following actions:� Pressing of a button in the panel, which is bound to an event.� Entering or Exiting of a state.� Activating or Stopping of an activity.� Changing of data or contents of an array.� Time-out after that an event is occurred.5

Conditions are level sensitive elements of the system. As long as the condition is truethe associated transition is allowed. If the condition and event are both used in thelabel of an arrow, the transition is allowed only when the condition is true and the eventis triggered. The value of a condition becomes true by one of the following actions:� Pressing of a button in a panel, which is bound to a condition.� Being in a state.� When an activity is active.Actions manipulate some elements in the system after which a transition is performed.They are summarized below:� Trigger an Event or change a Condition.� Assignment of an expression to a variable.� Starting or Stopping of an Activity.� If, then, else construct.� While and For loops.Step: Step is a transition of the system from one con�guration to another and involves theexecution of one or more transitions. If no transitions can be executed, the system issaid to be in a stable con�guration. Step is executed in zero time. The values associ-ated with transition actions are changed only at the end of the step and the generatedevents may be sensed only at the step that immediately follows the current one.In the next part, some of the most important concepts of the statecharts are described.The Figures are the snapshots of the charts when their operations are simulated withthe simulator tool. The thicker arrows represent the currently active transitions whensimulating the chart and help us to pinpoint the important features of the examples.2.1.2 Statechart TimingA transition may occur on a time-out basis. This type of transition has the label of the formtm(e,n) in which \e" is any event of the above described form, and n is the number of systemtime-units. This transition will occur n time-units after the occurrence of event \e". Figure2 illustrates the use of delayed transition. When the state idle becomes active the eventen(idle) is triggered (state idle is entered). After 2 time-units the transition will be triggeredand the system moves to state date-time-s. At the next step the idle state is active again.In simulation of a chart, steps are performed at zero-time, but the time-out transitions aredependent on time not on steps. Therefore, to see the e�ects of time-based transitions, thesimulation should be performed in auto-run mode, not single-step, to let time proceed.6

��

��

tm(en(IDLE),2)

DATE_TIME_S>

IDLE

Figure 2: Timing in the Statechart. Delayed transition occurs after n time-units.2.1.3 Statechart HierarchyHierarchy is the decomposition of a state into more basic states. It reduces the number oftransitions and clari�es the system behavior. The statechart in Figure 3 has the followinginterpretation: When a transition is made to the outer edge of a state which is furtherdecomposed, the sub-state containing the default entrance is entered (thick arrows in Figure).When a transitions from the outer edge of a state, which is further decomposed, is triggered,all states inside that state becomes inactive. e.g. if the state B is active and condition C1 isfalse, transition with label [not C1] will occur and B becomes inactive. When a transitionleaves the edge of a sub-state, the system must be in that sub-state for the transition tooccur. e.g. in order to trigger transition \E2", state A must be active. When a transition ismade to the edge of a sub-state, the state is entered whether or not that state is the defaultentry state (not shown in Figure).2.1.4 Statechart ConcurrencyThe notion of being in more than one state at any given time is handled through the prin-ciple of concurrency. The statechart in Figure 4 illustrates the and-line construct (dottedline), which denotes concurrency. State S2 is an and-state. The and-state may have manyconcurrent states. When an and-state is entered, all of its concurrent sub-states are entered(thick arrows in Figure). This is true whether the and-state is entered by a transition to itsouter edge or by a transition to any of its descendants. When an and-state is exited all of itsconcurrent sub-states are exited. This is true whether the and-state is exited by a transitionfrom its outer edge or by a transition from any of its descendants.7

Figure 3: Hierarchy in the Statechart. State S2 is decomposed into states A and B.

Figure 4: Concurrency in the Statechart. Each state can be converted to an and state withmany concurrent elements. 8

Figure 5: Synchronization in the Statechart. Several states can be synchronized using thejoint transition (thick arrow).2.1.5 Statechart SynchronizationThe combination of hierarchy and concurrency simpli�es the modeling of large, complexsystem. Concurrent processes (or individual statecharts) rarely exist independently. It istherefore, necessary to synchronize their interaction. A joint transition is one which combinestwo or more transitions with the same label (Figure 5). This transition will only occur whenall states that share the joint transition are entered and the conditions for transition are met.This is shown by the thick arrow. The resultant transition can generate an event which isused for synchronizing of concurrent processes in the scope of the statechart or can be usedto synchronize di�erent statecharts.2.1.6 Statechart Declutter & MergeAs the complexity of the design increases, the charts become messy and di�cult to under-stand. The decluttering mechanism permits the detail of any box to be de�ned in a separateo�-page chart. Its reference box is named with the pre�x \@". Diagram connectors are usedto mark the entry and exit points of the transitions in the de�ned chart. In order to illustratethe signi�cance of decluttering and its e�ect in separating the di�erent levels of hierarchies,we declutter the chart in Figure 6. Three states S1, C, and D are decluttered, and the resultis shown in Figure 7. As is seen, the name of each decluttered state is pre�xed by the sign(@) which means the state is the representation of a chart and is called box-is-chart. For9

Figure 6: Putting all details of the hierarchical states in a statechart, makes the chart messyand di�cult to understand.each decluttered state a separate chart will be generated and the link between the new gen-erated chart and the decluttered state is established. Logical Diving to a decluttered stateis a concept that causes the system to display the associated chart so that you can see thedetails of the state.Merge, the opposite concept of Declutter, causes the separate charts to be combined into onechart.2.2 Language of the Activity-chartsAn Activity-chart is a data- ow diagram with elements (syntaxes) such as: activities (edgedboxes), information ow (solid arrow), control ow (dashed arrow), data repository (boxwith dashed sides). A typical activity-chart is shown in Figure 8. The relation of the state-charts and activity-charts are through a special activity called control-activity (box @systemin Figure). This activity is in fact another statechart which controls the activation of itssibling activities.Statemate has three kinds of activities which di�er in the way that they terminate. Theactivation of all activities are controlled by activation of its parent activity or its siblingcontrol activity. 10

Figure 7: Decluttering in the Statechart, allows the details of the boxes to be de�ned in theo�-page charts.Procedure-like activity: This activity performs a set of actions upon its start and thenstops. It is active for one simulation step.Reactive-controlled activity: This activity has a control-activity. It can be active forseveral steps, but only stops when its control-activity terminates.Reactive-self activity: This activity is similar to the above activity, but it can also ter-minate by itself.Other important concepts in activity-charts are as follows:Mini-Speci�cation \Mini-Spec": The activity mini-spec is a textual behavioral descrip-tion which consists of a list of reaction/actions or actions. The mini-specs are de�nedthrough a data-dictionary form and become active when the associated activity is madeactive, and stopped when the associated activity is stopped. When a mini-spec is de-�ned for an activity, the sign \>" will be appeared after the name of the activity. Thisconcept is used in section 3.3.Context-Variables: Actions in transitions or mini-specs are performed simultaneously, i.ein transition label /A;B;C, actions A, B, and C occur at the same time. Contextvariables are variables whose value can change within a step. These variables have adollar sign "$" before their names. Context variables permit us to have For or While11

Figure 8: Activity-chart in Statemate. Edged-boxes are activities and rounded-box is thecontrol-activity.loops within a single simulation step. For example the only way to perform a loop ina mini-spec is as follow:For $x in 1 to 5loopxarray($x):=$x;end loop;This loop sets the 5 elements of the xarray() to the integers 1 to 5.Box-is-chart: Activity-charts like statecharts bene�t from the concept decluttering, andhence complex activities can be decluttered to produce o�-page charts. The declutteredactivity is called box-is-chart and its name is the name of the activity which is pre�xedby the sign \@". This concept is also used in section 3.3. It is immediately observedthat this method of hierarchical representation of the activities hides the unnecessarydetails of the design at a certain level of abstraction.Scoping of elements: Statemate tool uses a versatile data-dictionary which acts as a database and contains the information from all types of elements in the system. Data-items,events, and conditions should be explicitly de�ned in the data dictionary, where theyare bound to a statechart or activity-chart. This chart is the scope of the element, and12

the element can be shared among all activities or states of that chart and its o�spring.This scoping permits the designer to de�ne variables to be accessed by di�erent groupsof charts, some (global) variables accessible by all charts, and some (local) variablesaccessible to smaller group of charts.3 Design Example: Fast-Food Restaurant SystemWe1 used the Statemate tool for developing a system to control the di�erent units of afast-food restaurant. The project was large and consisted of four communicating unitsand one management unit. It is a typical team-work project and can be considered as abenchmark for evaluating software development tools. Figure 9 illustrates the physical viewof the restaurant. The acronyms OT, ASM, PREP, INV, and MGR are used for ordertaking, assembling, food preparation, inventory, and management units respectively. Theinformation ows, among di�erent units, are shown by thick vertical arrows, and the controldata from management unit are shown with thin arrows. Orders and payments are taken bysta� using touch-screen displays. food-preparation and delivery sta� view orders on displays,and register the status of the orders by pressing buttons on keypads. An inventory of thefood and supplies is tracked by the computer system. The restaurant manager is able tocon�gure the system to set menu items, ingredients, prices, inventory levels, and store setup.The speci�cation of the system is presented in the following section.3.1 System Speci�cationThis system assists the operations of various parts of the restaurant. The detailed systemspeci�cation is mostly extracted from Request For Proposal (RFP), and by consulting withthe client at the requirement analysis phase of the project. It is not the report's aim togo to the details of the design e�orts for this system. This speci�cation illustrates thedesign complexity of a system which can be implemented by the Statemate tool. Below, thespeci�cation of various units of the system, extracted form the RFP2, are presented.� Order-TakingOrder-takers stand behind the counter and enter the orders given by the customer.Menu items are selected by pressing the buttons on the screen. Selecting an itemcauses it to be added to the current order (which is displayed in a scroll-able windowon the screen). The subtotals and the tax of the cost of the order is displayed. Oncean order is completed, it must be paid, prepared, assembled and delivered to thecustomer. Payment of the order is performed by pressing the single or digit buttons.Single buttons are used to facilitate the payment. The system keeps the cash balanceof each order taker and has facilities for supporting the cash skims and cash oats of1This design is a joint work by Kamran Sartipi and Amir H. teimoortagh, department of computer science,University of Waterloo.2This is a modi�ed RFP, tailored for this report. the original RFP was given to students of the SoftwareEngineering course by Professor G. V. Cormack, May 1994.13

(OT

)

(ASM

)

(PR

EP

)

(MG

R)

(IN

V)

Figure 9: Physical View of the fast-food restaurant with four communicating units and themanagement unit. 14

each order taker. All of the monetary supervision is performed by the manager whohas the authority to access the manager screen. Each order is handled by only oneorder taker, however, the orders could be stored in a list and each order taker in thesystem can access this list to service the stored orders.� Food PreparationWhen an order is setup in the system, its items are distributed among di�erent prepa-ration stations which are equipped to prepare certain items of the restaurant menu.There may be more than one station capable of making a particular item. Each sta-tion has a screen and a keypad and the interaction with the system is reduced toa minimum. Similar items of di�erent orders are grouped together and, consideringthe items assigned to each station and its current load of work, the system decideswhether to send the items to the station or not. Menu items once prepared, are storedin the chutes to be accessible by the assembler sta�. There is one chute for each menuitem. The screen of the preparation-station displays a list of items and their quanti-ties. Kitchen sta� prepare the required quantity of an item, put them in the chute andusing the keypad marks that item. Menu items are prepared in response to the realand anticipated demands. Real demands are those requested which are initiated by thecustomers. Anticipatory demands denote the number of the items in the chutes beforethere exists any request for them. Anticipatory demands are set up by the manager toshorten the average time that customers wait for food.� AssemblingWhen the computer system determines that all items of an order are available in thechutes, the order can be assembled. Each station which is not busy, picks the orderand displays it on its screen. Stations use screen and keypad for interaction with thesystem and the computer system takes care of all the required communication withthe order taker and preparation sections. The assembler-person picks up the requirednumber of each item from the chutes and put them in the package or box, then usingthe keypad, informs the system. If the order is paid, the assembler delivers it to thecustomer, otherwise, the order is assembled but the delivery time will be postponed tothe time that the order is paid. If the system indicates that an order can be �lled, butthe chutes do not contain a su�cient quantity of some item, the shortage is indicatedusing keypad, and will be reported to the system so that it can be prepared.� InventoryThe inventory section in the system is responsible for keeping track of the consumptionof all the material used for preparation and packaging of the order-items. This unit hasa very close communication with the preparation unit and also sends some informationto the order-taker section. The system has a stock and the inventory of the rawmaterials is updated dynamically. The recipes of the menu items are also accessibleby this unit. The arrival of new materials to the storage is entered into the system bythe manager, and the consumption of the material is dictated by the recipes That arerequested by the food-preparation unit. To preserve the system integrity, the system15

assumes a minimum threshold for usage of each item in the system and if the numberof a certain menu item crosses this threshold, it is considered as an unavailable itemand the inventory section sends a message to the order-taker stations to avoid takingany further orders for those items.� ManagerThe manager in the system is authorized to access and modify any system information.Manager authority covers the following activities:{ Assigning the number of the active stations in order taking, preparation, andassembling units.{ Setting up the system tables such as: menu item table, item recipes, anticipateddemand for chutes, item batch size, and minimum item threshold, and inventorysupply items.{ Assignment of preparation stations to make each menu item.{ Assignment the amount of cash skim and oat.{ De�ning the name and rate for di�erent applicable taxes.{ Setting the system time and date.Each station in the system has a secured button on the keypad which can be used onlyby the Manager.3.2 Architectural DesignIn this part, the high level architectural design of the system is described. This design as-pect of the system is illustrated using the module-chart graphical editor of Statemate and isshown in Figure 10.The dashed boxes at the top and bottom of the Figure represent the external entities of thesystem such as customers and suppliers. At one side, the customers provide their Request-for-food as the input to the system and receive the Foods as the output from the system. Atthe other side the Suppliers provide the original materials for food preparation unit whichare again considered as input to the system. The system itself is bound to the system boxand consisted of the following boxes:1. Order-Taking:This module consists of several order-taker stations which receive their input fromthe external entity Customers in the form of verbal requests for food items. At theinterface to this module,3 the restaurant sta� using the touch screen panels selectthe menu items and set up orders for the customers. The system will keep track ofthe orders as a bunch of related items with a unique number throughout the system.3The terms module and unit both are used for the boxes.16

CHUTES

INVENTORY

ASSEMBLING

ORDER_TAKING

ORDERS

CONTROLAND_DATA

AND_DATACONTROL

CONTROL

CONTROL

AND_DATA

FOODS REQUEST_FOR_FOOD

CUSTOMERS

SUPPLIERS

SUPPLIES

MATERIAL

SUPPLIES

ORDERS

ORDERS

ITEMS

MATERIAL

ITEMS

SYSTEM

FOOD_PREPARATION

GERMANA ORDER_ITEMS

Figure 10: The Architecture of the restaurant system is shown using the module chart ofStatemate.The order-taking unit gathers each order-item and puts them in a repository which islabeled orders. Order-taking stations insert each order in an order-queue to be usedby the Assembling module.2. Assembling:This module is located after the order-taking module and may seem to be in thewrong place, since logically, the orders should �rst be prepared and then be assem-bled. There is a reason for this architecture; the system assumes the ordered-itemsare already prepared and exist in the chutes, hence they are ready to be assembled.The assembling-unit has two layers in its structure. The top layer inspect the ordersof the order-queue to see if they can be assembled or not. It receives the orders andchute-items from the repositories orders and chutes respectively and checks the itemsof each order against the chute-items. If an order is ready for assembling, it is sent tothe lower layer to be assembled. The top layer also informs the food-preparation unitto prepare the items of the orders. At the lower layer, a set of assembling-stations existwhich display the items of an order in a station screen. The sta� then assemble anddeliver the orders to the customers and using keypads inform the system. In Figure10, the delivery of the orders to the customers is shown by an arrow labeled Foods.3. Food-Preparation:This module is responsible for getting the requested quantities of the individual menuitems from the assembling unit and preparing them. The interface to the assembling17

module is provided by a list of the required quantities for each menu-item. This moduledoes not know anything about the orders. There is a coordinator program in this unitwhich takes the requested items and distributes them among the preparation stations.Each station is equipped for preparing parts of the menu items, and it is possible thatmore than one station is assigned for preparing of certain items. The coordinator shouldbalance the work loads of the various stations. Each item along with its distributedquantity is displayed on the screen of a preparation station. The sta� then preparethe items and put them in the chutes and, using the keypad, inform the system. TheFood-Preparation unit has access to the raw material through a repository which islabeled Supplies.4. Inventory:This module is responsible for keeping the inventory list of all the raw materials requiredfor food preparation. This unit receives the supplies from the suppliers and updatesthe inventory list. Preparation of the menu items in the kitchen is traced by this unit.It deducts the used materials for food or packaging from the available materials. Theinventory always knows how many of each menu-item can be made by the system.Should the number of the items, still possible to be prepared in the kitchen, reacha minimum threshold, The inventory inhibits the ordering of that item in the order-taking unit.5. Manager:The manager-module has the key responsibilities in the system. When the systemis �rst started, this module is activated to setup the system parameters, lists andcon�gurations. This module can also be activated, whenever the Manager decides tochange the system lists. It can modify or update the main lists used by other modules,and/or control their activities.3.3 Functional and Behavioral DesignIn the above discussion, the Architectural Design of the system was described and the highlevel functional decomposition using the module chart illustrated in Figure 10. In order tohave a precise and clear perspective of the system activity, its architectural design should bedescribed in terms of Functional and Behavioral design.In general, each software system performs its duties using two conceptually distinct activitiesas was described in section 2.1. Functional Design:The functional design of the complete system, using an activity chart, is shown in Fig-ure 11. The chart consists of several activities (edged boxes) and two external activities(dashed boxes). The rounded box, labeled @system-cntl is a control activity and infact it is not an activity chart. This box is responsible for controlling the activation18

SYSTEM

ORDERS

CHUTE_IN

@MANAGER

SYSTEM_INIT>

CUSTOMERS

ORDERS

FOOD@ORDER_TAKER_UNIT

@ASSEMBLY_UNIT

CHUTE_ITEMS PREP_ORDER

PREP_INCHUTE_OUT

SUPPLY_REQUEST

@SYSTEM_CNTL

@INVENTORY

@FOOD_PREP

PREP_OUT

SUPPLIERS

INFO_FLOW_OUT

INFO_FLOW_IN

SUPPLIES

TIME_STAMP

ORDER_IN

Figure 11: Activity-chart of the restaurant system. The boxes with the pre�x of \@" areo�-page charts.and stopping the activities or o�-page charts de�ned in this chart.A brief comparison of the functional design with the architectural design of the system(Figure 10) reveals the similarities between them. The �ve main modules in architec-tural design still exist as �ve individual activity-charts (the sign @ means the box ischart). The manager-module in the former Figure is now an independent chart whichimplicitly controls the other units of the system.As we already mentioned, in the Statemate environment each data-item, condition, orevent should be bound to a single chart in the system. This mechanism determines thescope of the variables which causes the availability of those variables to the activitiesin that chart and its descendent charts. For example those data-items, conditions,or events which are de�ned in the scope of the system activity-chart, are accessibleby all of the activities and charts in the restaurant system. In our system all of thesystem-parameters and lists, which should be setup by the Manager, are de�ned in thescope of the activity system. Therefore, the manager chart can access and manipulateall the lists in the system. These system-variables are also accessible to the other19

main charts in the system (i.e. order-taking, assembling, food-prep, and inventoryunits). This global usage of variables, makes the chart clean and easily understood.In fact, the need for drawing information- ows and control- ows from manager box toother boxes in the chart system is eliminated. Although communication using globalvariables has several bene�ts, it has its own disadvantage of not hiding the informationfrom untrusted modules in the system. The system-init box is the only activity in thischart It is responsible for loading initial setups for the system data structures. Thesign \ > " shows that this activity has a mini-spec assigned to it.2. Behavioral Design:The behavioral design of a software system expresses the control mechanism required tosequence di�erent activities in the system, and provide the means for parallel executionand required synchronizations in the system. In Figure 12 the state-chart system-cntlis shown. This chart is the control activity we introduced in the previous section.It has one and-state (parallel-cntl) including �ve parallel states. These �ve stateswill be active when the parallel-cntl state is active, and will be stopped when thestate is inactive. The chart system-cntl starts its operation by initializing the system-parameters in the state system-init-s>. In this state the activity system-init in Figure11 is activated which initializes the system-parameters. The system does not wait inthis state and moves to state manager-s. The condition-variable cold-start becomestrue which indicates the cold start has been completed. In the current state, the boxmanager in Figure 11 is started. This box is connected to the o�-page chart manager,hence the manager unit is active to manipulate various lists and system-parameters.When the manager has completed his task, he presses the key manager-ended and thesystem stops the manager unit and enters the concurrent state parallel-cntl. In thisstate all four units of the restaurant system become active. The state @management-cntl in the parallel states enables the Manager to enter the system when the system isoperational to change some of the system lists. To shutdown the system, the managerpresses the key corresponding to the event shut-down-key. Then the whole system willbe stopped by going to the terminator connector.3.4 Data OrganizationThe design of data structures for the system is controlled by the available data types inthe Statemate tool and these are not ample. Below, the main data types available in theStatemate 5.0 are shown.� Integer: single and array.� Real: single and array.� String: single and array. Each single string is an array of characters.� Bit: single and array. 20

PARALLEL_CNTL

SYSTEM_INIT_S>

MANAGER_S>

ORDER_TAKER_S>

ASSEMBLER_S>

FOOD_PREP_S>

INVENTORY_S>

@MANAGEMENT_CNTL

SHUT_DOWN_S>

SHUT_DOWN_KEY

/COLD_START:=true

MANAGER_ENDED/COLD_START:=false

SYSTEM_CNTL

T

SHUT_DOWN_ENDEDFigure 12: Statechart of the restaurant system. Concurrent states control the di�erent unitsof the restaurant.Statemate 5.0 does not support Records, which are essential in design of systems. The newversion Statemate 6.0, contains Records, Unions, and Queues as new data-types. Anothershortcoming of Statemate which restricts the performance of the design is the lack of dy-namic memory allocation. The size of the lists and tables must be carefully determinedbeforehand and further expansion or contraction of the lists is not easily possible. Withthese de�ciencies, the task of data design becomes di�cult. To create an array of structures,several arrays with di�erent types must be used. For example the information about all ofthe orders in our system are kept in 25 separate arrays. Using this number of arrays, westill have a restriction on the number of the items in an order. The design procedure for theorder data structure is explained below.Each item has a Name, Quantity, and Unit Price. The name is a string of characters butsince each menu-item has a �xed place in the menu-list, it can be identi�ed by a code. Thequantity and unit price can be de�ned by real numbers. An array of real numbers is used forthese three pieces of information. This array is for only one item of the order, and each ordercan have many items. Now we should decide on the maximum number of the items in the or-der which in turn should be a �xed number (we do not have dynamic allocation). We decidedthat an order can have at most 20 items, so we need 20 arrays. Other information about anorder consists of: Subtotals, Total, Entered time, Paid Time, and Assembled Time. Enteredtime denotes the time that the order has been completed by the order-taker. The lack of exible data types increases the number of data structures. Restricted access to these ar-21

rays is also another issue which hinders the design of the activities which work on these data.In such an environment which imposes a huge number of data structures, the naming proce-dure is an essential factor. A classi�ed and meaningful name helps the designer to rememberand to �nd the desired variable with the minimum e�ort. The availability of a Data Dictio-nary for searching the variables by their names is also another motivation to use the classi�ednames.3.5 User Interface DesignDesigning of an interface to a software system has always been one of the essential designe�orts. Creating a mouse driven, menu driven, windowing system interface is desired inany system. Existence of modern Window Systems such as X11 and versatile Window Man-agers such as OSF/Motif facilitate the development of sophisticated man-machine interfaces.These facilities provide a series of default features for the design tool which eases the designtask. Still the main task of the design tool is to employ these available mechanisms and pro-vide some higher level means for system developer to easily design a man-machine interface.The variety of the interface design widgets de�ne the richness of the syntax of the user-interface designer. The semantics of the interface, on the other hand, express interactionsbetween the design widgets in the interface and design elements in the system. For example,semantics de�nes how a particular display in the user-interface screen can communicate witha running process in the system. Various methods of triggering an event from the keyboardof the system is another example.The Statemate integrated tool, has a rather sophisticated built-in user interface design toolcalled the Panel Graphic Editor. This panel-editor uses the X11 window system and Motifor Open Window window manager to provide exible window manipulations such as: ex-panding, shrinking, and moving the window, utilizing a spectrum of colors and fonts. Usingthe Network features of the X11 window system such as Remote Display, enables Statematetool to set up the user-interface of the system in any host computer or X-Terminal across theNetwork, independent of the location of the running program. This allows to easily designmulti-screen systems.In Figure 13 the Panel Graphic Editor of Statemate is shown. A part of the order takingpanel is also shown. The design of the user-interface (Panel) in Statemate is easily performedusing a variety of panel elements which are de�ned below:� Push Button: Is mainly used for triggering an event to the system or changing thevalue of a condition.� Radio Button (vertical and horizontal): Is mainly used for changing the values ofthe conditions.� Lamp (Indicator with label L): Shows the change of a condition or occurrence of anevent in the system. 22

Figure 13: Panel Graphic-Editor of Statemate. Using a variety of design widgets, sophisti-cated user-interface panels can be easily implemented.23

� Text Display (square with label DISP): Is used for inputing (or outputting) of textto (from) the system.� Measuring Display (circles or slider): Is used for indicating the values of the vari-ables.� Primitive Elements: These are primitive shapes such as circle, square, arch, line,and polynomial which can be gathered in groups to constitute composite �gures. Bycontrolling the di�erent attributes of these groups of primitives such as: Visibility,movement, color, rotation, and scale, the resulting �gure looks like an animation.The combination of the panel visual-elements presents quite a wide range of design optionsfor the user-interfaces. It should be mentioned that the panel editor has also some restric-tions. For example we cannot overlap a display region over the push-button region of thescreen.Bindings: Each element of the panel should be bound to one of the variables (Data-item,Event, or Condition) in the system.For example the push-buttons are usually used to trigger an event in the system. Theevent is bound to the label of an arrow in the state-chart so it causes the system to make atransition and change its state. Radio-buttons are usually bound to conditions, so pressinga button causes a condition to become \true". Conditions like the events are used as a labelof an arrow in state-chart and this condition will also make a state transition. Text displaysare always bound to the string data-items and are used for inputting or outputting of text.Writing a text string to the corresponding data-item will cause the text to be shown on thedisplay. Typing in the region of the text-display causes it to be directly re ected in thedata-item. The versatility and ease of use of the panel editor, greatly reduced the designe�ort for the user-interface of the system.4 Designing of a Reactive SystemA typical design using the Statemate tool can be started from any of the two conceptuallydi�erent aspects of the system, its functionality or its behavior. If the system has massivedata processing, the activity-chart is a good point to start the design, and if the system ismainly event-driven, the statechart is the better choice.4.1 Top-Down / Bottom-Up DesignThe box-is-chart feature of the Statemate permits developing a design in di�erent styles, i.e.top-down, bottom-up, or mixture of both. This feature allows further decomposition of ahigh level design into its lower level details, as well as integration of individual design parts,developed by di�erent designers, into a higher level chart. In the latter chart, each designpart is represented as a chart-is-box. The project-manager feature of Statemate permits24

a controlled access to the charts, hence provides a safe and isolated environment for eachmember of the design group to develop his/her design. The version controller of Statemategenerates a new copy of each chart of the system upon its modi�cation.Designing a large reactive system requires precise following of the design life-cycle principlesof software engineering. A brief introduction to the di�erent design life-cycles is presentedin the appendix of this report. Statemate permits a spiral style of designing a system. Usingthe hierarchical structure of the charts, the designer is capable of creating a prototype modelof the system from its speci�cation. The simulator tool is used to simulate the functionalityof the prototype to detect possible errors or any inconformity with the system requirements.Potential errors can be detected early in the design process, preventing the high cost oferror detection when they are revealed at the later stages of the system development. Therequirement traceability tool of the Statemate can also be used for this.In the design of the fast-food restaurant, The activity-chart system (Figure 11) and the state-chart system-cntl (Figure 12) represent the interconnection of various units and their overallcontrol mechanism at the highest level of abstraction. Statechart system-cntl controls theoperation of the activity-chart system. In subsequent loops of the spiral, by functional de-composition of the activities in activity-charts, and hierarchical decomposition of states inthe statecharts, more details of the design are implemented and the system is incrementallyenhanced. At each level of design, the simulator tool is used as a means of ensuring thecorrectness of the system. Considering the two highest level charts mentioned above, wecan generate a chart associated with each box labeled by an "@" sign (box-is-chart). Thenwe can proceed with developing the operations assigned to that box in more detail. Thisoperation in fact creates one lower level of abstraction in our design. For example the chartassembly-unit in Figure 14 is the result of generating a chart for the box assembly-unit. Thischart itself does not contain the lowest level of design details and consists of three o�-pagecharts and two instances of the generic-chart asm-generic (this concept will be describedlater). Each of the o�-page charts and the generic chart are complex charts. From the abovediscussion we conclude that top-down designing of a system is a suitable approach for a largeproject, and the Statemate tool provides the required facilities in this regard. Certainly,top-down design style requires a well de�ned functional partitioning of the system at thehighest level of the design.In our experience with the design of the fast-food restaurant, we were uncertain about howexactly the highest level of charts would look like. Therefore we decided to use the bottom-updesign style. From investigating the system requirements some of the functions of each unitof the system emerged. e.g. In the order-taker unit, operations such as setting up an orderfrom di�erent menu-items, getting the quantities of each item, computing the price of theorders, deleting an item, scrolling the lists, and so on. For us, this point seemed to be a goodpoint to start. The functional decomposition of the units revealed the main data-structuresof the system which unfortunately had to be tailored to the available data types of Statemate5.0. This phase of the project was a frustrating part and we were obliged to sacri�ce some25

PREP_IN PREP_OUT

CHUTE_IN

CHUTE_OUT

PREP_ORDER CHUTE_ITEMS

@ASSEMBLY_DIRECTOR

@ASSEMBLY_UNIT_CNTL

@ASM_INSTANCE_CNTL

ASM1<ASM_GENERIC

ASM2<ASM_GENERIC

CHUTE_SHORTAGE

INST_OUT

INST_IN

READY_ORDERS

CMPLT_ORDERS

ORDERS

ASSEMBLY_UNIT

ORDER_IN

ORDER_OUT

INSTANCESFigure 14: Activity-chart of the assembly-unit. This chart consists of several o�-page chartsand two instances of the generic-chart asm-generic.of the exibilities of the system to match our needs. This part of the design resulted in aset of basic functions of the system which were implemented in di�erent activities in a largeactivity-chart. The activity-chart order-taker-generic is responsible for all the required tasksperformed in each order-taker unit. Its chart is shown in Figure 15.The next step in the design process is the input/output design. The design of a reactivesystem is dominated by the number and nature of external and internal signals. In a heavilyevent driven system the input/output characteristics of the system are crucial and shouldbe speci�ed at the early stages of the design. A thorough investigation of the system isrequired to de�ne what input signals the environment produces to the system and whatsignals and information the system produces in response. The design of the user-interfacedisplays and keypads directly a�ects the design of data-structures and the control design.In the restaurant system, the order-taker panel could be designed with di�erent sets of in-put/output elements having the same functionality. For example, the selection of an itemin the order-screen can be done using scroll-up and scroll-down buttons, or using separatepush-buttons beside each order-item.In the order-taker panel which is shown in Figure 16, 40 push-buttons for generating eventsto the system, in addition to 6 arrays and 12 single data-items for displaying the information,are used. The system contains at least two order-taker stations, two assembler-stations, 526

SHIFT_ORD_ITMS>

SET_CASH>

SUBTOT_TAX_TOTAL>

SET_ITM_PRICE>

TEST_DBLE_CMPLT>

RECALL_ORDER>

STORE_ORDER>

SET_CHANGE>

ERASE_LAST_ITM>

SET_PAID_TIME>

CMPLT_ORD

SELECT_ITM>

CMPLT_ORD_TO_Q>

DATE_TIME>

@OT_GENERIC_CNTL

ORDERS

INFO_FLOW_OUT

INFO_FLOW_IN

PUT_ORD_TO_GLOB>

GET_ORD_FROM_GLOB>

SET_NEW_ORD>

GET_QNTY_FROM_NO>

GET_DIGIT_MAKE_NO>

SET_ITM_UPRICE>

MENU_SCRL_UP>

MENU_SCRL_DWN>

ORD_SCRL_UP>

ORD_SCRL_DWN>

OSCRN_UPDATE>

INIT_MENU>

SELECT_ORDER>

ORDER_TAKER_GENERIC

Figure 15: Activity-chart order-taker-generic consists of all the basic activities required fordi�erent tasks in one order-taker station.preparation stations, and a manager and inventory station. The large number of input andoutput signals and information which must be handled concurrently in this system highlightthe importance of the design of the control parts in reactive systems.Designing the functions and input/output signals of the units suggests how the control partof these functions should be. Therefore we proceed with designing of the control parts to ac-tivate the functions in response to the incoming signals. A reasonable solution is to assign aseparate statechart to each logically independent input signal, which monitors the activationof the signal. Groups of similar signals can be monitored in one statechart (e.g. the signalsassociated with the decimal digits of the keypads). These simple charts are easily designedand tested. A parent statechart is then used to gather them in a group which provides them aconvenient connection to the activity-chart whose functions must be controlled by this groupof statecharts. For example the statechart select-itm-cntl in Figure 17 monitors the pressingof the 10 item-select keys in the order-taker screen. The system waits in the reactive-stateget-select-key-s> for a select-key to be pressed. When the key is pressed, the system getsthe number of the key and proceeds with selecting the associated menu-item and displaysit in the order-screen of the order-taker terminal. To do this task, the chart activates theactivities select-itm and update-screen in the activity-chart order-taker-generic. The overallcontrol and synchronization of these sibling charts are discussed in the next section.The parent statechart order-taker-generic-cntl is shown in Figure 18. This chart consists of12 box, each represents an o�-page Statechart. Statechart select-itm-cntl is one of them. This27

Figure 16: The order-taker panel of the fast-food restaurant system. A typical order is shownon the order-screen. This panel consists of many keys and displays which interact with thestatecharts of the order-taker unit. 28

SELECT_ITM_CNTL

SELECT_ITM_S>

UPDATE_SCREEN_S>

E_NOTGO

E_GO

E_GET

E_SKIPEXIT

CMPLT_ORD_ITEM_GET_TEST>

ITEM_INACTIVE_TEST>

GET_SELECT_KEY_S>

S3>

E3

[ITMSEL_FLAG]

E_CMPLT_SENSED[ITMSEL_FLAG]

Figure 17: Statechart select-itm-cntl is responsible to monitor the pressing of the item-selectbuttons on the order-taker panel.concurrent chart controls the activities in the activity-chart order-taker-generic in Figure 15.The above design style has several advantages. It is straightforward. The functionality ofthe system can easily be modi�ed or enhanced which facilitates the system developmentprocess. Adding extra features to the system is accomplished by adding a control box in theparent statechart, adding the required functions to the parent activity-chart, and designingthe o�-page statechart which monitors the input signals. Since the design is modular, theerror detection and correction in the maintenance phase is not a di�cult task. The methodis feasible because of the usage of global variables which are accessible to all of the chartsin this unit. This is done by binding the variables to the parent activity-chart order-taker-generic. As we are aware of the disadvantage of de�ning global variables, information hidingis not achieved in this method.4.2 Concurrency in a Reactive-SystemMajor problems in a system consisting of a number of concurrent processes include thesynchronization of the processes' operations and their inter-process communication throughshared memory (IPC).4.2.1 SynchronizationBy synchronization we mean each process should wait until one or more processes reach acertain point in their execution. A large reactive system is exposed to a number of internal29

ORDER_TAKER_GENERIC_CNTL

@MSCRL_UP_DWN_CNTL

@OSCRL_UP_DWN_CNTL

@DELETE_ITM_CNTL

@SELECT_ITM_CNTL

@DELETE_ORD_CNTL

@DATE_TIME_CNTL

@GET_QNTY_CASH_CNTL

@RECALL_ORD_CNTL

@STORE_ORD_CNTL

@INIT_MENU_ORD_CNTL

@COMPLETE_ORD_CNTL

@SEL_RECALL_ORD_CNTLFigure 18: Statechart order-taker-generic-cntl is the parent of all of the statecharts in order-taker unit which provides the concurrent execution environment for them.and external signals, which in most cases are random in nature and can occur simultane-ously. To clear up this situation, a kind of distributed control mechanism is needed to reactproperly to the arriving signals. An example of this situation is random button pressing inthe order-taker station. Each button triggers a signal (event). A normal sequence of buttonpressing for taking an order consists of, selecting menu items, followed by their quantities.This sequence ends with inputting of the amount of cash to the system. There are a greatnumber of combinations of signals which are possible and only a small number of them areallowed.How can the overall control-mechanism be implemented? Centralized-control mechanismscannot be applied since managing the di�erent threads of control make it a very complicatedprocedure. A distributed-control mechanism is appropriate. The overall control sequenceis divided into pieces that are separately assigned to each process to control itself. Manag-ing this distributed-control mechanism in concurrent programming languages is done usinga binary semaphore. The P and V operations are used to synchronize the activation ofparallel-processes. The P operations in front of each process invocation control the activa-tion of it and the V operations at the end of the process signal the activation of the nextscheduled processes. By initialization of the semaphores, the �rst scheduled process(es) willbe assigned. The activation sequence is easily made in this manner. This simple mechanismcan also be used in statecharts. A condition variable can be assigned to each concurrentchart to control its operation. The activation of each chart (process) in this reactive system30

depends on two parameters. First, the condition-variable assigned to the chart must be true,and second, the signal which is monitored by this chart is triggered. All of the statechartsin the order-taker unit are controlled in this fashion. The chart recall-order-cntl is chosen toillustrate this method. This chart is shown in Figure 19.E9

S9>

SET_NEW_ORD_S>

RECALL_ORDER_S>

OSCRN_UPDATE_S>

E_RECALL[RECALL_FLAG]

RECALL_ORDER_CNTL

Figure 19: Statechart recall-order-cntl. S9 is a reactive-state and is responsible for synchro-nization of the chart operation with other sibling charts.When the system is working, all of the 12 concurrent statecharts in Figure 18 are active andall are in their standby states (the blank state in Figure 19), waiting for external signalsto be triggered. All condition variables of the charts are initialized to false other than onechart (item-selection chart Figure 17). In this situation neither of the control buttons on thisunit works and only item-select buttons are enabled. In fact pressing each button triggersan event, but the associated condition-variable prevents the operation of the correspondingchart. When the item-select chart �nishes its operation, it is responsible for assigning thenext allowed operation(s). This is performed by manipulation of the condition-variables ofthe other charts in a reactive-state. In the case of our example, when the condition recall- ag is true, and the event e-recall is triggered, The chart operates and performs its duties.It then enters to state S9 and speci�es which signals are allowed afterward (changes theirconditions to true), and which signals are inhibited (changes their conditions to false). Thecontents of state S9 is shown below./RECALL-FLAG:=false;;/SELRECALL-FLAG:=true;;/ORDER-FLAG:=true;;/EXITRECALL-F:=true;; 31

/ITMSEL-FLAG:=false;;/E9;4.2.2 Inter-Process CommunicationInterprocess communication (IPC) is another important feature of concurrent systems. Inconcurrent textual languages there are some constructs which allow private access to shareddata-structures which is essential for communication in concurrent environments. The keypoint in these constructs is the kernel support for atomic operations which manipulate someprotected variables. For example, changing the value of the semaphore-variable S in P andV operations is done atomically. In Statemate, the transitions and procedural-activities areexecuted in one simulation step. In a typical execution of a concurrent system, many of suchactivities exist which are executed at the same step. As we experienced in the design of thisproject, Statemate atomically executes all of these activities, hence permits private accessto a shared data.In our design, there is an order-bu�er that is shared between the chart assembly-director,which puts one ready-order in it, and assembly-stations which race to get the order to as-semble it. This is a typical relation of the producer and consumers with a single bu�er. Inorder to inspect the solution to this problem, a chart producer-and-consumer is used whichconsists of one producer and three consumers. This chart is shown in Figure 20.Two condition-variables bu�er-full (buf-f) and data-used (d-used) are employed to ensurethat the data is loaded into the bu�er, only when the consumer has removed the previousdata, and the data will be used only when the producer has put new data in the bu�er. Stateput-data-in-buf in the producer state P, and state get-data in consumer states C1 to C3 arecritical-sections which should be privately accessed. The mechanism is very simple. Produceris allowed to start the communication by putting data in the bu�er, the consumers can thenget the data from the bu�er. In the worst case when some or all of the consumers are racingfor accessing the data, a simple mechanism provides mutual-exclusion. In transition fromthe state wait to the state test-winner, all the racing consumers simultaneously put their IDin a data-variable (winner). In the state winner-test they all test the winner to see whoseID is written in it. The consumer whose ID is in winner, trigger the event WINx (x can be1, 2 , or 3) and proceeds. The other consumers trigger the event LOSEx and return to waitstate. In Figure 20 consumer two has won and will get the data from the bu�er. The mainpoint in this solution is the parallel and atomic execution of the actions in the transitionwith label: [BUF-F]/fs!(BUF-F); WINNER:=x;When all of the consumers are in the wait state and the bu�er is full, in the next simulationstep all can proceed and make a transition to the next state. In this transition the conditionvariable buf-f becomes false, and the data-variable winner is set, and all these 3 assign-ments are done in zero time (theoretically). Condition-variable buf-f controls whether the32

/tr!(BUF_F);fs!(D_USED);

/fs!(BUF_F);tr!(D_USED);

PORCESS

C2WAIT

GET_DATA

/tr!(D_USED)

WIN2

PORCESS

C3WAIT

GET_DATA

/tr!(D_USED)

WIN3

[BUF_F]/fs!(BUF_F);WINNER:=2;


PRODUCE_NEXT_DATA

PUT_DATA_IN_BUF

WAIT

[D_USED]

P

PRODUCER_AND_CONSUMER

PORCESS

C1WAIT

GET_DATA

/tr!(D_USED)

WIN1


LOSE1

LOSE3 LOSE2

TEST_WINNER>

TEST_WINNER> TEST_WINNER>

Figure 20: This chart illustrates the typical example of the producer and consumer. Stateput-data-in-buf in the producer chart, and states get-data in the consumer charts are criticalsections. 33

consumers enter their critical sections, and d-used controls whether the producer enters itscritical section. These conditions are similar to the P operation in a binary semaphore. Theprocesses, waiting in a state to enter their critical sections, are not blocked by the systemhence they consume the CPU while waiting for an event. This is known as busy waiting.Other forms of process communications such as bounded-bu�er are also feasible with theabove solution. In the restaurant system the order-taking stations provide orders and putthem in a FIFO queue, and the assembly-director chart is responsible for removing themfrom the queue and assembling them. Their access to the shared bu�er can be resolvedusing the above mechanism.4.3 InstantiationIn the example producer-and-consumer presented above, there are three consumer chartsC1, C2, and C3 which are the same except for the name of the events and the ID numberof the charts. This method of directly copying the same chart for several times has somedrawbacks. The number of the charts in the system increases. New charts and their asso-ciated variables should be de�ned in data-dictionary, and other time consuming redundantworks. The concept of generic-chart and the use of its instances instead of the real charts isa solution to this problem which is o�ered by the Statemate tool.Statecharts and activity-charts can be de�ned as a generic-chart. This concept provides theability to instantiate di�erent charts which encourages the designer to reuse the availablecharts. The idea is to create a generic-chart which performs a desired task and use it inother places without copying it. The chart is de�ned completely independently of the othercharts of the system. When we wish to use one or more instances of that chart, we de�nean activity or state using a special naming pattern.Name of Instance < Name of generic chartAs a result, the activity or state becomes an instance of the generic chart. Formal parame-ters at the generic-chart side and Actual Parameters at the instance side are the means ofcommunicating the values of the variables between the generic chart and its instances. Theseparameters should be bound together using the data-dictionary forms of the instances. Thismethod of instantiation available in Statemate has some disadvantages which prevents thedesign of a exible software system. For example:� The system does not support parameterized instantiation. This means each instancemust be graphically de�ned, hence preventing a variable number of instances in thesystem.� To create each instance, all of the actual-parameters should be explicitly declared inthe system. There is no way of automatic creation of instances as in the fork() functionin the language C. 34

To better illustrate the concept of generic-chart, we convert the example of producer-and-consumer chart into three separate charts as follow:1. Chart producer, which is a regular chart (Figure 21).2. Chart consumer, which is a generic chart and many instances of it can be de�ned inthe system (Figure 22).3. Chart producer-consumer, which is a parallel-state (AND state) and consists of thebox producer, and three instances of the generic-chart consumer (Figure 23).\tr!(BUF_FULL);fs!(DATA_USED);

/fs!(BUF_FULL);tr!(DATA_USED);

PUT_DATA_IN_BUFFER

PRODUCE_NEXT_DATA

PRODUCER

[DATA_USED]

WAITFigure 21: The producer o�-page chart is waiting to enter its critical section.WAIT

LOSER

WINNER

/tr!(DATA_USED);

CONSUMER

TEST_WINNER_ID>

GET_DATA

PROCESS_DATA

/[BUF_FULL];fs!(BUF_FULL);WINNER_ID:=CONSUMER_ID;

Figure 22: One of the instances of the generic-chart consumer which is entering its critical-section.When the chart producer-consumer is activated, generates three instances of the generic-chart consumer which are completely similar. These instances communicate with each other35

CONSUMER_2<CONSUMER

CONSUMER_3<CONSUMER

CONSUMER_1<CONSUMER

@PRODUCER

PRODUCER_CONSUMER

Figure 23: The parent chart producer-consumer provides concurrent execution of the pro-ducer chart and 3 instances of the consumer chart.and with producer via their actual parameters which are: data-used, buf-full, winner-id, andconsumerx-id. In binding of these parameters to the formal-parameters of generic-charts, thename of the parameters are the same in both sides. For example buf-full (actual-parameter)in each instance-chart is bound to the buf-full (formal-parameter) of the generic-chart. Theonly di�erence which causes the instances to be distinguished form each other is the parame-ter consumerx-id. For example: consumer1-id is the actual parameter for instance one. Thisparameter is de�ned as a constant in the data-dictionary and has the value 1. It is boundto the consumer-id of the generic-chart consumer. The same method is used for the othertwo instances. Therefore when three instances are generated, the variable consumer-id is1 for instance number one, and is 2 for instance number two, and so on. In this way theinstances of a generic-chart can be separated and assigned to di�erent tasks. This method ofseparating di�erent instances of a generic-chart is similar to the way that the child-processesare distinguished in the fork() function call of the language C. Each child-process returns itsprocess-ID to the parent-process, providing a means for the parent to assign di�erent jobsto the child-processes.In our restaurant system we extensively used the generic-chart concept in allocating severalstations to order-taking, assembling, and preparation units of the restaurant. In fact thewhole order-taker unit is designed as a generic activity-chart (Figure 15) consisting of 26activities. In this way the number of order-taker stations can be easily increased. No designe�ort is needed in increasing the number of order-takers but binding the actual-parameters ofeach instance to the user-interface elements such as buttons and displays is a time consumingtask. The assembly-stations in the assembling unit of the restaurant are also instances of ageneric-chart asm-generic. In Figure 14 two activities are at the bottom which are responsiblefor creating two instances of the assembly-stations (asm1 and asm2). The activation and36

termination of these stations are controlled by the control-activity asm-instance-cntl. Thepreparation unit of the restaurant also uses the instantiation method.5 Evaluation of StatemateIn this part the Statemate tool is evaluated against a number of criteria we proposed asa result of our initial research on graphical system design tools on July 1994. The designof the fast-food restaurant system with Statemate was mainly performed to obtain a goodunderstanding of the di�erent aspects of graphical tools and the facilities provided by themto ease the design task and also the design restrictions and drawbacks resulted by them. Inthe following section after each criterion the Statemate is assessed for that aspect and theexplanations are in italic form.5.1 Data-dictionaryAvailability of a support tool for de�ning non-graphic elements. Also its features: whatclasses of elements are allowed, data-types, etc.Statemate has a data-dictionary tool which provides separate forms for each system elementsuch as: chart (simple or generic), variables (data-items, conditions, and events). Theforms are well designed and contain all required information about a particular element.Name searching feature of the data-dictionary which accepts the star-character as wildcardeases the search through the data-base.5.2 Completeness as a design documentationHow system capabilities to capture a design, satisfy application system requirements:� Finite vs in�nite (application systems)� Types of requirements: Can they be captured?{ Functionality{ Maintenance{ Performance{ Security{ etc.Statemate provides a variety of documentary and reporting formats for the design whicheases the future references to the design. Statemate's project manager produces severalversions of the design elements, developed by di�erent design team members. Thisinformation is kept in a central data base and using a hierarchy of authorizations, itprotects the information against unauthorized team members.37

5.3 Code generationProperties of automatically synthesized code:� Size: How big is executable compare to manually written similar piece of code.� Functionality: What kind of activities can be supported.� Performance: How fast is it executed compare to manually written similar piece ofcode.� Back-end tools: What tools are available on the market that a generated code can befed to directly.� Availability: Is code generating tool available.� Standardization: Is a code produced a standard version of the language.� Correctness: How correct is generated code.� Completeness: Are all application system features implemented or just part of them.� Portability: How easily code is transportable from one platform to another.Statemate generates standard C and Ada codes for the designed system. We are notcompletely sure about the code correctness. According to an experience with the designof a thermostat system, The generated code completely conformed with the designedspeci�cation. We run the code on Unix system consisting of various machines whichindicate code portability of the Statemate. The size of the generated code is rather largeand can not be compared with the hand written code.5.4 Customization:Ability to incorporate already designed systems (code) into larger systems.One major advantage of the Statemate tool is its integrability with the modules written in Cor Ada. Statemate has a simple interface mechanism for re-using the existing code.5.5 Reusability of speci�cation:How easy it is to create home libraries of the designed systems and are any of them alreadyavailable?This feature is not directly supported by Statemate. The concept of generic-chart and in-stantiation provides the facility of using the instances of a generic-chart in di�erent places.Therefore we can create a local library of generic-charts and then use the instances of them.38

5.6 Project management:How application system design process is organized, how easy it is to partition a job betweenseveral designers, what is the level of security, etc.Statemate has a project manager which easily provides a secure environment for each designerto divide the design in between. The version control of the Statemate tool creates a newversion of each chart upon its modi�cation.5.7 Application interface design support (panel):What tools are available for the design of the interface of an application system.The Panel-editor tool of Statemate provides a number of widgets which ease the task of userinterface design. The variety of types and functionality of these widgets and the use ofnetworking aids to easily design a multi station user interface.5.8 Environment modeling support:How environment can be simulated other than by actual user interaction (availability of anenvironment simulating language that enables the system to run in a batch mode).Statemate uses a speci�c language called Simulation Control Language for supporting thiskind of system simulation. The language is used to write a program for sequencing thesimulation process, and for providing di�erent stimuli in proper instances.5.9 Customized design documents:What kind of user documentation support tool on a designed application system is available.Statemate provide a number of documentation protocols. It produces di�erent types andstructures of documents which eases the documentary task. This facility aids the futurereferences to the system for further enhancements or maintenance.5.10 Di�erent views of design:How a designed application system can be represented (charts, ow-graphs, code, diagrams,etc.)Statemate can represent a system with three di�erent views such as: functional, behavioral,and physical. The system behavior can also be represented by a block of code called mini-speci�cation. 39

5.11 Traceability:What kind of tools are available to provide a mechanism for linking application system ele-ments with system requirements.Statemate bene�ts from the requirement-traceability tool which associates each system ele-ment to a speci�c part of the system requirement.The above evaluation indicates that Statemate contains almost all the expected aspectsof a graphical design tool. Its power in describing the system speci�cation in three distinctconcept, its dedicated user-interface tool, and its capability in di�erent modes of speci�cationsimulation which aids the debugging process, make it a rather ideal integrated design toolfor a wide range of systems from pure software, pure hardware, or combination of hardwareand software.6 ConclusionStatemate provides an environment for developing large reactive systems. It consists ofdi�erent design tools such as: graphical editors for designing functional and behavioralcharacteristics of the system, simulation, code generation, a project manager, etc. Thisreport introduced the semantics of the statecharts and activity-charts with examples foreach. The step by step design procedures of a large reactive system (a fast-food restaurant)was described. Top-down and bottom-up design styles using the concepts of declutteringand o�-page charts were explained. Functional decomposition of the system and de�ningthe basic functions in mini-specs of the activities is the basis for designing activity-charts.In most designs activity-charts are the �rst step. Data structures and input/output designare the next steps. Designing of the data-structures is crucial since Statemate 5.0 has manyshortcomings in this regard. User-interface design in Statemate is easily performed using thededicated panel-editor. Various bindings of variables to the charts or to the panel elementsare done in the data dictionary. De�ning the external signals to the system and separatecontrol sequences for small parts of the system function is the key to the design of thestatecharts. Lower level charts of the system can be easily integrated into parent chartsto provide a higher level of abstraction in system design. Techniques for synchronizationand communication among concurrent charts were described and the instantiation of thegeneric-charts along with their advantages and disadvantages were discussed. At the end,using a number of criteria, the Statemate tool is evaluated and its merit as an ideal systemdevelopment environment is indicated. 40

AppendixIn this part various styles of design life-cycle are brie y presented.Classical life-cycle :This design style starts with analyzing the system requirements, presented by a RFP(Request For Proposal). This information is not complete, therefore the analyst in-vestigates the RFP and asks the customer for more information on the system andreviews it several times until a detailed system speci�cation is obtained. The designerthen designs the system based on the speci�cation and code is written based on thedesign. The program is tested against the speci�cation. Sometimes, backward stepsare needed if the design is not following the speci�cation. In this method a workingversion of the program will not be available until late in the project, therefore someerrors are undetected until the working program is reviewed.Prototyping :Based on the information supplied by the customer, a quick design of the system is per-formed and an executable program is implemented. This prototype is then evaluatedby the customer and if it conforms with the requirements, re�nements and other detailsare added to its speci�cation and the complete design is obtained and implemented incode.Spiral model of life-cycle :This model is based on the prototyping model and gradual improvement of the systemthrough some loops. An initial system-requirement is arranged and a risk analysis isperformed to see if the project is feasible or not. If yes, its prototype is implementedand is evaluated by the customer. This evaluation generates new requirements andre�nements. The next loop of the spiral is begun by planning a new speci�cation fromthe new requirements which is then analyzed for its risk. If passed by the risk analysis,the next prototype is implemented and evaluated by the customer, and the previousprocedures are repeated until the last version of the system is implemented or theproject is rejected in one of the phases of the risk analysis.41

References[1] i-Logix inc. Statemate User Reference Manual Version 5.0. June 1993.[2] i-Logix inc. Languages of Statemate. January 1991.[3] R. S. Pressman. Software Engineering, A Practitioner's approach, third edition. MCGraw Hill, 1992.[4] K. Sartipi. Design Documents for the Veggie Vittles System. Department of ComputerScience, University of Waterloo, March 1995.

42