CISC836: Models in Software Development: Methods, Techniques and - - PowerPoint PPT Presentation

▶
cisc836 models in software development methods techniques
SMART_READER_LITE
LIVE PREVIEW

CISC836: Models in Software Development: Methods, Techniques and - - PowerPoint PPT Presentation

Aug 21, 2022 316 likes •749 views

CISC836: Models in Software Development: Methods, Techniques and Tools Languages: UML-RT I Juergen Dingel Jan, 2017 UML-RT CISC836, Winter 2017 1 Modeling Modelica Languages Physical systems Equation-based Simulink

slide-1
SLIDE 1

UML-RT CISC836, Winter 2017 1

CISC836: Models in Software Development: Methods, Techniques and Tools

Juergen Dingel Jan, 2017

Languages: UML-RT I

slide-2
SLIDE 2

Modeling Languages

increasing generality increasing domain-specifity EGGG [Orw00] Examples in [Voe13, Kel08] UML Stateflow

  • Reactive systems
  • Discrete control
  • State-machine-based

AADL

  • Embedded, real-time

UML-RT

  • Embedded, real-time
  • State-machine-based

UML MARTE

  • Embedded, real-time

Simulink

  • Continuous control, DSP
  • time-triggered dataflow

Lustre/SCADE

  • Embedded real-time
  • Synchronous dataflow

Modelica

  • Physical systems
  • Equation-based

2 UML-RT CISC836, Winter 2017

slide-3
SLIDE 3

UML-RT: History

Real-time Object-Oriented Modeling (ROOM)

  • Early 1990 ties
  • ObjecTime Ltd

Major influence on UML 2

UML-RT CISC836, Winter 2017 3 [SGW94] B. Selic, G. Gullekson, and P.T. Ward. Real-Time Object-Oriented Modellng. Wiley. 1994

slide-4
SLIDE 4

UML-RT: Core Concepts

  • System: collection of capsules (instances) communicating via messages
  • Capsule (instances):
  • Active class (object) whose behaviour defined by a state machine
  • Communicates by sending and receiving messages through its ports
  • Port: typed by protocol defining input and output messages
  • State machine:
  • Transition triggered by incoming messages
  • Action code can contain send statements that send messages over certain ports

UML-RT CISC836, Winter 2017 4 [drawn with Papyrus-IM]

slide-5
SLIDE 5

Capsules

UML-RT CISC836, Winter 2017 5

  • Kind of active class
  • Instance executes in its own thread of control
  • (A)synchronous method invocation
  • Processing of messages follows ‘run-to-completion’

semantics

  • Creation and use of instances tightly controlled
  • Instances created by runtime system (RTS) and cannot be

passed around

  • No public attributes or operations

⇒ better concurrency control and encapsulation

  • Behaviour defined by state machine
  • May have ports over which messages can be sent

and received

slide-6
SLIDE 6

Capsule Parts/Roles

UML-RT CISC836, Winter 2017 6

Instance of a capsule stored in an attribute

  • f another capsule

Owned by a capsule

  • Created and destroyed by owning capsule

Similar to parts in Composite Structures (a.k.a., Structured Classes) in UML 2.5

slide-7
SLIDE 7

Passive Classes/Data Classes

Similar to regular classes Not executing in own thread Behaviour defined through operations Typically used to define data structures and operations on them

UML-RT CISC836, Winter 2017 7

slide-8
SLIDE 8

Protocols

UML-RT CISC836, Winter 2017 8

  • Provides type for ports
  • Defines input, output, and

input/output messages

  • Input messages
  • Services provided by capsule
  • wning port
  • Output messages
  • Services required by capsule
  • wning port
slide-9
SLIDE 9

Ports

UML-RT CISC836, Winter 2017 9

  • “Boundary objects” owned by capsule instance
  • Typed over a protocol
  • Have ‘send’ operation
  • port1.msg2(arg1,...,argn).send()
  • Can be
  • base (not conjugated)
  • conjugated

