1 / 35

SFWR ENG 3KO4 Software Development

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

gcrooks
Download Presentation

SFWR ENG 3KO4 Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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. • Graphical Editors • Data Dictionary • Check Model • Simulator • Code Generator • Panel Generator • Project Manager

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

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

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

  7. The Syntax of Event [Condition] / Action Chart Basic State Transition Or - State and - State

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

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

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

  11. Concurrency in Statecharts All concurrent components become active:

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

  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. Synchronization in Statecharts ... • Activation of the state S1 is synchronized with the activation of States S2 and B.

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

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

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

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

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

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

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

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

  23. Decluttering in Statecharts ... 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.

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

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

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

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

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

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

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

  31. WINNER:=1; fs!(D_USED) WINNER:=3; WINNER:=2; Inter Process Communication ... • 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. Instantiation in the • 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. Name of Instance < Name of generic-chart • Formal-Parameters & Actual-Parametersare the means for communicating the values of variables.

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

  34. Instantiation in the Restaurant System • 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.

  35. Conclusion • Statemate has shortcomings in: • Semantics of module-charts • Data Types and dynamic memory allocation • Parametric Instantiation • 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.

More Related