Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

141-CIS

System Analysis and Design

Department of Information systems

College of Computer Science

King Khalid University

(Lab Manual)
Semester II (2019/2020)

141-CIS LAB Manual 1


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Topics Distribution on the Semester Weeks

Week Topic Page

1 LAB (01): Introduction to process modeling and basic concepts of process modeling. 3

2 LAB (02): Data Flow Diagrams (DFDs) 6

3 LAB (03): DFDs Case Studies 15

4 LAB (04): Introduction to Entity-Relationship Diagram (ERD) 21

5 LAB (05): ERDs Case Studies 27

6 LAB (06): Introduction to UML 31

7 LAB (07): Use-Case Diagrams and related case studies 35

8 LAB (08): Use-Case Scenario and related case studies 39

9 LAB (09): Class Diagrams 47

10 LAB (10): Class Diagrams Case Studies 54

141-CIS LAB Manual 2


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (1): Process Modeling: Introduction to process modeling and basic
concepts of process modeling.

Systems Theory and Process Concepts

• A System is a Process
o The simplest process model of a system is based on inputs, outputs, and the system itself
viewed as a process.
o The process symbol defines the boundary of the system.
o The system is inside the boundary; the environment is outside that boundary.
o The system exchanges inputs and outputs with its environment

The Classis model of a system

141-CIS LAB Manual 3


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

System Models

• Logical models show what a system ‘is’ or ‘does’. They are implementation-independent; that is, they
depict the system independent of any technical implementation. As such, logical models illustrate the
essence of the system. Popular synonyms include essential model, conceptual model, and business
model.
• Physical models show not only what a system ‘is’ or ‘does’, but also how the system is physically and
technically implemented. They are implementation-dependent because they reflect technology
choices, and the limitations of those technology choices. Synonyms include implementation model
and technical model

What is Process Modeling?

• Process modeling is a technique for organizing and documenting the structure and flow of data
through a system’s PROCESSES and/or the logic, policies, and procedures to be implemented by a
system’s PROCESSES.
• Process modeling originated in classical software engineering methods. A systems analysis process
model consists of data flow diagrams (DFDs)

Data Flow Diagrams (DFDs)

• A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
Information System.
• A Data Flow Diagram can also be used for the visualization of data processing (structured design).

DFD Symbols (Gane & Sarson)

141-CIS LAB Manual 4


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

• Data flow diagram (DFD) is a picture of the movement of data between external entities and the
processes and data stores within a system

Order In-Stock Request

CUSTOMER WAREHOUSE

1.0
Status
Message
Check Shipping
Status Data Status Order

Order
2.0 Data
Shipping 3.0
Confirmation Pending
Issue D1 Orders
Status
Messages Generate
Shipping
Order Data Order

Payment 4.0
Order Data
Invoice
Manage
Accounts
Receivable
5.0
Accounting Data Accounts Receivable Data

Produce
Accounts Reports
D2 Receivable
Inventory
Reports

ACCOUNTING

141-CIS LAB Manual 5


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (2): Data Flow Diagrams (DFDs)

Process:
1.0

Grade Report

Produce
Grade Detail
Grade

Report

n Work or actions performed on data (inside the system)

n Labels should be verb phrases
n Receives input data and produces output

PROCESS - Rule 1:

n A process can have more than one outgoing data flow or more than one incoming data flow

Graded Work
Submitted Work 1.0

Grade
Student Student Grade
Work

3.0
Hours Worked
Gross Pay
Calculated
Pay Rate
Gross
Pay

141-CIS LAB Manual 6


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

PROCESS - Rule 2:

n Can connect to any other symbol (including another process symbol)

Inventory
Order 1.0 Accepted Order 2.0 Change

Verify Assemble
Order Order

PROCESS – Correct/Incorrect?

141-CIS LAB Manual 7


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Data Flow

Deposit

n Is a path for data to move from one part of the Information System to another
n Arrows depicting movement of data
n Can represent flow between process and data store by two separate arrows

2.1
Payment Detail

D1 Accounts
Post Invoice Detail
Receivable

Payment

Data Flow: Correct/Incorrect

141-CIS LAB Manual 8


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Data Store

D1 Students

n Is used in a DFD to represent data that the system stores

n Labels should be noun phrases

Rule: Data Store

Customer Payment
n Must have at least one incoming and one outgoing data flow

Daily
D1
Payments

Daily Payment

Data Store: Correct/Incorrect?

141-CIS LAB Manual 9


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Source/Sink (External Entity)

1.0
Order