° Direction of messages declared in protocol is reversed

base conjugated

slide-10
SLIDE 10

Connectors

UML-RT CISC836, Winter 2017 10

Connect two ports Ports must be compatible

  • Both are instances of same protocol
  • Either (asymmetric)

° one is ‘base’ (i.e., not ‘conjugated’)

qtypically owned by ‘client’

° and the other is ‘conjugated’

qtypically owned by ‘server’

  • Or (symmetric)

° only InOut messages

slide-11
SLIDE 11

Ports: 5 Different Kinds

External behaviour

  • Provides (part of) externally visible functionality (isService=true)
  • Incoming messages passed on to state machine (isBehaviour=true)
  • Must be connected (isWired=true)

Internal behaviour

  • As above, but not externally visible (isService=false)
  • Connect state machine with a capsule part

Relay

  • Pass external messages to and from capsule part

Service Provision Point (SPP) and Service Access Point (SAP) System

UML-RT CISC836, Winter 2017 11

relay internal external external

  • r relay
slide-12
SLIDE 12

System Ports

Provide access to services in Run-time System (RTS) library

  • Timing: setting timers, time out message

° timer.informIn(UMLRTTimespec(10, 0)); // set timer that will expire in 10 secs and 0 nanosecs

° When timer expires, ‘timeout’ message will be sent

  • Log: sending text to console

° log.show(“Ready to self-destruct\n”)

  • Frame: incarnate, destroy capsules

System port: Port connecting capsule to RTS library via corresponding system protocol

UML-RT CISC836, Winter 2017 12

Application code

(generated or hand-written)

RTS Library Target OS Target HW

slide-13
SLIDE 13

Example: PingPong

UML-RT CISC836, Winter 2017 13

slide-14
SLIDE 14

Example: Rover

UML-RT CISC836, Winter 2017 14

slide-15
SLIDE 15

Example: Door Lock System

UML-RT CISC836, Winter 2017 15

slide-16
SLIDE 16

State Machines

States

  • Capture relevant situations during lifetime
  • f object
  • Determine how object can respond to

incoming messages

  • May have invariants associated with them

Pseudo states

  • Don’t belong to description of lifetime of
  • bject

⇒ object cannot be ‘in’ a pseudo state

  • Helper constructs to define complex state

changes

Transitions

  • Describe how object can move from one

state to next in response to message input

UML-RT CISC836, Winter 2017 16

slide-17
SLIDE 17

States and Pseudo States

States

  • Kinds:

° Basic ° Composite (in hierarchical state machines)

  • May contain

° Entry action (written in action language) ° Exit action (written in action language)

UML-RT CISC836, Winter 2017 17

Pseudo states

  • Kinds:
  • Initial,

choice point

  • In hierarchical

state machines: history, entry points, exit point

choice point exit point history entry point initial state initial transition

slide-18
SLIDE 18

Transitions

Transitions

  • Kinds:

° Basic ° Group (in hierarchical state machines)

  • Consists of

° Triggers

qTransitions out of pseudo states (initial, choice) don’t have triggers qTransitions out of non-pseudo state should have at least one trigger

° Guards (optional, written in action language) ° Effect/Actions (optional, written in action language)

UML-RT CISC836, Winter 2017 18

t[g]/a Trigger

Specifies port and message

Guard

Boolean condition that must hold

Effect/Actions

Code that is executed when transition is taken

s1 s2

slide-19
SLIDE 19

Action Language

Language used in

  • guards to express boolean expressions
  • entry action, exit action, transition effects to read and update

attribute values, send messages

Typically: C/C++, Java ⇒ State machines are a hybrid notation combining

° graphical notation for state machines and ° textual notation for source code in actions

⇒ UML and UML-RT State Machines

° different from, e.g., Finite Automata ° closer to ‘extended hierarchical communicating state machines’ [Alu03]

UML-RT CISC836, Winter 2017 19

[Alu03] R. Alur. Formal Analysis of Hierarchical State Machines. Verification: Theory and Practice. 2003.

