Systems Analysis Design

MBIS4004
Session 5 – Object-Oriented Systems Analysis and
Design Using UML

Resources – Chapter 10: Kendall, K. E., & Kendall, J. E. (2019). Systems

analysis and design. (10th Edition). Pearson Prentice Hall, USA.
 COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969

WARNING

This material has been reproduced and communicated to you by or on behalf of the Australian
Institute of Higher Education pursuant to Part VB of the Copyright Act 1968 (the Act).

The material in this communication may be subject to copyright under the Act. Any further
reproduction or communication of this material by you may be the subject of copyright
protection under the Act.

Do not remove this notice.

 Learning Objectives
• Understand what object-oriented systems analysis and design is and
appreciate its usefulness
• Comprehend the concepts of Unified Modeling Language (UML), the
standard approach for modeling a system in the object-oriented world
• Apply the steps used in UML to break down the system into a use case
model and then a class model
• Diagram systems with the UML toolset so they can be described and
properly designed
• Document and communicate the newly modeled object-oriented system
to users and other analysts
 Major Topics
• Object-oriented concepts
• CRC cards and object think
• Unified Modeling Language
• Use case and other UML diagrams
• Packages
• Using UML
 Object-Oriented Analysis and Design
• Works well in situations where complicated systems are undergoing
continuous maintenance, adaptation, and design
• Objects, classes are reusable
• The Unified Modeling Language (UML) is an industry standard for modeling
object-oriented systems.
• Reusability
– Recycling of program parts should reduce the costs of development in
computer-based systems
• Maintaining systems
– Making a change in one object has a minimal impact on other objects
 Object-Oriented Concepts
• Objects
• Classes
• Inheritance
 Objects
• Objects are persons, places, or things that are relevant to the system
being analyzed.
• Object-oriented systems describe entities as objects.
• Typical objects may be customers, items, orders, and so on.
• Objects also may be graphical user interface (GUI) displays or text
areas on the display.
 Classes
• Defines the set of shared attributes and behaviors found in each object in
the class
• Should have a name that differentiates it from all other classes
• Instantiate is when an object is created from a class
• An attribute describes some property that is possessed by all objects of
the class
• A method is an action that can be requested from any object of the class
 UML Class

Figure 10.1 An Example of a U M L Class

 Inheritance
• When a derived class inherits all the attributes
and behaviors of the base class
• Reduces programming labor by using common
objects easily
• A feature only found in object-oriented systems

Car and truck are specific

examples of vehicles and
inherit the characteristics
of the more general class
Figure 10.2 A
vehicle. Class Diagram
Showing
Inheritance
 CRC Cards and Object Think
• CRC Cards is a way to create classes and objects from the business
problems and systems we are facing.
• CRC stands for class, responsibilities, and collaborators.
• An analyst can use these concepts when beginning to talk about or model
a system from an object-oriented perspective.
• CRC cards are used to represent the responsibilities of classes and the
interaction between the classes.
• Analysts create the cards based on scenarios that outline system
requirements.
• These scenarios model the behavior of the system under study.
• If they are to be used in a group, CRC cards can be created manually on
small note cards for flexibility, or they can be created using a computer.
 CRC Cards and Object Think
• We have added two columns to the
original CRC card template: the
Object Think column and the
property column.
• The Object Think statements are
written in plain English, and the
property, or attribute, name is
entered in its proper place.
• The purpose of these columns is to
clarify thinking and help move toward
creating UML diagrams.

Figure 10.3 Four C R C Cards

 Interacting during a CRC Session
• CRC cards can be created interactively with a handful of analysts who
can work together to identify the class in the problem domain
presented by the business.
• One suggestion is to find all the nouns and verbs in a problem
statement that has been created to capture the problem. Nouns usually
indicate the classes in the system, and responsibilities can be found by
identifying the verbs.
• As first step, use brainstorming, to come up with all possible classes, and later
compile and weed out illogical one’s.
• As second step, write each class on its own card and assign one class to each
person in the group, who will own it for CRC session duration.
• As third step, creates scenarios; these are walkthroughs of system functions that
use the desired functionality from the requirements document previously created.
 Interacting during a CRC Session
