Group excercise 'Objektification'

In this excercise you will start with a problem description and pick out classes, attributes and methods. A suitable group size is 2 to 4 persons. At the end of the excercise you will draw a class diagram on a transparancy and the tutor then shows it to all groups as an example of a solution. You don't have to present the solution yourself but it is wery interesting to see different solutions, and if there is time we can discuss the alternatives. You will not write any code in this excercise, the output will be list of classes with attributes and methods, and a class diagram.

Here is the problem statement:

"A company intends to build a two-story office building and equip it with the "latest" in elevator technology. The company wants you to develop a program that simulates the operation of the elevator to determine if it will meet their needs.

The elevator, which has a capacity of one person, is designed to conserve energy, so it only move when neccesary. The elevator starts the day waiting with its doors closed on the building's first floor. The elevator, of course, alternates directions - first up, then down.

Your simulator has no user interface - new persons are randomly created and arrives at either of the two floors. The person then presses the floor's call button. The persons destination floor is always 'the other' floor, so if the person is on the second floor he/she will want to travel to the first floor and vice versa.

If a person arrives on a floor were the elevator happens to be, that person can immediately get on the elevator (after pressing the call button and waiting for the floor doors and elevator doors to open). If a person arrives on a floor without elevator, the elevator should respond to the call button by moving to the other floor and pick up the waiting person. For simplicity, in this version of the simulation, the elevator moves between floors in zero time. This will be made more realistic in future verisons of the elevator.

The elevators arrival at a floor is signalled by turning on a ligth on that floor above the doors and by ringing the floor bell. The floor button and the elevator button are reset, the elevator doors open, the floor's doors open, and the passenger gets out of the elevator. If a passenger is waiting on the floor he/she boards the elevator and presses the a destination button. If the elevator needs to begin moving, it determines in which direction it should go (a simple decision on a two-story elevator !), and begins moving to the other floor. For simplicity, assume that all the evnts that happen once the elevator reaches a floor and until the floor's doors are closed take zero time. The elevator always knows its current floor and its destination floor.

Due to the fact that all events in this version of the simulation take zero time, only one person can be in the simulation at a time. The simulation should process each person completely before the next person arrives in the simulation. In other words, when a person is created, that person should press the call buton, be picked up by the elevator, be moved to the opposite floor and should exit the elevator before the next person walks onto a floor to wait for the elevator."

Task 1 - Classes

Identify the classes in the problem. The description mentions many objects that work together to simaulate the elevator and its interaction with passengers, floors, the bell etc. Find all nouns in the description - they are likely to represent most of the classes that you would need to implement the simulation program.

For every class found, write a short description with the facts you have about the class.

Task 2 - attributes

Time to fins the attributes. In this example attributes are things like: the lamp shines, the button is depressed. One way to go about this task is to write down all facts you know about the problem, and then group these facts under the corresponding class that was identified in task 1.

The list migth look something like this:

Direction up/down
Occupied floor
Person in elevator
Person on a floor
Person entering the elvator
A button is depressed
Elevator doors
Floor
etc ...

This is not an exact science, but try to do as good as you can. It is always better to include more attributes than neccesary, there is always the possibility to remove them later on.

Group the facts under each class, and decide whether a fact is an attribute or something else. Events should be grouped under 'something else' Examples of attributes to the elevator might be:

moving or still
has a passenger
direction - up or down

Attribute for a button might be:

depressed - on or off

Classes can have other classes as attributes, i.e. an elevator has (perhaps) two buttons. This is called an aggregate.

Task 3 - Methods

Look at the facts marked 'something else' and try to pick out behaviours that the objeects in the class might have, that is something you can tell the object to do. One example is a button: it can be pushed (by a passenger), so pushButton might be a behaviour of a button and is represented as a method. methods ofteh change the value of the objects attributes (the 'state'), for example pushButton changes the attibute deopressed to true (unless it already was depressed). Often there are facts 'left over', that are neither attributes or methods.

Task 4 - Class Diagram

Finally, schetch a class diagram in UML notation. Your solution doesn't have to have all types of relations (inhertiance, aggregate and association), and there is no completely 'correct' answer. Draw your class diagram on a transparancy, and if you have room add the most important attributes and methods in your classes.