1 / 9

State Model for Active Class Two-State

State Model for Active Class Two-State. State Model Name : TS:Two-State (behaves like an RS Flipflop with set and reset inputs). Default initial state = TSS0. TSE01:Set. TSS0:OFF AR1: no-op. TSS1:ON AR2: no-op. TSE02:Reset. State Transition Diagram (STD) Notation:.

hedy
Download Presentation

State Model for Active Class Two-State

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. State Model for Active Class Two-State State Model Name: TS:Two-State (behaves like an RS Flipflop with set and reset inputs) Default initial state = TSS0 TSE01:Set TSS0:OFF AR1: no-op TSS1:ON AR2: no-op TSE02:Reset State Transition Diagram (STD) Notation: • States = Nodes, labeled by State (ST) names *1 • (e.g. TSS0 :OFF is the name of state S0 in State Model TS) • Transitions = Links with labels = Event (ET) names *2 • (e.g.,TSE01:ON is the label of the transiton from OFF to ON in State Model TS) • Inputs = Event Type (ET) parameters • (Event Instances (EI’s) of all types are queued for serial execution.) • Outputs = State Codes + Action Routine effects. • (Action Routines are called on state entry and are event-dependent) • 1 Beginning State Names with the State Model tag and S# is a S&M:OLC convention • 2 Beginning Event Names with the State Model tag and E## is a S&M:OLC convention

  2. Two-State Flipflop –TSStateModel.dat File Content • TwoState STDiagram stored in the StateModel SM.dat file: • (SchemaVersion table entry omitted; EventType.Label field syntax restructured as in the revised ChkgAcct.ppt case study. • This file is generated by LCP from string constants for each SM.) • SM000001 SV000001 TS TwoState /* equiv. to an RS Flipflop */ • /*-------------------- (comment lines are ignored by pr_load) ----------------*/ • ST000001 SM000001 TSS0:Off no-op /* Initial state:output=0 */ • ST000002 SM000001 TSS1:On no-op /* Alternate state:output=1*/ • /*-------------------------------------------------------------------------------------------*/ • TR000001 ST000001 ST000002 /* enabled by set event */ • TR000002 ST000002 ST000001 /* enabled by reset event */ • /*-------------------------------------------------------------------------------------------*/ • ET000001 SM000001 ET01:TSSet /* causes ON-to-OFF TR */ • ET000002 SM000001 ET02:TSReset /* causes OFF-to-ON TR */ • /*-------------------------------------------------------------------------------------------*/ • EN000001 ET000001 TR000001 /* TSset enables TR1: ST1->ST2 */ • EN000002 ET000002 TR000002 /* TSReset enables TR2: ST2->ST1 */

  3. Event Communication Examples - 1 Sample OCD for three inter-comunicating objects AC2, AI2 AC1, AI1 TIE03:SetTImer OPerator TImer OPExx::TImeUp TSE1:ON TSE2:OFF AC#, AI# identify the ActiveClass and ActiveInstance superclass instances corresponding to these object instances. AC3, AI3 TwoState [Ref: Shlaer&Mellor: Object Life Cycles, P-H 1992] • An OCD defines event communication paths between Objects but does not show object’s internal behavior in terms of the interaction among states, events and transitions. • Three active objects from different active classes are shown. • TImer and OPerator are built-in service classes. • Multiple instances of these service classes can be created dynamically at run time.

  4. Event Communication Examples - 2 OCD for three ActiveClass types: AC1, AI4 AC2,AI5 TIE1:SetTimer * OP01: OPerator TI01: TImer OPE2:TimeOut TSE1:ON TSE2:OFF In this model, the OPerator is a client of a TImer instance, which provides support by notifying the OPerator when it is time to reset machine TS01. AC3, AI6 TS01: TwoState

  5. Event Communication Examples - 3 OCD for three ActiveClass types, when TImer forwards replies for OPerator AC2, AI8 AC1, AI7 TIE1:SetTimer OP02: OPerator TI02: TImer TSE1:ON TSE2:OFF AC3, AI9 TS02: TwoState In this example, the OPerator (client) instance OP02 tells its TImer (server) instance TI02 to forward a different reply, an instance of the event type with label “TSE02:OFF”, to a third TwoState machine instance TS02.

  6. Event Communication Examples - 4 OneShot (single pulse) Generator as a client of a TImer instance: StateModel OneShot: OCDiagram: (a variable-width single-pulse generator) (OSE01 is from OPerator, OSE02 is from TImer) AC1, AI10 OSE01:ON OS03: OPerator ON: GenEvent (TIE03:SetTimer, ...) OFF OSE02:OFF OSE01:TimedON(ttg) AC2, AI11 AC4,AI12 TIE03:SetTimer TI03: TImer OS01: OneShot OSE02:OFF

  7. Event Communication Examples - 5 OCD: Periodic use of OneShot pulse generator OneShot is called at an operator-controlled repetition rate (1/pd). The one-shot turns itself off with the help of its timer TI05. AC1, AI13 AC2, AI14 TIE03:SetTimer(pd) OP04: OPerator TI04: Timer OPE02:OFF OS01:TimedON(pd) AC2,AI16 AC4,AI15 TIE03:SetTimer(pw) OS04: OneShot TI05: TImer OSE02:OFF

  8. This Pulse Generator turns its output on and off with the help of two timers. One timer replies toPG03 with event PGE01:on and the other timer replies with PGE02:off. Both are repeatedly generated in PG state PGS1. Event Communication Examples - 6 OCD: Variable-width, Variable-frequency Pulse Generator AC2, AI19 AC1,AI17 TI06: Timer PGE01:init(pd, pw) TIE01:SetTimer(pd) OP05: OPerator PG01:PulseGen PGE01:on AC5,AI18 TIE01:SetTimer(pw) PGE02:off AC2, AI20 StateModel of PulseGen: PGE01:init(pd,pw) TI07: TImer PGS0:INIT: Store args; GenEv(PGE02:off) PGE02:off PGS1:Off: ActionRoutine is: GenEvent (TIE01:SetTimer, TI06, PGE01, pd); GenEvent(TIE01:SetTimer, TI07, PGE02, pw). PGE01:on PGE02:off PGS2:ON: (No Action)

  9. Event Communication Examples - 7 OCD: Pulsegenerator with one timer AC1, AI21 PGE03:Quit OP06: OPerator AC5, AI22 PG02: PulseGen PGE01:init(pd,pw) TIE3:SetTimer (pd-pw, TI08, PGE01:on) TIE3:SetTimer (pw, PG02, PGE02:off) StateModel for PulseGen: AC2, AI23 PGE01:on PGS0:INIT: Store args; GenEv(PGE02:off) PGE01:init(pd,pw) TI08: TImer PGE02:Off PGE02:off • This Pulse Generator turns itself on and off alternately using only one timer. • Reply events alternate between ON and OFF. • Event arguments must be saved inside PG. • One event could toggle between PG states. • Instance id's are denoted OP06, PG02, TI08. • The OPerator can send a PGE03 event to quit generating pluses. • A Timer Queue Manager could handle multiple setTimer events on a priority queue. • See:$PH/2kf522/TQManagerProjects2kf/jdmccart PGS1: OFF: ActRoutine is: GenEvent (TIE01:SetTImer (pd-pw, PG02, PGE01:on)); PGE03:Quit PGE01:on PGE02:off PGE03:Quit PGS2:ON: ActRoutine is: GenEvent(TIE01:SetTimer (pw, PG02, PGE02:off))

More Related