• As fourth step, it is decided which class is responsible for a particular function, the
analyst who owns the class for the session picks up that card and declares, “I
need to fulfill my responsibility.” When a card is held in the air, it is considered an
object and can do things.
• As final step, analysts group then proceeds to refine the responsibility into smaller
and smaller tasks, if possible. The object can fulfill these tasks if it is appropriate,
or the group can decide that it can be fulfilled by interacting with other things. If
there are no other appropriate classes in existence, the group may need to create
one.
 CRC Cards and Object Think
• The four CRC cards show four classes. In a class
called Course, the systems analyst is referred to four
collaborators: the department, the textbook, the
course assignment, and the course exam. These
collaborators are classes on the other CRC cards.
• The responsibilities listed will eventually evolve into
what are called methods in UML.
• The Object Think statements seem elementary, but
they are conversational so as to encourage a group
of analysts during a CRC session to describe as
many of these statements as possible.
• As shown in the example, all dialogue during a CRC
session is carried out in the first person, so that even
the textbook speaks: “I know my ISBN.” “I know my
author.” These statements can then be used to
describe attributes in UML. These attributes can be
called by their variable names, such as edition and
publisher.
Figure 10.3 Four C R C Cards
 Activity 01
Around the world in 80 objects:

• Class will be broken in teams of 3-4 students using breakout rooms.

• Access your E-Book on page 302, read and discuss the case to
answer (you have 30 min.):
• Each of you must access Discussion Board “Session 6 Group X:
“Around the world in 80 objects” to write your answers (you have 30
min.) - 1% Mark.
• It must be done within this given time, otherwise you won’t receive
any mark.
 The Unified Modeling Language (UML)
Concepts and Diagrams
• UML provides a standardized set of tools to document the analysis and
design of a software system.
• UML consists of
• Things
• Relationships
• Diagrams
 Things
• You may call it objects, but in UML terminology it is called Things
• Structural things are:
– Classes, interfaces, use cases, and other elements that provide a way to create
models
– They allow the user to describe relationships
• Behavioral things
• Describe how things work
– Interactions and state machines
• Group things
– Used to define boundaries
– An example of a group thing is a package
• Annotational things
– Can add notes to the diagrams
 Relationships
• Relationships are the glue that holds the things together. It is useful to
think of relationships in two ways.
• Structural relationships
– Tie things together in structural diagrams
– include dependencies, aggregations, associations, and
generalizations
– Structural relationships show inheritance, for example.
• Behavioral relationships
– Used in behavioral diagrams
– The four basic types of behavioral relationships are communicates,
includes, extends, and generalizes.
 Diagrams
• Structural diagrams
– Used to describe the relation between classes
– It includes class diagrams, object diagrams, component diagrams, and
deployment diagrams
• Behavioral diagrams
– Used to describe the interaction between people (actors) and a use
case (how the actors use the system)
– It includes use case diagrams, sequence diagrams, communication
diagrams, statechart diagrams, and activity diagrams
 Overall view of UML
UML Category UML Elements Specific UML Details
Things Structural Things Classes
Interfaces
Collaborations
Use Cases
Active Classes
Components
Nodes
Things Behavioral Things Interactions
State Machines
Things Grouping Things Packages
Things Annotational Things Notes
Relationships Structural Dependencies
Relationships Aggregations
Associations
Generalizations

Figure 10.4 An Overall View of U M L and Its Components: Things, Relationships, and Diagrams
 Overall view of UML
UML Category UML Elements Specific UML Details
Relationships Behavioral Communicates
Relationships Includes
Extends
Generalizes
Diagrams Structural Diagrams Class Diagrams
Component Diagrams
Deployment Diagrams
Diagrams Behavioral Diagrams Use Case Diagrams
Sequence Diagrams
Communication Diagrams
Statechart Diagrams
Activity Diagrams

Figure 10.4 An Overall View of U M L and Its Components: Things, Relationships, and Diagrams
 Commonly Used UML Diagrams
• Use case diagram
– Describing how the system is used
– The starting point for UML modeling
• Use case scenario (although technically it is not a diagram)
– A verbal articulation of exceptions to the main behavior described by
the primary use case
• Activity diagram
– Illustrates the overall flow of activities
– Each use case may create one activity diagram.
 Commonly Used UML Diagrams
• Sequence diagrams
– Show the sequence of activities and class relationships
– Each use case may create one or more sequence diagrams.
• Class diagrams
– Show classes and relationships
– Class diagrams, showing the classes and relationships. Sequence
diagrams are used (along with CRC cards) to determine classes.
• Statechart diagrams
– Show the state transitions
– Each class may create a statechart diagram, which is useful for
determining class methods.
Commonly Used UML Diagrams

