Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 SFWR ENG 3KO4 Software Development Statemate I-CASE Tool for Designing Software Systems from Different Views Statemate I-CASE Tool for Designing Software.

Similar presentations


Presentation on theme: "1 SFWR ENG 3KO4 Software Development Statemate I-CASE Tool for Designing Software Systems from Different Views Statemate I-CASE Tool for Designing Software."— Presentation transcript:

1 1 SFWR ENG 3KO4 Software Development Statemate I-CASE Tool for Designing Software Systems from Different Views Statemate I-CASE Tool for Designing Software Systems from Different Views Dr. Kamran Sartipi Dept. Computing and Software McMaster University Hamilton, ON, Canada

2 2 Outline ã Introduction ã Language of the Statemate ã Design Example: Fast-Food Restaurant System ã Conclusion

3 3 ã Graphical Editors ã Data Dictionary ã Check Model ã Simulator ã Code Generator ã Panel Generator ã Project Manager A CASE Tool For Designing Reactive Systems Reactive systems receive a large number of external and internal signals of the form Event or Condition, hence they are sometimes called event driven systems. The system reacts to the signals and performs different tasks accordingly. The examples of such systems include: avionic systems, telephone and communication controller, robots, etc.

4 4 Three Specification Views of a System ã Functional ã Behavioral ã Structural Introduction..

5 5 The Language of : Functional View : Functional View : Behavioral View : Behavioral View : Structural View : Structural View Data Dictionary Forms: Data Dictionary Forms:

6 6 The Language of Statecharts ã State, Transition, Step ã Timing ã Hierarchy ã Concurrency ã Synchronization ã Interrupt ã Declutter & Merge Concepts of:

7 7 The Syntax of ChartBasic State Or - State and - State Transition Event [Condition] / Action

8 8 Timing in Statecharts IDLE DATE_TIME_S> tm(en(IDLE),2) Z A transition may occur on time-out bases. tm(e,n) tm(e,n) e: event, n: System time-unit

9 9 Hierarchy in Statecharts ã Previous Step: m State S1 was active. m Event E1 was triggered. ã Current Step: m State S2 is active. (S2 is a hierarchical state) m State A is active.

10 10 Hierarchy in Statecharts... ã Previous step: m State A was active m Condition C1 was False ã Current Step:  State S1 becomes active

11 11 Concurrency in Statecharts All concurrent components become active:

12 12 Concurrency in Statecharts... All Concurrent components become inactive:

13 13 Synchronization in Statecharts Using joint transition, Concurrent states or independent Statecharts can be synchronized Sequence of events: (S1) [C1]  (S1, A)  (S2, A) E1  (S3,B) en(S3)  (S3,A) E1  (S2, B)  (S1)

14 14 Synchronization in Statecharts... ã Activation of the state S1 is synchronized with the activation of States S2 and B.

15 15 Interrupt in Statecharts Interrupt handeling using history and deep-history connectors Interrupt handeling using history and deep-history connectors

16 16 Interrupt in Statecharts... Event CONT INUE is triggered  C1 and D1 activate

17 17 Interrupt in Statecharts... Condition C1 is False  AND state S3 is Deactivated  B1 is active

18 18 E1 is triggered State B2 is active. Interrupt in Statecharts... ã An external device requests a service by triggering the event INT_REQ.

19 19 Control is transferred to the interrupt handler. Interrupt in Statecharts...

20 20 ã Entrance through history connector activates the state in its own level, which was active: S1 ã Entrance through deep history activates the deepest state which was active: B2 Interrupt request has Z Interrupt request has been serviced, and the signal INTA is generated. Interrupt in Statecharts...

21 21 Decluttering in Statecharts Decluttering mechanism permits to define the details of any box in a separate off-page box.

22 22 Decluttering in Statecharts... The decluttered state is called Box-is-Chart, and its named is prefixed by a @ sign.

