Introductory Example: Lift

This is a simple example to illustrate the principle of user conceptual modelling: a model of a single-shaft passenger lift in a building (loosely based on the one I work in).  Throughout, remember that it is what the user needs to know to facilitate appropriate actions, not the structure of the system (the lift) per-say that we are concerned with in the model.

Below is one possible scenario of use (also downloadable as a pdf). I’ve kept the analysis to one scenario for the sake of simplicity. A useful exercise would be to create other scenarios and see how they might affect the conceptual model.  Interestingly, I can’t think of a convincing scenario that would show that the top and bottom floors are different from the intermediate floors, in that the lift may only be called to go down and up respectively.  However, the lift engineer would know this.

Task Scenario

Project Title:         Single shaft lift

Date:                       29/10/2016

Company:             University of Brighton

Authors:                 Richard N Griffiths

Contact Details:   r.n.griffiths@brighton.ac.uk

Tick Date

Confirmed by users (or their representatives):

This document describes details of a key task using the developed software.

Scenario 1: Take lift between intermediate floors

Practical Goal: Move from one intermediate floor in a university building to a higher one.

Context:

Physical environment: Single shaft lift with doors on each floor of the building.

Frequency of task: Several times a day.

Time constraints:  Should not take longer than 3 minutes.

Prioritization and scheduling:  The user may have only minutes to reach a commitment (meeting or lecture) in another part of the building.  Use of the stairs is an alternative to using the lift.

Resource conflicts:  The lift may be heavily used, particularly in a brief period before the hour (when student are travelling to and from lectures).

Individual or group activity: The lift will be shared with other people having different destinations.

Known problems or error situations: Lift overloaded.

User/s: Lecturers, students and administrative staff.

The user is a lecturer who is due shortly to take a class in a lecture theatre higher in the building.They are currently on the 3rd floor in front of the lift door, and wish to go to the 7th.

The lift car is currently on the 1st floor and contains two people, one going to the 3rd floor and the other the 6th.

No one else is intending to use the lift.

1.    Request lift to go up.

2.    Wait for lift door to open.

3.    Determine the direction of the car; in this instance, up.

4.    Enter the car.

5.    Request floor 7.

6.    Wait for car door to open.

7.    Determine floor car is at; in this instance, 6.

8.    Wait for the car door to open.

9.    Determine floor; in this instance, 7.

10. Exit the car.

In the table below, the task action steps have been marked up to identify nouns (putative objects or attributes) and verbs (putative actions).

Task Activities

Interpretation

1.    Request lift to go up.

Floor.request_up

Whilst Lift has been mentioned in the scenario, it is clearer to use Floor; the Car is being called to that particular floor..

2.    Wait for lift door to open

Door.wait_open

The Lift and Car doors are conceptually the same (at least as far as the actions of the user are concerned) so the object is just ‘Door’.

3.    Determine the direction of the car in this instance, up.

Car.determine_direction

4.    Enter the car.

Car.enter

5.    Request floor 7.

Car.request_floor(7)

The object the action is applied to is implied.

6.    Wait for car door to open.

Door.wait_open

7.    Determine floor car is at; in this instance, 6.

Car.determine_floor

8.    Wait for the car door to open.

Door.wait_open

9.    Determine floor; in this instance, 7

Car.determine_floor

10. Exit the car.

Car.exit

The identified objects, attributes and actions have been used to draft the UML Static Relationship Model below (created using the supplied template in MS Visio™ and downloadable as a pdf).

lift-uml-static-relationshipThe four ‘objects’ at the bottom of the diagram are data-types (i.e. they specify the type of data that attributes can contain and functions return).  In this case all are enumerated types, i.e. there is a finite list of values that they can contain.

Advertisements