CUSTOMER Invoice Verify
Order

n External entity that is origin or destination of data (outside the system)

n Is the singular form of a department, outside organization, other IS, or person
n Labels should be noun phrases
n Source – Entity that supplies data to the system
n Sink – Entity that receives data from the system

Rule: Source/Sink

n Must be connected to a process by a data flow

BANK

Bank
Deposit

2.0

Prepare
Deposit

141-CIS LAB Manual 10


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Source/Sink: Correct/Incorrect?

141-CIS LAB Manual 11


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Context Diagram

n Top-level view of IS
n Shows the system boundaries, external entities that interact with the system, and major
information flows between entities and the system.
n Example: Order system that a company uses to enter orders and apply payments against a
customer’s balance

141-CIS LAB Manual 12


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Level-0 DFD

n Shows the system’s major processes, data flows, and data stores at a high level of abstraction
n When the Context Diagram is expanded into DFD level-0, all the connections that flow into and
out of process 0 needs to be retained.

n Functional Decomposition

¨ An iterative process of breaking a system description down into finer and finer detail

¨ Uses a series of increasingly detailed DFDs to describe an IS

n Balancing

¨ The conservation of inputs and outputs to a data flow process when that process is
decomposed to a lower level

¨ Ensures that the input and output data flows of the parent DFD are maintained on the child
DFD

141-CIS LAB Manual 13


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (2) HOMEWORK

141-CIS LAB Manual 14


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (3): DFDs Case Studies

Case – 1: University Registration System

Student Registration System is a system that will be used to help the student to register for courses.

• The Student retrieves a list of offered courses from the courses file and submits the application
to the system. Then, the system will validate the student application by checking his details using
the registration file.
• If the student’s application is valid then it will be processed. If not, the student will get a message
of error.
• The Department sends information of scheduled courses and requirements list of students to
Student registration system
• When the application is accepted, the student should pay the tuition of the course
• Then, the department receives a report of the student application
• After the payment, the Student data is sent to Admission portal where it is available for student
to check if they are selected or not.
• The Student entity is connected with two processes. One of the process displays the courses

Step-1: Identify Entities

• Student
• Department
• Admission Portal

Step-2: Identify Processes

1. Display Course Information

2. Validate Application
3. Process Application
4. Apply Payments

Step-3: Identify Data Stores

1. Courses file
2. Registration info. file

141-CIS LAB Manual 15


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Context Level Diagram

Level-0 Diagram

141-CIS LAB Manual 16


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Case -2: World’s Trend Catalog Division

World’s Trend is a mail order supplier of high-quality, fashionable clothing. Customers place orders by
telephone, by mailing an order form included with each catalog, or via the Web site.

When customer orders come in, the item master and the customer master files are both updated. If an
item is out of stock, the inventory control department is notified. If the order is from a new customer, a new
record is created in the customer master file.

Picking slips are produced for the customer order and sent to the warehouse. A shipping statement is
prepared. The process of shipping a customer order involves getting the goods from the warehouse and
matching up the customer shipping statement, getting the correct customer address, and shipping it all to
the customer.

The customer statement is generated, and a billing statement is sent to a customer once a month. An
accounts receivable report is sent to the accounting department.

Step-1: Identify Entities

• Customer
• Inventory
• Warehouse
• Accounting

Step-2: Identify Processes

• Add Customer Info.

• Add Customer Order
• Produce Picking Slip
• Prepare Shipping Statement
• Ship Customer Order
• Create Customer Statement
• Produce Account Receivable

Step-2: Identify Data Stores

• Customer File
• Items File

141-CIS LAB Manual 17


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Context Level Diagram

Level 0 Diagram

141-CIS LAB Manual 18


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Example of child DFD from process (1) – Level 1

141-CIS LAB Manual 19


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (3) HOMEWORK

Consider Case Study (2): World’s Trend Catalog Division.

If you know that the parent process (3) – PRODUCE PICKING LIST have the following child subprocesses:

1. Read Item Record (from Items File)

2. Create Order Record (to Order Item File)
3. Sort Item by Location in Warehouse (to sorted orders file)
4. Get Customer Records (from Customer File)
5. Print Order Picking Slip

Draw the child DFD (Level 3 Data Flow Diagram) for the mentioned process.

141-CIS LAB Manual 20


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Lab (4): Introduction to Entity-Relationship Diagrams (ERDs)

What is the ER Model?

The ER or (Entity Relational Model) is a high-level conceptual data model diagram. Entity-Relation
model is based on the notion of real-world entities and the relationship between them.