slide-20
SLIDE 20

Entry Action: Example

UML-RT CISC836, Winter 2017 20

slide-21
SLIDE 21

State Configuration

  • States can be active: flow of control resides at state
  • If a substate is active, its containing superstate is, too
  • State configuration: list of active states
  • Stable state configuration: no pseudo states and ends in basic state
  • Example: <play, player1Move, waitForHand>

UML-RT CISC836, Winter 2017 21

slide-22
SLIDE 22

Transition Execution

1. Machine in stable state configuration 2. Message m1 has arrived and is dispatched 3. If dispatching enables no transition, m1 is ‘dropped’ 4. If dispatching enables transition t,

  • Source state of t active,
  • message matches trigger of t, and
  • guard evaluates to ‘true’

5. then transition t executed

  • a. Execute exit action of source state of t (if any)
  • b. Execute action code of t (if any)
  • c. Execute entry code of target state of t (if any)

6. If target of t is pseudo state

  • a. continue by choosing and executing outgoing

transition (i.e., goto 5.)

7. Machine in stable state configuration

UML-RT CISC836, Winter 2017 22

… m5 m4 m3 m2 m1

drop drop drop fire fire

…

slide-23
SLIDE 23

Run-to-Completion

The event processing of state machines follows ‘run-to- completion’ semantics Dispatching of message triggers execution of possibly entire chain of transitions (Steps 5 and 6 on previous slide) Execution lasts until stable state configuration has been reached (last state in transition chain not a pseudo state) During transition execution, no other message will be dispatched ⇒ better concurrency control

UML-RT CISC836, Winter 2017 23

slide-24
SLIDE 24

Group Transitions

Source state is composite Example:

  • Suppose active state config is: (play,player2Move) and transition

‘reset’ becomes enabled,

  • Execution of ‘reset’ results in which new stable state config?

UML-RT CISC836, Winter 2017 24

slide-25
SLIDE 25

History

Re-establish full state configuration that was active when containing state was active most recently Example:

UML-RT CISC836, Winter 2017 25

slide-26
SLIDE 26

Self Transitions

  • Source and target states are the same
  • 2 kinds: external, internal
  • External: source state (and all substates) exited and target state entered

UML-RT CISC836, Winter 2017 26

slide-27
SLIDE 27

Self Transitions: Internal

Source state (and all substates) remain active; no exit or entry actions executed

UML-RT CISC836, Winter 2017 27

slide-28
SLIDE 28

Example: Ping Pong

UML-RT CISC836, Winter 2017 28

slide-29
SLIDE 29

Example: Door Lock

UML-RT CISC836, Winter 2017 29

set timer “doors open”; “hit key to lock” getchar(); lockPort.lock().send() “doors locked”; “hit key to open” getchar(); lockPort.unlock().send() “lock”+i+”locked”; lockPort.lockStatus(true).send

slide-30
SLIDE 30

UML-RT CISC836, Winter 2017 30

UML-RT: Tools

Commercial

  • RoseRT (IBM)
  • RSA-RTE (IBM)
  • eTrice (Protos)

Open source

  • Papyrus-RT

° https://www.eclipse.org/papyrus-rt/

slide-31
SLIDE 31

UML-RT CISC836, Winter 2017 31

CISC836: Models in Software Development: Methods, Techniques and Tools

Juergen Dingel Jan, 2017

Languages: UML-RT II

slide-32
SLIDE 32

Replication

Some elements can be replicated

  • attributes, ports, and parts (all instances of UML-meta type ‘Property’)

In controller

  • cPort.m().send()

would send m to all doors

  • cPort.m().sendAt(2)

would send m only to one door

UML-RT CISC836, Winter 2017 32

slide-33
SLIDE 33

Run Time Services (RTS) Library: Capsules

UMLRTCapsule (in umlrtcapsule.hh)

  • Methods

° string getName()

qname of capsule part

° string getTypeName()

qname of capsule

° int getIndex()

