Object Oriented System

Analysis and Design

Learners’ Material

Mettu University
Faculty of Engineering and Technology
Department of Information Technology
Written by:

Abu Santure (MSc)

Zebider Birhanie (MSc)
Edited by:
Yiteyehu Solomon (MSc)
Baessa Kejela (MSc)

March, 2019
Object Oriented System Analysis and Design:
ITec2062
Credit Hour: 5 ECTS

Written by:
Abu Santure (MSc)
Zebider Berhanie (MSc)

Edited by:

Yiteyehu Solomon (MSc)

Baessa Kejela (MSc)

January, 2019
I
 We hereby declare that this work is not copied from any
source without acknowledging.

Name Signature
Abu Santure ___________

Zebider Birhanie ___________

II
 Table of Contents
List of Figures...................................................................................................................... 4
List of Tables....................................................................................................................... 5
Acronyms.............................................................................................................................6
CHAPTER ONE.................................................................................................................. 1
1. Understanding the Basics of Object Oriented Concepts..................................................1
Chapter Two.......................................................................................................................20
2. Object Orientation: The new software paradigm...........................................................20
Chapter Three.....................................................................................................................27
3. Gathering User Requirements........................................................................................27
3.1 What is Requirements Elicitation?...............................................................................28
3.5.1 Responsibilities and Collaborations..........................................................................34
3.5.2 Elements of a CRC Card...........................................................................................35
Chapter Four...................................................................................................................... 41
4. Ensuring Your Requirements are correct: Requirement validation Techniques........... 41
Chapter Five.......................................................................................................................50
Determining What to Build: Object Oriented Analysis.....................................................50
5.1 Object Oriented Analysis.............................................................................................50
5.2. System Use Case Modeling........................................................................................ 51
The UML icon for use cases.............................................................................................. 54
5.2.1 Sequence Diagram Notations....................................................................................60
5.6.1 Design Patterns......................................................................................................... 74
Chapter Six.........................................................................................................................79
How to Build your System: Object Oriented Design.........................................................79
Object Oriented Design......................................................................................................79
Fig layering classes............................................................................................................ 80
Fig Component Diagram Example: Online Shop.............................................................. 87
GUI Elements.....................................................................................................................90
Chapter Seven.................................................................................................................... 98
Object Oriented /Software Testing.................................................................................... 98
Leading Questions............................................................................................................. 98
Chapter Eight................................................................................................................... 103

III
Software process.............................................................................................................. 103
References........................................................................................................................107

IV
 List of Figures

Figure 1.1 The Systems Development Life Cycle ............................................................ 2

Figure 1.2 object and class..................................................................................................6
Figure 1.3 Real world objec.................................................................................................6
Figure 1.4 The attribute of a car...........................................................................................7
Figure 1.5 Objects of the class employee............................................................................8
Figure 1.6 Class hierarchy...................................................................................................9
Figure 1.7 Association represents the relationship among objects, which is
bidirectional...........................................................................................................13
Figure 1.8 a Aggregation...................................................................................................13
Figure 1.8 b Aggregation...................................................................................................14
Figure 1.9 An MP3 player is system with power supply storage and control system.......16
Figure 3.1 Sample CRC card.............................................................................................37
Figure 4.1 The intraction between users and action..........................................................47
Figure 4.2 The use case scenario testing process pattern...................................................49
Figure 5.1 Use case model.................................................................................................54
Figure 5.2 ATM use case diagram.....................................................................................57
Figure 5.3 Sequence diagram.............................................................................................65
Figure 5.4 Class diagram...................................................................................................69
Figure 5.5 Analysis level class diagram............................................................................70
Figure 5.6 A design level class diagram............................................................................71
Figure 6.1 Layering classess..............................................................................................85
Figure 6.2 Component diagram example...........................................................................92
Figure 6.3 ATM deployment diagram...............................................................................93

V
 List of Tables

Table 3.1 Functional requirement……………………………………………………….30

Table 3.2 Non-functional requirements………………………………………………….30

Table 3.3 Three types of questions………………………………………………………33

Table 4.1 Difference between Verification and validation………………………………42

Table 5.1 Template for a use case description…………………………………………..59

Table 5.2 Use case description …………………………………………………………59

Table 5.3 Activity diagram symbols…………………………………………………….73

Table 6.1 Table 3.1 visibility levels……………………………………………………88

VI
 Acronyms

OOP…………………………..object oriented programming

OOSAD……………………….Object oriented system analysis and design

OOA…………………………..object oriented analysis

OOD………………………….object oriented design

JAD………………………….Joint Application Development

CRC………………………….Class Responsibility collaboration

VII
 CHAPTER ONE
1. Understanding the Basics of Object Oriented Concepts
Unit Objectives

At the end of this chapter the students will be able to:

 Discuss objects in object oriented paradigm
 Understand the object oriented concepts
 Identify and know the principle of object oriented
 Differentiate objects and classes

Leading questions
 What is an object oriented?
 What is an object?
 What is class?
 What are the principles of OOSAD?

1.1 Object Oriented Concepts

Systems Analysis and Design is an exciting, active field in which analysts continually learn new
techniques and approaches to develop systems more effectively and efficiently. However, there is a
core set of skills that all analysts need to know no matter what approach or methodology is used.
All information systems projects move through the four phases of planning, analysis, design, and
implementation; all projects require analysts to gather requirements, model the business needs, and
create blueprints for how the system should be built; and all projects require an understanding of
organizational behavior concepts like change management and team building (Dennis A. et al,
2012).

In object oriented system analysis and design all activities you conduct is also fall under one of the
following phases of system development which is known as system development life cycle. The
life of the system is cyclical since you start the maintenance of the system from the beginning and
go through up to the end again i.e. from planning and section phase to implementation phase. All
information systems projects move through the four phases of planning, analysis, design, and
implementation (Dennis A. et al, 2012).

1
 Figure 1.1 The Systems Development Life Cycle

The four phases of system development life cycle (SDL) are discussed as follows:
System Planning
The systems planning phase usually begins with a formal request to the IT department, called a
systems request, which describes problems or desired changes in an information system or a
business process. In many companies, IT systems planning is an integral part of overall business
planning. When managers and users develop their business plans, they usually include IT
requirements that generate systems requests. A systems request can come from a top manager, a
planning team, a department head, or the IT department itself. The request can be very significant
or relatively minor. A major request might involve a new information system or the upgrading of
an existing system. In contrast, a minor request might ask for a new feature or a change to the user
interface The purpose of this phase is to perform a preliminary investigation to evaluate an IT-
related business opportunity or problem. The preliminary investigation is a critical step because the
outcome will affect the entire development process. A key part of the preliminary investigation is a
feasibility study that reviews anticipated costs and benefits and recommends a course of action
based on operational, technical, economic, and time factors (Shelly G. et al, 2012).

2
System Analysis
The purpose of the systems analysis phase is to build a logical model of the new system. The first
step is requirements modeling, where you investigate business processes and document, what the
new system must do to satisfy users. Requirements modeling continues the investigation that began
during the systems planning phase. To understand the system, you perform fact-finding using
techniques such as interviews, surveys, document review, observation, and sampling. You use the
fact finding results to build business models, data and process models, and object models. The
deliverable for the systems analysis phase is the system requirements document. The system
requirements document describes management and user requirements, costs and benefits, and
outlines alternative development strategies (Shelly G. et al, 2012).

System Design
The purpose of the systems design phase is to create a physical model that will satisfy all
documented requirements for the system. At this stage, you design the user interface and identify
necessary outputs, inputs, and processes. In addition, you design internal and external controls,
including computer-based and manual features to guarantee that the system will be reliable,
accurate, maintainable, and secure. During the systems design phase, you also determine the
application architecture, which programmers will use to transform the logical design into program
modules and code. The deliverable for this phase is the system design specification, which is
presented to management and users for review and approval. Management and user involvement is
critical to avoid any misunderstanding about what the new system will do, how it will do it, and
what it will cost (Shelly G. et al, 2012).

System Implementation
During the systems implementation phase, the new system is constructed. Whether the developers
use structured analysis or Object Oriented methods, the procedure is the same — programs are
written, tested, and documented, and the system is installed. If the system was purchased as a
package, systems analysts configure the software and perform any necessary modifications. The
objective of the systems implementation phase is to deliver a completely functioning and
documented information system. At the conclusion of this phase, the system is ready for use. Final
preparations include converting data to the new system’s files, training users, and performing the

3
actual transition to the new system. The systems implementation phase also includes an assessment,
called a systems evaluation, to determine whether the system operates properly and if costs and
benefits are within expectations (Shelly G. et al, 2012).

Maintenance/Support
It Include all the activities such as phone support or physical on-site support for users that is required
once the system is installing. It implement the changes that software might undergo over a period of
time, or implement any new requirements after the software is deployed at the customer location. It
also includes handling the residual errors and resolve any issues that may exist in the system even
after the testing phase. Maintenance and support may be needed for a longer time for large systems
and for a short time for smaller systems (https://www.tutorialspoint.com). It involves making changes
to hardware, software, and documentation to support its operational effectiveness. It includes making
changes to improve a system's performance, correct problems, enhance security, or address user
requirements.

1.2 Object Oriented

What is an object oriented?

Object-oriented refers to a programming language, system or software methodology that is built on
the concepts of logical objects. It works through the creation, utilization and manipulation of
reusable objects to perform a specific task, process or objective.
(https://www.techopedia.com/definition/3233/object-oriented)

Object oriented is a computer science concept that has been widely implemented, specifically in
programming languages and applications/software. The object-oriented technique is different from
conventional programming, which focuses on functions/behaviors, while object-oriented works on
the interactions of one or more objects. An object-oriented based system is modeled and created
through the use of objects, where each object's class instance has specific attributes and behaviors,
and the relative methods or behaviors are called to manipulate or utilize such a system. The
essence of object-oriented is that each of the created objects can be reused in the same and other
programs and applications.

4
Furthermore, object-oriented is a programming language, system or software methodology that is
built on the concepts of logical objects/software objects. It works through the creation, utilization
and manipulation of reusable objects to perform a specific task, process or objective. Object-
oriented analysis and design (OOAD) is a software engineering approach that models a system as a
group of interacting objects. Each object represents some entity of interest in the system being
modeled, and is characterized by its class, its state (data elements), and its behavior.

According to Shelly G. et al, 2012, structured analysis treats processes and data as separate
components, object oriented analysis combines data and the processes that act on the data into
things called objects. Systems analysts use Object-Oriented to model real-world business processes
and operations. The result is a set of software objects that represent actual people, things,
transactions, and events. Using an Object-Oriented programming language, a programmer then
writes the code that creates the objects.

1.3 Object

What is an Object?

An entity that has a well-defined role in the application domain and has state, behavior, and
identity. An object is a thing, an entity, a noun, something you can pick up or kick, anything you
can imagine that has its own identity. Some objects are living, some aren’t. Examples from the real
world include a car, a person, a house, a table, a dog, a pot plant, a check book or a raincoat. In an
object-oriented system, everything is an object: A spreadsheet, a cell in a spreadsheet, a bar chart,
a title in a bar chart, a report, a number or telephone number, a file, a folder, a printer, a word or
sentence, even a single character all are examples of an object. Each of us deals with objects daily
(Valacich J. et al, 2012).

According to Shelly G. et al, 2012, An object is a member of a class, which is a collection of

similar objects. Objects possess characteristics called properties, which the object inherits from its
class or possesses on its own. As shown in Figure 1.2, the class called PERSON includes
INSTRUCTOR and STUDENT. Because the PERSON class has a property called Address, a
STUDENT inherits the Address property. A STUDENT also has a property called Major that is
not shared by other members of the PERSON class.

5
Figure 1.2 object and class

All objects have attributes: for example, a car has a manufacturer, a model number, a color and a
price; a dog has a breed, an age, a color and a favorite toy. Objects also have behavior: a car can
move from one place to another and a dog can bark.

Figure 1.3 Real world objects

1.3.1 Object State and Behaviour

Real-world objects share two characteristics: They all have state/data and behavior/method or
function. Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging

6
tail). Bicycles also have state (current gear, current pedal cadence, current speed) and behavior
(changing gear, changing pedal cadence, applying brakes). State: Every object, at any given point
of time would have to have a set of attributes defining its state. Behavior: Every object based on
its state and optionally identity will have particular behavior.

1.3.2 Attributes: Object State and Properties

Properties represent the state of an object. Often, we want to refer to the description of these
properties rather than how they are represented in a particular programming language. In our
example, the properties of a car, such as color, manufacturer, and cost, are abstract descriptions are
represented as follows.

Figure 1.4 The attributes of car object

1.4 Messages
An object-oriented program is a growing and shrinking collection of objects that interact via messages.
You can send the same message to similar objects--the target decides how to implement or respond to
a message at run-time. Objects can send and receive messages. Over its lifetime, the object has a state
that varies.

A message is called a request or an event. The event contains the name of the object, the name of the
operation, and maybe a group of parameters. As a result of receiving an event (message) the object

7
runs a script (program) that may modify its state or send messages to other objects.

1.5 Class

What is a class?
A class is a group of similar objects. For example, Toyota belong to a class called CAR. Classes
are used to distinguish one type of object from another. In the context of object-oriented systems, a
class is a set of objects that share a common structure and a common behavior; a single object is
simply an instance of a class. A class is a specification of structure (instance variables), behavior
(methods), and inheritance for objects). Classes are an important mechanism for classifying objects.

The chief role of a class is to define the properties and procedures (the state and behavior) and
applicability of its instances. The class car, for example, defines the property color. Each
individual car (formally, 9th instance of the class car) will have a value for this property, such as
maroon, yellow, or white. In an object-oriented system, a method or behavior of an object is
defined by its class. Each object is an instance/variable of a class. There may be many different
classes.

Figure 1.5 objects of the class Employee

8
1.5.1 Class Hierarchy

An object-oriented system organizes classes into a subclass-super class hierarchy. Different

properties and behaviors are used as the basis for making distinctions between classes and sub-
classes. At the top of the class hierarchy are the most general classes and at the bottom are the
most specific are placed.

The family car in Figure 1.6 is a subclass of car. A subclass inherits all of the properties and
methods (procedures) defined in its super class. In this case, we can drive a family car just as we
can drive any car or, indeed, almost any motor vehicle. Sub-classes generally add new methods
and properties specific to that class. Sub-classes may refine or constrain the state and behavior
inherited from its super class. In this example, race cars only have one occupant, the driver. In this
manner, sub-classes modify the attribute (number of passengers) of its super class, Car.

Figure 1.6 Class hierarchy

9
1.6 Encapsulation and Information Hiding
1.6.1 Information hiding

