SOFTWARE CONSTRUCTION AND

DEVELOPMENT

LABORATORY MANUAL

Lab 01: INTRODUCTION TO OBJECT ORIENTED

SOFTWARE ENGINEERING AND OBJECT
ORIENTATION IN UML

Faculty of Computing (FC)

Riphah International University Islamabad
 LAB 1 – INTRODUCTION TO OBJECT ORIENTED SOFTWARE
ENGINEERING AND OBJECT ORIENTATION IN UML

Objective

• Introduction to Object Oriented Software Engineering

• Review of OOP
• Understanding system models
• Understanding Object Oriented Analysis and Design (OOAD)
• Software Development activities in OO

Time Required : 3 hrs

Programming Language : NIL
Software Required : MS Word
Hardware Required : PC/Laptop

1. Engineering a Software Solution: There is a standard design methodology whenever

you want to build a software:
a. List the requirements the software is supposed to meet.
b. Make a complete design.
c. Develop (implement) it.
d. Test it to make sure it’s going to work.

2. What is Object Oriented Software

Engineering?
It is a methodology for engineering a
software solution based on the principles of
object-orientation, where real-world
entities are represented as objects in the
solution system. OBJECT-ORIENTED
SOFTWARE DEVELOPMENT uses the
object-oriented concepts of abstraction,
encapsulation, inheritance, and
polymorphism to model (analyse and
design) a software solution which is then
implemented in an object-oriented programming language (such as Java, C# etc). This
allows the solution software to achieve reusability, extensibility, and flexibility goals of
software engineering. Thus, object-oriented software development is the object-oriented
way of constructing software.
3. What are Principles of Object Orientation? When modelling a solution in object-
oriented software development, principles of object orientation form the foundation of the
constructed system, therefore it is important to understand them:

a. Abstraction: Abstraction means a representation of a real-world entity, thing or a

concept as an Object. It focuses on ignoring irrelevant features, properties, or functions
of the real-world object and emphasizing the ones relevant to the scope of the problem.
For example: A Student class in a university’s course registration system represents a
real-world student at a university. This student may have grandparents, but for a course
registration system, this information about the student is irrelevant. Only his/her name,
registration number and semester details are relevant. Hence only relevant details are
kept when modelling the system.
b. Polymorphism: Polymorphism is the phenomenon of an something existing in more
than one form. It ensures that the appropriate method is called for an object of a specific
type when the object is disguised as a more general type.

c. Inheritance: A class can extend another class, inheriting all its data members and
methods while redefining some of them and/or adding its own. Inheritance represents
the is a relationship between data types. For example: a Circle is a Shape. A Software
Engineering Student is a Student.

d. Encapsulation: Encapsulation means that all relevant information and behaviour of a

real-world object are enclosed as a class/object and is also hidden from the other objects
to protect it from unauthorized access (such as private attributes and functions of a
class). Other classes interact with this class only through its interface (i.e. constructors
and public methods).

4. Software Lifecycle in OO development: The activities associated with software

development are:

a. Requirements Elicitation: During

requirements elicitation, the client
and developers define the purpose of
the system. The result of this activity
is a description of the system in terms
of actors and use cases. Non-
functional requirements are also
elicited.

b. Analysis: During analysis,

developers aim to produce a model of
the system that is correct, complete,
consistent, and unambiguous.
Developers transform the use cases
produced during requirements
elicitation into an object model that
completely describes the system.
 c. System Design: During system design, developers define the design goals of the project
and decompose the system into smaller subsystems that can be realized by individual
teams. The result of system design is a clear subsystem decomposition and a deployment
diagram representing the hardware/software mapping of the system.

d. Object Design: During object design, developers define solution domain objects to
bridge the gap between the analysis model and the hardware/software platform defined
during system design.

e. Implementation: During implementation, developers translate the solution domain

model into source code. This includes implementing the attributes and methods of each
object and integrating all the objects such that they function as a single system.

f. Testing: During testing, developers find differences between the system and its models
by executing the system (or parts of it) with sample input data sets. During system
testing, typical and exception cases are run through the system and compared with the
requirements model. The goal of testing is to discover as many faults as possible such
that they can be repaired before the delivery of the system.

Broadly we can say:

Analysis -- Conceptual Model, System Requirements
Design -- System Design, Detailed Design
Implementation -- Coding, Testing

5. Work Product or Artefacts: Each of these software development activities generates an

artifact, such as an analysis document or a piece of code for other developers or for the
client, these artefacts are called work products.

6. Modelling a System in object-oriented software development: System development in

object-oriented software
development focuses on three
different models of the system:
System Model, Task Model, and
Issue Model. Models are used to
represent real word concepts or
systems in a notational form thus is
done for understanding the system
we want to build and for
documenting the system. System
Model is basically used to analyse
and design the system itself. Task
Model includes the project
management aspect for the
developed system and Issue Model
covers the important change
management aspects.
7. Object Oriented Analysis and Design (OOAD): Analysis and Design activities attempt
to build a system model that describes the application domain and object-oriented software
development aims to construct the system into objects. Thus, OOAD aims at identifying
objects and classes the system can be composed of, their associated behaviours and
identifies the roles (internal/external) that will interact with this behaviour when the system
is fully operational. So OOAD is effectively the modelling documentation that you have to
generate before you embark on fully implementing a long and potentially expensive
software project. Analysis takes place after (or during) requirements specification and
design comes after (or along with it). During OOAD the System Model is developed, aimed
at helping the analyst and designer to understand a system from three different aspects
(each represented by a different type of system model):
a. The Functional Model describes the functionality of the system from the user’s point
of view. “What the system is supposed to do?” and “Who uses which behaviour of the
system?” – These questions are answered through model.

b. The Object Model describes the structure of the system in terms of objects, attributes,
associations, and operations. Answers questions of “What classes/objects is the system
divided into?” and “How are these classes inter-related?”

c. The Dynamic Model describes the internal behaviour of the system in reaction to an
external trigger. This model helps answer the following questions about the system
under construction: “What is the sequence of functionality executed by the system?”
and “How does an object behave when its function is called by some external trigger?”

8. Unified Modelling Language: The Unified Modelling Language (UML) is a general-

purpose, developmental, modelling language in the field of software engineering that is
intended to provide a standard way to visualize the design of a system, including elements
such as: any activities (jobs); individual components of the system; and how they can
interact with other software components; how the system will run; how entities interact
with others (components and interfaces); external user interface. UML is originally
intended for object-oriented design documentation, however now it has been extended to a
larger set of design documentation and been found useful in many contexts. UML is a tool
for modelling an Object-Oriented system. UML has many types of diagrams, which are
divided into two categories:

a. Static (or structural) diagrams emphasize the static structure of the system using
objects, attributes, operations, and relationships. It includes class diagrams and
composite structure diagrams. The four structural diagrams in UML are:
• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
 b. Dynamic (or behavioural) diagrams emphasize the dynamic behaviour of the system
by showing collaborations among objects and changes to the internal states of objects.
This view includes sequence diagrams, activity diagrams and state machine diagrams.
Some types represent structural information, and the rest represent general types of
behaviour, including a few that represent different aspects of interactions.
UML has the following five types of behavioural diagrams:
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Activity diagram.
9. UML Notations: Each UML diagram consists of symbols (which
depict a concept), directed lines or arcs (which depict
relationships between concepts), and labels for these symbols and
lines (depicting their name or nature).
10. UML Versions: UML has been evolving
since the second half of the 1990s and has
its roots in the object-oriented
programming methods. UML started
from version 1.0 and has reached 2.5
currently. Each version supports a
variation of symbols and diagramming
elements.
11. UML Tools: Many professional UML
tools are available on the internet (for free
and/or paid) that let you draw UML
diagrams with ease.
12. Goals of UML: A picture is worth a thousand words; this absolutely fits while discussing
about UML.
There are a number of goals for developing UML but the most important is to define some
general-purpose modelling language which all modelers can use and also it needs to be
made simple to understand and use. UML diagrams are not only made for developers
but also for business users, common people and anybody interested to understand
the system. The system can be a software or non-software. So, it must be clear that UML
is not a development method rather it accompanies with processes to make a successful
system.
At the conclusion the goal of UML can be defined as a simple modelling mechanism to
model all possible practical systems in today’s complex environment.
13. Object Oriented Analysis and Design using UML Diagrams: UML diagrams are used
to understand and elicit system requirements and helps in providing a visual picture of the
system to be constructed. Therefore, Analysis and even design heavily involves
diagramming using UML. However, it is important to distinguish that a diagram is a partial
graphic representation of a system's model. The set of diagrams need not completely cover
the system model and deleting a diagram does not change the model. The model may also
contain documentation that drives the model elements and diagrams (such as written use
cases). The following diagrams are associated with the given system models:
Functional model: Use Case Diagram
Object Model: Class Diagram and Object Diagram
Dynamic Model: Sequence Diagram, Interaction diagram, State Machine Diagram,
Activity Diagram.

Data Flow Diagram

A data flow diagram shows the way information flows through a process or system. It
includes data inputs and outputs, data stores, and the various subprocesses the data moves
through. DFDs are built using standardized symbols and notation to describe various
entities and their relationships. Data flow diagrams visually represent systems and
processes that would be hard to describe in a chunk of text. You can use these diagrams to
map out an existing system and make it better or to plan out a new system for
implementation.

Data flow diagrams can be divided into logical and physical. The logical data flow diagram
describes flow of data through a system to perform certain functionality of a business. The
physical data flow diagram describes the implementation of the logical data flow.
 DFD rules and tips
• Each process should have at least one input and an output.
• Each data store should have at least one data flow in and one data flow out.
• Data stored in a system must go through a process.
• All processes in a DFD go to another process or a data store.

Levels Of Data Flow Diagrams:

i) 0-level DFD:
It is also known as a context diagram. It’s designed to be an abstraction view, showing the
system as a single process with its relationship to external entities. It represents the entire
system as a single bubble with input and output data indicated by incoming/outgoing
arrows.

Hotel
management
information

ii) 1-level DFD:

In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes. In this
level, we highlight the main functions of the system and breakdown the high-level process
of 0-level DFD into subprocesses.

Installation of UML Software (at the end of lab)

• See Task 1.3

Note: Carefully understand the concept present in manual. (At the end of lab there will
be a short viva too)

LAB TASK
Note: You may browse online to answer the following questions. But you must have complete
understanding of that and write references too. [Total Marks = 10]
Lab Task 1.1
Describe the difference of Abstraction and Encapsulation principles of object orientation
through the diagram? Also gave one example of each. Make sure each student should have
different example.
Lab Task 1.2
Which UML diagram corresponds to Functional model of a system? Explain
How?

Lab Task 1.3

Explore online UML tools with their pro and cons and mentions the name and website address
of at least 4 of them.
After taking suggestion we will finalize the tool for the lab and install it in the systems.
2. DFDs Tasks: You can use MS Word or PowerPoint for this
Lab task 2.1
Make Data flow diagram of the cash withdrawal through Automated Teller Machine (ATM).

Lab task 2.2

Draw the flow diagram of courier management service? (For e.g., TCS, Leopard etc)