ER modeling helps you to analyze data requirements systematically to produce a well-designed

database. So, it is considered a best practice to complete ER modeling before implementing your database.

What is ER Diagram?

Entity relationship diagram displays the relationships of entity set stored in a database. In other words,
we can say that ER diagrams help you to explain the logical structure of databases. At first look, an ER diagram
looks very similar to the flowchart. However, ER Diagram includes many specialized symbols, and its
meanings make this model unique.

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram

• Helps you to define terms related to entity relationship modeling

• Provide a preview of how all your tables should connect, what fields are going to be on each
table
• Helps to describe entities, attributes, relationships
• ER diagrams are translatable into relational tables which allows you to build databases quickly
• ER diagrams can be used by database designers as a blueprint for implementing data in specific
software applications
• The database designer gains a better understanding of the information to be contained in the
database with the help of ERP diagram
• ERD is allowed you to communicate with the logical structure of the database to users

Components of the ER Diagram

This model is based on three basic concepts:

• Entities
• Attributes

• Relationships

141-CIS LAB Manual 21


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Example

For example, in a University database, we might have entities for Students, Courses, and Lecturers.
Students entity can have attributes like Rollno, Name, and DeptID. They might have relationships with
Courses and Lecturers.

WHAT IS ENTITY?

An entity can be place, person, object, event or a concept, which stores data in the database. The
characteristics of entities are must have an attribute, and a unique key. Every entity is made up of some
'attributes' which represent that entity.

• Person: Employee, Student, Patient

• Place: Store, Building
• Object: Machine, product, and Car
• Event: Sale, Registration, Renewal
• Concept: Account, Course

141-CIS LAB Manual 22


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Example of Entities:

A university may have some departments. All these departments employ various lecturers and offer
several programs.

Some courses make up each program. Students register in a particular program and enroll in various
courses. A lecturer from the specific department takes each course, and each lecturer teaches a various group
of students.

Relationship

Relationship is nothing but an association among two or more entities. E.g., a student can attend many
classes

Relationships Cardinality

Defines the numerical attributes of the relationship between two entities or entity sets. Different types
of cardinal relationships are:

• One-to-One Relationships
• One-to-Many Relationships
• May to One Relationships
• Many-to-Many Relationships

141-CIS LAB Manual 23


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Weak Entities

A weak entity is a type of entity which doesn't have its key attribute. It can be identified uniquely by
considering the primary key of another entity. For that, weak entity sets need to have participation.

Attributes

• It is a single-valued property of either an entity-type or a relationship-type.

• For example, a lecture might have attributes: time, date, duration, place, etc.

• An attribute is represented by an Ellipse

141-CIS LAB Manual 24


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Types of Attributes

Steps to Create an ERD

Following are the steps to create an ERD.

Attribute Relationship Cardinality

Enitiy Identification Create ERD
Identification Identification Identification

EXAMPLE:

In a university, a Student enrolls in Courses. A student must be assigned to at least one or more
Courses. Each course is taught by a single Professor. To maintain instruction quality, a Professor
can deliver only one course.

Step 1) Entity Identification

• Student
• Course
• Professor

Step 2) Attribute Identification

• Student: id, name

• Professor: id, name

141-CIS LAB Manual 25


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

• Course: id, name

Step 3) Relationship Identification

• The student is assigned a course

• Professor delivers a course

Step 4) Cardinality Identification

• A student can be assigned multiple courses

• A Professor can deliver only one course

Step 5) Create the ERD

141-CIS LAB Manual 26


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Lab (5): ERDs Case Studies

Case Study 1) Car Garage

We want to build a system for a car garage. In a car garage the customer/ client can buy a car, sell a car
or get repaired a car. In the garage, there are two types of employees, one is salesman and other is mechanic.
The salesman is responsible for selling and buying cars. The mechanic is responsible for repairing the cars.

The cars are repaired through repair-job which is a weak entity associated to the entity car through
weak association “repair”.

Identify the possible entities and their attribute, the relationships among the attributes and draw the
ER diagram for the above-mentioned activities and associations.

Solution

Step 1) Entity & Attributes Identification

Entity Attribute
Mechanic Id, Name, Salary
Salesman Id, Name, Salary
Repair Job Description, number, cost (parts, work)
Car Id, Make, Model, Price
Client Id, Name, Phone Number, address
Step 2) Relationship Identification

• Mechanic does repair job

• Repair job rapiers cars
• Salesman sells cars
• Salesman buys cars
• Client buys cars
• Client sells cars

