elevator 2.0 leon, leland and lloyd starr m o d e l i n t e g r a t i o n, l l c a detailed look at...

Elevator 2.0

Leon, Leland and Lloyd Starr

M O D E L I N T E G R A T I O N, L L C

A DETAILED LOOK AT AN xtUML CASE STUDY FOR DEVELOPERS AND ARCHITECTS

||

Rev 1.0 2

The Elevator Project

+ Build a complete working xtUML project

+ Demonstrate practical analysis and modeling techniques

+ Highlight good and bad in the development environment

+ Build GUI, equipment and platform independent models

+ Do it in our spare time

Rev 1.0 3

Familiar application

Stable requirements

Easy to reverse engineer

Multiple domains to explore

Why an Elevator?

Rev 1.0 4

Analysis and Modeling Goals

+ No manager classes- No functions masquerading as classes

+ Good domain separation- Reusability, portability, platform independent

+ Straightforward threads of control- Testing and reliability

+ Use statecharts to model lifecycles- Factor out distractions into domains and other

classes

+ Models are supported by analysis - Minimize time wasted hacking, reliability

+ Data Driven- Not so much here, see Network Case Study

Rev 1.0 5

Coming up…

+ Quick Elevator 1.0 Trace

+ Tips and lessons in model improvement 1.0 -> 2.0

+ GUI Development and Demonstration

+ Initialization and Bridging

+ Testing

+ Next steps

+ Stuff you can download

Elevator 1.0 Quick Trace ||

6

Rev 1.0 7

Elevator 1.0 Collaboration

No polymorphism

Asynchronous only

Old style event bridging

Limitations

Rev 1.0 8

Passenger makes a request

Rev 1.0 9

Dispatch the cabin

Rev 1.0 10

Move to floor and open up

Rev 1.0 11

Elevator 2.0 Collaboration

Eliminate Command Processors AndOther Modeless Statecharts ||

12

Rev 1.0 13

This kind of thing is unnecessary

Only one passive state

The modeless “wait-for-command-to-process” statechart should be replaced with an operation or function.

Rev 1.0 14

No synchronization – no states

Even without states, it is still possible to “disable” an operation.

Use Domain Specific Datatypes And Operations||

15

Rev 1.0 16

Functions and datatypes

Why are these the only data types?

Integer (+, -, *, %)

Real (+, -, *, /)

String (+)

Datatypes should be domain

specific and type safe.

Direction (Toggle)

Face (Rotate)

Angle (+, -)

Counter (incr, decr)

Vector (*)

::Toggle(dir:my_Cabin.Travel_dir)

::decr (Value:self.Cycles)

::ppF (f:rect_A.Face)

No Big StatesTHE STATE AND PROCESS MODELS SOLVE DIFFERENT PROBLEMS

||

17

Rev 1.0 18

Big states are unnecessary

Rev 1.0 19

Separate state and process models

Process Model – Shaft.Ping(OUT_Destination)

Don’t Second Guess The Model Compiler ||

20

Rev 1.0 21

Floor Access Analysis 1.0

Coordinate System Attributes

The x, y and z axes are often not modeled as classes.

You could similarly incorporate the z-coordinate into each Shaft-Level identifier and dispense with the floor as a class.

Now you can search through Shaft Level instances using a counter.if no requests at current floor

++ curr_Floor;

Rev 1.0 22

Floor Access Model 1.0

Rev 1.0 23

Floor Access Model 1.0

There’s just no getting around the notion of Floor as a class.

And there is really no benefit to the z-coordinate axis idea.

Rev 1.0 24

Floor Access Model 2.0

Rev 1.0 25

Floor and BLEV Sequencing

Note the same!

Synchronize Everything! ||

26

Rev 1.0 27

Resolving race conditions

What happens when you push the OPEN button inside the cabin?

If the cabin is waiting, open the door.

So what happens when the button is pressed and the cabin starts moving at the exact same point in time?

But if the cabin is moving, do NOT open the door!

OPEN

Rev 1.0 28

Cabin cannot move until the door is locked. While locked, all user open events are ignored. Only the cabin can unlock the door.

Rev 1.0 29