Figure 10.5 An Overview of U M L Diagrams Showing How Each Diagram

Leads to the Development of Other U M L Diagrams
 Use Case Modeling
• Describes what the system does, without describing how the system does
it
• Based on the interactions and relationships of individual use cases
• Use case describes
– Actor
– Event
– Use case
 Use Case Modeling
COMMUNICATES. To INCLUDES. A use
connect an actor to a case contains
use case. Remember behavior that is
that the task of the use common to more than
case is to give some one use case. In other
sort of result that is words, the common
beneficial to the actor in use case is included
the system. in the other use
cases. A dotted arrow
EXTENDS. the situation that points to the
in which one use case common use case
possesses the behavior indicates the includes
that allows the new use relationship.
case to handle a
variation or exception
from the basic use case.

Figure 10.6 A Use Case Example of Student Enrollment

 A Use Case Scenario

Figure 10.7 A Use Case Scenario is Divided into Three Sections: Identification and Initiation, Steps
Performed, and Conditions, Assumptions, and Questions
 City Bus Application Use Case
• Every city bus will be equipped with an application to
receive preloaded card fare payments. This
application will read passengers’ card when getting
in and out of the bus to calculate fares. Drivers log
in and out when starting his/her route, and print
tickets when passenger requires it. An admin user
will be able to log in and download reports.
• use diagrams.net and prepare a Use Case for the
City Bus application.
City Bus Application Use Case
SOLUTION
 Activity Diagrams
• Show the sequence of activities in a process, including sequential and parallel
activities, and decisions that are made
• Symbols
– Rectangle with rounded ends
– Arrow
– Diamond
– Long, flat rectangle
– Filled-in circle
– Black circle surrounded by a white circle
– Swimlanes
 Activity Diagrams

Figure 10.8 Specialized Symbols are Used to Draw an Activity Diagram

 Creating Activity Diagrams
• Created by asking what happens first, what happens second, and so on
• Must determine what activities are done in sequence or in parallel
• The sequence of activities can be determined from physical data flow
diagrams.
• Can be created by examining all the scenarios for a use case
 Swimlanes
• Useful to show how the data must be
transmitted or converted
• Help to divide up the tasks in a team
• Makes the activity diagram one that
people want to use to communicate
with others

Figure 10.9 This Activity

Diagram Shows Three
Swimlanes: Client Web
Page, Web Server, and
Mainframe
 Activity Diagrams and Test Plans
• Activity diagrams may be used to construct test plans
• Each event must be tested to see if the system goes to the next state
• Each decision must be tested
 Activity Diagrams Not Created for All
Use Cases
• Use an activity diagram when:
– It helps to understand the activities of a use case
– The flow of control is complex
– There is a need to model workflow
– When all scenarios for a use case need to be shown
 Sequence Diagrams
• Illustrate a succession of interactions
between classes or object instances over
time
• Often used to show the processing described
in use case scenarios
• Used to show the overall pattern of the
activities or interactions in a use case

Figure 10.10 Specialized

Symbols Used to Draw a
Sequence Diagram
 Sequence Diagrams

Figure 10.11 A Sequence Diagram for Student Admission: Sequence

Diagrams Emphasize the Time Ordering of Messages
 Class Diagrams
• Show the static features of the system and do not represent any particular
processing.
• Show the nature of the relationships between classes
• Show data storage requirements as well as processing requirements
• Classes
• Attributes
– Private
– Public
– Protected
• Methods
– Standard
– Custom
 A Class diagram

Figure 10.13 A Class Diagram for Course Offerings: the Filled-In Diamonds Show Aggregation and
the Empty Diamond Shows a Whole-Part Relationship
 Types of Classes
• Entity classes
• Represent real-world items
• The entities represented on an entity-relationship diagram
• Interface classes
• Provide a means for users to work with the system
• Human interfaces may be a display, window, Web form, dialogue box, touch-tone
telephone, or other way for users to interact with the system
• System interfaces involve sending data to or receiving data from others
• Abstract classes
• Linked to concrete classes in a generalization/specialization relationship
• Cannot be directly instantiated
• Control classes
• Used to control the flow of activities
• Many small control classes can be used to achieve classes that are reusable
 Relationships