Step 3) Cardinality Identification

• At least one Mechanic repairs many cars

• At least one Salesman sells many cars
• At least one Salesman buys many cars
• One client buys many cars
• One Client sells many cars

141-CIS LAB Manual 27


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Step 4) Create the ERD

LAB ACTIVITY

Based on what you have learned about relationships, try to draw the cardinality between relations in
the above diagram.

141-CIS LAB Manual 28


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Case Study 2) Online Book Store:

We want to build a system for online bookstore. In the online bookstore there should be all required
information related to books, their authors, publishers and other attributes.

The following information need to be depicted by the ER diagram. The books are written by authors and
they are published by publishers. In the system, there should be the facility of shopping-basket/shopping
cart where the customers can put their selected books. The books are stored in warehouse, so we need to
include the information of warehouse too.

Identify the possible entities and their attribute, the relationships among the attributes and draw the E-
R diagram for the above-mentioned activities and associations.

Step 1) Entity & Attributes Identification

Entity Attribute
Author AuthorId, Name, Address
Publisher URL, Name, Address
Book ISBN, title, year, price
Customer name, address, email, phone
Shopping-basket basketID
Warehouse code, address, phone
Step 2) Relationship Identification

1. Book written-by author

2. Book published-by publisher
3. Customer basket-of shopping-basket
4. Shopping-basket contains book
5. Warehouse stocks book

Step 3) Cardinality Identification (LAB ACTIVITY)

• ………………………………………………………………………………………………..
• ………………………………………………………………………………………………..
• ………………………………………………………………………………………………..
• ………………………………………………………………………………………………..
• ………………………………………………………………………………………………..

141-CIS LAB Manual 29


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Step 4) Create the ERD

141-CIS LAB Manual 30


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Lab (6): Introduction to UML

What is UML?

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing,
and documenting the artifacts of software systems, as well as for business modeling and other non-software
systems. The UML represents a collection of best engineering practices that have proven successful in the
modeling of large and complex systems. The UML is a very important part of developing object-oriented
software and the software development process. The UML uses mostly graphical notations to express the
design of software projects. Using the UML helps project teams communicate, explore potential designs,
and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

• Provide users with a ready-to-use, expressive visual modeling language so they can develop and
exchange meaningful models.
• Provide extensibility and specialization mechanisms to extend the core concepts.
• Be independent of particular programming languages and development processes.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the OO tools market.
• Support higher-level development concepts such as collaborations, frameworks, patterns and
components.
• Integrate best practices.

UML Modeling Tools

The important UML modeling tools include:

• Rational Rose
• Smart Draw
• Visible Analyst
• Microsoft Visio etc.

141-CIS LAB Manual 31


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Types of UML Diagrams

Each UML diagram is designed to let developers and customers view a software system from a different
perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools
include:

1. Use Case Diagram

2. Class Diagram
3. Interaction Diagrams
a. Sequence Diagram
b. Collaboration Diagram
4. State Diagram
5. Activity Diagram
6. Physical Diagrams
a. Component Diagram
b. Deployment Diagram

System Scenario

A scenario is a description of a person's interaction with a system. Scenarios help focus design efforts
on the user’s requirements, which are distinct from technical or business requirements.

Scenarios may be related to 'use cases', which describe interactions at a technical level. Unlike use cases,
however, scenarios can be understood by people who do not have any technical background. They are
therefore suitable for use during participatory design activities.

When are scenarios appropriate?

Scenarios are appropriate whenever you need to describe a system interaction from the user's
perspective. They are particularly useful when you need to remove focus from the technology in order to
open up design possibilities.

How do you use scenarios?

Use scenarios during design to ensure that all participants understand and agree to the design
parameters, and to specify exactly what interactions the system must support. Additionally, translate
scenarios into tasks for conducting walk-through activities and usability tests.

141-CIS LAB Manual 32


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

How do you write scenarios?

To write a scenario, you need a basic understanding of the tasks to be supported by the system. You also
need to have an understanding of the users and the context of use. Scenarios can be derived from data
gathered during contextual enquiry activities. To write a scenario, describe in simple language the
interaction that needs to take place. It is important to avoid references to technology. Include references to
all relevant aspects of the interaction. References may include cultural and attitudinal issues.

After you have written a scenario, review it and remove any unwanted references to systems or
technologies. You should also have the scenario reviewed by users to ensure that it is representative of the
real world.

Example:

(Scenario to cash a cheque in bank)

