Problem in creating a correct finite-state-machine for a given short text

Question

I like to create a finite-state machine for the given text below. While solving this, I came accross with several problems I listed at the bottom. (This example is in terms of testing (where you later derive tests of a specification which is in form of a state machine).)

Following specification of an elevator is given: The elevator is inside an house with access to the top/roof and can be requested from every storey (e.g. from outside). The top/roof of the house can only be approached if there is a key inside.

If the elevator is requested to any storey, then the elevator goes right there after having closed its doors. When elevator arrived, the doors open. The doors close, if the event timeout is triggered. If the elevator reaches the desired storey, then the event storeyReached (or topReached for reaching the top/roof) is triggered, as well as the event openElevatorDoors.

• I'm not sure how to choose the initial state. It's all about an elevator roughly said and starts there (my second option would be roof AND storey but then we would have two initial states which seems wrong, we only can have one). But then the elevator itself is inside a house, so I need to use house as a state too...?

• At some states, for example elevator, I used two events/edges to illustrate a decision, so only one of both events can be chosen, not both at once. This is fine like that?

• At the states storey and elevator, I made multiple events at one edge separated by a comma, is this possible too? Also I'm not sure about these self-edges :(

Answer 1

Some random thoughts:

You're not representing the individual stories in the state machine, thus, either you'll have to track them "externally" to the bubbles/states of the state machine, or, incorporate multiple stories in the state machine itself.  The former would capture a story number as an integer — Wikpedia's UML state machine article refers to this as Extended States; the latter would have a separate state for each of being on story-1, on story-2, etc...

Once you address the above, you'll find that the initial state is easier to define.  You can choose any floor for initial state, for variety, and perhaps you should try several with your test cases.

You're using a specific state for close doors, but an event for open doors.  This seems rather asymmetrical, when perhaps we could envision full states for both (or just events for both);   Though I appreciate that the text suggest an event for one but not the other.

The close doors state looses information since two different events converge on the same state, and you'll need to know which state it came from in order to accomplish the next transition.  Again, you have a choice of adding external state or of replicating that one state into two states.  It would be worth exploring the latter here as a learning exercise — two close doors states, such that one would be used by requested by story and one would be used by requested by top.  By using two separate states for close doors, you can effectively remember the history of which particular request happened, and so then you know what next state to transition (story or top).

That being said, though, there is little difference between the stories and the top (it is just the highest story).  The best diagram would probably use a single "on story" node for all stories and the top, with external state to indicate the story number, and also use guards (e.g. for has key).