• Relationships are connections between classes, similar to those found on
an E-R diagram.
• These are shown as lines connecting classes on a class diagram. There
are two categories of relationships:
• associations and
• whole/part relationships.
 Associations
• The simplest type of
relationship
• Association classes are those
that are used to break up a
many-to-many association
between classes
• An object in a class may have
a relationship to other objects
in the same class, called a
reflexive association.
Figure 10.18 An Example of an Associative Class in Which a
Particular Section Defines the Relationship between a
Student and a Course
 Whole/Part Relationships
• When one class represents the whole object, and other classes represent
parts
• Categories
– Aggregation
• A “has a” relationship
• Provides a means of showing that the whole object is composed of the sum of its
parts
– Collection
• Consists of a whole and its members
• Members may change, but the whole retains its identity
• A weak association
– Composition
• The whole has a responsibility for the parts, and is a stronger relationship
• If the whole is deleted, all parts are deleted
 Aggregation

Figure 10.19 An Example of Whole-Part and Aggregation Relationships

 Finding Classes
• During interviewing or JAD sessions
• During facilitated team sessions
• During brainstorming sessions
• Analyzing documents and memos
• Examining use cases, looking for nouns
 Messages
• Used to send information by an object in one class to an object in
another class
• Acts as a command, telling the receiving class to do something
• Consists of the name of the method in the receiving class, as well as the
attributes that are passed with the method name
• May be thought of as an output or an input
 Packages
• Containers for other UML things
• Show system partitioning
• Can be component packages
• Can be physical subsystems
• Use a folder symbol
• May have relationships

Figure 10.23 Use Cases Can Be

Grouped into Packages
 OO Modelling
• Practice
• “Osceola Auto Parts is an independent auto parts dealer that sells
auto parts, runs tests on customers’ cars, and delivers parts and
tools to mechanic shops around town.”
• Based on Osceola Auto Parts and using diagrams.net prepare :
1. A Use Case
2. A Class Diagram
3. A Sequence Diagram
Solution
 Activity 02
Recycling the programming environment:

• Class will be broken in teams of 3-4 students using breakout rooms.

• Access your E-Book on page 312, read and discuss the case to
answer (you have 30 min.):
• Each of you must access Discussion Board “Session 6 Group X:
“Recycling the programming environment” to write your answers
(you have 30 min.) - 1% Mark.
• It must be done within this given time, otherwise you won’t receive
any mark.
Systems Analysis Design
MBIS4004
Web UML

Resources – Chapter 3: Kapel. G.,Prol. B., et. al (2019). Web

Engineering. John Wiley & Sons
 Learning Objectives
• Web Modeling
▪ Use Case Model
▪ Content Model
▪ Navigation Model
▪ Presentation Model
▪ Processing Model
 Traditional SE
Analysis and Design
• The analysis and design activities help on
transforming the requirements of the system into a
design that can be realized in software
• Analysis and design can be done both ways,
separately or combined, as part of the same set of
activities.
Software Application Modeling
Levels

User interface

Application Logic

Phases
Structure Analysis Design Implementation

Behavior

Aspects

• Levels – the “how” & “what” of an application

• Aspects – objects, attributes, and relationships;
function & processes
• Phases – Development cycle
 Web Application Modeling
Levels

Presentation
Hypertext
Customization
Content

Phases
Structure Analysis Design Implementation

Behavior

Aspects

• Levels – Information, node/link structure, UI & page layout separate.

• Aspects – Same as Software Applications
• Phases – Approach depends upon type of application
• Customization – Context information
 Web Modeling
• Modeling static & dynamic aspects of content, hypertext, and
presentation.
• Extra things need to model
– Navigation (hypertext structure)
• Good navigation structure of an application helps user to find relevant information
fast and avoids him/her to be “lost” in hyperspace
– Adaption
• Makes Web System more suitable for individual users
• Based on: User’s platform, User’s preferences; User’s behaviour.
– Access structure, presentation structure Etc.
 Unified Modeling Language (UML)
• “The Unified Modeling Language is a visual language for specifying
and documenting the artifacts of systems.”
• Language of choice (and ISO standard) for diagramming notation
in OO development.
– Structural – Class diagrams (domain models)
– Behavioral – Use Cases, Sequence diagrams, activity diagram
 UML for Web Engineering
