CHAPTER 1

INTRODUCTION
PROGRAM vs. SOFTWARE
1. Program: Set of instructions written for a specific task.

2. Documentation: Documents produced during software development.

• SRS
• SDD
• Test plan
• Test suite

3. Operating Procedure Manuals: Prepared to help the customer to install, operate and
maintain the software
• Installation Manual
• Beginner’s guide
• System administration manual
• System overview
• Reference guide
 SOFTWARE CHARACTERISTICS
• Software does not wear out.
• Flexibility
• Reusability
Hardware curve Software curve
 WHAT IS SOFTWARE ENGINEERING??

• The term ‘software engineering’ was coined at the first conference on software
engineering held in 1968 in which Fritz et al. (1968) defined software engineering as:
The establishment and use of sound engineering principles in order to obtain
economically developed software that is reliable and works efficiently on real
machines.
• IEEE Computer Society’s software engineering body of knowledge defines software
engineering as (Abren et al., 2004):
The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software, and the study of these
approaches, that is, the application of engineering to software.
 OBJECT ORIENTED CONCEPTS
• Classes and Objects
• Messages, Attributes and Methods
• Encapsulation
• Inheritance
• Polymorphism
• Abstraction
OBJECT ORIENTED METHODOLOGIES

• Object oriented analysis by Coad and Yourdon

• Object oriented design by Booch
• Object modelling technique by Rumbaugh et al.
• Object oriented software engineering by Jacobson et al.
COAD AND YOURDON METHODOLOGY

• In OOA, an analysis model is developed and it consists of five steps:

1. Identification of classes and objects
2. Identification of structures
3. Definition of subjects
4. Definition of attributes
5. Definition of services (methods)
 BOOCH METHODOLOGY
• The main concern of the Booch methodology is the iterative process and
creativity of designer in order to develop OOD.
• The Booch methodology follows and incremental and iterative life cycle.
• It combines analysis, design an implementation and provides a sound
object-oriented software engineering process for analysts, designers and
developers.
• The Booch methodology can be broadly divided into two processes: macro
process and micro process
MACRO PROCESS
 MICRO PROCESS
• The following recursive steps are followed in OOD micro process:
1. Identification of classes and objects
2. Identification of semantics of classes and objects
3. Identification of relationship amongst classes and objects
4. Specification of interfaces and implementation of classes and objects
 RUMBAUGH METHODOLOGY
• Focuses on analysis, design and implementation of the system.
• Popularly known as Object Modelling Technique (OMT) (Rumbaugh et al.,
1990).
• The OMT consists of four phases: analysis, dynamic design, object design
and implementation.
• Analysis phase is composed of 3 models: object model, system model and
functional model.
 JACOBSON METHODOLOGY
• The Jacobson’s methodology known as Object-Oriented Software Engineering (OOSE)
consists of five models (Jacobson et al., 1999):
1. The requirement model: The aim of this model is to gather software requirements.
2. The analysis model: The goal of this model is to produce ideal, robust and modifiable
structure of an object.
3. The design model: It refines the objects keeping the implementation environment in mind.
4. The implementation model: It implements the objects.
5. The test model: The goal of the test model is to validate and verify the functionality of the
system
 OBJECT ORIENTED MODELING
• Object-oriented modelling is a way of constructing visual models based on
real-world objects. Modelling helps in understanding the problems,
developing proper documents and producing well-designed programs.
• The models must depict the various views of the system and these models
must be verified to check whether they capture the customer’s requirements
• OOD, OMT and OOSE are combined into UML(Unified Modeling
Language).
 UML
• The UML was adopted by Object Management Group (OMG) in November 1997.
• The UML is defined as a language for visual modelling that allows to specify,
visualize, construct, understand and document the various artifacts of the system
(Rumbaugh et al. 2004).
• UML models the static and dynamic aspects of the system. The static aspect of the
system models the objects and relationship amongst these objects. The dynamic
aspect of the system models the events and states used for interaction amongst
objects over time.
 SOME TERMINOLOGIES
• Customer, Developer and Users: Customers are persons who request the
system, approve the system and pay for the system. Developers are the
persons at the supplier side who are responsible for the development of the
system. Users are the persons who actually use the system.
• Product and Process: Product is what is delivered to the customer. It may
include software requirement specification (SRS) document, source code, test
reports, user manuals and system guide. Process is the way in which the
software is produced. A process is like a tunnel through which the project
goes in order to produce a product.
• Actor, Use cases, Use case model and Use case scenario: An actor represents
the role of a user that interacts with the system. A use case describes who does
what with the system, for what goal, without considering the internal details of
the system. A complete set of use cases explains the various ways to use the
system. The use case model depicts actors, use cases and the relationship between
them. A use case scenario is an instance of a use case or a complete path through
the use case. The basic flow is one scenario and every alternative path gives
another scenario.
• Systems and Subsystems: A system is an organized and arranged structure as a
whole that consists of interrelated and well-defined procedures, processes and
methods. The system may consist of several subsystems. Subsystems are a way of
reducing complexity of the system.
• Class, Responsibility and Collaboration: A class is a template that consists of
attributes and operations. Responsibilities are attributes and operations included
in a class. Collaborations are the other classes that a class calls in order to achieve
the functionality.
• Measures, Metrics and Measurement: Pressman (2005) explained this clearly
as: “A measure provides a quantitative indication of the extent, amount,
dimension, capacity or size of some attributes of a product or process.
Measurement is the act of determining a measure. The metric is a quantitative
measure of the degree to which a product or process possesses a given attribute.”
• Software Quality and Reliability: Software reliability is defined as “the
probability of failure free operation for a specified time in a specified
environment” (ANSI, 1991). Software quality determines how good the software
designed is (quality of design), and how good the software conforms to that
design (quality of conformance).
• Quality assurance and Quality control: The purpose of quality assurance (QA)
activity is to enforce standards and techniques to improve the development
process and prevent the previous bugs from ever occurring. Quality control
attempts to build a software and test it thoroughly. If failures are experienced,
remove the causes of failures and ensure the correctness of removal.
• Verification and Validation: As per IEEE (2001) verification is defined as, “It
is the process of evaluating the system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start
of that phase”. As per IEEE (2001) validation is defined as, “It is the process of
evaluating a system or component during or at the end of development process to
determine whether it satisfies the specified requirements”.
Testing = Verification + Validation
• Fault, Error, Bug and Failure: When we make an error during coding, we call
this ‘bug’. Hence, error/mistake/defect in coding is called a bug. A fault is the
representation of an error. If the fault is in the source code, we call it a bug. A
failure is the result of execution of a fault and is dynamic in nature. When the
expected output does not match with the observed output, we experience a
failure. The program has to execute for a failure to occur. A fault may lead to
many failures. A particular fault may cause different failures, depending on the
inputs to the program.
• States and Events: A state is an abstract situation in the life cycle of an entity
that occurs in response to occurrence of some event. An event is an input (a
message or method call). Due to the occurrence of some event, the system transits
from one state to the other.
Traditional Approach and OO Approach
Traditional Approach Object Oriented Approach
1. The system is viewed as a collection of 1. The system is viewed as a collection of
processes. objects.
2. Reusable source code may not be produced. 2. Produce reusable source code.
3. Follows a top down approach for modelling 3. Follows a bottom up approach for
the system. modelling the system.
4. Non- iterative. 4. Highly iterative.
5. Data flow diagram, ER diagrams, data 5. UML models such as use case diagram, class
dictionary etc. are used. diagram, sequence diagrams etc. are used