Document Sample
wm Powered By Docstoc
					UML Example: Workshop Manager.

          Vehicle Garage Scenario

          A computer system is required which will support the following small garage

          Customers bring their cars to a local garage for servicing and repair. The
          garage attendant must check the car in, recording details about both the
          owner and vehicle, along with any specific customer requests. A workshop
          manager inspects each car and creates a job specification for it. The
          workshop manager then schedules the job and assigns a mechanic to
          complete the specified work. When finished, the mechanic must complete a
          report detailing the time spent, work done and materials used. This
          information is used by the garage attendant in creating an invoice for the
          customer and also for calculating the workshop manager’s bonus which
          depends on how accurately he or she can estimate the effort required to
          complete each specified job.

          When the customer arrives back to collect their car, they must pay the
          invoice before the car will be released from the parking bay and returned to

Build a segment of the overall class model using UML notation which shows the classes and
relationships which involve the Workshop Manager. Also build a partial dynamic model.
Use Cases

We can say that the Workshop scenario contains two use cases

The Garage Use Case

The Payment Use Case

These of course can be further described in text and activity diagrams
Class Diagram

The following class diagram contains one diagram only. Separate diagrams may be constructed.
Equally, one diagram might illustrate all aspects.

The class diagram contains classes that may have attributes and operations. Publicly available attributes
and operations are offered as services to other classes (this in fact defines the interface of the class and
represents the only means of communicating with it). A class may have private attributes and
operations…these are used within the class.
NB the model constructed does not yet concern itself with public or private services, but it could.

An operation in a class may be a response to an event (a communication of information between a
sending object and a receiving object). An operation may raise an event or simply carry out other tasks.
This may not be evident in high level analysis models (as is the case here) but as the implementation
detail increases this will become evident.

An operation in a class may be a response to an event (a communication of information between a
sending object and a receiving object). An operation may raise an event or simply carry out other tasks.
This may not be evident in high level analysis models (as is the case here) but as the implementation
detail increases this will become evident.
NB Operation details may be elaborated in an activity diagram. At the analysis level it is sufficient to
describe the behaviour of named operations in narrative. A few sentences at most for each operation.
This is not shown in this document but is important for understanding the model as a whole.

A sequence diagram illustrates the sequence of events communicated between objects. It may show
selection or iteration and can illustrate a specific example of important sequences of communication
from the applications perspective.

The use of association classes.
Association classes provide a means of associating data values with links. These data values may well
be stored as attributes of the classes in the model, but this has its problems. If you believe that the
information rightly belongs to the association then there are two things to consider if you wish to create
an association class.

1.   The case for creating an association class is compelling whenever the association between two
     classes is many:many. In such a case it can be problematic to assign attributes to a specific class.
     For example

              Student                                                                     Module

                           1..*                                                   1..*

A student takes many modules and a module is taken by many students. Lets assume that the system
has to record all the marks gained by students on all the modules.
We cannot add a mark attribute to student class because students take many modules and therefore it
will be necessary to record more than one mark for each student. We could create an attribute which
stored a set of marks but this would not preserve the information about which mark was gained for
which module. It would be undesirable to introduce some type of attribute that specifically coupled
marks and module identifiers because this would lead to duplication and possible consistency
problems. (The same problems exist if we look at the module class).

If a student only did one module we might model as:

because the previous objections do not apply.
2.     To reduce maintenance problems should the multiplicity change, it might be thought prudent to
       use an association classes even when we currently do not have a many:many.
3.     NB. The information stored in an association class only makes sense in the context of knowledge
       about both participant classes. For example, the return date for a book only makes sense when
       married with a book id and a borrower id.

Once the initial class diagram has been constructed , the drawing of an activity diagram might now
clarify the responsibilities of each class. See the activity diagram drawn in the classroom. The
description of the operations is important from the standpoint of understanding the sequence of
operation calls in the sequence diagram.

Sequence Diagrams
These communications have labels as shown. The response to these events within a class will be the
execution of an operation. Classes which receive events (which are calls for a service) must have
operations to respond to these calls. These operations should be represented in the class diagram but
often trivial operations are not shown in the class diagram (operations such as create or examine).

The best use of an interaction diagram is to illustrate a very specific scenario. In this case there will be
no iterations nor selections indicated in the diagram.

This interaction diagram illustrates the sequence of communications for both use cases identified.

                               : Attendant                       :             : Job-Spec             : Schedule       : Mechanic       : Work-Report   : Invoice
: Customer                                                                                                                                                          : Vehicle


                                     15 Min                                                         check-in(regno )


                                                                  15 Min     Job-Spec created                      inspect(regno )

                                                                              Update(regno )

                                                                                      work(time, regno)

                                                                                                             Examine( regno)

                                                                                                Examine( regno)


                                                                                                                               Create( regno)

                                                                                 Examine( regno)

                                                     Examine( regno)

                                             update-bonus( )

                                                                                            Create( regno)

                                                                                                post( )


             collect( regno)
State Diagram
A state diagram illustrates for given classes the proper states that an object of the class can be in, the
events which cause a change of state and the actions/activities (operations from an object model) which
the object performs. Responses to events and generation of events can also be shown (these are just
operations anyway).

Together the state diagrams and event traces for an application form the dynamic model.

State Diagram for Mechanic Class

                         [ work time ]          [ home time ]


                       Work( time, regno )[ work available ]

                                   Working                         ^Attendant.job-completed(regno)
                       entry: ^Job-Spec.examine
                       do: Service/Repair Vehicle

                          entry: Reflect-on-work
                          exit: ^Work-Report.create

From this state diagram we can conclude that the mechanic requires the operations
 Work (time,regno)
 Service/Repair Vehicle
Reflect on Work
And also calls the following services from other classes
 From the Job-Spec class the service examine
 From the Work-Report class the service create
 From the Attendant class the service job-completed
Some guards on transitions are shown. These are more for completeness but may be necessary for some
The class model must be revisited and any missing operations assigned to the appropriate classes.
New Customer( Reg No )

                     Check in
    entry: Check in vehicle
    do: ^Workshop-Manager.new-job(regno)

        [ job-completed ] ^Invoice.create(regno)

   entry: calculate bonus
   do: ^Workshop-Manager.update-bonus(bonus)

Shared By: