Lab Manual: Software Construction

Teacher Signature:

Student Registration No:

Lab Manual for Software Construction

Lab No. 4
Introduction to UML – System
Modeling

1
Software Engineering Department
Bahria University (Karachi Campus)
Lab Manual: Software Construction

BAHRIA UNIVERSITY KARACHI CAMPUS

Department of Software Engineering

SOFTWARE CONSTRUCTION

LAB EXPERIMENT # 4

Introduction to UML – System Modeling

Objective

 Study the benefits of visual modeling.

• Learn use case diagrams: discovering actors and discovering use cases.\
• Learn Context and Data Flow Diagram.
 Practice Diagrams Using Modeling software i.e Rational Rose or MS Visio

Background
Visual Modeling is a way of thinking about problems using models organized around
real-world ideas. Models are useful for understanding problems, communicating with
everyone involved with the project (customers, domain experts, analysts, designers,
etc.), modeling enterprises, preparing documentation, and designing programs and
databases

Visual Modeling
• Capture the structure and behavior of architectures and components.
• Show how the elements of the system fit together.
• Hide or expose details appropriate for the task.
• Maintain consistency between a design and its implementation.
• Promote unambiguous communication.

What is UML(Unified Modeling Language)?

The UML is the standard language for visualizing, specifying, constructing and
documenting the artifacts of a software-intensive system. UML can be used with all
processes throughout the development life cycle and across different implementation
technologies.

History of UML
The UML is an attempt to standardize the artifacts of analysis and design: semantic
models, syntactic notation and diagrams. The first public draft (version 0.8) was
introduced in October 1995. Feedback from the public and Ivar Jacobson's input were

10
10
Lab Manual: Software Construction

included in the next two versions (0.9 in July 1996 and 0.91 in October 1996).
Version 1.0 was presented to the Object Management Group (OMG) for
standardization in July 1997. Additional enhancements were incorporated into the 1.1
version of UML, which was presented to the OMG in September 1997. In November
1997, the UML was adopted as the standard modeling language by the OMG.

Video-Rental LTD Case Study

Video-Rental LTD is a small video rental store. The store lends videos to customers for a
fee, and purchases its videos from a local supplier.

REQ1: A customer wishing to borrow a video provides the empty box of the video they
desire, their membership card, and payment

REQ2: payment is always with the credit card used to open the customer account. The
customer then returns the video to the store after watching it.

REQ3: If a loaned video is overdue by a day the customer's credit card is charged, and a
reminder letter is sent to them. Each day after that a further card is made, and each week a
reminder letter is sent. This continues until either the customer returns the video, or the
charges are equal to the cost of replacing the video.

REQ4: New customers fill out a form with their personal details and credit card details,
and the counter staff give the new customer a membership card. Each new customer's form
is added to the customer file.

REQ5: The local video supplier sends a list of available titles to Video-Rental LTD, who
decide whether to send them an order and payment. If an order is sent then the supplier
sends the requested videos to the store. For each new video a new stock form is completed
and placed in the stock file.

Putting UML into Work:

Use Case Diagram
The behavior of the system under development ( i.e. what functionality m u s t be
provided by the system) is documented i n a use case model that illustrates the
system's intended functions (use cases), its surroundings (actors), and relationships
between the use cases and actors (use case diagrams).

Actors
• Are NOT part of the system – they represent anyone or anything that must interact
with the system.
• Input information to the system.
• Receive information from the system.
• Both input to and receive information from the system.
• Usually represented in UML as a stickman.

11
11
Lab Manual: Software Construction

Actors are classified into:

primary actors (also called active actors)

• Primary actors initiate a use case and hence are somewhat independent.
• Placed on Left Side of Use Case System Boundary.

Secondary actors (also called passive actors).

• Secondary actors are used by the system but they do not interact with the system on
their own. In other words, secondary actors do not initiate any use case.
• Placed on right side of Use Case system boundary

The symbol for an actor does not differentiate between a primary actor and a secondary
actor; the difference must be inferred from the use case descriptions (also called use case
narratives).

Use Case
• A sequence of transactions performed by a system that yields a measurable result
of values for a particular actor
• A use case typically represents a major piece of functionality that is complete
from beginning to end. A use case must deliver something of value to an actor.
Represented by Oval with use case text inside

Use Case Relationships

• Between actor and use case(Association / Communication)
• Arrow can be in either or both directions; arrow indicates who initiates
communication.
• Between use cases (generalization):
Include
• Mandatory behavior
• Behavior in which one use case (the base use case) includes the functionality of
another use case (the inclusion use case).

Extends
• Optional behavior.
• Behavior only runs under certain conditions (such as alarm).
• Several different flows run based on the user’s selection.

12
12
Lab Manual: Software Construction

Context Diagram
The context diagram is used to establish the context and boundaries of the system to
be modelled: which things are inside and outside of the system being modelled, and
what is the relationship of the system with these external entities.

The context diagram is used to establish the context and boundaries of the system to
be modelled: which things are inside and outside of the system being modelled, and
what is the relationship of the system with these external entities.

The process of establishing the analysis framework by drawing and reviewing the
context diagram inevitably involves some initial discussions with users regarding
problems with the existing system and the specific requirements for the new system.
These are formally documented along with any specific system requirements
Having agreed on the framework, the detailed investigation of the current system must
be planned. This involves identifying how each of the areas included within the scope
will be investigated. This could be by interviewing users, providing questionnaires to
users or clients, studying existing system documentation and procedures, observation
and so on. Key users are identified and their specific roles in the investigation are
agreed upon.

13
13
Lab Manual: Software Construction
In order to produce the context diagram and agree on system scope, the following
must be identified:
• External entities
• External entities are the sources and recipients lies outside of the system under
investigation.
• Identify external entities by identifying sources and recipients of the data-flows,
which lie outside of the system under investigation.
• Draw and label a process box representing the entire system.

• Data-flows
• Data Flow is the Flow of data between system entities.
• Identify data-flows by listing the major documents and information flows
associated with the system.
• You may find the use of the following kind of table is useful:

Add the data-flows between the external entities and the system box

We can do a quick check when we have created the diagram by counting the number
of flows out of, and into each entity.
From column 'sender' we can see there should be:
o 5 data-flows out of the system
o 5 data-flows out of customer
o 2 data-flows out of supplier

14
14
Lab Manual: Software Construction
From column 'receiver' we can see there should be:
o 7 data-flows into the system.
o 3 data-flows into customer
o 2 data-flows out of supplier
Our context diagram looks as follows:

Data Flow Diagram

Data-flow diagrams provide a graphical representation of the system that aims to be
accessible to computer specialist and non-specialist users alike. The models enable
software engineers, customers and users to work together effectively during the
analysis and specification of requirements. Although this means that our customers are
required to understand the modeling techniques and constructs, in data-flow modeling
only a limited set of constructs are used, i.e Context level Data Stores are not shown
and the rules applied are designed to be simple and easy to follow.
DFD notation consists of only four main symbols:
• Processes — the activities carried out by the system which use and transform
information. Processes are notated as rectangles with three parts.
 The top left-hand box contains the process number.
 The main part of the box is used to describe the process
itself, giving the processing performed on the data it
receives.
 The smaller rectangular box at the bottom of the process
is used to indicate the location where the processing
takes place. A process box that cannot be decomposed further is marked
with an asterisk in the bottom right hand corner
• Data-flows — the data inputs to and outputs from to these activities. Data-
flows are notated as named arrows

• External entities — the sources from which

information flows into the system and the recipients of information leaving the
system.

15
15
Lab Manual: Software Construction

• Data stores — where information is stored within the system. Data stores are
notated as rectangles with two parts
• The small left-hand box is used for the identifier, which comprises a
numerical reference prefixed by a letter
• The main area of the rectangle is labelled with the name of the data
store
 “M” is used where a manual data store is being depicted.
 “D” is used where it is a computer-based data store.
 “T” is used where a temporary data store is being represented.

Multiple copies of entities and data stores on the same

diagram. Where more than one copy of an external entity appears on a diagram it has
a cut off corner in the top left.

Types of DFD
Data Flow Diagrams are either Logical or Physical.
Logical DFD
This type of DFD concentrates on the system process, and flow of data in the system.
For example in a Banking software system, how data is moved between different
entities.

Physical DFD
This type of DFD shows how the data flow is actually implemented in the system. It is
more specific and closer to the implementation.

DFD Level 1
Divide the Main system into major sub-system, Add data stores in our
system/ sub-system

16
16
Lab Manual: Software Construction

There are two reasons for making more levels.

The first is the obvious one: you, as the software engineer, have not fully described a
process to your satisfaction, so you expand that process into a next level diagram. The
new diagram is built in just the same way that a level one is built from a context
diagram only the new inputs and outputs are precisely to the data flows to and from
the process you are expanding.

The second reason is that you realise the diagram you are working on is becoming
cluttered and unclear. To simplify the diagram, collect together a few of the processes.
Ideally, these processes should be related in some way. Replace them with a single
process and treat the original collection of processes as a lower level, expanding the
new process. The inputs and outputs to the new process are whatever inputs and
outputs that are needed to make the diagrams balance. Remember to re-number the old
processes to show that they have been moved down a level.

DFD Level 2

17
17
 Lab Manual: Software Construction

Lab Tasks:
Now you will learn how to apply the above-mentioned methods to draw
Diagrams
1. From the problem statement of your project draw Use Case Diagram, Context
Diagram and Data Flow Diagram update the SRS and upload the updated version
on Trello.
2. Capture a screenshot of the updated SRS document, including the version number
and the created diagrams, and attach them to your lab file.
Note: Use Draw.io or MS Visio to accomplish the above mention task

TIME BOXING:

Activity Name Activity Time Total Time

Instruments Allocation + Setting up 10 mints 10 mints
Lab
Walk through Theory & Tasks 60 mints 60 mints
(Lecture)
Implementation & Practice time 90 mints 80 mints
Evaluation Time 20 mints 20 mints
Total Duration 180 mints

Teacher Signature:

Student Registration No:

11