Tuesday, 16 December 2008

Green Street Car Park-- Use Case Diagram

Green Street Car park Case study

Green Street management wishes to increase security, both in their building and on site, without antagonising their employees. They would also like to prevent people who are not part of the company from using the Green Street car park.

It has been decided to issue cards to all employees, which they are expected to wear while on the Green Street site. The cards record the name, department and number of the member of staff, and permit access to the Green Street car park.

A barrier and a card reader are placed at the entrance to the car park. The driver of an approaching car inserts his or her numbered card in the card reader, which then checks that the card number is known to the Green Street system. If the card is recognised, the reader sends a signal to raise the barrier and the car is able to enter the car park.

At the exit there is also a barrier, which is raised when a car wishes to leave the car park.

When there are no spaces in the car park, a sign at the entrance displays Full and is only switched off when a car leaves.

Special visitor’s cards, which record a number and the current date, also permit access to the car park. Visitor’s cards may be sent out in advance, or collected from reception. All visitor’s cards must be returned when the visitor leaves Green Street.






1. Nouns

  • Employee
  • Cards
  • Card record
  • Name
  • Department
  • Number
  • Barrier
  • Card reader
  • Car park
  • Driver
  • Car
  • Check
  • Signal
  • Raise
  • Exit
  • Spaces
  • Visitor
  • Visitor's card
  • Reception


2.Use case Diagram:-






  • Use case 1:-












  • Use Case 2






  • Use Case 3



3 comments:

  1. Hi Anusha, good to see some more material on your blog. I have some comments for you which I hope will help:

    1) In the noun analysis, you have 'raise' and 'check' but those are verbs. The purpose of the noun analysis is to identify objects, and verbs usually don't translate to objects.

    2) In your use case diagrams you have Barrier and Card Reader as actors. But, and I quote from A Student Guide to Object-Oriented Development, " Actors are external to the system - they represent people or things that interact with the system and receive some benefit from it." So I wouldn't have had Barrier and CardReader as actors because they are internal to the system.

    3) I believe the relationships between actors and use cases only need to be lines, not arrows. But if you are linking 2 use cases you do need arrows and probably a label saying 'include' or 'extend' to make the relationship more specific.

    Keep posting!

    ReplyDelete
  2. Ah... Use case diagrams. I will paste what Frank wrote on mine:
    "They are really the explication of interfacing between actors and system. The detail of sequencing that this engenders is listed in the scenario sequences that you then evolve to define how the events occur and change system object states while completing processes."

    In other words, keep it simple. They are simple diagrams, really and use cases have only very specific associations between them, described as 'include' or 'extend'. It is described in the text 'A Student Guide to Obect Oriented Development' , chapter 3, Use Cases

    ReplyDelete
  3. I noticed the "Car Park Administator" actor appearing in the use cases a lot. I think that the system would perform most of the tasks assigned to the administrator in the use cases.

    ReplyDelete