Upload
mary-morrison
View
217
Download
3
Tags:
Embed Size (px)
Citation preview
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://[email protected]
M O D E L I N T E G R A T I O N L L C