Use Case modelling 1

Objectives  Document user requirements with a model  Describe the purpose of an actor and a use case  Construct a use case model  Define use cases in detail 2

Object-Orientation – why is it used?  Has been in existence since the late nineteen sixties  Covers all aspects of system development  Throughout development of a system there is a key concept of an object 3

Why object-orientation ?  An object is something within the problem domain such as an Invoice or a Purchase Order  These real world objects become embodied in a model during analysis and design stages  They eventually end up as part of the final code that is produced  There is thus a continuity that exists throughout all stages of development  An approach based on objects rather than functions is more robust 4

Object-orientation - Summary  Key concept follows through all stages of development - objects  Object - invoice, purchase order  Real world objects are placed in models at an early stage and continue throughout development to implementation  Approach based on objects (rather than what the system will do) is more stable 5

Starting a project  Imagine being asked to provide a new system for a company.  What would you do first? 6

Use Case Models  Use case models are a way of specifying user requirements  They specify what the system will do for the people/systems who will interact with it  They break a project down into the functions that must be carried out by the system  The models produced will initially act as a means of communication between developers and users. 7

Actors  Actors are entities that interact with the system  Actors either provide or receive information  Actors are outside the system  Names of actors are usually discovered from dialogue with the users or may be specified in the problem statement 8

Roles and Actors  An actor plays a role  It is the role that interacts with the system  A person may play different roles  An role may have a number of interactions with the system 9

UML representation of an Actor 10 Actor Role

Use Cases A use case  describes the interaction between users and an application system  describes what a user does with the system to produce a business event, which forms part of a business process  models a dialogue between the actor and the system 11

Use Cases A use case  represents the functions which are made available by the system to the actors  is a sequence of transactions performed by a system that produce a measurable result for particular actors 12

Representation of a use case in UML 13

SFU example  Stafford Free University (SFU) needs a new information system for registration purposes. There are currently problems with registering students on modules and determining which modules their lecturers have elected to teach.  The registration section of SFU decides the modules to be offered in each semester of the coming year. This information is made available to the lecturers on-line. Each module has a number of credit points associated with it. It has a code, title, and it may have a module pre-requisite as well as a description. 14

SFU example (cont)  It may be delivered in any of three modes of delivery (part- time, open learning, or full-time) in any semester. Every time a module is delivered, the start and end date is recorded and the total hours needed to study it.  The registration service adds, changes and removes the details held on each lecturer. Details stored on each lecturer include the highest qualification they have achieved and their subject specialism. If a lecturer has had a formal teacher training this is also recorded. 15

SFU example (cont)  The lecturers may elect to teach any of the modules offered in a particular semester by accessing the registration system on- line. They may also change their minds and decide not to teach a module after they have previously elected to do so. At any time, they may wish to view the module offerings they have chosen. The students fill out a registration form on-line and indicate their choice of modules. 16

SFU example (cont)  Both students and lecturers have a name and an id to use this registration service. The expiry date of their account is also recorded. Students may register to take up to any three modules in each semester. This information is then entered into the information system.  Students are then assigned to modules which, have a limit on student numbers. If a student has elected to take a module that is oversubscribed the Registration Service contacts the student and another module is usually substituted. 17

SFU example (cont)  After the registration period each lecturer receives a module student list with the student names for that module and rooms and times for the module delivery they have elected to teach. A schedule of modules is sent to the student for confirmation of correct registration. This schedule shows the modules and the start and end dates that the student has registered for. 18

SFU example (cont)  Any module offering with fewer than the minimum student numbers will be cancelled. The registration service makes the registration information available to a separate billing system that will send out invoices to the students. An invoice contains a date and amount together with a number. 19

Use Case Diagrams  A use case diagram is a picture of some or all of the actors and their interactions with the system.  Each system will have a main use case diagram showing  the system boundary  the major functions provided by the system  Large systems may employ more than one use case diagram 20

What are the use cases?  Look for verbs in the problem description  How much detail in a use case ? What about the Registration Service? It must maintain the registration by adding deleting and modifying modules.  How many use cases are there here?  This is matter of judgement 21

Use cases for SFU  Register for modules  Select modules to teach  Issue module student list  Maintain module information  Maintain student information  Maintain lecturer information 22

References Bennett, S., McRobb, S. and Farmer,R. Object-Oriented Systems Analysis and Design using UML, London: McGraw- Hill, (3rd Ed.) 2005 Britton, C. and Doake, J. Object-Oriented Systems Development – a gentle introduction, London: McGraw-Hill,