23 23 fetches the chart associated to the box. Logical Diving to a Box-is-Chart fetches the chart associated to the box. Diagram connectors mark the entry or exit points of the transitions. Decluttering in Statecharts...

24 24 Merge in Statecharts ã Merging is the opposite concept of decluttering ã Charts C and D have been merged into the chart S1.

25 25 p Defines the functionality of the system. p Involves the concepts such as: u Control-Activity. u External-Activity. u Mini-Specification. u Hierarchical construct. u Decluttering and Merging. u Data stores The Language of

26 26 The Syntax of Activity-Charts Activity IN OUT @ SYSTEM POWER_On/OFF EXECUTE INIT A OPERATE RESET B Z Activity Control-Activity Control-Flow Data-Store Data -Flow External- Activity Chart

27 27 Designing a large Reactive System with ã Requirement analysis and System Specification. (Requirement Traceability) ã High-level Design & Test. (Graphical Editors & Simulator) ã Detailed Design & Test. (Box-is-Chart Concept) p Data-Structure Design. (Data Dictionary) p Functional and Behavioral Design. (Graphical Editors) p User-Interface Design. (Panel Generator) ã Implementation. (Code Generator) P Team Project & Version Control. (Project Management)

28 28 Design Example: ã Order-Taking unit. ã Assembling unit. ã Preparation unit. ã Inventory unit. ã Management unit. Z System Specification: This System controls different activities in a typical Fast-Food Restaurant, and consists of Five communicating units: (OT) (ASM) (PREP) (MGR) (INV)

29 29 Detailed Design: User-Interface ã Order-Taker screen consists of 40 buttons to generate events as inputs and 18 text- displays as outputs. Z User-Interface design of a reactive system is crucial. Z Bindings of the Z Bindings of the Panel- to the Elements to the Variables of the charts are performed in the Data-Dictionary Forms.

30 30 PRODUCER_AND_CONSUMER Inter process communication Distributed control Z Distributed control mechanism for private access to the shared- memory WINNER:=1; WINNER:=3; WINNER:=2; fs!(D_USED) An example of producer-consumer Z Key point: atomic execution of the actions in one transition

31 31 Inter Process Communication... WINNER:=1; WINNER:=3; WINNER:=2; fs!(D_USED)  Conditions D_USED & BUF_F control the Producer and Consumers to enter their critical sections respectively.  Variable WINNER determines which consumer can access to the shared buffer. (Consumer C2)

32 32 Instantiation in the An independent produces copies of a statechart or activity-chart (Reusability). Z An independent Generic-Chart produces copies of a statechart or activity-chart (Reusability). To create an instance of a generic-chart, an activity or a state with a special naming pattern is used. Z To create an instance of a generic-chart, an activity or a state with a special naming pattern is used. Name of Instance < Name of generic-chart  Formal-Parameters & Actual-Parameters are the means for communicating the values of variables.

33 33 Instantiation in the... Producer & Consumer example fs!(DATA_CONSUMED; WINNER_ID:= CONSUMER_ID; CONSUMER Generic-Chart Instances of the Generic_Chart Off-Page Chart Box-is-Chart Box-is-Chart

34 34 ã Order-Taking Stations, Assembling Stations, and Preparation Stations are Instances of different Generic activity-charts. ã For each instance, binding of the panel elements to the actual-parameters is done in Data- Dictionary. Instantiation in the Restaurant System

35 35 Conclusion ã Statemate has shortcomings in: p Semantics of module-charts p Data Types and dynamic memory allocation p Parametric Instantiation p User-interface generator ã Statemate is good for modeling and simulating the System behavioural. The System functionality can then be implemented in C or Ada languages ã Statemate has a long learning curve.


Download ppt "1 SFWR ENG 3KO4 Software Development Statemate I-CASE Tool for Designing Software Systems from Different Views Statemate I-CASE Tool for Designing Software."

Similar presentations


Ads by Google