• A customer presents a cheque to a clerk.

• The clerk checks the file containing all the account numbers and make sure whether the account
number on the cheque is valid.
• Adequate balance is there in the account
• The signature is authentic.
• Having done these the clerk gives the customer a token.
• The clerk also debts the customer account by the amount specified on the cheque.
• If the cheque cannot be cashed due to a mistake on it, it will be returned.
• The token number is written on the top of the cheque and it is passed on to the cashier.
• The cashier calls out the token number.
• The customer goes to the cashier with the token.
• The cashier
o Checks the token,
o Takes the customer's signature,
o Pays cash,
o Enters cash paid in the ledger/ debt book and stores the cheque.

141-CIS LAB Manual 33


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (6) HOMEWORK

Write a scenario of your choice. The scenario should provide basic understanding of the tasks to be
supported by the system. The scenario also should give an understanding of the users and the context of use.

141-CIS LAB Manual 34


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (07): Use Case Diagram

Use Case Diagram

A use case is a set of scenarios that describing an interaction between a user and a system. A use case
diagram displays the relationship among actors and use cases.

Elements of Use Case Diagram

The two main components/ elements of a use case diagram are

• Actors
• Use cases
• Arrows to represent relationship between actors and use cases

Actor:

• An actor is representing a user or another system that will interact with the system you are
modeling.
• An actor in a use case diagram interacts with a use case. For example, for modeling a
banking application, a customer entity represents an actor in the application.
Similarly, the person who provides service at the counter is also an actor. But it is up
to you to consider what actors make an impact on the functionality that you want to
model. If an entity does not affect a certain piece of functionality that you are modeling, it makes
no sense to represent it as an actor.
• An actor is shown as a stick figure in a use case diagram.

Use Case:

• A use case is an external view of the system that represents some action the user might perform
in order to complete a task.
• A use case in a use case diagram is a visual representation of distinct business functionality in a
system. The key term here is...Distinct business functionality." Remember that identifying use
cases is a discovery rather than a creation
• A use case is shown as an ellipse in a use case diagram.

141-CIS LAB Manual 35


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

How to Draw Use Cases Diagrams?

Use cases are a relatively easy UML diagram to draw, but this is a very simplified example.

This example is only meant as an introduction to the UML and use cases. If you would like to learn more
see the Resources page for more detailed resources on UML.

Start by listing a sequence of steps a user might take in order to complete an action. For example, a user
placing an order with a sales company might follow these steps.

1. Browse Products
2. select items.
3. Call sales representative.
4. Supply shipping information.
5. Supply payment information.
6. Receive conformation number from salesperson.

These steps would generate this simple use case diagram

141-CIS LAB Manual 36


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Case Study 1) Online Shopping

A web Customer uses some web site to make purchases online.

• The customer could be a new customer or registered customer.

The customer can:

• View Items
o Search Items
o Browse Items
o Add to shopping cart
• Make Purchase
• Checkout
o Make a payment by credit card
o Make a payment by PayPal
• Client Register

View Items could be used by customer as top-level use case if customer only wants to find and see some
products. This use case could also be used as a part of Make Purchase use case. Client Note, that Checkout
use case is included use case not available by itself - checkout is part of making purchase.

141-CIS LAB Manual 37


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Case Study 2) Hospital reception management

Hospital Management System is a large system including several subsystems or modules providing
variety of functions. UML use case diagram example below shows actor and use cases for a hospital's
reception.

• Purpose: Describe major services (functionality) provided by a hospital's reception.

• Hospital Reception subsystem or module supports some of the many job duties of hospital
receptionist. Receptionist does the following:
• schedules patient's appointments and admission to the hospital
• collects information from patient upon patient's arrival and/or by phone.
• For the patient that will stay in the hospital ("inpatient") she or he should have a bed allotted in
a ward.
• Receptionists might also receive patient's payments
• record them in a database and provide
o receipts
o file insurance claims
o medical reports.

141-CIS LAB Manual 38


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (7) Activity

Refer to the scenario you wrote in LAB (6) HOMEWORK. Draw the Use Case Diagram for the scenario.
You diagram should illustrate the following:

• Actors
• Top-level use cases
• <<include>> use cases
• <<extend>> use cases
• Generalizations

141-CIS LAB Manual 39


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (08): Use-Case Scenarios and related case studies

Developing Use Case Scenarios

Each use case has a description which is referred to as use case scenario (situation). There is no standardized
use case scenario. The followings are must specified in use case scenarios:

• Use case name and ID