qindex of capsule part

UML-RT CISC836, Winter 2017 33

slide-34
SLIDE 34

Run Time Services (RTS) Library: Communication (1)

  • UMLRTOutSignal
  • Methods

° bool send(priority)

q asynchronous q priority argument optional q if port replicated, send over all instances

° bool sendAt(index, priority)

q to specific instance of replicated port (indices are 0-based)

° int invoke(replyMsg)

q synchronous, i.e., sender blocks until reply is received q mimicks ‘operation call’

  • Properties

° Messages sent over same connector received in same order they’ve been sent (unless application is distributed) ° Delivery of messages to unbound ports will fail ° Delivery of messages that don’t trigger transition, will be dropped with error message ° If message data has type descriptor, it will be copied and passed by value

UML-RT CISC836, Winter 2017 34

slide-35
SLIDE 35

Run Time Services (RTS) Library: Communication (2)

  • UMLRTMessage
  • Base type for messages

° Created upon send signal event; refers to signal being sent and its ‘payload’ ° Signals separated from messages, so that different messages can refer to same signal (for broadcast signals)

  • Methods

° bool defer()

q Put message into ‘defer queue’

UML-RT CISC836, Winter 2017 35

slide-36
SLIDE 36

Run Time Services (RTS) Library: Communication (3)

  • UMLInSignal
  • type of input signals
  • methods

° bool recall()

q Move messages from defer queue to message queue

UML-RT CISC836, Winter 2017 36

slide-37
SLIDE 37

Run Time Services (RTS) Library: Communication (4)

  • UMLRTProtocol
  • Base type for port protocols
  • Implemented as LIFO queue
  • Methods

° bool registerSAP(string)

q Non-wired ports with ‘RegistrationKind=Application’ have to be wired programmatically q Registers this port as SAP port with RTS to allow for dynamic binding from SPP q Example: ‘p1.registerSAP(“myService”);’

° bool registerSPP(string)

qRegisters port as SPP providing service with name ‘string’ and automatically connects with matching SAP ports qTypically, one SPP port and multiple SAP ports

° bool deregisterSAP() ° bool deregisterSPP()

UML-RT CISC836, Winter 2017 37

slide-38
SLIDE 38

Run Time Services (RTS) Library: Timer Services

  • UMLRTTimerProtocol
  • Type of timer ports
  • Methods

° UMLRTTimerId informAt(UMLRTTimespec)

q ‘one-shot’ timer, absolute q Example: 'UMLRTTimespec now; UMLRTTimespec::getclock(now); timer.informAt(now + UMLRTTimespec(5, 0));'

° UMLRTTimerId informIn(UMLRTTimespec)

q ‘one-shot’ timer, relative q Example: 'timer.informIn(UMLRTTimespec(5, 0));‘

° UMLRTTimerId informEvery(UMLRTTimespec)

q Periodic timer q Example: 'timer.informEvery(UMLRTTimespec(5, 0));‘

° cancelTimer(UMLRTTimerId)

  • UMLRTTimespec
  • Supports comparison (e.g., ‘<‘,’>=‘, ‘==‘) and simple manipulation (e.g., ‘+’, ‘-’)

UML-RT CISC836, Winter 2017 38

slide-39
SLIDE 39

Run Time Services (RTS) Library: Logging Services

  • UMLRTLogProtocol
  • Type of log ports
  • Methods

° log(primitiveType)

q With newline appended

° show(primitiveType)

q No newline appended

° cr(int)

q Output newlines

UML-RT CISC836, Winter 2017 39

slide-40
SLIDE 40

Run Time Services (RTS) Library: Frame Services

  • UMLRTFrameProtocol
  • Type of frame ports
  • Methods

° bool destroy(UMLRTCapsuleId) ° UMLRTCapsuleId incarnate(UMLRTCapsuleClass)

UML-RT CISC836, Winter 2017 40

slide-41
SLIDE 41

The RTS is actually not that big

UML-RT CISC836, Winter 2017 41