Xfer Race Condition

Only one instance per cabin is allowed at one time.

What happens when a better destination is discovered while this transfer is in progress?

In Elevator 1.0, the instance is remotely deleted. Not a good plan.

Rev 1.0 30

Xfer 2.0 Solution

If XFER in progress and a better destination is found, Shaft generates change request to XFER.

XFER ignores if too late, updates if cabin not moving, otherwise asks cabin to redirect if possible.

Cabin tries to accommodate, redirects Transport and, if successful, updates the XFER destination.

Rev 1.0 31

XFER idle – immediate change

Rev 1.0 32

XFER active – Ask Cabin to change

Rev 1.0 33

Cabin notifies XFER if successful

Transport will reject the request if the stop is too short.If successful, the XFER will be updated.

Rev 1.0 34

Race condition avoidance

Careful Analysis Pays Off. ||

35

Rev 1.0 36

Same old selection algorithm.

The floor selection algorithm has not changed.

Modeling of this algorithm has evolved considerably.

Migration And Polymorphism ||

37

Rev 1.0 38

Only requested levels are evaluated.

In this case, only two levels are requested.

Rev 1.0 39

Polymorphic Operations

Testing ||

40

Rev 1.0 41

Transparent stubs

A separate subsystem is dedicated to all stubs.The stub subsystem imports from the application so the application contains no stub references.

Rev 1.0 42

Functions in place of bridge calls

When the stubs are replaced by a service domain, ::Namexx is replaced by Name::

User Interface ||

43

Rev 1.0 44

User Interface

+ Introduction

+ Leon’s phone call

+ Delivery of the GUI Spec

Rev 1.0 45

Challenges

+ Challenges- Communication via the UI and the Application- Location of Development Team Members

(Seattle, San Francisco, Denver)

+ Solution:- Virtual, Secure Development Environments

+ Proof of Concept- IP to IP Instant messaging program

Rev 1.0 46

Designing the Interface

+ Designed UI using the GUI specifications- Creative direction- A few rounds of revisions

Rev 1.0 47

User Interface Creation

+ Flash Development- Process- Simultaneous development- Challenges- Delivery

Rev 1.0 48

Models

+ Connecting to the models:- Communication.

Rev 1.0 49

Flash

+ Using as a GUI:- In browser?- Communicating with the movie.

Rev 1.0 50

Starting the simulation

+ Startup considerations- Servers before clients.- GUI Initialization.

Initialization ||

51

Rev 1.0 52

Application procedural init function

This goes on for about six pages.

Rev 1.0 53

Tcl/tk GUI declarative init file

Just one page.

Bridges ||

54

Rev 1.0 55

Bridge calls out from the application are wired into functions that construct UI command strings.

The command strings are fed into Mtalk (Model Integration’s TCP/IP plugin)

Rev 1.0 56

Mtalk -> Valid string -> MC func

UI is hand coded. It invokes functions provided by the model compiler.

Rev 1.0 57

Function -> Select and prod

::EV_UI_door_open (shaft_id);

Rev 1.0 58

Modeled to modeled domain

Both the Elevator and Transport domains are modeled.

Service call is invoked by action within the Cabin statechart.

Elevator collaboration diagram

Transport collaboration diagram

Service call is wired to Transport service domain.

Action language in Goto_floor function maps the shaft/floor_name entities to load/stop entities and generates the L1 event.

Rev 1.0 59

Domain separation

Floor selection Cabin dispatching Door open/close timing

Door

Bank Cabin

Shaft

Safe acceleration Precise transport

Motor

Axis of Motion

Acceleration Profile

gotoFloor (Cabin 3, Floor 6)

cabinArrived ()

Load

moveCompleted ()

move (Load 14, Position 334.25, Ramp 3B)

Elevator uses Transport Bridge between domains

E levator Transport

What’s Next? ||

60

Rev 1.0 61

What’s next?

+ Course Integration

+ New book(s)

+ Transport and Signal IO domains

+ Lego kit

+ Look for web goodies in January 2005

2.0

Leon Starrhttp://www.modelint.comleon_starr@modelint.com

M O D E L I N T E G R A T I O N L L C