• Author and Date
• Actor(s)
• Description
• Triggering events
• Preconditions
• Post conditions
• Basic path
• Alternative path

Use Case ID and Name

Give each use case a unique integer sequence number identifier. State a concise name for the use case
that indicates the value the use case would provide to some user. Begin with an action verb, followed by an
object.

Author and Date Created

Enter the name of the person who initially wrote this use case and the date it was written.

Primary and Secondary Actors

An actor is a person or other entity external to the software system being specified who interacts with
the system and performs use cases to accomplish tasks. Different actors often correspond to different user
classes, or roles, identified from the customer community that will use the product. Name the primary actor
that will be initiating this use case and any other secondary actors who will participate in completing
execution of the use case.

Description

Provide a brief description of the reason for and outcome of this use case, or a high-level description of
the sequence of actions and the outcome of executing the use case.

141-CIS LAB Manual 40


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Trigger

Identify the business event, system event, or user action that initiates the use case. This trigger alerts
the system that it should begin testing the preconditions for the use case so it can judge whether to proceed
with execution.

Preconditions

List any activities that must take place, or any conditions that must be true, before the use case can be
started. The system must be able to test each precondition. Number each precondition. Example: PRE-1:
User’s identity has been authenticated.

Postconditions

Describe the state of the system at the successful conclusion of the use case execution. Label each
postcondition in the form POST-X, where X is a sequence number. Example: POST-1: Price of item in the
database has been updated with the new value.

Normal Flow

Provide a description of the user actions and corresponding system responses that will take place during
execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to
accomplishing the goal stated in the use case name and description. Show a numbered list of actions
performed by the actor, alternating with responses provided by the system. The normal flow is numbered
“X.0”, where “X” is the Use Case ID.

Alternative Flows

Document other successful usage scenarios that can take place within this use case. State the alternative
flow and describe any differences in the sequence of steps that take place. Number each alternative flow in
the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number for the alternative flow. For example,
“5.3” would indicate the third alternative flow for use case number 5. Indicate where each alternative flow
would branch off from the normal flow, and if pertinent, where it would rejoin the normal flow.

Other Information

Identify any additional requirements, such as quality attributes, for the use case that may need to be
addressed during design or implementation. Also list any associated functional requirements that aren’t a
direct part of the use case flows but which a developer needs to know about. Describe what should happen
if the use case execution fails for some unanticipated or systemic reason (e.g., loss of network connectivity,

141-CIS LAB Manual 41


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

timeout). If the use case results in a durable state change in a database or the outside world, state whether
the change is rolled back, completed correctly, partially completed with a known state, or left in an
undetermined state as a result of the exception.

Use Case Scenario Template

UC ID and Name:
Created By: Date Created:
Primary Actor: Secondary Actors:
Trigger:
Description:
Preconditions:
Postconditions:
Normal Flow:
Alternative Flows:
Other Information:

141-CIS LAB Manual 42


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Case Study 1) Online Shopping

A web Customer uses some web site to make purchases online.

• The customer could be a new customer or registered customer.

The customer can:

• View Items
o Search Items
o Browse Items
o Add to shopping cart
• Make Purchase
• Checkout
o Make a payment by credit card
o Make a payment by PayPal
• Client Register

View Items could be used by customer as top-level use case if customer only wants to find and see some
products. This use case could also be used as a part of Make Purchase use case. Client Note, that Checkout
use case is included use case not available by itself - checkout is part of making purchase.

141-CIS LAB Manual 43


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

UC ID and Name: UC-1 Register an account
Created By: NAME Date Created: DD-MM-YYYY
Primary Actor: Customer Secondary Actors: Online Shopping System
Description: A Customer accesses Online Titan Electronics via Internet and registers in it.
Trigger: A Customer indicates that he/she wants to register an account.
Preconditions: PRE-1: Customer does not have an account
Postconditions: POST-1: Customer has successfully created an account
Normal Flow:
1. User clicks on “Create an Account” from the front page
2. System displays the “Registration” page
3. User inputs Name
4. User inputs Address
5. User inputs City
6. User inputs State
7. User inputs Zipcode
8. User inputs emailed
9. User inputs password
10. User inputs confirm password
11. User clicks on “Register” button
12. System creates the account for user
Alternative Flows:
1a. The user clicks on add to cart button to add an item to the shopping cart
1a1. The system navigates to Step 2
Exceptions:
3.0.E01. The user leaves any of the registration information as blank
1. System displays error message “this field is required”
2. System Navigates to one of the steps 3,4,5,6,7,8
1.0.E10. User keeps confirm password as blank
1. System displays an error message saying “This field is required”
2. System navigates to step 12
1.0.E12. User enters confirm password other than password
1. System displays an error message saying “Entered password does not match”
2. System navigates to step 12.
Other Information
Priority:
§ High
Business Assumption
§ This is a pre-condition for all other use-cases because without the user account
none of the other features can be accessed except View Items