• For Web-centric modeling, we will employ the UML Web Engineering (UWE)
notation.
– https://uwe.pst.ifi.lmu.de/
– UML-compliant comprehensive modeling tool
• Not the only modeling language
– WebML, OOHDM, etc.
• The overall functionality of a Web application is modeled as a set of use cases,
which describe the Web application requirements from the actors’ (people
and other systems) perspectives.
• Additionally, use cases can be supplemented by UML activity diagrams to
describe the functional requirements in more detail.
• One peculiarity of Web application requirements is navigation functionality,
which allows the user to navigate through the hypertext and to find nodes.
 Use Case Model
• Depending if the feature modifies the persistent
data of the application or not, the use cases are
distinguished by the stereotypes «browsing» and
«processing»
 Use Case Model

An approach (UWE), selected herein,

is to create one single use case model,
which uses the UML navigation
stereotype to denote the difference
between functional and hypertext-
specific use cases.

Source: Web Engineering – Kappel et al.

 Activity Diagram
➢Need to separate user activity and server activity.
➢Need to separate display and processing.
➢Need to tell what are the inputs.
 Content Modeling
• Purpose: To model the information requirements of
a Web application
– Diagramming the structural (i.e., information objects) &
behavioral aspects of the information.
– NOT concerned with navigation.
• Primary Models
– Class diagrams – enough for static applications.
– State machine diagrams – captures dynamic aspects
 Class Diagrams
• Notice the invariant attached to the class “Paper”: it ensures that authors
won’t be able to review their own papers.

Composition Derived Attribute Value

Invariant

Source: Web Engineering – Kappel et al.

 Class Diagram – Example 1
• Conference Paper Submission System

Source: Web
Engineering –
Kappel et al.
 State Machine Diagrams
• For dynamic Web applications, they depict important states
and events of objects, and how objects behave in response to
an event (transitions)
• Show the life-cycle of an object.
• Used only for state-dependent objects
 State Machine Diagram - Example
• The life-cycle of a Paper object in the conference paper
submission system.

Source: Web Engineering – Kappel et al.

 Navigation Modeling
• Also known as hypertext modelling
• Purpose: To model the navigation paths available to users.
• Focuses on the structure of the hypertext & access elements.
– Hypertext modeling generates a two-fold result: First, it produces the
hypertext structure model, also known as navigation structure model
which defines the structure of the hypertext, i.e., which classes of the
content model can be visited by navigation. Second, it refines the
hypertext structure model by access elements in the form of an access
model.
• Use “ <<navigation class>> ” annotation to distinguish from
content classes.
 Navigation Model
• Conference Paper Submission System

Source: Web Engineering – Kappel et al.

 Navigation Model
• Navigation Elements
– <<index>> (list of objects of the same type)
– <<menu>> (list of heterogeneous objects)
– <<guided-tour>> (sequential links)
– <<query>>
Navigation Model - Example

Source: Web
Engineering –
Kappel et al.
 Presentation Modeling
• Purpose: To model the look & feel of the Web application
at the page level.
• The design should aim for simplicity and self-explanation.
• Describes presentation structure:
– Composition & design of each page
– Identify recurring elements (headers/footers)
• Describes presentation behavior:
– Elements => Events
 Levels of Presentation Models
• Presentation Page – “root” element; equivalent to a
page container.
• Presentation Unit
– A fragment of the page logically defined by grouping related
elements.
– Represents a hypertext model node
• Presentation Element
– A unit’s (node’s) informational components
– Text, images, buttons, fields
 Presentation Model - Example
• Paper and Author Page Templates

Source: Web Engineering – Kappel et al.

 Sequence Diagrams
• Purpose: Depicts sequential interactions (i.e., the flow of
logic) between objects in an application over time.
– What messages, what order, & to whom.
– Ex.: Object A calls method of Object B
– Ex.: Object B passes method call from Object A to Object C.
• Result: Dynamic system interactions diagrammed in a
“fence” format.
Sequence Diagram – Example 1

Source: Web Engineering – Kappel et al.

Sequence Diagram – Example 2

Source: Web Engineering – Kappel et al.

 Customization Modeling
• Ubiquitous applications often require multi-platform
and/or personalized delivery.
• Purpose: To represent content adaptation based on
context information.
• Customization models are often integrated with other
diagrams.
• Use <<customization>> annotation to denote
customization rules in adapted classes.
 Customization Modeling
