Practice Problems for Use Cases, Class Diagrams, State Diagrams, and Sequence Diagrams
Index of Problems
----------------------------------------------------------------------------------------------------------------
Problem 1: Automatic Teller Machine (ATM)
Emphasis: Use cases, simple class diagram, responsibility-driven design, state modeling.
Problem statement: Well, you know -- a typical ATM.
1.1 Draw the Use Case Diagram for an ATM. Think of all possible actors, and for all possible actors, think of all possible use cases.
1.2 Create high-level sequence diagrams showing the "sunny day" scenarios for logging in, withdrawing cash, and making a deposit. Note on your diagrams where exceptions can occur, and describe (one short sentence) the exceptions.
1.3 Fill out a use case specification on log in and withdraw cash.
1.4 To the best of your knowledge, determine the internal parts of the ATM. (e.g., card reader, CRT, keyboard, cash dispenser, etc.) and make a class diagram of these parts.
1.5 Create a low-level sequence diagram of the use cases log-in and withdraw cash (combined). The low-level sequence diagram will show communication between the internal parts of the ATM in the course of carrying out the use case.
1.6 Create a state diagram showing all of the states of the ATM during the log-in use case.
----------------------------------------------------------------------------------------------------------------------------------------
Problem 2: Dungeons and Dragons
Emphasis: Class relationship modeling
Problem statement: A computer game is being devised which models a castle, its parts, and its occupants. For a first pass, the following game elements should be placed into a class diagram, and the relationships (association, aggregation, and inheritance) between the classes determined:
castle
guard
tower
brick
Lord (Man who owns the castle)
bedroom
dungeon
window
kitchen Lady (Lord's wife)
dragon
wall
stairwell
hallway moat (a circular
body of water around the castle for protection)
dining
room
cook
fish
floor
ghost
ceiling
crocodile
stairs
handmaiden (a special servant for the lady)
Note that you may come up with
generalized classes not in the above list to facilitate inheritance. The
above example
was taken from Object-Oriented Modeling and Design by James Rumbaugh, et. al,
(C) 1991 by Prentice-Hall. It was
expanded significantly from the version given in that book.
----------------------------------------------------------------------------------------------------------------------------------------
Problem
3: Der Volks Microwaven (The People's Microwave)
Problem Statement:
A
minor corporation has decided that there is a market for a very low budget
microwave oven, with reduced functionality.
This oven simply has three buttons -- a start button, a cancel button,
and a time button which increments the time one minute each time it is pushed.
A display shows the time in minutes and seconds.
To
cook food, the user pushes the time button the number of minutes the food will
be cooked. The display increments
one minute for each push. The food
is then placed in the oven, and the start button is pressed. The user can cancel cooking at any time by pressing the
cancel button. Time may be added to
the cooking time while cooking is in progress by pressing the time button.
Further
requirements:
1.
The oven has a light, which will be on when the food is cooking, or when
the door is opened.
At
all other times, the light will be off.
2.
Pressing the start button starts cooking, but only if there is time on
the timer, and the door is closed.
3.
Pressing the cancel button cancels cooking.
The power tube is turned off immediately and the timer and display are
cleared. The light is also
turned off.
4.
Opening the door immediately turns off the power tube (if it is on) and
turns on the light. If the oven was
cooking when the door was opened, the timer is halted and the display is frozen.
If the door is shut, the oven remains in a suspended state until the
start button is pressed (to resume cooking) or the cancel button is pressed (to
halt cooking (see above).
5.
Pressing the time button increments the cooking time one minute,
regardless of whether the oven is running or not.
The simple display is also incremented.
6.
The oven also has an annoying beeper which beeps every time a button is
pressed. The beeper will also beep
three times when time has run out (cooking
stops normally, not in response to an opened door or the cancel button being
pressed).
--------------------------------------------------------------------------------------------------------------------------
3.1 Create the Candidate Class Catalog from the above description. Decide which items are really valid classes, and which are not.
3.2 Create the analysis class diagram for the microwave oven and its components.
3.3 Create a high-level sequence diagram for the use case Cook Food.
3.4 Create the low-level sequence diagram for the use case Cook Food. Determine which objects have which responsibilities in carrying out the internal operations of Cook Food.
3.5 Go back to your class diagram, and add the responsibilities (methods) to the various classes whose objects carry out the responsibilities (methods) at run-time. In addition, add obvious attributes to the classes.
3.6 Create a state diagram for the use case Cook Food.
----------------------------------------------------------------------------------------------------------------------------------------
Problem 4: Course Automated Registration System (CARS)
Focus: Entire system analysis and design.
Problem Statement:
A new Online Course Automated Registration System is being designed to help students register for courses online. The system will keep track of courses offered during any given semester. Students will be able to log on to the system, add courses, add to waiting lists for full courses, drop courses (whether in the course or on the waiting list), get the list of courses they have enrolled in, and find out their grades for courses previously taken. They can also list courses being offered by various search criteria.
CARS administrators can CRUDL courses, CRUDL students, and CRUDL instructors. (Instructors include professors, assistant professors, lecturers, and temporary staff). Student records are an integral part of CARS -- they are not kept separately in a different system. Updating a course includes assigning courses to classrooms, and assigning instructors to courses. CARS administrators can also CRUDL classrooms and (relatively) permanent equipment in classrooms (e.g., multimedia equipment, computers, projectors, etc.) CRUDLing students includes assigning course grades to the students at the end of each semester, clearing up incompletes, or changing grades later on due to various factors. It also includes entering students into the system for the first time when they first enroll in the university, and altering contact information when necessary.
Instructors can get lists of students enrolled in courses they are teaching. Instructors can also check prerequisites on students, although this is also performed automatically by CARS. CARS can also interface with the Financial System for the school, and check on financial obligations of students ("holds" -- e.g., unpaid tuition, library fines, etc.). This is performed every time a student tries to add a course via CARS.
CARS will have multiple interfaces -- via the web, via telephones with numeric keypads, and via terminals at school.
----------------------------------------------------------------------------------------------------------------------------------------
4.1. Create the use case diagram for CARS. Do not forget to employ use case decomposition when needed, and to show the includes and extends relationships between the use cases.
4.2. Fill out full use case specifications for Student Adds Course and Student Drops Course. (Or at least create the high-level sequence diagrams for these use cases).
4.3. Create some prototype screens for logging in, and adding a course. You may have to decide on one or two of many different ways a student might add a course via a GUI.
4.4 Create the Candidate Class Catalog for CARS. Decide which elements in the catalog are actually classes, and which are not.
4.5 Create the Analysis-level class diagram for CARS.
4.6 Create the low-level sequence diagram for the use case Student Adds Course. Determine which objects have which responsibilities in carrying out this use case.
4.7 Create the state diagram for a course. This diagram will model the states that a course can be in, and the transitions between those states. A few states might be: open, full, overfull, closed, and "retired" (e.g., the semester is over). There are more states than these -- these are just to get you going.
-----------------------------------------------------------------------------------------------------------------------------------------
Emphasis: Class Modeling. Using Use Cases with internal events as actors
Problem
Statement:
Breakout
is an interactive game
in which a player
attempts to eliminate
the bricks in a wall of bricks by hitting the bricks with a ball.
When the bricks are hit, they disappear, and the player is rewarded with
points. When the entire wall of
bricks is eliminated, a new wall is constructed, and the level of difficulty is
increased (the ball travels faster, and/or some other factors increase in
difficulty).
The
ball is set into motion upon game start-up, then maintains a velocity dependent
on the game surfaces hit. The game
surfaces that can be hit include
the bricks, a player-controlled paddle, two side boundaries, an upper boundary,
and a lower boundary. The lower
boundary differs from the upper and
side boundaries in the fact that the ball does not rebound from it, but rather
when the ball contacts the lower boundary, the ball is considered “lost”.
The player is allowed three balls; when a ball is lost, a new ball is put
into play until all three balls are lost, at which point the game is over.
The player controls the ball by means of a “paddle”, which is manipulated by a mouse. The paddle lies below the bricks on the playing surface, and can be moved horizontally (but not vertically) by means of the mouse. When the ball hits the paddle, it obtains a new velocity dependent on the angle of the ball when it strikes the paddle, the speed of the paddle, and the speed of the ball. Balls may be speeded up or slowed down by gaining or losing energy from a moving paddle. Balls may also obtain “spin” from the deflection angle with the paddle, which will influence how they bounce off hittable objects in the game. (Advanced feature -- may not be present in first release. First release will probably not have the ball increase in velocity when hitting the paddle, or pick up "spin" from the paddle).
The balls cannot lose or gain energy from hitting the boundaries or most bricks. Some bricks, however, are “speed” bricks and can increase the velocity of the ball.
The game also contains a "scoreboard" (not shown below) which contains the name(s) of the player(s), the ball which they are currently playing (1, 2, or 3) and their scores. (Up to 3 players can play, alternating turns.). In addition, the scoreboard shows the top 5 scores recorded for this instance of the breakout game, and the names of the players who obtained those scores.
The
game needs to be designed so that possible future enhancements are easy to add
on. These enhancements may include options for multiple balls, multiple
paddles (possibly at different levels) and alternative arrangements of bricks.
Issues: What causes the ball to move? (At the implementation level -- how is the ball moved?) What detects collisions between the ball and other game elements? Is the brick wall a separate entity from the bricks? What detects mouse movements and translates them to paddle movements?
5.1 Create the candidate class catalog for the Breakout game, using the above problem statement.
5.2 Create the analysis class diagram for the Breakout game.
5.3
Create low-level sequence diagrams for the following events: Ball moves
(trigger stimulus -- a clock or timer of some type), Ball hits brick, ball
hits last brick in wall, ball hits bottom
5.4 Try converting the low-level sequence diagrams to "internal" use cases.
5.5 If you have lots of time, try implementing the code in Java.