141-CIS LAB Manual 44


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

UC ID and Name: UC-03 Search Items
Created By: NAME Date Created: DD-MM-YYYY
Primary Actor: Customer Secondary Actors: Online Shopping System
Description: A Customer accesses the online shopping systems via Internet and registers an account,
logs into it and searches for items he/she wish to purchase
Trigger: The customer clicks on Search items button
Preconditions:
PRE-1: UC #01 (customer registration)
PRE-2: UC #02 (customer login)
Postconditions: POST-1.: The customer is successfully able to find desired items; the system will display a
list of the items that match the search criteria.
Normal Flow:
1. Customer clicks on ‘Items’ link from the home page
2. System displays ‘Items’ Page
3. Customer inputs Item name he/she wish to purchase in the ‘Search’ Box
4. Customer clicks on ‘Search’ Button
5. System shows all the items to the user that matches the search criteria
Alternative Flows:
3a. Customer filters the items category, price range, brand
3a1. Customer clicks on ‘Search by Filter’ Button
3a2. System navigates to Step 5
5a. System does not show any product to the customer that matches the search
criteria
5a1. System displays a message saying ‘No Products that matches the criteria’
5a2. System navigates to Step 2
Exceptions:
7.0.E4. The customer inputs a wrong spelling of an item
1. System shows an error message saying ‘Cannot find items’
2. System navigates to Step 3
Other Information
Priority:
§ High
Business Assumption
§ The user can search for items through the website

141-CIS LAB Manual 45


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Lab (8) Homework

Choose any two use cases from case study -2 in lab 7. Then, write a complete scenario as you learned in
this lab.

141-CIS LAB Manual 46


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (09): Class Diagram

Imagine you were given a task of drawing a family tree. The steps you would take would be:

• Identify the main members of the family.

• Determine how they are related to each other.
• Identify the characteristics of each family member.
• Find relations among family members.
• Decide the inheritance of personal traits and characters.

A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces
reflecting important entities of the business domain of the system being modeled, and the relationships
between these classes and interfaces.

The classes and interfaces in the diagram represent the members of a family tree and the relationships
between the classes are analogous to relationships between members in a family tree.

Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent
classes and related child classes under the parent classes.

Similarly, a software application is comprised of classes and a diagram depicting the relationship
between each of these classes would be the class diagram.

Definition:

By definition class diagram is a diagram showing a collection of classes and interfaces along with the
collaborations and relationships among classes and interfaces.

• Class diagrams are widely used to describe the types of objects in a system and their
relationships.
• Class diagrams model class structure and contents using design elements such as classes,
packages and objects.
• A class diagram is a pictorial representation of the detailed system design. A thing to remember
is that a class diagram is a static view of a system.
• The structure of a system is represented using class diagrams. These perspectives become
evident as the diagram is created and help solidify the design.

141-CIS LAB Manual 47


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Components of a Class Diagram

Classes are composed of three things:

• Name.
• Attributes.
• Operations.

The format for attributes is:

visibility AttributeName: type

The visibility is as follows:

Symbol Access

- Private

+ Public

# Protected

/ Derived

Relationships between classes

UML is not just about pretty pictures. If used correctly, UML precisely conveys how code should be
implemented from diagrams. If precisely interpreted, the implemented code will correctly reflect the intent
of the designer. A class may be involved in one or more relationships with other classes. A relationship can
be one of the following types:

141-CIS LAB Manual 48


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Inheritance (or Generalization):

A generalization is a taxonomic relationship between a more general classifier and a more specific classifier.
Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific
classifier inherits the features of the more general classifier.

• Represents an "is-a" relationship.

• An abstract class name is shown in italics.
• SubClass1 and SubClass2 are specializations of SuperClass.

The figure below shows an example of inheritance hierarchy. SubClass1 and SubClass2 are derived from
SuperClass. The relationship is displayed as a solid line with a hollow arrowhead that points from the child
element to the parent element.

Association

Associations are relationships between classes in a UML Class Diagram. They are represented by a solid
line between classes. Associations are typically named using a verb or verb phrase which reflects the real-
world problem domain.