Concepts
• User Profile – preferences & characteristics
• Physical context – user or location
• Logical context – situational knowledge
• Context adaptation
– Static – A unique model for every variant
– Dynamic – Rule-based transformation
• Events/Conditions/Actions
• Actual variants created at runtime, so model may be harder to
understand.
 Dynamic Adaptation - Integrated
• Filtering papers based on interest

Source: Web Engineering – Kappel et al.

 Dynamic Adaptation - Integrated
• Link Hiding example

Source: Web
Engineering
– Kappel et
al.
 Let’s
talk about A2!
 A2 – Part 1 Practical Individual
• Weight: 20%
• Due: Session 8
• Via Moodle During class.
• Individual
• Duration: 1 hour
• Number of questions: 2
• Basic diagrammatic modelling skills to systems
analysis will be assessed.
 A2 – Practical Individual
INSTRUCTIONS:
• You will have to solve:
• ONE exercise from “Exercise Group 1”: You will be provided case type questions based
on the topics covered in Week 1-7.
• ONE exercise from “Exercise Group 2”: You will be provided Modelling/diagramming
type questions based on the topics covered in Weeks 1-7. For example, Data flow
diagrams, context and diagram 0, use case, activity, class and sequence diagrams.
 A2 – Practical Individual
• You may use www.creately.com, www.diagrams.net, MS
Visio or any other modeling tool to create diagrams.
• NO HANDWRITING ACCEPTED or solution in
NOTEBOOK. You must demonstrate your skills at
using diagramming technologies.
• Submission will be through moodle as part of the
timely completion and submission of quiz.
Review: Exercises
 Exercise 1
As part of your systems analysis project to update the automated accounting
functions for Xanadu Corporation, a maker of digital cameras, you will interview
Leo Blum, the chief accountant. Write four to six interview objectives covering his
use of information sources, information formats, decision-making frequency,
desired qualities of information, and decision-making style.
a. In a paragraph, write down how you will approach Leo to set up an interview.
b. State which structure you will choose for this interview. Why?
c. Leo has four subordinates who also use the system. Would you interview them
also? Why or why not?
d. Write three open-ended questions that you will email to Leo prior to your
interview. Write a sentence explaining why it is preferable to conduct an
interview in person rather than via email.
 Exercise 2
You are hired as a systems analyst by an organization that is planning to redesign
its website. Consider the following situations and describe the most appropriate
sampling method for each of them.
a. To gauge employee perception towards website redesign, you post a notice
on the intranet portal asking the employees to post their opinions.
b. You design a customer survey to find out which website features they wish
to see redesigned.
c. You seek customer opinions through forms available at three of the
company’s 20 helpdesks.
Explain why the answer to each situation would vary.
 Exercise 3
As part of a larger systems project, Clone Bank of Clone, Colorado, wants your
help in setting up a new monthly reporting form for its checking and savings
account customers. The president and vice presidents are very attuned to what
customers in the community are saying. They think that their customers want a
checking account summary that looks like the one offered by the other three banks
in town. They are unwilling, however, to commit to that form without a formal
summary of customer feedback that supports their decision. Feedback will not be
used to change the prototype form in any way. They want you to send a prototype
of one form to one group and to send the old form to another group.
a. In a paragraph discuss why it probably is not worthwhile to prototype the
new form under these circumstances.
b. In a second paragraph discuss a situation under which it would be advisable
to prototype a new form.
 Exercise 4
Henry has been hired as a systems analyst to work on an information system
project for a library. Currently, books are ordered manually. Three librarians
receive a checklist containing details of forthcoming books and journals every
week. Each one places checkmarks against the books they think should be ordered.
The three marked lists are then reviewed by a head librarian, who finalizes the list
of books and the quantity to be ordered. The final list is sent to a clerk, who mails
it to the appropriate publishers for orders.

a. Draw a context diagram for this situation.

b. Draw a level 0 data flow diagram for this situation.

 Exercise 5
The public transport company operating in a rural area has created a system to receive
driver’s applications, hire them and assign routes. The company has a fleet of 100 buses
serving more than 5000 rides each day. It involves 35 regular routes, plus routes for special
circumstances. The company has 50 full time and 20-30 part time drivers. A dispatcher
coordinates the staffing and routes and relays messages to drivers regarding traffic
information and special passenger pick-up arrangements.

Develop a Use Case diagram for the above system.