Information hiding is the principle of concealing the internal data and procedures of an object and
providing an interface to each object in such a way as to reveal as little as possible about its inner
workings. As in conventional programming, some languages permit arbitrary access to objects and
allow methods to be defined outside of a class.

1.6 .2 Encapsulation

Encapsulation refers to an object hiding its attributes behind its operations (it seals the attributes
in a capsule, with operations on the edge). Hidden attributes are said to be private.

As an example of why encapsulation is a good idea, consider an object representing a circle. A

circle would be likely to have operations allowing us to discover its radius, diameter, area and
perimeter. What attributes would we need to store in order to support this behavior? Well, we
could store the radius and calculate the other attributes on demand. Or, we could store the diameter
and calculate the other attributes from that. In fact, we could store any one of the four attributes
and calculate the other three on demand.

1.7 Inheritance
Inheritance is the property of object-oriented systems that allows objects to be built from other
objects. Inheritance allows explicitly taking advantage of the commonality of objects when
constructing new classes. Inheritance is a relationship between classes where one class is the
parent class of another (derived) class. The parent class also is known as the base class or super
class.

Inheritance provides programming by extension as opposed to programming by reinvention. The

real advantage of using this technique is that we can build on what we already have and, more
important, reuse what we already have. Inheritance allows classes to share and reuse behaviors and
attributes. Where the behavior of a class instance is defined in that class's methods, a class also
inherits the behaviors and attributes of all of its super classes.

10
From a programming point of view, we want inheritance because:
 It supports richer, more powerful, modeling. This benefits both the development team and
other developers who might want to reuse code.
 It allows us to define information and behavior in one class and share the definitions in
related sub-classes. This means that we have less code to write.
 A subclass inherits all of the fields, messages, methods (and assertions) of its super-lass.

1.7.1 Dynamic Inheritance

Dynamic inheritance allows objects to change and evolve over time. Since base classes provide
properties and attributes for objects, changing base classes changes the properties and attributes of a
class. A previous example was a Windows object changing into an icon and then back again, which
involves changing a base class between a Windows class and an Icon class. More specifically,
dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes) at
run time.

1.7.2 Multiple Inheritance

Some object-oriented systems permit a class to inherit its state (attributes) and behaviors from
more than one super class. This kind of inheritance is referred to as multiple inheritance. For
example, a utility vehicle inherits attributes from both the Car and Truck classes.

Multiple inheritance can pose some difficulties. For example, several distinct parent classes can
declare a member within a multiple inheritance hierarchy. This then can become an issue of choice,
particularly when several super classes define the same method. It also is more difficult to
understand programs written in multiple inheritance systems.

1.8 Polymorphism
Poly means "many" and morph means "form." In the context of object-oriented systems, it means
objects that can take on or assume many different forms. In other words, polymorphism means that
the same operation may behave differently on different classes.

11
Polymorphism allows us to write generic, reusable code more easily, because we can specify
general instructions and delegate the implementation details to the objects involved. Since no
assumption is made about the class of an object that receives a message, fewer dependencies are
needed in the code and, therefore, maintenance is easier. For example, in a payroll system,
manager, office worker, and production worker objects all will respond to the compute payroll
message, but the actual operations performed are object specific.
1.9 Associations
Association is a relationship among object classes. It is also a weak form of connection: the objects
may be part of a group, or family, of objects but they’re not completely dependent on each other.
For example, consider a car, a driver, a passenger and another passenger. When the driver and the
two passengers are in the car, they’re associated: they all go in the same direction, they occupy the
same volume in space, and so on. But the association is loose: the driver can drop off one of the
passengers to go their separate way, so that the passenger is no longer associated with the other
objects (Valacich J. et al, 2012).

In addition, Association represents the relationships between objects and classes. For example, in the
statement "a pilot can fly planes" the italicized term is an association. Associations are bidirectional;
that means they can be traversed in both directions, perhaps with different connotations. The direction
implied by the name is the forward direction; the opposite direction is the inverse direction. For
example, can fly connects a pilot to certain airplanes. The inverse of can fly could be called is flown
by.

An important issue in association is cardinality, which specifies how many instances of one class
may relate to a single instance of an associated class. Cardinality constrains the number of related
objects and often is described as being "one" or "many," Generally, the multiplicity value is a
single interval, but it may be a set of disconnected intervals.

12
Figure 1.7 Association represents the relationship among objects, which is bidirectional.

1.10 Aggregation
Aggregation is a part-of relationship between a component object and an aggregate object. It is a
stronger form of an association relationship and is represented with a hollow diamond at the aggregate
end. For example, Figure 1.8 a and b shows a personal computer as an aggregate of CPU, hard disk,
monitor, keyboard, and other objects. Note that aggregation involves a set of distinct object instances,
one of which contains or is composed of the others. For example, a Personal Computer object is
related to (consists of) CPU objects, one of its parts. In contrast, generalization relates to object
classes: An object (e.g., Tola Abdi) is simultaneously an instance of its class (e.g., Graduate Student)
and its super-class (e.g., Student) (Valacich J. et al, 2012).

Figure 1.8 a Aggregation

In other way, aggregation means putting objects together to make a bigger object.
Manufactured items usually form aggregations: for example, a microwave is made up of a
cabinet, a door, an indicator panel, buttons, a motor, a glass plate, a magnetron, and so on.
13
Aggregations usually form a part–whole hierarchy. Aggregation implies close dependency, at
least of the whole to the part.

Figure 1.8 b Aggregation

1.11 Collaboration

Every object is connected to at least one other object. An isolated object wouldn’t be much use to
anyone. Once objects are connected, they can collaborate, to perform more complex tasks than they
could on their own. Objects collaborate by sending messages to each other (Docherty M., 2005).

1.12 Persistence
Objects have a lifetime. They are explicitly created and can exist for a period of time that,
traditionally, has been the duration of the process in which they were created. A file or a database
can provide support for objects having a longer lifeline longer than the duration of the process for
which they were created. From a language perspective, this characteristic is called object
persistence.

An object can persist beyond application session boundaries, during which the object is stored in a
file or a database, in some file or database form. The object can be retrieved in another application
session and will have the same state and relationship to other objects as at the time it was saved.

The lifetime of an object can be explicitly tenanted. After an object is deleted, its state is inaccessible
and its persistent storage is reclaimed. Its identity, however, is never reused, not even after the object
is deleted.

14
1.13 Cohesion
The extent to which a system or subsystem performs a single function. For instance, In the MP3
player example, supplying power is a single function (Valacich J. et al, 2012).

In other term, cohesion is “how closely the operations in a routine are related.” A simplification is
to say “we want this method to do just one thing” or “we want this module to deal with just one
thing.” We want our code to exhibit strong cohesion ( highly cohesive) methods: the method

performs one operation. Classes: the class achieves a fine-grain design or implementation goal.

Packages: the package achieves some medium-grain design goal subsystems: this subsystem

achieves a coarse-grain design goal. System: the system achieves all design goals and meets its

requirements.

1.14 Coupling
The extent to which subsystems depend on each other.Subsystems should be as independent as
possible. If one subsystem fails and other subsystems are highly dependent on it, the others will either
fail themselves or have problems functioning. Looking at Figure 1.9, we would say the components of
a portable MP3 player are tightly coupled. The best example is the control system, made up of the
printed circuit board and its chips. Every function the MP3 player can perform is enabled by the board
and the chips. A failure in one part of the circuit board would typically lead to replacing the entire
board rather than attempting to isolate the problem on the board and fix it. Even though repairing a
circuit board in an MP3 player is certainly possible, it is typically not cost effective; the cost of the
labor expended to diagnose and fix the problem may be worth more than the value of the circuit board
itself. In a home stereo system, the components are loosely coupled because the subsystems, such as
the speakers, the amplifier, the receiver, and the CD player, are all physically separate and function
independently. If the amplifier in a home stereo system fails, only the amplifier needs to be repaired
(Valacich J. et al, 2012).

15
Figure 1.9 An MP3 player is a system with power supply, storage and control subsystems

Coupling in other words is “the strength of a connection between two routines”. It is a

complement to cohesion. Weak cohesion implies strong coupling. Strong cohesion implies loose
coupling with strong or tight coupling, a single change in one method or data structure will cause
ripple effects, that is, additional changes in other parts of the system. We want systems with parts
that are highly cohesive and loosely coupled.

1.15 Interfaces
Interface is a point of contact where a system meets its environment or where subsystems meet each
other. In computing, an interface is a shared boundary across which two or more separate components
of a computer system exchange information. The exchange can be between software, computer
hardware, peripheral devices, humans, and combinations of these. In other words, interface is a
boundary across which two independent systems meet and act on or communicate with each other. In
computer technology, there are several types of interfaces like user interface - the keyboard, mouse,
menu of a computer system. The user interface allows the user to communicate with the operating
system. Software interface - the languages and codes that the applications use to communicate with