Simple Association

• A structural link between two peer classes.

• There is an association between Class1 and Class2

The figure below shows an example of simple association. There is an association that connects the
<<control>> class Class1 and <<boundary>> class Class2. The relationship is displayed as a solid line
connecting the two classes.

141-CIS LAB Manual 49


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Cardinality

Cardinality is expressed in terms of:

• one to one
• one to many
• many to many

Aggregation

A special type of association.

• It represents a "has-a" relationship.

• Class2 is part of Class1.
• Many instances (denoted by the *) of Class2 can be associated with Class1.
• Objects of Class1 and Class2 have separate lifetimes.

The figure below shows an example of aggregation. The relationship is displayed as a solid line with a
unfilled diamond at the association end, which is connected to the class that represents the aggregate.

Composition

• A special type of aggregation where parts are destroyed when the whole is destroyed.
• Objects of Class2 live and die with Class1.
• Class2 cannot stand by itself.

141-CIS LAB Manual 50


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

The figure below shows an example of composition. The relationship is displayed as a solid line with a
filled diamond at the association end, which is connected to the class that represents the whole or composite.

When to Use Class Diagrams?

Class diagrams are used in nearly all Object-Oriented software designs. Use them to describe the Classes
of the system and their relationships to each other.

How to Draw Class Diagrams?

Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and useful
diagrams a person would have to study UML and Object-Oriented principles for a long time.

When designing classes consider what attributes and operations it will have. Then try to determine how
instances of the classes will interact with each other. These are the very first steps of many in developing a
class diagram.

Dos and Don'ts

• Classes in a class diagram should be descriptive and must be named after business entities.
• Using business entities as names ensures greater readability of class diagrams.
• Relationships between classes may not be apparent in the first iteration.
• Revise and refine your class diagrams to determine possible relationships during each
iteration.
• Designing is an incremental process and class diagrams are updated as the system gets built.
Hence, do not try to capture and freeze the class diagrams of a system in the first pass.

141-CIS LAB Manual 51


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Examples

Inheritance (or Generalization):

Association relationship:

141-CIS LAB Manual 52


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Example of aggregation and composition:

LAB (09) Activity

Draw the above diagram using the software using Visual Paradigm, or Creately

141-CIS LAB Manual 53


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

LAB (10): Class Diagram Case Studies

Case Study (1) Online Shopping System

Here we provide an example of UML class diagram which shows a domain model for online shopping.
The purpose of the diagram is to introduce some common terms, "dictionary" for online shopping - Customer,
Web User, Account, Shopping Cart, Product, Order, Payment, etc. and relationships between. It could be used
as a common ground between business analysts and software developers.

Each customer has unique id and is linked to exactly one account. Account owns shopping cart and
orders. Customer could register as a web user to be able to buy items online. Customer is not required to be
a web user because purchases could also be made by phone or by ordering from catalogues. Web user has
login name which also serves as unique id. Web user could be in several states - new, active, temporary
blocked, or banned, and be linked to a shopping cart. Shopping cart belongs to account.

Account owns customer orders. Customer may have no orders. Customer orders are sorted and unique.
Each order could refer to several payments, possibly none. Every payment has unique id and is related to
exactly one account.

Each order has current order status. Both order and shopping cart have line items linked to a specific
product. Each line item is related to exactly one product. A product could be associated to many line items or
no item at all.

141-CIS LAB Manual 54


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

a Person could be associated with different Hospitals, and a Hospital could employ or serve multiple
Persons. Person class has derived attributes name and homeAddress. Name represents full name and could
be combined from title, given (or first) name, middle name, and family (or last) name. Patient class has
derived attribute age which could be calculated based on her or his birth date and current date or hospital
admission date.

The Patient class inherits attributes from the Person class. Such as name, gender, and birthdate.

141-CIS LAB Manual 55


Department of Information systems ‫ﻗﺴﻢ ﻧﻈﻢ اﻟﻤﻌﻠﻮﻣﺎت‬

Ward is a division of a hospital or a suite of rooms shared by patients who need a similar kind of care.
In a hospital, there are a number of wards, each of which may be empty or have on it one or more patients.
Each ward has a unique name.

Every ward has a fixed capacity, which is the maximum number of patients that can be on it at one time
(i.e. the capacity is the number of beds in the ward). Different wards may have different capacities. The
doctors in the hospital are organized into teams. Each team has a unique name or code (e.g. Orthopedics
or Pediatrics) and is headed by a consultant doctor or attending physician.

141-CIS LAB Manual 56