16
each other and with the hardware. Hardware interface - the wires, plugs and sockets that hardware
devices use to communicate with each other (https://www.webopedia.com/TERM/I/interface.html).
1.16 Components
A system (a group of interrelated procedures used for a business function, with an identifiable
boundary, working together for some purpose ) is made up of components. A component is either an
irreducible part or an aggregate of parts, also called a subsystem. The simple concept of a component
is very powerful. For example, just as with an automobile or a stereo system, with proper design, we
can repair or upgrade the system by changing individual components without having to make changes
throughout the entire system. The components are interrelated; that is, the function of one is
somehow tied to the functions of the others. For example, the work of one component, such as
producing a daily report of customer orders received, may not progress successfully until the work of
another component is finished, such as sorting customer orders by date of receipt (Valacich J. et al,
2012).

In programming and engineering disciplines, a component is an identifiable part of a larger program

or construction. Usually, a component provides a particular function or group of related functions. In
programming design, a system is divided into components that in turn are made up
of modules. Component test means testing all related modules that form a component as a group to
make sure they work together. In object-oriented programming and distributed object technology, a
component is a reusable program building block that can be combined with other components in the
same or other computers in a distributed network to form an application. Examples of a component
include: a single button in a graphical user interface, a small interest calculator, an interface to a
database manager. Components can be deployed on different servers in a network and communicate
with each other for needed services (https://whatis.techtarget.com/definition).
1.17 Patterns
In software development, a pattern (or design pattern) is a written document that describes a general
solution to a design problem that recurs repeatedly in many projects. Software designers adapt the
pattern solution to their specific project. Patterns use a formal approach to describing a design
problem, its proposed solution, and any other factors that might affect the problem or the solution. A
successful pattern should have established itself as leading to a good solution in three previous
projects or situations (https://searchsoftwarequality.techtarget.com).

17
In object-oriented programming, a pattern can contain the description of certain objects and
object classes to be used, along with their attributes and dependencies, and the general approach to
how to solve the problem. Often, programmers can use more than one pattern to address a specific
problem. A collection of patterns is called a pattern framework
(https://searchsoftwarequality.techtarget.com).

18
1.18 Review Questions
Try the below given questions by yourself
1. What is an object ? Discuss with examples.
2. What is a class? Discuss with examples.
3. What is meant by polymorphism when applied to object-oriented systems?
4. Describe the four primary phases of the Systems Development Life Cycle (SDLC)?
5. Describe the basic characteristics of object-oriented systems: objects, attributes, methods, messages,
encapsulation, information hiding, dynamic binding, and inheritance?

19
 Chapter Two
2. Object Orientation: The new software paradigm
Unit Objectives

At the end of this chapter the students will be able to:

 Understand the potential benefits of object orientation

 Understand the potential drawbacks of object orientation
 Discuss the object orientation software process
 Differentiate the different unified approach

Leading questions
 What are the benefits of object orientation?
 What is the new software paradigm?
 What are potential draw backs of object orientation paradigm?
 What is object orientation software process?

The object-oriented paradigm took its shape from the initial concept of a new programming approach,
while the interest in design and analysis methods came much later. The first object–oriented language
was Simula (Simulation of real systems). The object-oriented paradigm took its shape from the initial
concept of a new programming approach, while the interest in design and analysis methods came
much later.

2.1 Object-Oriented Analysis

Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements
and developing software specifications in terms of a software system’s object model, which
comprises of interacting objects.

Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines
requirements from the perspective of the classes and objects found in the vocabulary of the problem
domain”.

20
The primary tasks in object-oriented analysis (OOA) are:-

 Identifying objects

 Organizing the objects by creating object model diagram

 Defining the internals of the objects, or object attributes

 Defining the behavior of the objects, i.e., object actions

 Describing how the objects interact

The common models used in OOA are use cases and object models

2.2 Object-Oriented Design

Object–Oriented Design (OOD) involves implementation of the conceptual model produced during
object-oriented analysis. In OOD, concepts in the analysis model, which are technology−independent,
are mapped onto implementing classes, constraints are identified and interfaces are designed,
resulting in a model for the solution domain, i.e., a detailed description of how the system is to be
built on concrete technologies.

The implementation details generally include:-

 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,

 Implementation of control, and

 Implementation of associations.

Grady Booch has defined object-oriented design as “a method of design encompassing the process of
object-oriented decomposition and a notation for depicting both logical and physical as well as
static and dynamic models of the system under design”

(https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_paradigm.ht
m)

The main difference between object-oriented analysis and other forms of analysis is that in object-
oriented approach, requirements are organized around objects, which integrate both data and
functions. They are modelled after real-world objects that the system interacts with. In traditional
analysis methodologies, the two aspects - functions and data - are considered separately.

21
 2.3 The potential benefits of object orientation
Today, an exciting enhancement to systems analysis and design is the application of the object-
oriented approach. The object-oriented approach views a system as a collection of self-contained
objects, including both data and processes. As you know, traditional systems analysis and design
methodologies are either data-centric or process-centric. Until the mid-1980s, developers had to keep
the data and processes separate in order to build systems that could run on the mainframe computers
of that era. Due to the increase in processor power and the decrease in processor cost, object-oriented
approaches became feasible. Consequently, developers focused on building systems more efficiently
by enabling the analyst to work with a system’s data and processes simultaneously as objects. These
objects can be built as individual pieces and then put together to form a system. The beauty of objects
is that they can be reused over and over in many different systems and changed without affecting
other system components.

Object-oriented systems focus on capturing the structure and behavior of information systems in little
modules that encompass both data and processes. These little modules are known as objects (Dennis
A. et al, 2012).

An object oriented system is made of objects. How these objects interact with one another determines
how the program behaves. They work collaboratively by sending messages to each other. This is not
like calling a function because when a target object receives a message, it decides what function to
carry out to service that message. You could have one message implemented by many different
functions. The message selected depends on the target object. These are implemented in Object
Oriented Programming (OOP).
(https://www.brighthub.com/internet/web-development/articles/74166.aspx).

22
2.3.1 The major advantages of OOP are:

 Simplicity:Software objects model real world objects, so the complexity is reduced and the
program structure is very clear.
 Modularity: Each object forms a separate entity whose internal workings are decoupled from
other parts of the system.
 Modifiability:It is easy to make minor changes in the data representation or the procedures in an
OO program. Changes inside a class do not affect any other part of a program, since the only
public interface that the external world has to a class is through the use of methods.
 Extensibility:Adding new features or responding to changing operating environments can be
solved by introducing a few new objects and modifying some existing ones.
 Maintainability:Objects can be maintained separately, making locating and fixing problems
easier.
 Reusability:Objects can be reused in different programs.
(https://www.quora.com/What-are-the-benefits-of-object-oriented-programming).
 It allows for parallel development.
If you’re working with programming teams, then each can work independently of one another
once the modular classes have been worked out. That allows for a relative level of parallel
development that wouldn’t be available otherwise.
 The modular classes are often reusable.
Once the modular classes have been created, they can often be used again in other applications or
projects. At times, little-to-no modification is necessary for the next project as well. That gives a
team more flexibility once they get beyond the initial start-up phase.
 The coding is easier to maintain.
With OOP, because your coding base has been centralized, it is easier to create a maintainable
procedure code. That makes it easier to keep your data accessible when it becomes necessary to
perform an upgrade. This process also improves the security of the programming since high
levels of validation are often required (https://greengarageblog.org/6-pros-and-cons-of-object-
oriented-programming).

23
2.4 The potential drawbacks of object orientation
The main disadvantages of OOP are: Size: Object Oriented programs are much larger than other
programs. In the early days of computing, space on hard drives, floppy drives and in memory were at
a premium. Today we do not have these restrictions.
 Object-oriented programming
It tends to use more CPU than alternative options. That can make it be an inefficient choice when
there are technical limitations involved due to the size that it can end up being. Because of the
duplication involved, the first-time coding can be more extensive than other options as well.
 It can be too scalable
If OOP is left to run out of control, then it can create a massive amount of bloated, unnecessary code.
When that occurs, the overhead rises and that makes it difficult to keep costs down.
 It can cause duplication.
OOP projects tend to be easier to design than implement. That is because of the modular classes are
so flexible in their application. You may be able to get new projects up and running at a greater speed,
but that comes at the cost of having projects sometimes feel like they’ve been cloned
(https://greengarageblog.org/6-pros-and-cons-of-object-oriented-programming).

2.5 Object-oriented systems development: Software process

Set of project phases, stages, methods, techniques, and practices that people employ to develop
and maintain software and its associated artifacts. There are a number of phases common to every
development, regardless of methodology, starting with requirements capture and ending with
maintenance. With the traditional approach, you’re expected to move forward gracefully from one
phase to the other. With the modern approach, on the other hand, you’re allowed to perform each
phase more than once and in any order.

The process can be divided into small, interacting phases-sub processes. The sub processes must
be defined in such a way that they are clearly spelled out, to allow each activity to be performed as
independently of other sub processes as possible. Each sub process must have the following
 A description in terms of how it works
 Specification of the input required for the process
 Specification of the output to be produced

24
The software development process also can be divided into smaller, interacting sub processes.
Generally, the software development process can be viewed as a series of transformations, where
the output of one transformation becomes the input of the subsequent transformation .
2.5.1. Requirements
Requirements capture is about discovering what we’re going to achieve with our new piece of
software and has two aspects. The first phase involves understanding what need to be design and
what is its function, purpose etc. It is about discovering what we’re going to achieve with our new
piece of software. System requirements modeling (or functional specification) means deciding
what capabilities the new software will have and writing down those capabilities. We need to be
clear about what our software will do and what it won’t do, so that the development doesn’t veer
off into irrelevant areas and we know both when we’ve finished and whether we’ve been
successful.
2.5.2. Analysis

Analysis means understanding what we’re dealing with. Before we can design a solution, we need to
be clear about the relevant entities, their properties and their inter-relationships. We also need to be
able to verify our understanding.

2.5.3. System Design

The requirement specifications from first phase are studied in this phase and system design is
prepared. System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture.

2.5.4 Implementation
At this stage the physical specification is turned into a working system,. This phase specifically
involves Coding.

Testing- When our software is complete, it must be tested against the system requirements to see if it
fits the original goals.

Deployment- In the deployment phase, we’re concerned with getting the hardware and software to
the end users, along with manuals and training materials

25
Maintenance- This step occurs after installation, and involves making modifications to the system or
an individual component to alter attributes or improve performance.

26
2.6 Review Questions
Try the below given questions by yourself
1. List and discuss the potential benefits of object orientation?
2. List and discuss the potential disadvantages of object orientation?
3. Discuss about Object-oriented systems development Software process?
4. Discuss the importance of object orientation now a days?
5. Discuss object oriented analysis and design in new software development paradigm?

27
 Chapter Three
3. Gathering User Requirements
Unit Objectives

At the end of this chapter the students will be able to:

 Understand the purpose of the requirements gathering
 Classify requirements correctly as business, user, functional, or nonfunctional
requirements.
 Lists the requirement gathering determination techniques apply
 Define the role of each requirement elicitation technique plays in determining
requirements
Leading questions
 What is a requirement?
 What is requirement gathering?
 What are requirement gathering techniques?
 What are use cases?

This chapter begins by describing the analysis phase and its primary deliverable, the system
proposal. The concept of a requirement is explained and several categories of requirements are
defined. The purpose and structure of the requirements definition statement is outlined. Techniques
to elicit requirements are discussed, including interviews, JAD sessions, questionnaires, document
analysis, and observation. Finally, several requirements analysis strategies are described to help the
analyst discover requirements.

During the analysis phase, the analyst determines the functional requirements for the new system.
The analysis phase is so named because the term analysis refers to breaking a whole into its parts
with the intent of understanding the parts’ nature, function, and interrelationships. In the context of
the SDLC, the outputs of the planning phase (the system request, feasibility study, and project
plan), outline the business goals for the new system, define the project’s scope, assess project
feasibility, and provide the initial work plan. These planning phase deliverables are the key inputs
into the analysis phase. In the analysis phase, the systems analyst works extensively with the

28
business users of the new system to understand their needs from the new system. The basic process
of analysis involves three steps:

 Understand the existing situation (the as-is system)

 Identify improvements

 Define requirements for the new system (the to-be system)

3.1. Requirements Elicitation

What is Requirements Elicitation?

Requirements elicitation which is also known as requirements gathering or capturing is the process of
generating a list of requirements such as functional, system, technical, etc. from the various
stakeholders like customers, users, vendors, IT staff, etc. that will be used as the basis for the
formal requirements definition.

The process is not as straightforward as just asking the stakeholders what they want the system to do,
as in many cases, they are not aware of all the possibilities that exist, and may be limited by their
immersion in the current state. For example, asking people in the 19th Century for their requirements
for a self-propelled vehicle, would have just resulted in the specification for a faster horse-drawn
carriage rather than an automobile.

 A requirement is a statement about an intended product that specifies what it should

do or how it should perform.
 Goal: To make as specific, unambiguous, and clear as possible.

3.2 The Requirements Definition Statement

The requirements definition statement is usually just called the requirements definition. It is a
straightforward text report that simply lists the functional and nonfunctional requirements in an
outline format. Table shows a sample requirements definition for Holiday Travel Vehicles, a
fictitious recreational vehicle dealership.

29
 Table 3.1 Functional Requirements
Functional Requirements
1. New Vehicle Management
1.1 The system will allow managers to view the current new vehicle inventory.
1.2 The system will allow the new vehicle manager to place orders for new vehicles.
1.3 The system will record the addition of new vehicles to inventory when they are received
from the manufacturers.
2. Vehicle Sales Management
2.1 The system will enable salespersons to create a customer offer.
2.2 The system will allow salespeople to know whether an offer is pending on a specific
vehicle.
2.3 The system will enable managers to record approval of a customer offer.
2.4 The system will prepare a sales contract.
2.5 The system will prepare a shop work order based on customer requested dealer options.
2.6 The system will record a customer deposit.
2.7 The system will record a customer payment.
2.8 The system will create a record of the customer's vehicle purchase.
3. Used Vehicle Management
3.1 The system will record information on a customer trade-in vehicle ... etc

Table 3.2 Nonfunctional Requirements

Nonfunctional Requirements
1. Operational
1.1 The system should run on tablet PCs to be used by salespeople.
1.2 The system should interface with the shop management system.
1.3 The system should connect to printers carelessly.
2. Performance
2.1 The system should support a sales staff of 15 salespeople.
2.2 The system should be updated with pending offers on vehicles every 15 minutes.
3. Security
3.1 No salesperson can access any other salesperson's customer contacts.

30
3.2 Only the owner and sales manager may approve customer offers.
3.3 Use of each tablet PC should be restricted to the salesperson to whom it is assigned.
4. Cultural and Political
4.1 Company policy says that all computer equipment is purchased from Dell.
4.2 Customer personal information is protected in compliance with the Data Protection Act.
4.3 The system will conform to the state's "lemon law.

3.4 Requirements Elicitation Techniques

The best analysts will thoroughly search for requirements using a variety of techniques and make
sure that the current business processes and the needs for the new system are well understood
before moving into design (Dennis A. et al, 2012).

First, the analyst should recognize that important side effects of the requirements definition
process include building political support for the project and establishing trust and rapport between
the project team and the ultimate users of the system. Every contact and interaction between the
analyst and a potential business user or manager is an opportunity to generate interest, enthusiasm,
and commitment to the project. Therefore, the analyst should be prepared to make good use of
these opportunities as they arise during the requirements definition process (Dennis A. et al, 2012).

Second, the analyst should carefully determine who is included in the requirements definition
process. The choice to include (or exclude) someone is significant; involving someone in the
process implies that the analyst views that person as an important resource and values his or her
opinions. You must include all of the key stakeholders (the people who can affect the system or
who will be affected by the system). This might include managers, employees, staff members, and
even some customers and suppliers (Dennis A. et al, 2012).

In this section, we focus on the five most commonly used requirements elicitation techniques.
These are interviews, JAD sessions, questionnaires, document analysis, and observation.
3.4.1 Interviews
The interview is the most commonly used requirements elicitation technique. After all, it is
natural-usually, if you need to know something, you ask someone. In general, interviews are
conducted one on one (one interviewer and one interviewee), but sometimes, due to time
31
constraints, several people are interviewed at the same time. There are five basic steps to the
interview process: selecting interviewees, designing interview questions, preparing for the
interview, conducting the interview, and post interview follow-up.

Selecting Interviewees. An interview schedule should be created, listing who will be interviewed,
the purpose of the interview, and where and when it will take place. The schedule can be an
informal list that is used to help set up meeting times or a formal list that is incorporated into the
work plan. The people who appear on the interview schedule are selected on the basis of the
analyst’s information needs.

Designing Interview Questions. There are three types of interview questions: closed-ended
questions, open-ended questions, and probing questions.

Closed ended questions require a specific answer. You can think of them as being similar to
multiple choice or arithmetic questions on an exam. Closed-ended questions are used when the
analyst is looking for specific, precise information (e.g., how many credit card requests are
received per day). In general, precise questions are best. For example, rather than asking “Do you
handle a lot of requests?” it is better to ask “How many requests do you process per day? ”

Open-ended questions are those that leave room for elaboration on the part of the interviewee.
They are similar in many ways to essay questions that you might find on an exam. Open-ended
questions are designed to gather rich information and give the interviewee more control over the
information that is revealed during the interview.

The third type of question is the probing question. Probing questions follow up on what has just
been discussed in order for the interviewer to learn more, and they often are used when the
interviewer is unclear about an interviewee’s answer. They encourage the interviewee to expand
on or to confirm information from a previous response, and they are a signal that the interviewer is
listening and interested in the topic under discussion.

32
 Table 3.3 Three Types of Questions
Types of questions Examples

 How many telephone orders are received per day?

Closed-Ended Questions
 How do customers place orders?
 What information is missing from the monthly sales report?
 What do you think about the way invoices are currently
Open-Ended Questions processed?
 What are some of the problems you face on a daily basis?
 What are some of the improvements you would like to see in
the way invoices are processed?
Probing Questions  Why?
 Can you give me an example?
 Can you explain that in a bit more detail?

3.4.2 Joint Application Development (JAD)

Joint application development (or JAD as it is more commonly known) is an information gathering
technique that allows the project team, users, and management to work together to identify
requirements for the system.It is a structured process in which 10 to 20 users meet under the
direction of a facilitator skilled in JAD techniques. The facilitator is a person who sets the meeting
agenda and guides the discussion, but does not join in the discussion as a participant. He or she
does not provide ideas or opinions on the topics under discussion and remains neutral during the
session. The facilitator must be an expert in both group process techniques and systems analysis
and design techniques. One or two scribes assist the facilitator by recording notes, making copies,
and so on. Often, the scribes will use computers and CASE tools to record information as the JAD
session proceeds.
3.4.3 Questionnaires
A questionnaire is a set of written questions for obtaining information from individuals.
Questionnaires often are used when there is a large number of people from whom information and
opinions are needed. In our experience, questionnaires are commonly used for systems intended
for use outside of the organization (e.g., by customers or vendors) or for systems with business
users spread across many geographic locations. Most people automatically think of paper when
they think of questionnaires, but today more questionnaires are being distributed in electronic form,

33
either via e-mail or on the Web. Electronic distribution can save a significant amount of money,
compared with distributing paper questionnaires.

Designing the Questionnaire. Developing good questions is critical for questionnaires because
the information on a questionnaire cannot be immediately clarified for a confused respondent.
Questions on questionnaires must be very clearly written and must leave little room for
misunderstanding; therefore, closed-ended questions tend to be most commonly used. Questions
must enable the analyst to clearly separate facts from opinions. Opinion questions often ask the
respondent the extent to which they agree or disagree (e.g., “Are network problems common?”),
while factual questions seek more precise values (e.g., “How often does a network problem occur:
once an hour, once a day, or once a week?”).

Administering the Questionnaire. The key issue in administering the questionnaire is getting
participants to complete the questionnaire and send it back. Dozens of marketing research books
have been written about ways to improve response rates. Commonly used techniques include
clearly explaining why the questionnaire is being conducted and why the respondent has been
selected; stating a date by which the questionnaire is to be returned; offering an inducement to
complete the questionnaire (e.g., a free pen); and offering to supply a summary of the
questionnaire responses. Systems analysts have additional techniques to improve responses rates
inside the organization, such as personally handing out the questionnaire and personally contacting
those who have not returned them after a week or two, as well as requesting the respondents’
supervisors to administer the questionnaires in a group meeting.

Questionnaire Follow-up It is helpful to process the returned questionnaires and develop a

questionnaire report soon after the questionnaire deadline. This ensures that the analysis process
proceeds in a timely fashion and that respondents who requested copies of the results receive them
promptly.

3.4.4 Document Analysis

Project teams often use document analysis to understand the as-is system. Under ideal
circumstances, the project team that developed the existing system will have produced

34
 documentation, which was then updated by all subsequent projects. In this case, the project
team can start by reviewing the documentation and examining the system itself.
3.4.5 Observation
Observation, the act of watching processes being performed, is a powerful tool to gain insight
into the as-is system. Observation enables the analyst to see the reality of a situation, rather than
listening to others describe it in interviews or JAD sessions.
3.5 Class Responsibility Collaboration (CRC) Cards
CRC (Class–Responsibility–Collaboration) cards are used to document the responsibilities and
collaborations of a class. In some object-oriented systems-development methodologies, CRC cards
are seen to be an alternative competitor to the Unified Process employment of use cases and class
diagrams. However, we see them as a useful, low-tech approach that can compliment a typical
high-tech Unified Process approach that uses CASE tools. We use an extended of the CRC card to
capture all relevant information associated with a class (Dennis A., 2015 ).
3.5.1 Responsibilities and Collaborations
Responsibilities of a class can be broken into two separate types: knowing and doing. Knowing
responsibilities are those things that an instance of a class must be capable of knowing. An
instance of a class typically knows the values of its attributes and its relationships. Doing
responsibilities are those things that an instance of a class must be capable of doing. In this case,
an instance of a class can execute its operations or it can request a second instance, which it knows
about, to execute one of its operations on behalf of the first instance.

The structural model describes the objects necessary to support the business processes modeled by
the use cases. Most use cases involve a set of several classes, not just one class. These classes form
collaborations. Collaborations allow the analyst to think in terms of clients, servers, and
contracts.10 A client object is an instance of a class that sends a request to an instance of another
class for an operation to be executed. A server object is the instance that receives the request from
the client object. A contract formalizes the interactions between the client and server objects
An analyst can use the idea of class responsibilities and client–server–contract collaborations to
help identify the classes, along with the attributes, operations, and relationships, involved with a
use case. One of the easiest ways to use CRC cards in developing a structural model is through
anthropomorphism—pretending that the classes have human characteristics. Members of the

35
development team can either ask questions of themselves or be asked questions by other members
of the team. Typically the questions asked are of the form:
Who or what are you?
What do you know?
What can you do

Te answers to the questions are then used to add detail to the evolving CRC cards. For example, in
the appointment problem, a member of the team can pretend that he or she is an appointment. In
this case, the appointment would answer that he or she knows about the doctor and patient who
participate in the appointment and they would know the date and time of the appointment.
Furthermore, an appointment would have to know how to create itself, delete itself, and to possibly
change different aspects of itself (Dennis A., 2015 ).

3.5.2 Elements of a CRC Card

Te set of CRC cards contains all the information necessary to build a logical structural model of
the problem under investigation. Figure 5-6 shows a sample CRC card. Each CRC card captures
and describes the essential elements of a class. Te front of the card contains the class’s name, ID,
type, description, associated use cases, responsibilities, and collaborators. Te name of a class
should be a noun (but not a proper noun, such as the name of a specific person or thing). Just like
the use cases, in later stages of development, it is important to be able to trace back design
decisions to specific requirements. In conjunction with the list of associated use cases, the ID
number for each class can be used to accomplish this. T e description is simply a brief statement
that can be used as a textual definition for the class. T e responsibilities of the class tend to be the
operations that the class must contain (i.e., the doing responsibilities).

Te back of a CRC card contains the attributes and relationships of the class. Te attributes of the
class represent the knowing responsibilities that each instance of the class has to meet. Typically,
the data type of each attribute is listed with the name of the attribute (e.g., the amount attribute is
double and the insurance carrier is text). Three types of relationships typically are captured at this
point: generalization, aggregation, and other associations (Dennis A., 2015 ).

36
Figure 3.1 Sample CRC Card

3.6 Business Process Identification With Use Cases and Use-Case Diagrams
In this section you will learn how to begin modeling business processes with use cases and the
use-case diagram.
An analyst can employ use cases and the use-case diagram to better understand the functionality
of the system at a very high level. Typically, because a use-case diagram provides a simple,
straightforward way of communicating to the users exactly what the system will do, a use-case
diagram is drawn when gathering and defining requirements for the system. In this manner, the
use-case diagram can encourage the users to provide additional high-level requirements. A use-
case diagram illustrates in a very simple way the main functions of the system and the different
kinds of users that will interact with it

37
 3.6.1 Elements of Use-Case Diagrams
Te elements of a use-case diagram include actors, use cases, subject boundaries, and a set of
relationships among actors, actors and use cases, and use cases. These relationships consist of
association, include, extend, and generalization relationships

Actors. The stick figures on the diagram represent actors (see Figure 4-1). An actor is not a specific
user but instead is a role that a user can play while interacting with the system. An actor can also
represent another system in which the current system interacts. In this case, the actor optionally can be
represented by a rectangle containing <<actor>> and the name of the system. Basically, actors
represent the principal elements in the environment in which the system operates. Actors can provide
input to the system, receive output from the system, or both. The diagram in Figure 4-2 shows that
three actors will interact with the appointment system (a patient, a doctor, and management).

3.7 Essential User Interface Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input for
requirement gathering

User interface is the front-end application view to which user interacts in order to use the software.
User can manipulate and control the software as well as hardware by means of user interface. Today,
user interface is found at almost every place where digital technology exists, right from computers,
mobile phones, cars, music players, airplanes, ships etc.

User interface is part of software and is designed in such a way that it is expected to provide the user
insight of the software. UI provides fundamental platform for human-computer interaction.

UI can be graphical, text-based, audio-video based, depending upon the underlying hardware and
software combination. UI can be hardware or software or a combination of both
The software becomes more popular if its user interface is:

38
  Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent in all interfacing screening
UI is broadly divided into two categories:
 Command line interface (CLI)
 Graphical user interface (GUI)
User Interface (UI) is an important part of any software or hardware or hybrid system. A software is
widely accepted if it is :-
 Easy to operate
 Quick in response
 Effectively handling operational errors
 Providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for
users to perceive the system. A well performing software system must also be equipped with
attractive, clear, consistent, and responsive user interface. Otherwise the functionalities of
software system can not be used in convenient way. A system is said to be good if it provides
means to use it efficiently (www.tutorialspoint.com).
.
User interface requirements are briefly mentioned below:

 Content presentation
 Easy navigation
 Simple interface
 Responsive
 Consistent UI elements
 Feedback mechanism
 Default settings
 Purpose full layout
 Strategical use of color and texture

39
  Provide help information
 User centric Approach
 Group based view settings.

Prototyping is another form a contemporary requirement gathering method. Prototyping is

iterative process that heavily involves the users to complete. The user provides the requirements,
in which the analyst can plug in directly and show the user the outcome. Prototyping is dependent
on user interaction and cannot be utilized as its own method of gathering requirements. The
analyst must interview or perform some other form of requirement gathering to perform before
they begin prototyping. However, prototyping is very effective in specifying requirements,
because of how heavily involved the user is. The user will still be sitting side by side with the
analyst, providing them requirements as the analysts enters them into a working system. This will
allow the user to instantly see the outcome of their requirements. At this point the user may change
some of their requirements. They may see that what they provided was not what they had in mind.
A form may appear cluttered with information; at this point the user can go back and adjust their
information. This may also be the case in when the user forgets important information; they may
not realize it until they actually see a working version of the system. The user and analyst will
continue to go through different iterations, until all specifications are complete. The last prototype
will be used as a model to build the actual system. Some of the disadvantages of prototyping is the
user will pay too much attention to details on the screens, rather than what the prototype is meant
to communicate. Executives can grow impatient as they see a complete prototype, but will not
understand why the finished system takes so long to complete.

(https://www.umsl.edu/~sauterv/analysis/F2015/Requirement%20Gathering%20Methods.html.htm)

40
3.8 Review Questions
Try the below given questions by yourself
1. Create a requirements definition.
2. Differentiate between a functional and a nonfunctional requirement.
3. Discuss how to use interviews to gather requirements
4. Discuss how to use joint application development to gather requirements.
5. Discuss how to use questionnaires to gather requirements

41
 Chapter Four
4. Ensuring Your Requirements are correct: Requirement validation
Techniques

Unit Objectives

At the end of this chapter the students will be able to:

 Understand the purpose of correcting the requirement
 Understand the difference between verification and validation
 Understand the purpose of testing early and often
 Identify different Characteristics of use case testing
Leading questions
 What is the purpose of correcting requirement?
 What are the differences between requirement verification and validation ?
 What is Use Case Testing?
 What is the purpose of Use Case Scenario Testing

4.1 Difference between software Verification and Validation

Verification is the process of evaluating products of a development phase to find out whether they
meet the specified requirements. Validation is the process of evaluating software at the end of the
development process to determine whether software meets the customer expectations and
requirements.
Table 4.1 Difference between verification and validation
Verification Validation
Are we building the system right? Are we building the right system?
Verification is the process of evaluating products of Validation is the process of evaluating
a development phase to find out whether they meet software at the end of the development
the specified requirements. process to determine whether software meets
the customer expectations and requirements.
The objective of Verification is to make sure that the The objective of Validation is to make sure

42
 product being develop is as per the requirements and that the product actually meet up the user’s
design specifications. requirements, and check whether the
specifications were correct in the first place.
Following activities are involved in Verification: Following activities are involved
Reviews, Meetings and Inspections. in Validation: Testing like black box testing,
white box testing, gray box testing etc.
Verification is carried out by QA team to check Validation is carried out by testing team.
whether implementation software is as per
specification document or not.
Execution of code is not comes under Verification. Execution of code is comes under Validation.
Verification process explains whether the outputs are Validation process describes whether the
according to inputs or not. software is accepted by the user or not.
Verification is carried out before the Validation. Validation activity is carried out just after
the Verification.
Following items are evaluated during Verification: Following item is evaluated
Plans, Requirement Specifications, Design during Validation: Actual product or
Specifications, Code, Test Cases etc, Software under test.
Cost of errors caught in Verification is less than Cost of errors caught in Validation is more
errors found in Validation. than errors found in Verification.
It is basically manually checking the of documents It is basically checking of developed program
and files like requirement specifications etc. based on the requirement specifications
documents & files.

https://www.softwaretestingclass.com/difference-between-verification-and-validation

4.2 Requirements Validation

It’s a process of ensuring the specified requirements meet the customer needs. It’s concerned with
finding problems with the requirements. These problems can lead to extensive rework costs when
these they are discovered in the later stages, or after the system is in service. The cost of fixing a
requirements problem by making a system change is usually much greater than repairing design or
code errors. Because a change to the requirements usually means the design and implementation

43
must also be changed, and re-tested. During the requirements validation process, different types of
checks should be carried out on the requirements.
These checks include:
1. Validity checks: The functions proposed by stakeholders should be aligned with what the
system needs to perform. You may find later that there are additional or different functions
are required instead.
2. Consistency checks: Requirements in the document shouldn’t conflict or different
description of the same function.
3. Completeness checks: The document should include all the requirements and constrains.
4. Realism checks: Ensure the requirements can actually be implemented using the
knowledge of existing technology, the budget, schedule, etc.
5. Verifiability: Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system meets the specified
requirements.
There are some techniques you can use to validate the requirements, and you may use one or more
of them together, depending on your needs.
4.3 Requirements Reviews
A team of system customer; those who interact with the customer to gather requirements, and
system developers start reading the requirements in the document, and investigate in a great detail
to check for errors, inconsistency, conflicts, and any ambiguity. Then they may negotiate with the
customer on how to solve the problems and errors found.

4.4 Requirement Validation

It clarifies/certifies that requirements document is acceptable description of the system to be
implemented. In other words, requirement validation is the process of making sure that the
requirements say the right things. Someone, often the customers or users, need to work through all
the requirements and make sure that they: Describe things the application should do and Describe
everything the application should do (Stephens R., 2015).

44
A key concern during requirements validation is consistency. Use the system model to ensure that
requirements have been consistently stated. The work products produced as a consequence of
requirements engineering (a system specification and related information) are assessed for quality
during a validation step. Requirements validation examines the specification to ensure that all
system requirements have been stated unambiguously; that inconsistencies, omissions, and errors
have been detected and corrected; and that the work products conform to the standards established
for the process, the project, and the product.

The primary requirements validation mechanism is the formal technical review. The review team
includes system engineers, customers, users, and other stakeholders who examine the system
specification5 looking for errors in content or interpretation, areas where clarification may be
required, missing information, inconsistencies (a major problem when large products or systems
are engineered), conflicting requirements, or unrealistic (unachievable) requirements. Although the
requirements validation review can be conducted in any manner that results in the discovery of
requirements errors, it is useful to examine each requirement against a set of checklist questions.
The following questions represent a small subset of those that might be asked:

 Are requirements stated clearly? Can they be misinterpreted?

 Is the source (e.g., a person, a regulation, a document) of the requirement identified?
Has the final statement of the requirement been examined by or against the original
source?
 Is the requirement bounded in quantitative terms?
 What other requirements relate to this requirement? Are they clearly noted via a
cross-reference matrix or other mechanism?
 Does the requirement violate any domain constraints?
 Is the requirement testable? If so, can we specify tests (sometimes called validation
criteria) to exercise the requirement?
 Is the requirement traceable to any system model that has been created?
 Is the requirement traceable to overall system/product objectives?
 Is the system specification structured in a way that leads to easy understanding, easy
reference, and easy translation into more technical work products?
 Has an index for the specification been created?
45
  Have requirements associated with system performance, behavior, and operational
characteristics been clearly stated? What requirements appear to be implicit?
4.5 Testing Early and Often
Testing is one of the most valuable steps in the entire design processes. Testing as most of the
students are used:
• It is used to verify how you will have achieved your project goals.
• Is the only way to identify problem early on before:-
• Significant time
• Significant resources and
• Significant energy have been invested in continuing work

4.6 Use Case Scenario Testing

Use Case Testing is defined as a software testing technique, that helps identify test cases that cover
the entire system, on a transaction by transaction basis from start to the finishing point. It is also a
functional black box testing technique that helps testers to identify test scenarios that exercise the
whole system on each transaction basis from start to finish

(https://www.guru99.com/use-case-testing.html).

Characteristics of use case testing

 Use Cases capture the interactions between 'actors' and the 'system'.

 'Actors' represents user and their interactions that each user takes part into.

 Test cases based on use cases and are referred as scenarios.

 Capability to identify gaps in the system which would not be found by testing individual
components in isolation.

 Very effective in defining the scope of acceptance tests.

46
Example:
The Below example clearly shows the interaction between users and possible actions.

Fig 4.1 The interaction between users and actions

Use-case scenario testing (Ambler, 1995; Ambler, 1998a; Ambler, 1998b) is a task process pattern,
in which users are actively involved with ensuring that user requirements are accurate. The basic
idea is that a group of business domain experts (BDEs), with the aid of a facilitator, step through a
series of defined use cases to verify that CRC model accurately reflects their requirements.

There are six steps to acting out scenarios: 


• Call out a new scenario. Both the description of the scenario and the action(s) to be taken
are called out by the facilitator. Once this is complete, the group must decide if this
scenario is reasonable (remember, the system can’t handle some scenarios) and if it is
which card is initially responsible for handling the scenario. The facilitator starts out with
the ball, and throws it to the person holding that card. When the scenario is completely

acted out the ball will be thrown back to the facilitator. 


• Determine which card should handle the responsibility. When a scenario has been
described, or when the need for collaboration has been identified, the group should decide

47
 what CRC card should handle the responsibility. Very often there will already be a card
that has the responsibility identified. If this isn’t the case, update the cards. Once the update
is complete (if need be), whoever has the ball should throw it to the person with the card

that has the responsibility. 


• Update the cards whenever necessary. If a card needs to be updated, one of two
situations has arisen: The responsibility needs to be added to an existing card, or a new card
needs to be created with that responsibility. If a responsibility needs to be added to an
existing card, then ask yourself which card should logically have it, and then have the BDE
with that card update it. If a new card needs to be created, the facilitator should hand a
blank CRC card to one of the BDEs and ask them to fill it out. At the same time, you may
also find that you need to update your prototype drawings as well (if an interface or report

class changes, then the prototype may need to change as well). 


• Describe the processing logic. When the ball is thrown to someone, they should describe
the business logic for the responsibility step-by-step. Think of it like this: The BDEs are
effectively describing pseudo-code (high level program code) for the responsibility. This is
often the most difficult part of use-case scenario testing, as some of your BDEs might not
be used to documenting processes step-by-step. If this is the case with some of your BDEs,
then the facilitator needs to help them through the logic. You’ll find that after running
through the first few scenarios the BDEs will quickly get the hang of describing processing
logic. As the BDE describes the processing logic, the scribe should be writing it down
(remember, the job of the scribe is to record the business logic/rules for the system, which

is exactly what the BDE is currently describing!) 


• Collaborate if necessary. As the BDE describes the business logic of the responsibility,
they will often describe a step where they need to collaborate with another card to complete.
That’s great -- That’s what use-case scenario testing is all about! If this is the case, go back
to Step 2.
• Pass the ball back when done. Eventually the BDE will finish describing the
responsibility. When this happens, they should throw the ball back to whoever it was that
originally threw it to them. This will be another BDE (remember, every time you need to
collaborate you throw the ball to the person holding the card that you need to collaborate

48
 with) or to the facilitator (remember, the facilitator starts with the ball and throws it to the

person holding the card that initially handles the scenario). 


Figure 4.2 The Use-Case Scenario Testing process pattern

49
4.7 Review Questions
Try the below given questions by yourself
1. Why is input validation important?
2. Describe five types of input validation methods
3. Explain the difference between verification and validation
4. What is the use of Requirement verification? Discuss it.
5. What is the use of Requirement Validation? Discuss it.

50
 Chapter Five
Determining What to Build: Object Oriented Analysis
Unit Objectives

At the end of this chapter, the students will be able to:

 Define use cases

 Understand sequence diagrams

 Know conceptual modelling in terms of class diagram

 Apply analysis patterns in object oriented analysis and

 Know object oriented analysis

Leading Questions:

 What is object oriented analysis?

 What is use case?

 Why and when we use use-cases?

 What is sequence and activity diagrams?

5.1 Object Oriented Analysis

For a given problem, Analysis focus on investigation of the problem and requirements, rather than
searching for a solution. For example, if a new online shopping system is desired, how will the system
be used? “Analysis” is a broad term, best qualified, as in requirements analysis (an investigation of
the requirements) or object analysis (an investigation of the domain objects).

What is object oriented analysis?

It is the use of modelling to define and analyze the requirements necessary for success of the system.
Object oriented analysis is a process that groups items that interact with one another, typically by
class, data and behavior, to create a model that accurately represents the intended purpose of the
system as a whole (www.businessdictionary.com, n.d.).

51
In other words, object-oriented analysis and design is a popular technical approach for analyzing and
designing an application, system, or business by applying object-oriented programming, as well as
using visual modeling throughout the development life cycles to foster better stakeholder
communication and product quality.

According to ALAN, WIXOM, & ROTH, 2012, the analysis phase answers the questions of who will
use the system, what the system will do, and where and when it will be used. The analysis phase is so
named because the term analysis refers to breaking a whole into its parts with the intent of
understanding the parts’ nature, function, and interrelationships. In the context of the SDLC, the
outputs of the planning phase (the system request, feasibility study, and project plan), outline the
business goals for the new system, define the project’s scope, assess project feasibility, and provide
the initial work plan. These planning phase deliverables are the key inputs into the analysis phase. In
the analysis phase, the systems analyst works extensively with the business users of the new system to
understand their needs from the new system. The basic process of analysis involves three steps:
 Understand the existing situation (the as-is system)
 Identify improvements
 Define requirements for the new system (the to-be system)

5.2. System Use Case Modeling

A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. Models the goals of
system/actor (user) interactions
(https://searchsoftwarequality.techtarget.com/definition/use-case)

Use cases are used to explain and document the interaction that is required between the user and the
system to accomplish the user’s task. Use cases are created to help the development team understand
more fully the steps that are involved in accomplishing the user’s goals. Once created, use cases often
can be used to derive more detailed functional requirements for the new system. A use case represents
how a system interacts with its environment by illustrating the activities that are performed by the
users of the system and the system’s responses. The goal is to create a set of use cases that describe all
the tasks that users need to perform with the system. Use cases are often thought of as an external or

52
functional view of a business process, showing how the users view the process rather than the internal
mechanisms by which the process operates. Since use cases describe the system’s activities from the
user’s perspective in words, user involvement is essential in their development. Therefore, creating
use cases helps ensure that users’ insights are explicitly incorporated into the new system. (ALAN,
WIXOM, & ROTH, 2012).

Use case Model

Use case modeling involves finding actors and use cases. Use case modeling is a form of
requirements engineering. Use case modeling is a different and complementary way of eliciting and
documenting requirements. Use case modeling typically proceeds as follows.
Find the system boundary.
 Find the actors.
 Find the use cases:
a. specify the use case
b. create scenarios
What is use-case modelling?
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a
discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single
unit of meaningful work; for example, login to system, register with system and create order are all
Use Cases. Each Use Case has a description which describes the functionality that will be built in the
proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use
Case with its own behavior. Use Cases are typically related to 'actors'. An actor is a human or
machine entity that interacts with the system to perform meaningful work.
(https://sparxsystems.com.au/downloads/whitepapers/The_Use_Case_Model.pdf)

53
Fig 5.1 Use case model

A use-case model is a model of how different types of users interact with the system to solve a
problem. As such, it describes the goals of the users, the interactions between the users and the
system, and the required behavior of the system in satisfying these goals. A use-case model consists
of a number of model elements. The most important model elements are: use cases, actors and the
relationships between them. Much of the use-case model is in fact textual, with the text captured in
the Use-Case Specifications that are associated with each use-case model element. These
specifications describe the flow of events of the use case. The use-case model serves as a unifying
thread throughout system development. It is used as the primary specification of the functional
requirements for the system, as the basis for analysis and design, as an input to iteration planning, as
the basis of defining test cases and as the basis for user documentation.

Basic model elements

The use-case model contains, as a minimum, the following basic model elements.

Actor

It is a roles played by people or things that use the system. Actor specifies a role played by a user or
any other system that interacts with the subject. An actor specifies a role that some external entity
adopts when interacting with your system directly. It may represent a user role, or a role played by
another system, that touches the boundary of your system. Actors are external to the system. A model

54
element representing each actor. Properties include the actors name and brief description (ARLOW &
NEUSTADT, 2002). Its symbol is

actor symbol

Use Case

A use case describes behavior that the system exhibits to benefit one or more actors. A specification
of sequences of actions, including variant sequences and error sequences, that a system, subsystem or
class can perform by interacting with outside actors.” A use case is something an actor wants the
system to do. It is a “case of use” of the system by a specific actor: Use case is a list of steps, typically
defining interactions between an actor and a system, to achieve a goal. A model element
representing each use case. Properties include the use case name and use case specification (ARLOW
& NEUSTADT, 2002).

The UML icon for use cases

use case symbol Example

55
System Boundary. According to (ARLOW & NEUSTADT, 2002), the system boundary separates
the system from the rest of the world. The first thing you need to do when you are thinking about
building a system is to decide where the boundaries of the system are. In other words, you need to
define what is part of your system (inside the system boundary) and what is external to your system
(outside the system boundary).

The system boundary defines the system of interest in relation to the world around it. The system
boundary is potentially the entire system as defined in the requirements document
(https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-
diagram/).

Associations

Associations are used to describe the relationships between actors and the use cases they participate in.
This relationship is commonly known as a “communicates-association”.

Dependencies

A number of dependency types between use cases are defined in UML. In particular, <<extend>> and
<<include>>.

<<extend>> is used to include optional behavior from an extending use case in an extended use case.

<<include>> is used to include common behavior from an included use case into a base use case in
order to support re-use of common behavior.

The latter is the most widely used dependency and is useful for:

56
 Factoring out behavior from the base use case that is not necessary for the understanding of the
primary purpose of the use case to simplify communications.
 Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify
maintenance and ensure consistency.

Example: Use-Case Diagram

Figure 5.2 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.

Fig 5.2 ATM Use-Case Diagram

This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and
Maintenance Person), five use cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine
and Validate User), three <<includes>> dependencies, and the associations between the performing
actors and the use cases.

The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the
customer is identified to the system. This behavior can be extracted to a new inclusion use case called
Validate User, which the three base use cases <<include>>. The base use cases are independent of the

57
method used for identification, and it is therefore encapsulated in the inclusion use case. From the
perspective of the base use cases, it does not matter whether the method for identification is to read a
magnetic bank card, or perform a retinal scan. They only depend on the result of Validate Customer.

Use case description

A brief textual description of what the use case does. A use case is a written description of how users
will perform tasks on your website. It outlines, from a user's point of view, a system's behavior as it
responds to a request. Each use case is represented as a sequence of simple steps, beginning with a
user's goal and ending when that goal is fulfilled (https://www.dummies.com/business/business-
strategy/how-to-create-use-case-description-for-your-business-analysis-report/).

Components of use case descriptions

There some components of use case descriptions. Among those elements some of the are discussed as
the follows:
1. Title: The title communicates the goal of the use case.
2. Use case ID: A unique identifier used for tracing.
3. Description: A brief textual description of what the use case does
Use case descriptions can be summarized in the form of tabulation as follows:
4. Actors: These folks are the people or systems who interact with the use case. Some people
writing use cases also break down the actors by level within the use case: primary (the actor who
starts the use case), secondary (the one who interacts with the use case), and even off-stage (those
who don’t interact directly with the use case but are involved from a business rule perspective).
5. Pre-conditions: Preconditions are those things that need to be in place before the use case can
start.
6. Post-conditions: Post conditions are in place when you finish the use case successfully or
unsuccessfully. A post condition on success indicates what happens when the process completes
successfully. A post condition on failure is the opposite; it specifies what happens when the
process doesn’t complete successfully.
7. Path: Also called flow or story, the path is the step-by-step action and interaction between the
actor and the system. Paths come in three types:
8. Alternate path: This path is an alternate, less-frequented way to get to a successful conclusion.

58
Table 5.1 Template for a Use Case Description

Use case description for Withdraw cash use case

Table 5.2 Use case description
Use case Name Withdraw Cash
Actor Bank Customer
Description This use case describes how a Bank Customer uses an ATM to withdraw
money from his/her bank account.
Flow of Events: 1. Insert Card.
Basic Flow This use case begins when the Bank Customer inserts a Bank Card in the
card reader on the ATM machine. The ATM validates the card.
2. Enter PIN.
The ATM asks for the customer PIN code. The Bank Customer enters the
PIN code. The ATM verifies the PIN.
3. Select ‘Withdraw Cash’
The ATM displays the different alternatives that are available on this unit.
The Bank Customer selects “Withdraw Cash”.
4. Enter Account and Amount.
The ATM asks for account to withdraw from and amount to withdraw. The

59
 Bank Customer enters account and amount.
5. Debit Bank Account.
The ATM sends the card id, PIN, amount and account to the Bank
Consortium. The Bank Consortium replies that the transaction is accepted.
The ATM system reports to the Bank Customer that it is ready to dispense
cash.
6. Print Receipt.
The ATM asks the Bank Customer if a receipt is desired. The Bank
Customer requests a receipt. The ATM system prints the receipt.
7. Receive Cash and Card.
The ATM system dispenses money to the Bank Customer, and returns the
Bank Card. The use case ends.
Pre-Conditions 1. Bank Customer has a card. The Bank Customer must have a bank card
in order to begin this use case.
2. ATM contains cash. The ATM must have cash available in the machine
in order to begin this use case.
3. ATM has connection to Bank Consortium. The ATM must have a
connection to the Bank Consortium in order to begin this use case.
Post-Conditions 1. Card return. At the end of this use case, either the Bank Customer will
have their bank card returned or the bank card will be kept and the Bank
Customer will be notified of where it will be sent.
2. Accounts balanced. At the end of the use case, all account and
transaction logs are balanced, and communication with the banking
system is reinitialized.
Alternative 1. Not a valid card.
Flows In Step 1, Insert Bank Card, of the basic flow, if the card is not valid it is
ejected to the Bank Customer with a "sorry not a valid card" message. The
use case ends.
2. Wrong PIN.
In Step 2, Enter PIN, of the basic flow, the PIN is wrong. The ATM displays
the message "wrong PIN" to the Bank Customer. The Bank Customer has

60
 three tries to get it right. If the Bank Customer correctly enters the PIN, the
basic flow resumes at Step 3. Otherwise the card is kept by the machine and
the use case terminates.

5.2 Sequence Diagrams: From Use Cases to Classes

Sequence diagrams, commonly used by developers, to model the interactions between objects in a
single use case. They illustrate how the different parts of a system interact with each other to carry out
a function, and the order in which the interactions occur when a particular use case is executed. In
simpler words, a sequence diagram shows different parts of a system work in a ‘sequence’ to get
something done (https://creately.com/blog/diagrams/sequence-diagram-tutorial/).

There are 3 types of Interaction diagrams; Sequence diagrams, communication diagrams, and timing
diagrams. These diagrams are used to illustrate interactions between parts within a system. Among the
three, sequence diagrams are preferred by both developers and readers alike for their
simplicity(https://creately.com/blog/diagrams/sequence-diagram-tutorial/).

5.2.1 Sequence Diagram Notations

A sequence diagram is structured in such a way that it represents a timeline which begins at the top
and descends gradually to mark the sequence of interactions. Each object has a column and the
messages exchanged between them are represented by arrows.

A sequence diagram is made up of several of these lifeline notations that should be arranged
horizontally across the top of the diagram. No two lifeline notations should overlap each other. They
represent the different objects or parts that interact with each other in the system during the sequence
(https://creately.com/blog/diagrams/sequence-diagram-tutorial/).

61
Lifeline Notation

A sequence diagram is made up of several of these lifeline notations that should be arranged
horizontally across the top of the diagram. No two lifeline notations should overlap each other. They
represent the different objects or parts that interact with each other in the system during the sequence.

Activation Bars

Activation bar is the box placed on the lifeline. It is used to indicate that an object is active (or
instantiated) during an interaction between two objects. The length of the rectangle indicates the
duration of the objects staying active. In a sequence diagram, an interaction between two objects
occurs when one object sends a message to another. The use of the activation bar on the lifelines of
the Message Caller (the object that sends the message) and the Message Receiver (the object that
receives the message) indicates that both are active/is instantiated during the exchange of the message.

62
Message Arrows

An arrow from the Message Caller to the Message Receiver specifies a message in a sequence
diagram. A message can flow in any direction; from left to right, right to left or back to the Message
Caller itself. While you can describe the message being sent from one object to the other on the arrow,
with different arrowheads you can indicate the type of message being sent or received.

The message arrow comes with a description, which is known as a message signature, on it. All parts
except the message name are optional.

Sequence diagram for withdrawing an amount of cash/money from ATM

The Four Classes are:

 Bank Client
 ATM Machine
 Account
 Checking Account

63
These classes are depicted at the top of the diagram.

The different methods used between classes are as follows. The following is the order of the methods
used in the program.

1. Request kind()
2. Enter kind()
3. Request Amount()
4. Enter Amount()
5. Process Transaction()
6. Withdraw from Checking Account()
7. Withdraw successful()
8. Transaction Successful()
9. Dispense Cash()
10. Request Take cash()
11. Take cash()
12. Request continuation()
13. Terminate()
14. Print Recipt()

64
Fig 5.3 Sequence diagram

5.3 Conceptual Modeling: Class diagrams

Conceptual modeling is used as a way to describe physical or social aspects of the world in an abstract
way. For example, in the realm of software development, a conceptual model may be used to
represent the relationships of entities within a database. Whether written down via text or diagrammed
visually, such a conceptual model can easily represent abstract concepts of the relationships between
objects in the system, such as Users and their relationship to Accounts.

In fact, conceptual models within a typical software development life cycle are often referred to
as domain models. A domain model is a type of conceptual model that incorporates representations of
both behavior and data at the same time. It is often representing database entities, using simple

65
diagramming techniques to illustrate 1-to 1, 1-to-many, and many-to-many relationships within the
system (https://airbrake.io/blog/sdlc/conceptual-model).

In software engineering or object oriented programming, a class diagram in the Unified Modeling
Language is a type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations, and the relationships among objects. In other words, A
class diagram is an illustration of the relationships and source code dependencies among classes in the
Unified Modeling Language (UML). In this context, a class defines the methods and variables in
an object, which is a specific entity in a program or the unit of code representing that entity. Class
diagrams are useful in all forms of object-oriented programming (OOP). The concept is several years
old but has been refined as OOP modeling paradigms have evolved
(https://searchmicroservices.techtarget.com/definition/class-diagram).

Relationships
Relationships allow you to show on a model how two or more things relate to each other. Thinking of
families, and the relationships between all of the people in a family, gives you a pretty good idea of
the role relationships play in UML models – they allow you to capture meaningful (semantic)
connections between things. Relationships apply to the structural and grouping things in a model.

This part discusses relationships between objects and relationships between classes.
Relationships are semantic (meaningful) connections between modeling elements – they are the UML
way of connecting things together. Few types of relationships are:
 Between actors and use cases (association)
 Between use cases and use cases (generalization, «include», «extend»)
 Between actors and actors (generalization)
66
In order to create a functioning object oriented system, you can’t let the objects stand alone in
glorious isolation. You need to connect them together so that they can perform useful work of benefit
to the users of the system. Connections between objects are called links, and when objects work
together, we say that they collaborate.

If there is a link between two objects, there must also be some semantic connection between their
classes. This is really common sense – for objects to communicate directly with each other, the
classes of those objects must know about each other in some way. Connections between classes are
known as associations. Links between objects are actually instances of the associations between their
classes (ARLOW & NEUSTADT, 2002).

Association
Associations are connections between classes. Just as links connect objects, associations connect
classes. The key point is that for there to be a link between two objects, there must be an association
between the classes of those objects. This is because a link is an instantiation of an association, just as
an object is an instantiation of a class.

Multiplicity
Multiplicity constrains the number of objects of a class that can be involved in a particular
relationship at any point in time. The phrase “at any point in time” is vital to understanding
multiplicities.

67
Class Diagram
Class diagrams are used when developing an object-oriented system model to show the classes in a
system and the associations between these classes. Loosely, an object class can be thought of as a
general definition of one kind of system object. An association is a link between classes that indicates
that there is a relationship between these classes. Consequently, each class may have to have some
knowledge of its associated class.

The next major diagramming technique is the class diagram. The class diagram is a static model that
supports the static view of the evolving system. It shows the classes and the relationships among the
classes that remain constant in the system over time. The class diagram is very similar to the entity
relationship diagram (ERD); however, the class diagram depicts classes, which include attributes,
behaviors, and states, while entities in the ERD include only attributes. The scope of a class diagram,
like the ERD, is system-wide.

The main building block of a class diagram is the class, which stores and manages information in the
system. During analysis, classes refer to the people, places, events, and things about which the
system will capture information. Later, during design and implementation, classes can refer to
implementation-specific artifacts like windows, forms, and other objects used to build the system.
Each class is drawn by using three part-rectangles with the class’s name at the top, attributes in the
middle, and methods (also called operations) at the bottom.

68
Fig 5.4 class diagram

Class Diagram (Analysis Level)

A class diagram shows which classes exist in the business (during analysis) or in the system itself
(during subsystem design). Figure 5.5 shows an example of an analysis-level class diagram, with each
class represented as a labeled box. As well as the classes themselves, a class diagram shows how
objects of these classes can be connected together. For example, a CarModel has inside it a
CarModelDetails, referred to as its details.

69
Fig 5.5 Analysis Level class diagram

Class Diagram (Design Level)

The class diagram uses the same notation as the analysis level. The only difference is that design-level
class diagrams tend to use more of the available notation, because they’re more detailed. This one
expands on part of the analysis class diagram to show methods, constructors and navigability.

70
Fig. 5.6 A design-level class diagram

5.4 Activity Diagram

According to https://www.smartdraw.com/activity-diagram/ link, an activity diagram visually

presents a series of actions or flow of control in a system similar to a flowchart or a data flow diagram.
Activity diagrams are often used in business process modeling. They can also describe the steps in
a use case diagram. Activities modeled can be sequential and concurrent. In both cases an activity
diagram will have a beginning (an initial state) and an end (a final state). An activity diagram is used
to model a large activity's sequential work flow by focusing on action sequences and respective action
initiating conditions. The state of an activity relates to the performance of each work-flow step.

An activity diagram is represented by shapes that are connected by arrows. Arrows run from activity
start to completion and represent the sequential order of performed activities. Black circles represent
an initial work-flow state. A circled black circle indicates an end state. Rounded rectangles represent

71
performed actions, which are described by text inside each rectangle. A diamond shape is used to
represent a decision, which is a key activity diagram concept. Upon activity completion, a transition
(or set of sequential activities) must be selected from a set of alternative transitions for all use
cases. Synchronization bars indicating the start or completion of concurrent activities are used to
represent parallel sub-flows
(https://www.techopedia.com/definition/27489/activity-diagram).

Basic components of an activity diagram

Before you begin drawing an activity diagram, you should first understand its components. Some of

the most common components of an activity diagram include:

1. Action: A step in the activity wherein the users or software perform a given task. actions are
symbolized with round-edged rectangles.
2. Decision node: A conditional branch in the flow that is represented by a diamond. It includes a
single input and two or more outputs.
3. Control flows: Another name for the connectors that show the flow between steps in the diagram
4. Start node: Symbolizes the beginning of the activity. The start node is represented by a black
circle.
5. End node: Represents the final step in the activity. The end node is represented by an outlined
black circle.
Activity diagram symbols
The activity diagram symbols you are find in UML diagrams are listed in the table below:

72
Table 5.3 Activity diagram symbols

Symbol Name Description

Start symbol Represents the beginning of a process or work flow in an

activity diagram. It can be used by itself or with a note
symbol that explains the starting point.

Activity symbol Indicates the activities that make up a modeled process.

These symbols, which include short descriptions within
the shape, are the main building blocks of an activity
diagram.

Connector Shows the directional flow, or control flow, of the activity.

symbol An incoming arrow starts a step of an activity; once the
step is completed, the flow continues with the outgoing
arrow.

Joint symbol/ Combines two concurrent activities and re-introduces

Synchronizati them to a flow where only one activity occurs at a time.
on bar Represented with a thick vertical or horizontal line.

Fork symbol Splits a single activity flow into two concurrent

activities. Symbolized with multiple arrowed lines from a
join.

Decision Represents a decision and always has at least two paths

symbol branching out with condition text to allow users to view
options. This symbol represents the branching or merging
of various flows with the symbol acting as a frame or
container.

73
Note symbol Allows the diagram creators or collaborators to
communicate additional messages that don't fit within the
diagram itself. Leave notes for added clarity and
specification.

Send signal Indicates that a signal is being sent to a receiving activity.

symbol

Receive signal Demonstrates the acceptance of an event. After the event

symbol is received, the flow that comes from this action is
completed.

Shallow Represents a transition that invokes the last active state.

history
pseudostate
symbol

Option loop Allows the creator to model a repetitive sequence within

symbol the option loop symbol.

Flow final Represents the end of a specific process flow. This symbol
symbol shouldn’t represent the end of all flows in an activity; in
that instance, you would use the end symbol. The flow
final symbol should be placed at the end of a process in a
single activity flow.

Condition text Placed next to a decision marker to let you know under
what condition an activity flow should split off in that
direction.

End symbol Marks the end state of an activity and represents the
completion of all flows of a process.

74
Activity diagram for a login page
Many of the activities people want to accomplish online—checking email, managing finances,
ordering clothes, etc.—require them to log into a website. This activity diagram shows the process of
logging into a website, from entering a username and password to successfully logging in to the
system. It uses different container shapes for activities, decisions, and notes.

75
Activity diagram for a banking system

This diagram shows the process of either withdrawing money from or depositing money into a bank
account.

5.5 User interface prototyping: Evolving your supplementary specification

User interface (UI) prototyping is an iterative development technique in which users are actively
involved in the mocking-up of the UI for a system. UI prototypes have several purposes: As an
analysis artifact that enables you to explore the problem space with your stakeholders
(http://www.ambysoft.com/essays/userInterfacePrototyping.html).

76
An interface design prototype is a mock-up or a simulation of a computer screen, form, or report. A
prototype is prepared for each interface in the system to show the users and the programmers how the
system will perform. In the “old days,” an interface design prototype was usually specified on a paper
form that showed what would be displayed on each part of the screen. Paper forms are still used today,
but more and more interface design prototypes are being built with computer tools instead of on paper.
The three most common approaches to interface design prototyping are storyboards, HTML
prototypes, and language prototypes ( DENNIS, WIXOM, & ROTH, 2012).

According to ALAN, WIXOM, & ROTH, 2012, user interface is the part of the system with which
the users interact. It includes the screen displays that provide navigation through the system, the
screens and forms that capture data, and the reports that the system produces (whether on paper, on
the Web, or via some other media). It is also Interface design is the process of defining how the system will
interact with external entities (e.g., customers, suppliers, other systems).

The user interface design defines the way in which the users will interact with the system and the
nature of the inputs and outputs that the system accepts and produces. The user interface includes
three fundamental parts. The first is the navigation mechanism, the way in which the user gives
instructions to the system and tells it what to do (e.g., buttons, menus). The second is the input
mechanism, the way in which the system captures information (e.g., forms for adding new customers).
The third is the output mechanism, the way in which the system provides information to the user or to
other systems (e.g., reports, Web pages). Each of these is conceptually different, but all are closely
intertwined: All computer displays contain navigation mechanisms, and most contain input and output
mechanisms. Therefore, navigation design, input design, and output design are tightly coupled
(ALAN, WIXOM, & ROTH, 2012).

5.6 Applying Analysis Patterns Effectively

Analysis patterns were described by Fowler, who found similarities during analysis of different
application domains. He described recurring patterns found in object-oriented analysis and
described them with static models, expressed in class diagrams (Gomaa, 2011).

77
 5.6.1 Design Patterns
In software design, one frequently encounters a problem that one has solved before on a different
project. Often the context of the problem is different; it might be a different application, a different
platform, or a different programming language. Because of the different context, one usually ends up
redesigning and implementing the solution, thereby falling into the “reinventing the wheel” trap. The
field of software patterns, including architectural and design patterns, is helping developers avoid
unnecessary redesign and reimplementation (Gomaa, 2011).

A design pattern describes a recurring design problem to be solved, a solution to the problem, and the
context in which that solution works. The description specifies objects and classes that are customized
to solve a general design problem in a particular context. A design pattern is a larger-grained form of
reuse than a class because it involves more than one class and the interconnection among objects from
different classes. A design pattern is sometimes referred to as a microarchitecture (Gomaa, 2011).

After the original success of the design pattern concept, other kinds of patterns were developed. The
main kinds of reusable patterns are as follows:

1. Design pattern. It is a small group of collaborating objects.

2. Architectural pattern. Architectural patterns are larger-grained than design patterns,
addressing the structure of major subsystems of a system.
3. Analysis patterns. It is describing recurring patterns found in object-oriented analysis
and described them with static models, expressed in class diagrams.
4. Product line–specific patterns. These are patterns used in specific application
areas, such as factory automation or electronic commerce. By concentrating on a
specific application domain, design patterns can provide more tailored domain-specific
solutions.
5. Idioms. Idioms are low-level patterns that are specific to a given programming
language and describe implementation solutions to a problem that use the features of
the language – for example, Java or C++. These patterns are closest
to code, but they can be used only by applications that are coded in the same
programming language (Gomaa, 2011).

78
 5.7 User Documentation
User documentation is a user guide or user's guide, also commonly known as a manual, is a
technical communication document intended to give assistance to people using a particular system.
User guides are most commonly associated with electronic goods, computer hardware and software,
although they can be written for any product.
(https://en.wikipedia.org/wiki/User_guide).

5.8 Organizing your models with packages

It is no coincidence that the package element in UML is represented by a folder icon, similar to
directories in a file system Graphical User Interface (GUI). Packages are used to organize the
elements of a model just as folders are used to organize files. The contents of a package are any kind
of element that is part of a model, including other packages. Beyond that description there's not much
more information on how to use packages in the UML specification. Since they are a general
grouping thing, it is up to usage scenarios to suggest what the best practices are for using packages.
There are some practices that apply in most situations, and more that depend upon the modeling
methodology or the purpose of the model
(https://www.omg.org/ocup-2/documents/UML_Model_Organization_with_Packages.pdf).

First and foremost, use packages to organize your model, regardless of the model purpose. Even the
most trivial model quickly becomes unmanageable without some kind of organization. There is no
single correct way to organize a model. A modeler may choose to organize around process or product
or some combination of the two. Second, use the package diagram to provide visualizations of that
organization. The model browser view below illustrates how even a simple model can begin to be
confusing with no organization of the model elements.

79
In addition to being able to gather like items together to allow modelers to focus their attention on
relevant elements and make those elements easier to find in the browser, packages provide a
namespace for the elements they contain. Namespaces allow modelers to create unambiguous named
references to each of the elements in a model. This is useful in situations such as when a modeler is
evolving a system and creating an as-is and a to-be system model. It is natural to have elements
named the same in each model. In order to disambiguate elements with the same name, they can be
placed in different packages so that the fully-qualified names are different.

80
Packages can be placed on a UML package diagram. The modeler might choose to do this to present a
high-level view of a model or to show relationships among the packages of elements. Three different
package diagrams representing the model organization shown above are presented here. Each of these
diagrams uses the optional diagram frame, showing the diagram type (pkg) and diagram name (Use
Case View). Note that although the diagram and the package have the same name (Use Case View)
this is not required. In the first diagram (Figure 2), the two high-level packages are shown. As with
many other modeling situations, only the details we need are presented, and the details of the package
contents are elided
(https://www.omg.org/ocup-2/documents/UML_Model_Organization_with_Packages.pdf).

81
5.8 Review Questions
Try the below given questions by yourself
1. What is a system use case? Discuss it.
2. What is an Activity Diagram? Explain it.
3. Compare and contrast class diagram design level class diagram and design level class diagram
4. What is activity diagram and when you use it? Explain it.
5. What is design pattern and when you apply it? Explain it?

82
 Chapter Six
Determining How to Build your System: Object Oriented Design

Unit Objectives

At the end of this chapter, the students will be able to:

 Define class type architecture

 Understand class modelling

 Know state chart modelling

 Apply deployment modelling

 Apply user interface design

Leading Questions:

 What is class type architecture?

 What is class modelling?

 Why state chart modelling?

 What is deployment modelling?

6.1 Object Oriented Design

Design focuses on a conceptual solution that fulfills the requirements, rather than its implementation.
As with analysis, the term is best qualified, as in object design or database design
(https://www.startertutorials.com/uml/analysis-design.html).

Object-oriented design (OOD) is the process of using an object-oriented methodology to design a

computing system or application. This technique enables the implementation of a software solution
based on the concepts of objects. OOD serves as part of the object-oriented programming (OOP)
process or lifecycle.

83
In object-oriented system design and development, OOD helps in designing the system architecture or
layout - usually after completion of an object-oriented analysis (OOA). The designed system is later
created or programmed using object-oriented based techniques and/or an object-oriented
programming language (OOPL).

The OOD process takes the conceptual systems model, use cases, system relational model, user
interface (UI) and other analysis data as input from the OOA phase. This is used in OOD to identify,
define and design systems classes and objects, as well as their relationship, interface and
implementation (https://www.techopedia.com/definition/21105/object-oriented-design-ood).

6.2 Layering your models: Class Type Architecture

Layering is the concept of organizing your software design into layers/collections of classes or
components that fulfill a common purpose, such as implementing your user interface or the business
logic of your system. A class-type architecture provides a strategy for layering the classes of your
software to distribute the functionality of your software among classes. Furthermore, class-type
architectures provide guidance as to what other types of classes a given type of class will interact with,
and how that interaction will occur. This increases the extensibility, maintainability, and portability of
the systems you create.

The most common architecture pattern is the layered architecture pattern, otherwise known as the n-
tier architecture pattern. This pattern is the defacto standard for most Java EE applications and
therefore is widely known by most architects, designers, and developers. The layered architecture
pattern closely matches the traditional IT communication and organizational structures found in most
companies, making it a natural choice for most business application development efforts
(https://www.oreilly.com/library/view/software-architecturepatterns/9781491971437/ch01.html).

84
Fig 6.1 Layering classes

6.3 Class Modeling

The purpose of design is to model how the software will be built. As you would expect, the purpose
of design-class modeling is to model the static structure of how your software will be built. Analysis
classes still apply. The only difference is your focus is on the solution domain, instead of on the
problem domain. You will introduce changes to your class model based on implementation
technologies. And perhaps you will implement business rules using a business rules engine, which
means your business/domain classes will invoke the rules, instead of directly implementing them in
methods. Perhaps you will apply known design patterns, to improve the design quality of your models.
Perhaps you will decide to take a component-based approach. Or, perhaps you will take advantage of
features of your permanent storage mechanism.

85
A collection of topics that are important to your design class modeling efforts are:

 Inheritance techniques
 Association and dependency techniques
 Aggregation and composition techniques
 Modeling attributes and methods during design
 Modeling interfaces
 Documenting design trade-offs
 Class modeling design tips

Similarities often exist between different classes. Quite often, two or more classes share the same
attributes and/or the same methods. Because You don't want to have to write the same code repeatedly,
you want a mechanism that takes advantage of these similarities. Inheritance is that mechanism.

Inheritance models "is a," "is like," and "is kind of" relationships, enabling you to reuse existing data
and code easily. In the real world, objects have associations to other objects. The associations between
objects are important because they help us to define how they interact with each other. For example,
students take courses and professors teach courses. Associations between objects enable
collaboration-an object needs to know about another object to work with it. When a persistent
association doesn't exist between two objects, but they need to collaborate with one another, you
model a dependency relationship between the two classes.

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage,
wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or more packages. A
team consists of two or more employees. These are all examples of the concept of aggregation, which
represents "is part of" relationships. Composition is a strong form of aggregation in which the
"whole" is completely responsible for its parts and each part is only associated to one whole.

86
Modeling Attributes
Attributes are the data aspects of objects. With UML, it is possible to model far more information
about an attribute, as you can see in the figure. During design, you should indicate each attribute's
visibility (the level of access external objects have to an attribute) on your class diagram. The name of
the attribute is also indicated. The type and initial value (if any) for each attribute should also be
indicated and, if the attribute repeats, it should be indicated with the "[*]" notation. Finally, the scope
of an attribute, whether it is a static attribute applicable to the class or an instance attribute applicable
to an individual instance of the class, should also be modeled.
The UML formats for an attribute are:
visibility name: type <<initialValue>>
visibility name[*]: type <<stereotype>>

Visibility indicates the access level of variables. The experience is that all fields should be declared as
private for purposes of information hiding and encapsulation. Attributes should never be accessed
directly; instead, accessory should be used. When fields are declared as protected, the possibility
exists that methods in subclasses will directly access them, effectively increasing the coupling within
a class hierarchy. This makes your classes more difficult to maintain and to enhance; therefore, it
should be avoided.

87
Table 6.1 Visibility levels

Visibility symbol description proper usage

public + A public method can be invoked When the method must be accessible
by any other method in any other by objects and classes outside of the
object or class. class hierarchy in which the method
is defined.
protected # A protected method can be When the method provides behavior
invoked by any method in the that is needed internally within the
class in which it is defined or class hierarchy, but not externally.
any subclasses of that class.
private - A private method can only be When the method provides behavior
invoked by other methods in the that is specific. to the class. Private
class in which it is defined, but methods are often the result of
not in the subclasses. refactoring.

6.4 State chart modeling

A state diagram, also called a state machine diagram or state chart diagram, is an illustration of
the states an object can attain as well as the transitions between those states in the Unified
Modeling Language (UML).

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a system.
A Statechart diagram describes a state machine. State machine can be defined as a machine which
defines different states of an object and these states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines the states, it is used to model the lifetime of an object

(https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm).

88
Purpose of Statechart Diagrams
Following are the main purposes of using Statechart diagrams −

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.

 To describe different states of an object during its life time.

 Define a state machine to model the states of an object.

How to Draw a Statechart Diagram

Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs. Before drawing a Statechart diagram we should
clarify the following points −

 Identify the important objects to be analyzed.

 Identify the states.

 Identify the events.

89
6.5 Collaboration Modeling
A collaboration diagram, also called a communication diagram or interaction diagram, is an
illustration of the relationships and interactions among software objects in the Unified Modeling
Language (UML). The concept is more than a decade old although it has been refined as modeling
paradigms have evolved.
(https://searchsoftwarequality.techtarget.com/definition/collaboration-diagram).

Collaboration diagrams (known as Communication Diagram in UML 2.x) are used to show how
objects interact to perform the behavior of a particular use case, or a part of a use case. Along with
sequence diagrams, collaboration is used by designers to define and clarify the roles of the objects
that perform a particular flow of events of a use case. They are the primary source of information
used to determining class responsibilities and interfaces.
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml-collaboration-
diagram/

90
 6.7 Component Modeling
In Unified Modeling Language, a component diagram depicts how components are wired together
to form larger components or software systems. They are used to illustrate the structure of
arbitrarily complex systems(Wikipedia). The purpose of a component diagram is to show the
relationship between different components in a system
(https://www.lucidchart.com/pages/uml-component-diagram?a=0).

91
Fig 6.2 Component Diagram Example: Online Shop
6.8 Deployment Modeling
A UML deployment diagram is a diagram that shows the configuration of run time processing
nodes and the components that live on them. Deployment diagrams is a kind of structure diagram
used in modeling the physical aspects of an object-oriented system. They are often be used to model
the static deployment view of a system (topology of the hardware) (https://www.visual-
paradigm.com/guide/uml-unified-modeling-language/what-is-deployment-diagram/)

Purpose of Deployment Diagrams

 They show the structure of the run-time system

 They capture the hardware that will be used to implement the system and the links
between different items of hardware.
 They model physical hardware elements and the communication paths between them
 They can be used to plan the architecture of a system.
 They are also useful for Document the deployment of software components or nodes

92
Fig 6.3 ATM deployment diagram

6.9 Rational Persistence Modeling

Persistence refers to object and process characteristics that continue to exist even after the process that
created it ceases or the machine it is running on is powered off. When an object or state is created and
needs to be persistent, it is saved in a non-volatile storage location, like a hard drive, versus a
temporary file or volatile random access memory (RAM).

In terms of data, persistence means an object should not be erased unless it is really meant to be
deleted. This entails proper storage and certain measures that allow the data to persist. In terms of
computer threads and processes, a persistent process is one that cannot be killed or shut down. This is
usually true for core system processes that are essential to a properly functioning system.

93
For example, even if a Windows operating system (OS) explorer fails or is killed, it simply restarts. A
persistent state refers to the retention of that state, even after the process has been killed. In this case,
the state is saved in persistent storage before device shutdown and then reloaded when the device
turns on, ensuring that the device, workspace or data are in the same state after turning on the device
(https://www.techopedia.com/definition/8842/persistence-computing).

6.10 User Interface Design

In information technology, the user interface (UI) is everything designed into an information device
with which a person may interact. This can include display screens, keyboards, a mouse and the
appearance of a desktop. It is also the way through which a user interacts with an application or
a website. The growing dependence of many companies on web applications and mobile applications
has led many companies to place increased priority on UI in an effort to improve the user's overall
experience
(https://searchmicroservices.techtarget.com/definition/user-interface-UI).

User interface design (UI design) refers to the design of various types of software and hardware
interfaces through which users interact with computers and other technologies. In today’s diverse tech
world, UI design involves a wide spectrum of engineering practices applied to different kinds of
products and devices (https://www.techopedia.com/definition/22776/user-interface-design-ui-design).

Principles of User Interface Design

1. Clarity is job #1. Clarity is the first and most important job of any interface.
2. Interfaces exist to enable interaction.
3. Conserve attention at all costs.
4. Keep users in control.
5. Direct manipulation is best.
6. One primary action per screen.
7. Keep secondary actions secondary.
8. Provide a natural next step.

94
GUI Elements
GUI provides a set of components to interact with software or hardware.

Every graphical component provides a way to work with the system. A GUI system has following
elements such as:

Interface Standards Design

Interface standards are the basic design elements that are common across the individual screens,
forms, and reports within the system. Depending on the application, there may be several sets of
interface standards for different parts of the system (e.g., one for Web screens, one for mobile screens,
one for paper reports, one for input forms). For example, the part of the system used by data entry
operators might mirror other data entry applications in the company, whereas a Web interface for
displaying information from the same system might adhere to some standardized Web format.
Likewise, each individual interface might not contain all of the elements in the standards (e.g., a
report screen might not have an edit capability), and they might contain additional characteristics
beyond the standard ones, but the standards serve as the touchstone that ensures the interfaces are
consistent across the system.

95
The following sections discuss some of the main areas in which interface standards should be
considered: metaphors, objects, actions, icons, and templates

Interface Metaphor. First of all, the analysts must develop the fundamental interface metaphor(s)
that defines how the interface will work. An interface metaphor is a concept from the real world that
is used as a model for the computer system. T e metaphor helps the user understand the system and
enables the user to predict what features the interface might provide, even without actually using the
system. Sometimes systems have one metaphor, whereas in other cases there are several metaphors in
different parts of the system.

Interface Templates. An interface template defines the general appearance of all screens in the
information system and the paper-based forms and reports that are used. Te template design, for
example, specif es the basic layout of the screens (e.g., where the navigation area(s), status area, and
form/report area(s) will be placed) and the color scheme(s) that will be applied. It defines whether
windows will replace one another on the screen or will cascade over the top of each other. T e
template defines a standard placement and order for common interface actions (e.g., File Edit View
rather than File View Edit). In short, the template draws together the other major interface design
elements: metaphors, objects, actions, and icons.

Interface Objects. The template specif es the names that the interface will use for the major interface
objects, the fundamental building blocks of the system, such as the classes. In many cases, the object
names are straightforward, such as calling the shopping cart the “shopping cart.” In other cases, it is
not so simple. For example, Amazon.com sells much more than books. In some cases, the user might
not know whether he or she is looking for a book, CD, DVD, or Kindle download. In those cases, the
user can use a catchall search item: All Departments. In the case that the user knows the type of item
that he or she wants to buy, the user can limit the search by specifying more-specif c types of search
items, such as Apps for Android, Books, Kindle Store, or Music. Obviously, the object names should
be easily understood and help promote the interface metaphor.

96
Interface Actions. The template also specifies the navigation and command language style (e.g.,
menus) and grammar (e.g., object-action order). It gives names to the most commonly used interface
actions in the navigation design (e.g., buy versus purchase or modify versus change).

Interface Icons. The interface objects and actions and their status (e.g., deleted or overdrawn) may be
represented by interface icons. Icons are pictures that appear on command buttons as well as in
reports and forms to highlight important information. Icon design is very challenging because it
means developing a simple picture less than half the size of a postage stamp that needs to convey an
of en-complex meaning. The simplest and best approach is to simply adopt icons developed by others
(e.g., a blank page to indicate create a new file, a diskette to indicate save). This has the advantage of
quick icon development, and the icons might already be well understood by users because they have
seen them in other software. Commands are actions that are especially difficult to represent with icons
because they are in motion, not static. Many icons have become well known from widespread use, but
icons are not as well understood as first believed. Use of icons can sometimes cause more confusion
than insight. Icon meanings become clearer with use, but sometimes a picture is not worth even one
word; when in doubt, use a word, not a picture (Dennis A. et al, 2015).

97
6.11 Review Questions
Try the below given questions by yourself

1. List and discuss in detail principles of User Interface Design?

2. Discuss Rational Persistence Modeling?
3. Discuss with examples Deployment Modeling?
4. Discuss use of Collaboration Modeling?
5. State and explain with example State chart modeling?

98
 Chapter Seven
Object Oriented /Software Testing

Unit Objectives
At the end of this chapter the students will be able to:
 Understand the stages of testing from testing, during development to acceptance testing by
system customers;
 have been introduced to techniques that help you choose test cases that are geared to
discovering program defects;
 understand test-first development, where you design tests before writing code and run these
tests automatically;
 know the important differences between component, system, and release testing and be aware
of user testing processes and techniques.
Leading Questions
 What is development testing?
 What is test-driven development?
 What is release testing?
 What is user testing?
7.1 Object-Oriented Testing
Object-Oriented Testing is a collection of testing techniques to verify and validate object-oriented
software. Software Testing is evaluation of the software against requirements gathered from users and
system specifications. Testing is conducted at the phase level in software development life cycle or at
module level in program code. Software testing comprises of Validation and Verification.
(https://www.tutorialspoint.com/software_engineering/software_testing_overview.htm)

Software Validation
Validation is process of examining whether or not the software satisfies the user requirements. It is
carried out at the end of the SDLC. If the software matches requirements for which it was made, it is
validated.

99
  Validation ensures the product under development is as per the user requirements.

 Validation answers the question – "Are we developing the product which attempts all that user
needs from this software ?".

 Validation emphasizes on user requirements.

Software Verification
Verification is the process of confirming if the software is meeting the business requirements, and is
developed adhering to the proper specifications and methodologies.

 Verification ensures the product being developed is according to design specifications.

 Verification answers the question– "Are we developing this product by firmly following all
design specifications ?"

 Verification concentrates on the design and system specifications.

7.2 Testing
Software Testing is evaluation of the software against requirements gathered from users and system
specifications. Testing is conducted at the phase level in software development life cycle or at module
level in program code. Software testing comprises of Validation and Verification. Testing is intended
to show that a program does what it is intended to do and to discover program defects before it is put
into use. When you test software, you execute a program using artificial data. You check the results of
the test run for errors, anomalies, or information about the program’s non-functional attributes.
Testing can only show the presence of errors, not their absence.

The testing process has two distinct goals:

 To demonstrate to the developer and the customer that the software meets its requirements.
For custom software, this means that there should be at least one test for every requirement in
the requirements document. For generic software products, it means that there should be tests
for all of the system features, plus combinations of these features, that will be incorporated in
the product release.
 To discover situations in which the behavior of the software is incorrect, undesirable, or does
not conform to its specification. These are a consequence of software defects. Defect testing

100
 is concerned with rooting out undesirable system behavior such as system crashes, unwanted
interactions with other systems, incorrect computations, and data corruption.
7.2 Development Testing
Development testing includes all testing activities that are carried out by the team developing the
system. The tester of the software is usually the programmer who developed that software, although
this is not always the case. Some development processes use programmer/tester pairs where each
programmer has an associated tester who develops tests and assists with the testing process. For
critical systems, a more formal process may be used, with a separate testing group within the
development team. They are responsible for developing tests and maintaining detailed records of test
results.
During development, testing may be carried out at three levels of granularity:
1. Unit testing, where individual program units or object classes are tested. Unit testing should
focus on testing the functionality of objects or methods.
2. Component testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.
3. System testing, where some or all of the components in a system are integrated and the system is
tested as a whole. System testing should focus on testing component interactions.

Development testing is primarily a defect testing process, where the aim of testing is to discover bugs
in the software. It is therefore usually interleaved with debugging— the process of locating problems
with the code and changing the program to fix these problems.
7.3 Test-driven development
Test-driven development (TDD) is an approach to program development in which you interleave
testing and code development . Essentially, you develop the code incrementally, along with a test for
that increment. You don’t move on to the next increment until the code that you have developed
passes its test. Test-driven development was introduced as part of agile methods such as Extreme
Programming. However, it can also be used in plan-driven development processes (Sommerville I.,
2011).

101
7.4 Release testing

Release testing is the process of testing a particular release of a system that is intended for use outside
of the development team. Normally, the system release is for customers and users. In a complex
project, however, the release could be for other teams that are developing related systems. For
software products, the release could be for product management who then prepare it for sale. There
are two important distinctions between release testing and system testing during the development
process:

 A separate team that has not been involved in the system development should be responsible for
release testing.

 System testing by the development team should focus on discovering bugs in the system (defect
testing). The objective of release testing is to check that the system meets its requirements and is
good enough for external use (validation testing).
7.5 User testing
User or customer testing is a stage in the testing process in which users or customers provide input
and advice on system testing. This may involve formally testing a system that has been commissioned
from an external supplier, or could be an informal process where users experiment with a new
software product to see if they like it and that it does what they need. User testing is essential, even
when comprehensive system and release testing have been carried out. The reason for this is that
influences from the user’s working environment have a major effect on the reliability, performance,
usability, and robustness of a system.

In practice, there are three different types of user testing:

1. Alpha testing, where users of the software work with the development team to test the software
at the developer’s site.
2. Beta testing, where a release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system developers.
3. Acceptance testing, where customers test a system to decide whether or not it is ready to be
accepted from the system developers and deployed in the customer environment (Sommerville I.,
2011).

102
In alpha testing, users and developers work together to test a system as it is being developed. This
means that the users can identify problems and issues that are not readily apparent to the development
testing team. Developers can only really work from the requirements but these often do not reflect
other factors that affect the practical use of the software. Users can therefore provide information
about practice that helps with the design of more realistic tests. Alpha testing is often used when
developing software products that are sold as shrink-wrapped systems. Users of these products may
be willing to get involved in the alpha testing process because this gives them early information about
new system features that they can exploit. It also reduces the risk that unanticipated changes to the
software will have disruptive effects on their business. However, alpha testing may also be used when
custom software is being developed. Agile methods, such as XP, advocate user involvement in the
development process and that users should play a key role in designing tests for the system.

Beta testing takes place when an early, sometimes unfinished, release of a software system is made
available to customers and users for evaluation. Beta testers may be a selected group of customers
who are early adopters of the system. Alternatively, the software may be made publicly available for
use by anyone who is interested in it. Beta testing is mostly used for software products that are used in
many different environments (as opposed to custom systems which are generally used in a defined
environment). It is impossible for product developers to know and replicate all the environments in
which the software will be used. Beta testing is therefore essential to discover interaction problems
between the software and features of the environment where it is used. Beta testing is also a form of
marketing— customers learn about their system and what it can do for them.

Acceptance testing is an inherent part of custom systems development. It takes place after release
testing. It involves a customer formally testing a system to decide whether or not it should be accepted
from the system developer. Acceptance implies that payment should be made for the system.

103
7.6 Testing vs. Quality Control, Quality Assurance and Audit
We need to understand that software testing is different from software quality assurance, software
quality control and software auditing.

 Software quality assurance - These are software development process monitoring means, by
which it is assured that all the measures are taken as per the standards of organization. This
monitoring is done to make sure that proper software development methods were followed.

 Software quality control - This is a system to maintain the quality of software product. It
may include functional and non-functional aspects of software product, which enhance the
goodwill of the organization. This system makes sure that the customer is receiving quality
product for their requirement and the product certified as ‘fit for use’.

 Software audit - This is a review of procedure used by the organization to develop the
software. A team of auditors, independent of development team examines the software
process, procedure, requirements and other aspects of SDLC. The purpose of software audit
is to check that software and its development process, both conform standards, rules and
regulations.

104
7.6 Review Questions
Try the below given questions by yourself
1. What is an Object-Oriented Testing ? Discuss with examples.
2. Compare and contrast release testing and user testing.
3. What is software verification? Explain it.
4. What is software validation? Explain it.
5. Compare and contrast software validation and verification?

105
 Chapter Eight
Software process
Unit Objectives
At the end of this chapter the students will be able to:

 Understand about software

 Understand software processes
 Know Software process models

Leading questions
 What is software?
 What are the elements of a software process?
 What is Software process model?
Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be collection of executable programming code,
associated libraries and documentations.

Software is both a product and a vehicle that delivers a product. Computer software is the product that
software professionals build and then support over the long term. It encompasses programs that
execute within a computer of any size and architecture, content that is presented as the computer
programs execute, and descriptive information in both hard copy and virtual forms that encompass
virtually any electronic media. Software engineering encompasses a process, a collection of methods
(practice) and an array of tools that allow professionals to build high quality computer software
(Pressman S., 2010).
A software process (also known as software methodology) is a set of related activities that leads to the
production of the software. These activities may involve the development of the software from the
scratch, or, modifying an existing system (https://medium.com/omarelgabrys-blog/software-
engineering-software-process-and-software-process-models-part-2-4a9d06213fdc).

A software development process, also known as a software development life-cycle, is a structure

imposed on the development of a software product. A software process is represented as a set of work
phases that is applied to design and build a software product. There is no ideal software process, and

106
many organizations have developed their own approach to software development. Software
development processes should make a maximum use of the capabilities of the people in an
organization and the specific characteristics of the systems that are being developed.

Software Process is a set of required activities and the outcome of the activities with a target to
produce a software product. A software process is a flowchart of developing a software product,
which includes fathering requirements, analyzing those requirements, scheduling development phases,
checking the developments, implementing changes etc. and this can be till the delivery of the final
software product to the after delivery service methods and more.

Any software process must include the following four activities:

1. Software specification (or requirements engineering): Define the main functionalities of the
software and the constrains around them.

2. Software design and implementation: The software is to be designed and programmed.

3. Software verification and validation: The software must conform to its specification and meets
the customer needs.

4. Software evolution (software maintenance): The software is being modified to meet customer and
market requirements changes.

(https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-
process-models-part-2-4a9d06213fdc)

Software process models

A software process model is an abstract representation of a software process. In this section a number
of general process models are introduced and they are presented from an architectural viewpoint.
These models can be used to explain different approaches to software development. They can be
considered as process frameworks that may be extended and adapted to create more specific software
engineering processes. In this chapter the following process models will be introduced:

107
 1. The waterfall model. In this model of software process the fundamental process activities of
specification, development, validation and evolution are represented as sequential process
phases such as requirements specification, software design, implementation, testing and so on.

2. Evolutionary development. This approach interleaves the activities of specification,

development and validation. An initial system is rapidly developed from abstract
specifications. Then the initial system is refined by customer inputs to produce a system that
satisfies the customer’s needs.
3. Component-based software engineering. The process models that use this approach are based
on the existence of a significant number of reusable components. The system development
process focuses on integrating these components into a system rather than developing them

These three generic process models are widely used in current software engineering practice. They are
not mutually exclusive and are often used together, especially for large systems development. Sub
systems within a larger system may be developed using different approaches. Therefore, although it
is convenient to discuss these models separately, in practice, they are often combined
(http://moodle.autolab.unipannon.hu/Mecha_tananyag/szoftverfejlesztesi_folyamatok_angol/ch03.ht
ml).

108
Review Questions
Try the below given questions by yourself
1. Define software processes?
2. Discuss software process models?
3. Explain about Software specification?
4. Explain about Software design and implementation?
5. Discuss about Component-based software engineering?

109
 Assignment
This assignment is evaluated out of 30% of your total assessment of the course. Each carries 5

marks. Do it in groups of five students or individually.

Answer the following questions accordingly.

1. Define the following key terms: association, class diagram, event, object, object class, operation,

sequence diagram, state, state transition, Unified Modeling Language, and use case.

2. Describe options for designing and conducting interviews and develop a plan for conducting an

interview to determine system requirements

3. Describe the concepts and principles underlying the object-oriented approach.

4. Develop simple requirements models using state and sequence diagrams.

5. Develop a simple object model using class diagrams.

110
 References
DENNIS, A., WIXOM, B. H., & ROTH, R. M. (2012). System Analysis and Design (5 ed.). John
Wiley & Sons, Inc.
Valacich, J. S., & George, J. F. (2011). Modern Systems Analysis and Design (8 ed.).
ARLOW, J., & NEUSTADT, I. (2002). UML and the unified process: Practical object oriented
analysis and Design.
Gomaa, H. (2011). SOFTWARE MODELING AND DESIGN:UML, Use Cases, Patterns, and
Software Architectures.
Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The unified modellin language reference manual.
Gary B. Shelly G.B, & Rosenblatt H.J.(2012).Systems Analysis and Design (9 ed.)
www.businessdictionary.com, n.d.
https://www.techopedia.com/definition/27489/activity-diagram
https://searchmicroservices.techtarget.com/definition/class-diagram
https://airbrake.io/blog/sdlc/conceptual-model
https://www.techopedia.com/definition/3233/object-oriented
https://www.tutorialspoint.com
https://whatis.techtarget.com/definition/component
https://searchsoftwarequality.techtarget.com
https://www.quora.com/What-are-the-benefits-of-object-oriented-programming
https://www.brighthub.com/internet/web-development/articles/74166.aspx
https://greengarageblog.org/6-pros-and-cons-of-object-oriented-programmin

https://www.guru99.com/use-case-testing.html

https://www.softwaretestingclass.com/difference-between-verification-and-validation

111