OOSE

MC4102 OBJECT ORIENTED SOFTWARE ENGINEERING
UNIT I SOFTWARE DEVELOPMENT AND PROCESS MODELS
Introduction to Software Development – Challenges – An Engineering Perspective – Object

Orientation – Software Development Process – Iterative Development Process – Process
Models – Life Cycle Models – Unified Process – Iterative and Incremental – Agile Processes.
UNIT II MODELLING OO SYSTEMS
Object Oriented Analysis (OOA / Coad-Yourdon), Object Oriented Design (OOD/Booch),

Hierarchical Object Oriented Design (HOOD), Object Modeling Technique (OMT) –
Requirement Elicitation – Use Cases – SRS Document – OOA - Identification of Classes and
Relationships, Identifying State and Behavior – OOD - Interaction Diagrams – Sequence
Diagram – Collaboration Diagrams - Unified Modeling Language and Tools.
UNIT III DESIGN PATTERNS
Design Principles – Design Patterns – GRASP – GoF – Dynamic Object Modeling – Static
Object Modeling.
UNIT IV SYSTEM TESTING
Software testing: Software Verification Techniques – Object Oriented Checklist :-

Functional Testing – Structural Testing – Class Testing – Mutation Testing – Levels of
Testing – Static and Dynamic Testing Tools - Software Maintenance – Categories –
Challenges of Software Maintenance – Maintenance of Object Oriented Software –
Regression Testing
UNIT V SOFTWARE QUALITY AND METRICS
Need of Object Oriented Software Estimation – Lorenz and Kidd Estimation – Use Case
Points Method – Class Point Method – Object Oriented Function Point – Risk Management –
Software Quality Models – Analyzing the Metric Data – Metrics for Measuring Size and
Structure – Measuring Software Quality - Object Oriented Metrics
1
UNIT - I
Software Development And Process Models
Introduction to Software Development
1.“Software development refers to a set of computer science activities

dedicated to the process of creating, designing, deploying and supporting
software.” ... Application software (applications or apps) to help users perform
tasks.
2. Software development is the computer programming, documenting,
testing, and bug fixing involved in creating and maintaining applications and
frameworks involved in a software release life cycle and resulting in a
software product.
3. Software itself is the set of instructions or programs that tell a computer

what to do. It is independent of hardware and makes computers programmable.
There are three basic types:
 System software to provide core functions such as operating systems, disk

management, utilities, hardware management and other operational necessities.
 Programming software to give programmers tools such as text editors,
compilers, linkers, debuggers and other tools to create code.
 Application software (applications or apps) to help users perform tasks. Office
productivity suites, data management software, media players and security
programs are examples. Applications also refers to web and mobile applications
like those used to shop on Amazon.com, socialize with Facebook or post pictures
to Instagram.
Types of Software Devolpment
1. Frontend Development
2. Backend Development
3. Full-Stack Development
4. Desktop Development
5. Database Development
1. Frontend Development
 Frontend developers work on the part of the product with which the user
interacts. They are primarily concerned with the user interface (UI).
 For example, they might create the layout, visual aspects, and interactive
elements of a website or app. However, their role isn’t identical to that of a UI
or user experience (UX) designer. They also fix bugs and make certain that the UI
can run on different browsers.
2
2. Backend Development
o A backend developer works with the part of the product users can’t see — the
back end.
o This professional builds the infrastructure that powers the website, app, or
program, focusing on functionality, integration of systems, and core logic.
o They will also deal with the complex, underlying structure, ensuring strong
performance, scalability, and security.
o The frontend and backend developers work closely together to create a final
product.
3. Full-Stack Development
 A full-stack developer works on all aspects of the product, including both the
front and back ends.
 To be a successful full-stack developer, must have strong programming skills, as
well as a variety of soft skills that all tech professionals must have, such as
problem-solving and critical thinking.
4. Desktop Development
 Desktop developers exclusively create applications that run on a desktop
operating system, such as Windows, Mac, or Linux.
 This is opposed to developers that create applications that run on mobile, tablet,
or other devices.
 This type of specialization was more ubiquitous in the early days of
programming, back before the days of mobile applications. However, they still
have a place in today’s landscape.
5. Database Development
 Not to be confused with a database administrator, who typically works with daily
database upkeep and troubleshooting and implements the system.
 A database developer is responsible for building the database, modifying
and designing existing or new programs, and ensuring that they satisfy the
requirements of the users.
 Sometimes, the roles of database administrator and developer do overlap — this
depends on the needs of the client or employer.
Challenges
Challenge 1: Project Infrastructure

Problem: An unestablished project environment is always a common challenge in
terms of its impact on project delivery. If the environment is not available, then there is
no way you can proceed with your project on time and under budget.
Solution: To ensure efficient project development, test and pre-production
environments should be made available during the development, testing, and user
acceptance testing (UAT) phases. Invest in a solid IT infrastructure upfront to create a
better software development environment.
3
Challenge 2: Design Influences

Problem: Product designs are under constant influence from stakeholders, the
development organization, and other internal and external factors. Managing these
influences is essential for maximizing the quality of systems and their related influence
on future business opportunities. The increase of easily accessible, simple applications
has resulted in user expectations growing exponentially.
Solution: A streamline design and offer a consistent experience across devices,
operating systems, and form factors.
Challenge 3: Security Infrastructure

Problem: Security breaches are on the rise; a recent study estimates that 96% of all
web applications contain at least one serious vulnerability. How do you cope with
evolving security threats? How do you keep each layer of your software or application
secure?
Solution: Security is not just the responsibility of the software engineer but also the
responsibility of all the stakeholders involved including the management, project
managers, business analysts, quality assurance managers, technical architects, and
application and developers.
 Look beyond technology to improve the security of the software

 Develop software using high-level programming languages with built-in security
features
 Require security assurance activities such as penetration testing and code review
 Perform essential core activities to produce secure applications and systems
Chellenges4:DataandSecurity
One of the most significant challenges to software development is data
privacy and security. Several data leaks and hacks take place every year. With the
pandemic, cybersecurity is becoming important - confidential data is stored on home
computers due to remote work. Software development best practices for security and
data protection are seeing rapid growth due to unknown vulnerabilities and threats.
Solution - First of all, customer information must be given priority. Companies should
tell users how they plan to use the customer data through their applications. After that,
continuous testing and monitoring of applications is essential to identify security
loopholes. Software developers must make sure that they comply with the data security
policies of the local government.
Chellenges5:TechnicalAdvancements
Last but not least, technical software engineering challenges are common
across every company. These range from selecting the right technology, integrating
third-party applications, QA & testing challenges, limited infrastructure and resources,
and others.
These are common software development challenges that are usually easily solvable -
but companies delay them until the end when they start creating problems.
Solution - New technical advancements must be embraced. If there’s a technology to
automate testing of bugs, it should be adopted to save employee time. On top of that, the
technical layout should be fixed from the beginning. The use-as-you-go model doesn’t
work while building dynamic web applications. Choose a technology stack and stick
with it till the end.
4
An Engineering Perspective
What is an engineering perspective?
A collection of short articles and opinions on a variety of subjects, though

mostly engineering, technology and business related. This is about perspective on
engineering, running a business, and happenings at Synthesis or around the world. ...
Software Engineering Definition
Software engineering is the application of various approaches and practices

for the development of computer software. Software engineering is directly related to
computer science, where engineers take systematic and disciplined methods to the
development, operation and maintenance of software.
What is a Software Engineer?
 Software engineers are the people that make the digital world tick. They’re
responsible for revolutionary social media apps, like Twitter and Instagram,
programming the future of autonomous transportation, robotics.
 The software engineering field is very broad, with engineers having various roles
and technical expertise. Everything you see on your computer isn’t just magic. It
takes a team of highly dedicated engineers, using their varying skills to bring you the
information, media or digital experience you want right away.
 What sets software engineers apart from most other professions is their flexibility
and agility. Whether it’s switching back and forth between different, highly-
complicated projects on a daily basis or keeping up with the latest industry
technologies and trends, software engineers must stay nimble to provide the best
digital experiences possible.
 Another trait most successful engineers possess is the ability to effectively

communicate. Engineers must work well with a team because projects nowadays
involve many different technologies, coding languages and specialties.
Types of Engineers
Front-End Engineer
Front-end engineers specialize in the development of customer-facing products.
These user interface (UI) engineers deal with everything from cross-browser
compatibility and fixing bug issues to incorporating design elements that provide the
smoothest user experience on applications and websites.
Back-End Engineer
Back-end engineers specialize in the logic, performance and coding of the
application that users don’t see. These engineers focus heavily on the code that is able to
flawlessly execute every action you take when using an application.
Back-end engineers rely on different databases, caches, programming languages

and Application Programming Interfaces (APIs) to make sure the back-end is free of
bugs and running smoothly.
5
Full Stack Engineer

Full stack engineers are highly sought after because they have the knowledge
and skills to handle both front- and back-end engineering tasks. Not only can these
engineers create clean, working code on the backend, they also can implement design
elements that help to create the best possible user experience.
Object Orientaion
In an object-oriented system, all data is represented as discrete objects with

which the user and other objects may interact. ... An object-oriented system
allows the user to focus completely on tasks rather than tools. Each object can have
unique values to the properties defined in the class.
The object-oriented approach, however, focuses on objects that represent
abstract or concrete things in the real world.
Object-oriented software is a practice of computer programming that has an end
result in mind. It is the idea that objects, which contain data in the form of structured
fields, are structured in procedural code, also known as methods.
Object-oriented software has the key feature of objects being able to modify or
edited by the program within the attributes in which it is found, making it
easier to change their relationship with other functions found in the
programming.
This is critical for front-end and back-end web development and is often found in
software that beginners use when first learning computer programming.
What Languages Use Object-Oriented Software?
 There are several object-oriented languages that are widely used within software
development. These include Java, C++, Python, Ruby, Perl, and PHP.
 Many of these programs, such as Python and Java, are multi-paradigm programming,
meaning they support object-oriented coding within its language while combining it
with procedural programming to build web applications and security systems.
 All of these programs are integral parts of computer programming and much of
software development relies on object-oriented software.
Object Orientation Principles
Abstraction
It is defined as hiding the complex details and presenting only with the relevant
or necessary details. Abstraction is used to manage complexity while writing programs.
Encapsulation and inheritance are used to implement abstraction while writing
programs. Abstraction represents the external behavior of the object (what the object
does) and encapsulation represents how it is implemented internally by the object.
Encapsulation
Encapsulation is the fundamental principle to achieve abstraction in object
oriented programming. Abstraction is conceptual and encapsulation is a way to
implement abstraction.
6
Encapsulation is defined as wrapping up or combining the data and code into

a single unit. In the definition data refers to variables and code refers to methods
(functions).
Every object contains private data (variables) and public methods which
allows other code to access the private data. Private methods are optional.
Data hiding or information hiding is the side effect of encapsulation. Whenever
we use encapsulation, we are implicitly hiding the data of an object which is known as
data hiding.
Encapsulation helps programmers to write code which is extensible.
Inheritance
In inheritance, classes are arranged as hierarchies. In such cases, it is better to
move all the common properties and behavior into one common class and the specific
properties and behavior into special or specific classes.
Inheritance is defined as one object derives or inherits the properties and

behavior of another object. A common properties and behavior are moved into a
common class also known as super class or base class or parent class. Specific
properties and behavior are moved into specialized classes also known as sub class or
derived class or child class.
Inheritance promotes re-usability.

Polymorphism
Polymorphism means many forms. More generally it is defined as one interface

multiple implementations. It means that based on the situation or different factors, the
same thing exhibits multiple behaviors or the same thing can be used to carry out
different tasks. Here thing is used as a general element.
Object Orientation Concepts
Structured Paradigm Vs Object Oriented Paradigm
In programming languages following structured paradigm or procedural

paradigm instructions are written in linear blocks or using functions. “Code allows
access to data”.
7
In object oriented paradigm, the program is written using objects and classes. A
problem can be solved through interactions between objects. It’s called object oriented
paradigm, “Data allows access to code”.
Difference between procedural/structured programming and object oriented
programming:
Object Oriented Paradigm

The fundamental unit in object oriented paradigm is an object.
Object
Object is a real world thing or entity that is tangible or intangible. An object
consists of properties and/or behavior. For example consider a student object whose
name is John. Student object contains properties or characteristics like name, age,
gender, date of birth etc and behavior like eat, sleep, register, write exam etc.
8
Class
It is common for most of the Java programs to have similar objects. Similar
means objects having same properties and behavior. So, a class can be defined as a mold
or template for creating objects. A class can also be defined as a collection of similar
objects.
Example:- let’s think of three student objects: John, Mary and Krishna. All of these three
students will have similar properties like name, age, gender etc and similar behavior
like register, write exam etc. These three objects can be grouped into a class
named Student. A class can be represented diagrammatically (using UML) as shown
below:
Now we can represent the class Student and the three objects John, Mary and Krishna of
the class Student as shown below:
A property is a characteristic which can be used to describe the object and will generally
be a noun. Behavior is defined as a set of operations that can be performed by the object
or on the object. Operations are generally verbs.
Object state
The set of values assigned to the properties of an object is known as the state of an
object. For example the John object there are three properties: name, age and gender.
Then, the state of John object will be John, 21 and male which are the values
of name, age and gender respectively.
9
Messages
In object oriented world objects don’t sit idle. They communicate with one other
by passing messages. A message is a request to carry out a task. A task can be anything
from displaying a message to retrieving data from database and process it.
An object can send messages to those objects only which can process the
messages. For example, an object Ken of Person class wants his dad (John) to purchase
apples for him. To carry out that task Ken sends the message getApples(10) to John.
It is the responsibility of John object to process the message getApples(10) and

give response back to Ken object. The response message is not mandatory. In the above
message getApples(10), 10 is a parameter.
A parameter is a mechanism to pass additional information along with the
message.
Advantages
 Its simplicity at the beginner level, enabling students of programming to easily
grasp the concepts.
 Modularity for objects, providing software programmers with the opportunity to
code without too much trial and error.
 And efficiency, which allows web developers who specialize in web applications
to reuse old code for new projects.
 This type of programming allows everyone to learn web development in a simple
and easy-to-understand format,
Disadvantages
 More complicated programming for back-end development.
 The programming is less efficient when not used in conjunction with procedural
programming.
 And the fact that the coding itself can be repetitive and cumbersome.
Software Development Process
6 Stages of Software Development Process
1>>Requirements Analysis and Resource Planning
The first step to any process is always planning. Being a project manager, have
done a requirement analysis of the project, and need of software engineering experts to
create a software development plan for the project.
10
Need to analyze the software, planning to develop, aligns with the business or
personal goals. This is a requirements analysis. The purpose of any software is to make
the tasks easier.
After this, allocate resources for software development process. And decide
what kind of resources will need in order to complete it.
2>>Design and Prototyping
After the analysis and planning part is over, it is time to start creating a software
architecture for the product. This architecture or design will define the complete
workflow of the software.
In terms of software, the design doesn’t only have to do about the look but also
about the overall functioning and user experience of the software.
The designers will design simple wireframes to show these interactions using
various tools like Adobe and InVision.
In this stage, check if there are any drawbacks or lack of any features. It can
easily make changes in this stage and start with development when everything is
finalized.
3>>Software Development
Development in software-process only begins are completely sure of the
requirements and onboard with the design and features. The development team starts
working on the development of a program by writing the necessary code.
Now, the development is carried out in different manners based on the type of
software requirements.
This is the riskiest phase of the software development process. However, being
an experienced software development company, easily understand the requirements
and develop a product up to the expectations.
4>>Testing
This is actually a continuous process of software development, and testing is

performed alongside developmnt. Testing is done to check the functionality, usability,
and stability of the product under the rapid development process.
We have a team of quality assurance testers or QA testers. This team tests every
piece of code created by the software development team. This is done both manually as
well with automated tools to find out if there are any bugs or glitches.
Later, bugs are fixed by changing or adding new code to the original code.Then
final product runs smoothly on the preferred devices and has all the required features
and functionalities as discussed.
5>>Deployment
This is a crucial stage in the software development life cycle. After coding and
testing are done, the next development phase is to deploy the software on the necessary
servers and devices. This is only done after approved of the product functionality and
the stability of the product is proved.
Many times, the product is given an Alpha release. A small bunch of users use the
product and give their feedback. After analyzing the feedback, modifications are made
to the software and then released as a Beta release. Now, more users have access to the
software program.
11
6>>Maintenance and Updates

As described earlier, software development is a cycle. It is an iterative process of
software development. After launching the product, the process is not complete. Need to
keep a track of software maintenance and keep upgrading it. To consistently monitor
software development and suggest changes whenever required.
This is done because technology keeps advancing and in order to keep up with
these changes, the software products are needed to be updated. As time passes, users
have different requirements that are uncovered. Further, user feedback also plays an
important role in devising future updates for any software product.
Iterative Development Process

 The iterative enhancement (IE) approach (Basili and Turner, 1975), or the iterative
development process (IDP), was defined to begin with a subset of the requirements
and develop a subset of the product that satisfies the essential needs of the users,
provides a vehicle for analysis and training for the customers, and provides a
learning experience for the developer.
 They carry many names: rapid application development, rational unified
process, total quality management, joint application development, and the
evolutionary life cycle,
 Based on the analysis of each intermediate product, the design and the requirements
are modified over a series of iterations to provide a system to the users that meets
evolving customer needs with improved design based on feedback and learning.
 The IDP model combines prototyping with the strength of the classical waterfall
model. Other methods such as domain analysis and risk analysis can also be
incorporated into the IDP model.
 The model has much in common with the spiral model, especially with regard to
prototyping and risk management. Indeed, the spiral model can be regarded as a
specific IDP model, while the term IDP is a general rubric under which various forms
of the model can exist.
 The model also provides a framework for many modern systems and software
engineering methods and techniques such as reuse, object-oriented development,
and rapid prototyping.
Implementation contains eight major steps
1. Domain analysis
2. Requirements definition
3. Software architecture
4. Risk analysis
5. Prototype
6. Test suite and environment development
7. Integration with previous iterations
8. Release of iteration
The iteration process involves the last five steps; domain analysis, requirements
definition, and software architecture are preiteration steps, which are similar to those
in the waterfall model.
12
During the five iteration steps, the following activities occur:
o Analyze or review the system requirements.

o Design or revise the solution that best satisfies the requirements.
o Identify the highest risks for the project and prioritize them. Mitigate the highest
priority risk via prototyping, leaving lower risks for subsequent iterations.
o Define and schedule or revise the next few iterations.
o Develop the iteration test suite and supporting test environment.
o Implement the portion of the design that is minimally required to satisfy the
current iteration.
o Integrate the software in test environments and perform regression testing.
o Update documents for release with the iteration.
o Release the iteration.
Advantages of the iterative development

 Iterative software development means building the product step by step, which
allows for the identification and correction of defects during the early stages, to
avoid their downward flow into further processes.
 With iterative development at the end of each stage you can get user feedback, such
as how they see the product now and what they are expecting it to look like in the
future. This allows you to make any necessary improvements and amendments.
 The iterative development approach helps to save time on documentation, which
often accompanies the waterfall workflow, and to focus more on designing the
project.
Disadvantages of the iterative development

 Although the whole iterative process is quite flexible, iteration phases are rigid and
have to be followed carefully.
 Unpredictable changes may occur during the iterative development because not all
the requirements are specified from the very beginning of the project.
Process Models
What is a software process model?
A software process model is an abstraction of the software development process.
The models specify the stages and order of a process. So, think of this as a
representation of the order of activities of the process and the sequence in which they
are performed.
A model will define the following:
 The tasks to be performed
 The input and output of each task
 The pre and post conditions for each task
 The flow and sequence of each task
There are five generic framework activities:
1.Communication:
The software development starts with the communication between customer and
developer.
2.Planning:
It consists of complete estimation, scheduling for project development and tracking.
13
3. Modeling:
Modeling consists of complete requirement analysis and the design of the
project like algorithm, flowchart etc.
The algorithm is the step-by-step solution of the problem and the flow chart
shows a complete flow diagram of a program.
4. Construction:
Construction consists of code generation and the testing part.
Coding part implements the design details using an appropriate programming
language.
Testing is to check whether the flow of coding is correct or not.
Testing also check that the program provides desired output.
5. Deployment:
Deployment step consists of delivering the product to the customer and take
feedback from them.
If the customer wants some corrections or demands for the additional
capabilities, then the change is required for improvement in the quality of the
software.
Factors in choosing a software process
Project requirements
Before you choose a model, take some time to go through the project
requirements and clarify them alongside your organization’s or team’s expectations.
Project size
Consider the size of the project you will be working on. Larger projects mean
bigger teams, so you’ll need more extensive and elaborate project management plans.
Project complexity
Complex projects may not have clear requirements. The requirements may
change often, and the cost of delay is high.
Familiarity with technology
This involves the developers’ knowledge and experience with the project
domain, software tools, language, and methods needed for development.
Project resources
This involves the amount and availability of funds, staff, and other resources.
Software Development Life Cycle (SDLC)

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle model represents all
the methods required to make a software product transit through its life cycle stages. It
also captures the structure in which these methods are to be undertaken.
14
A life cycle model maps the various activities performed on a software product
from its inception to retirement. Different life cycle models may plan the necessary
development activities to phases in different ways.
Need of SDLC
 The development team must determine a suitable life cycle model for a particular
plan and then observe to it.
 Without using an exact life cycle model, the development of a software product
would not be in a systematic and disciplined manner. When a team is developing a
software product, there must be a clear understanding among team representative
about when and what to do.
 A software life cycle model describes entry and exit criteria for each phase. A phase
can begin only if its stage-entry criteria have been fulfilled. So without a software life
cycle model, the entry and exit criteria for a stage cannot be recognized. Without
software life cycle models, it becomes tough for software project managers to
monitor the progress of the project.
SDLC Cycle
Stage1: Planning and requirement analysis
 Requirement Analysis is the most important and necessary stage in SDLC.
 The senior members of the team perform it with inputs from all the stakeholders
and domain experts or SMEs in the industry.
 Planning for the quality assurance requirements and identifications of the risks
associated with the projects is also done at this stage.
 Business analyst and Project organizer set up a meeting with the client to gather
all the data like what the customer wants to build, who will be the end user, what
is the objective of the product. Before creating a product, a core understanding
or knowledge of the product is very necessary.
For Example, A client wants to have an application which concerns money transactions.
In this method, the requirement has to be precise like what kind of operations will be
done, how it will be done, in which currency it will be done, etc.
Once the required function is done, an analysis is complete with auditing the
feasibility of the growth of a product. In case of any ambiguity, a signal is set up for
further discussion.
Once the requirement is understood, the SRS (Software Requirement
Specification) document is created. The developers should thoroughly follow this
document and also should be reviewed by the customer for future reference.
Stage2: Defining Requirements
Once the requirement analysis is done, the next stage is to certainly represent
and document the software requirements and get them accepted from the project
stakeholders.
This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and developed
during the project life cycle.
Stage3: Designing the Software
The next phase is about to bring down all the knowledge of requirements,
analysis, and design of the software project. This phase is the product of the last two,
like inputs from the customer and requirement gathering.
15
Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is
built. The implementation of design begins concerning writing code. Developers have to
follow the coding guidelines described by their management and programming tools
like compilers, interpreters, debuggers, etc. are used to develop and implement the
code.
Stage5: Testing
After the code is generated, it is tested against the requirements to make sure
that the products are solving the needs addressed and gathered during the
requirements stage.
During this stage, unit testing, integration testing, system testing, acceptance testing are
done.
Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is
deployed.
Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.
After the software is deployed, then its maintenance begins.
Stage7: Maintenance
Once when the client starts using the developed systems, then the real issues
come up and requirements to be solved from time to time.
This procedure where the care is taken for the developed product is known as
maintenance.
Life Cycle Models

A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle model represents
all the methods required to make a software product transit through its life cycle stages.
Introduction
 Software development life cycle (SDLC) is a series of phases that provide a common
understanding of the software building process.
 How the software will be realized and developed from the business understanding
and requirements elicitation phase to convert these business ideas and
requirements into functions and features until its usage and operation to achieve the
business needs.
 The good software engineer should have enough knowledge on how to choose the
SDLC model based on the project context and the business requirements.
 Therefore, it may be required to choose the right SDLC model according to the
specific concerns and requirements of the project to ensure its success.
Waterfall Model
The Waterfall Model is a linear sequential flow.
In which progress is seen as flowing steadily downwards (like a waterfall)
through the phases of software implementation.
This means that any phase in the development process begins only if the
previous phase is complete.
The waterfall approach does not define the process to go back to the previous
phase to handle changes in requirement.
16
The waterfall approach is the earliest approach and most widely known that was
used for software development.
The usage
Projects which not focus on changing the requirements, for example, projects
initiated from a request for proposals (RFPs), the customer has a very clear documented
requirements
Advantage Disadvantage
1. Easy to explain to the users. 1. Assumes that the requirements of a
2. Structures approach. system can be frozen.
3. Stages and activities are well defined. 2. Very difficult to go back to any stage
4. Helps to plan and schedule the project. after it finished.
5. Verification at each stage ensures early 3. A little flexibility and adjusting scope is
detection of errors/misunderstanding. difficult and expensive.
6. Each phase has specific deliverables. 4. Costly and required more time, in
addition to the detailed plan.
RAD Model
The Rapid Application Development (RAD model) is based on iterative development

and prototyping with little planning involved.
17
It focuses on input-output source and destination of the information. It

emphasizes on delivering projects in small pieces; the larger projects are divided
into a series of smaller projects. The main features of RAD modeling are that it
focuses on the reuse of templates, tools, processes, and code.
It involves the following phases:
1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation
5. Testing and turnover
Business Modeling:
On basis of the flow of information and distribution between various

business channels, the product is designed
Data Modeling:
The information collected from business modeling is refined into a set of

data objects that are significant for the business
Process Modeling:
The data object that is declared in the data modeling phase is transformed
to achieve the information flow necessary to implement a business function
Application Generation:
Automated tools are used for the construction of the software, to convert
process and data models into prototypes
Testing and Turnover:
As prototypes are individually tested during every iteration, the overall

testing time is reduced in RAD.
1.Flexible and adaptable to 1.It can’t be used for smaller
changes projects
2. It is useful when you have to 2.Not all application is

reduce the overall project risk compatible with RAD
3.It is adaptable and flexible to 3.When technical risk is high, it is

changes not suitable
18
Spiral Model (SDM)
The spiral model is a risk driven iterative software process model. The
spiral model delivers projects in loops. Unlike other process models, its steps
aren’t activities but phases for addressing whatever problem has the greatest risk
of causing a failure.
It is combining elements of both design and prototyping-in-stages, in an effort to
combine advantages of top-down and bottom-up concepts. This model of development
combines the features of the prototyping model and the waterfall model.
The spiral model is favored for large, expensive, and complicated projects. This
model uses many of the same phases as the waterfall model, in essentially the same
order, separated by planning, risk assessment, and the building of prototypes and
simulations.
1. Address the highest-risk problem and determine the objective and alternate
solutions
2. Evaluate the alternatives and identify the risks involved and possible solutions
3. Develop a solution and verify if it’s acceptable
4. Plan for the next cycle
As develop the concept in the first few cycles, and then it evolves into an
implementation. Though this model is great for managing uncertainty, it can be difficult
to have stable documentation. The spiral model can be used for projects with unclear
needs or projects still in research and development.
The usage
It is used in the large applications and systems which built-in small phases or segments.
Advantages and Disadvantages
1. Estimates (i.e. budget, schedule, etc.) 1. High cost and time to reach the final
become more realistic as work product.
progressed because important issues 2. Needs special skills to evaluate the
are discovered earlier. risks and assumptions.
2. Early involvement of developers.
3.Highly customized limiting re-
3. Manages risks and develops the usability
system into phases.
19
V-Shaped Model
Description
It is an extension of the waterfall model, Instead of moving down in a linear way.
The process steps are bent upwards after the implementation and coding phase,
to form the typical V shape.
The major difference between the V-shaped model and waterfall model is the
early test planning in the V-shaped model.
The usage
 Software requirements clearly defined and known
 Software development technologies and tools are well-known
1. Very inflexible, like the waterfall
1. Simple and easy to use model.
2. Each phase has specific 2. Adjusting scope is difficult and
deliverables. expensive.
3. Higher chance of success over the 3. The software is developed during
waterfall model due to the the implementation phase, so no
development of test plans early on early prototypes of the software are
during the life cycle. produced.
4. Works well for where requirements 4. The model doesn’t provide a clear
are easily understood. path for problems found during
5. Verification and validation of the testing phases.
product in the early stages of 5. Costly and required more time, in
product development. addition to a detailed plan
Incremental model
The incremental model is not a separate model. It is necessarily a series of
waterfall cycles. The requirements are divided into groups at the start of the project. For
each group, the SDLC model is followed to develop software.
The SDLC process is repeated, with each release adding more functionality until
all requirements are met. In this method, each cycle act as the maintenance phase for
the previous software release. Modification to the incremental model allows
development cycles to overlap. After that subsequent cycle may begin before the
previous cycle is complete.
20
Incremental Model is a process of software development where requirements

divided into multiple standalone modules of the software development cycle. In this
model, each module goes through the requirements, design, implementation and testing
phases. Every subsequent release of the module adds function to the previous release.
The process continues until the complete system achieved.
1. Requirement analysis:
In the first phase of the incremental model, the product analysis expertise
identifies the requirements. And the system functional requirements are understood by
the requirement analysis team. To develop the software under the incremental model,
this phase performs a crucial role.
2. Design & Development:
In this phase of the Incremental model of SDLC, the design of the system
functionality and the development method are finished with success. When software
develops new practicality, the incremental model uses style and development phase.
3. Testing:
In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various
methods are used to test the behavior of each task.
4. Implementation:
Implementation phase enables the coding phase of the development system. It

involves the final coding that design in the designing and development phase and tests
the functionality in the testing phase. After completion of this phase, the number of the
product working is enhanced and upgraded up to the final system product.
When we use the Incremental Model?
o When the requirements are superior.
o A project has a lengthy development schedule.
o When Software team are not very well skilled or trained.
o Errors are easy to be recognized. o Need for good planning

o Easier to test and debug o Total Cost is high.
o More flexible. o Well defined module
o Simple to manage risk because it handled interfaces are needed.
during its iteration.
21
Agile Model
Agile methodology is a practice which promotes continues interaction of
development and testing during the SDLC process of any project. In the Agile method,
the entire project is divided into small incremental builds. All of these builds are
provided in iterations, and each iteration lasts from one to three weeks.
Any agile software phase is characterized in a manner that addresses several key
assumptions about the bulk of software projects:
1. It is difficult to think in advance which software requirements will persist and
which will change. It is equally difficult to predict how user priorities will change
as the project proceeds.
2. For many types of software, design and development are interleaved. That is,
both activities should be performed in tandem so that design models are proven
as they are created. It is difficult to think about how much design is necessary
before construction is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a
planning point of view) as we might like.
It is based on iterative and incremental development, where requirements and
solutions evolve through collaboration between cross-functional teams.
1. Decrease the time required to avail 1. Scalability.
some system features. 2. The ability and collaboration of the
2. Face to face communication and customer to express user needs.
continuous inputs from customer 3. Documentation is done at later stages.
representative leaves no space for 4. Reduce the usability of components.
guesswork. Needs special skills for the team.
3. The end result is the high-quality
software in the least possible time
duration and satisfied customer.
Iterative Model
It is a particular implementation of a software development life cycle that
focuses on an initial, simplified implementation, which then progressively gains more
complexity and a broader feature set until the final system is complete. In short,
iterative development is a way of breaking down the software development of a large
application into smaller pieces.
22
In this Model, you can start with some of the software specifications and develop
the first version of the software. After the first version if there is a need to change the
software, then a new version of the software is created with a new iteration. Every
release of the Iterative Model finishes in an exact and fixed period that is called
iteration.
The Iterative Model allows the accessing earlier phases, in which the variations
made respectively. The final output of the project renewed at the end of the Software
Development Life Cycle (SDLC) process.
1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and check by an analyst whether requirements will fulfil or not. Analyst
checks that need will achieve within budget or not. After all of this, the software team
skips to the next phase.
2. Design: In the design phase, team design the software by the different diagrams like
Data Flow diagram, activity diagram, class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are written in the coding
language and transformed into computer programmes which are called Software.
4. Testing: After completing the coding phase, software testing starts using different
test methods. There are many test methods, but the most common are white box, black
box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is performed to
check the behaviour and validity of the developed product. And if there are any error
found then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the
working environment there may be some bugs, some errors or new updates are
required. Maintenance involves debugging and new addition options.
When to use the Iterative Model?
1. When requirements are defined clearly and easy to understand.
2. When the software application is large.
3. When there is a requirement of changes in future.
23
1. Testing and debugging during 1. It is not suitable for smaller
smaller iteration is easy. projects.
2. A Parallel development can plan. 2. More Resources may be required.
3. It is easily acceptable to ever- 3. Design can be changed again and
changing needs of the project. again because of imperfect
4. Risks are identified and resolved requirements.
during iteration. 4. Requirement changes can cause
5. Limited time spent on over budget.
documentation and extra time on 5. Project completion date not
designing confirmed because of changing
requirements.
Big bang model

In this model, developers do not follow any specific process. Development begins
with the necessary funds and efforts in the form of inputs. And the result may or may
not be as per the customer's requirement, because in this model, even the customer
requirements are not defined.
This model is ideal for small projects like academic projects or practical projects.
One or two developers can work together on this model.
Big bang model is focusing on all types of resources in software development and
coding, with no or very little planning. The requirements are understood and
implemented when they come.
This model works best for small projects with smaller size development team
which are working together. It is also useful for academic software development
projects. It is an ideal model where requirements are either unknown or final release
date is not given.
When to use Big Bang Model?
This model is required when this project is small like an academic project or a practical
project. This method is also used when the size of the developer team is small and when
requirements are not defined, and the release date is not confirmed or given by the
customer.
24
1. There is no planning required. 1. There are high risk and
2. Simple Model. uncertainty.
3. Few resources required. 2. Not acceptable for a large project.
4. Easy to manage. 3. If requirements are not clear that
can cause very expensive.
Unified Process
The Unified Software Development Process or Unified Process is a popular

iterative and incremental software development process framework. The best-known
and extensively documented refinement of the Unified Process is the Rational Unified
Process (RUP) Profile of a typical project showing the relative sizes of the four phases of
the Unified Process.
1. Unified Process Characteristics
Iterative and Incremental
The Unified Process is an iterative and incremental development process. The
Elaboration, Construction and Transition phases are divided into a series of timeboxed
iterations. (The Inception phase may also be divided into iterations for a large project.)
Each iteration results in an increment, which is a release of the system that contains
added or improved functionality compared with the previous release.
Although most iterations will include work in most of the process disciplines (e.g.
Requirements, Design, Implementation, Testing) the relative effort and emphasis will
change over the course of the project.
Use Case Driven
In the Unified Process, use cases are used to capture the functional requirements
and to define the contents of the iterations. Each iteration takes a set of use cases or
scenarios from requirements all the way through implementation, test and deployment.
Architecture Centric
The Unified Process insists that architecture sit at the heart of the project team's
efforts to shape the system. Since no single model is sufficient to cover all aspects of a
system, the Unified Process supports multiple architectural models and views.
One of the most important deliverables of the process is the executable
architecture baseline which is created during the Elaboration phase. This partial
implementation of the system serves and validate the architecture and act as a
foundation for remaining development.
Risk Focused
The Unified Process requires the project team to focus on addressing the most
critical risks early in the project life cycle. The deliverables of each iteration, especially
in the Elaboration phase, must be selected in order to ensure that the greatest risks are
addressed first.
25
Project Lifecycle
The Unified Process divides the project into four phases:
Inception
Elaboration
Construction
Transition
Inception Phase
Inception is the smallest phase in the project, and ideally it should be quite short.
If the Inception Phase is long then it may be an indication of excessive up-front
specification, which is contrary to the spirit of the Unified Process.
The following are typical goals for the Inception phase.
 Establish a justification or business case for the project
 Establish the project scope and boundary conditions
 Outline the use cases and key requirements that will drive the design tradeoffs
 Outline one or more candidate architectures
 Identify risks
 Prepare a preliminary project schedule and cost estimate
 The Lifecycle Objective Milestone marks the end of the Inception phase.
Elaboration Phase
During the Elaboration phase the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration are to
address known risk factors and to establish and validate the system architecture.
Common processes undertaken in this phase include the creation of use case diagrams,
conceptual diagrams (class diagrams with only basic notation) and package diagrams
(architectural diagrams).
The architecture is validated primarily through the implementation of an
Executable Architecture Baseline. This is a partial implementation of the system which
includes the core, most architecturally significant, components. It is built in a series of
small, timeboxed iterations.
26
By the end of the Elaboration phase the system architecture must have
stabilized and the executable architecture baseline must demonstrate that the
architecture will support the key system functionality and exhibit the right behavior in
terms of performance, scalability and cost.
Construction Phase
Construction is the largest phase in the project. In this phase the remainder of
the system is built on the foundation laid in Elaboration. System features are
implemented in a series of short, timeboxed iterations.
Each iteration results in an executable release of the software. It is customary to
write full text use cases during the construction phase and each one becomes the start
of a new iteration.
Common UML (Unified Modelling Language) diagrams used during this phase
include Activity, Sequence, Collaboration State (Transition) and Interaction Overview
diagrams.
Transition Phase
The final project phase is Transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may result in
further refinements to be incorporated over the course of several Transition phase
iterations. The Transition phase also includes system conversions and user training. The
Product Release Milestone marks the end of the Transition phase.
Iterative and Incremental development (IID)
Iterative and incremental development
(IID) is a model that is an incremental model that is developed in multiple
cycles of iterations. Project is started with a comparatively small task or component
and increments are made in each cycle of the iterations until desired product is
reached.
During this process, developers have advantage of evaluating and testing
components at each stage and gaining information that would be useful at end stages
as well. This knowledge is used to also improve design of final product.
Iteration includes update and execution of cycles are to be basic, direct, and
particular, supporting overhaul at that stage or as an errand added to task control list.
Degree of configuration detail isn’t directed by iterative methodology.
Phases in IID:
As development is incremental and iterative, different functions are applied in
different phases. According to prerequisites of organization, at each phase,
functionalities are implemented.
There are four phases in IID :
 Inception
In this phase reorganization of project scope, prerequisites, and risks at an elevated
level yet in enough detail that work can be assessed are done.
 Elaboration
In this phase, conveying a working structure that mitigates top dangers and
satisfies non-functional necessities is done.
 Construction
In this phase, functionalities are incremented gradually with codes for
functional requirements. Whole architecture is built in this phase.
 Transition
In this phase, project is transitioned into production and then deployment.
27
Advantages of IID :
 Each delivery is an item increment, with goal that client will have a working item
within reach constantly.
 You can create organized prerequisites first.
 If the requirements are changed midway, new requirements can be augmented
without any issue.
 Clients get significant functionality faster.
 Client can give input to every item increment, accordingly maintaining a
strategic distance from differences toward finish of improvement.
 Brings down introductory delivery cost.
 Initial item delivery is quicker.
Disadvantages of IID :
 Requires the early meaning of a total and completely functional framework to
permit the meaning of additions.
 Absolute expense of the total framework isn’t lower.
 Requires an effective plan to guarantee incorporation of the necessary
functionalities and arrangement for changes later.
 Requires successful arranging of cycles.
 Very characterized module interfaces are needed, as some are made some time
before others are created.
Where and when to use IID :
 There is a requirement to get fundamental functionality conveyed quick.
 There is new advancement in technology to implement a project.
 Prerequisites are organized.
 Vast majority of requirements are known in advance however are required to
advance after some time.
 Domain is new to working group.
Agile Process
"Agile process model" refers to a software development approach based on
iterative development. ... Each iteration involves a team working through a full
software development life cycle including planning, requirements analysis, design,
coding, and testing before a working product is demonstrated to the client.
The Agile methodology is a way to manage a project by breaking it up into
several phases.
It involves constant collaboration with stakeholders and continuous
improvement at every stage. Once the work begins, teams cycle through a process of
planning, executing, and evaluating.
Agile principles
 The highest priority of this process is to satisfy the customer.
 Acceptance of changing requirement even late in development.
 Frequently deliver working software in small time span.
 Throughout the project business people and developers work together on daily basis.
 Projects are created around motivated people if they are given the proper
environment and support.
 Face to face interaction is the most efficient method of moving information in the
development team.
28
 Primary measure of progress is working software.

 Agile process helps in sustainable development.
 Continuous attention to technical excellence and good design increases agility.
 From self organizing teams the best architecture, design and requirements are
emerged.
 Simplicity is necessary in development.
Phases of Agile Model:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback
1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed
to build the project. Based on this information, it can evaluate technical and
economic feasibility.
2. Design the requirements: identified the project, work with stakeholders to
define requirements. And use the user flow diagram or the high-level UML
diagram to show the work of new features and show how it will apply to
your existing system.
3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to
deploy a working product. The product will undergo various stages of
improvement, so it includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.
Agile Testing Methods:
o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)
Scrum -
SCRUM is an agile development process focused primarily on ways to manage tasks in
team-based development conditions.
o Scrum Master: The scrum can set up the master team, arrange the meeting
and remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the
delay and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete
the sprint or cycle.
29
eXtreme Programming(XP) -
This type of methodology is used when customers are constantly changing
demands or requirements, or when they are not sure about the system's performance.
Crystal -
1. Chartering: Multi activities are involved in this phase such as making a
development team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment,
post-deployment.
Dynamic Software Development Method(DSDM) -
DSDM is a rapid application development strategy for software development and
gives an agile project distribution structure.
The essential features of DSDM are that users must be actively connected, and teams
have been given the right to make decisions. The techniques used in DSDM are:
1. Time Boxing
2. MoSCoW Rules
3. Prototyping
The DSDM project contains seven stages:
1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project
Feature Driven Development(FDD) -
This method focuses on "Designing and Building" features. In contrast to other
smart methods, FDD describes the small steps of the work that should be obtained
separately per function.
Lean Software Development -
Lean software development methodology follows the principle "just in time
production.
" The lean method indicates the increasing speed of software development and
reducing costs.
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole
When to use the Agile Model?
o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.
30
UNIT - II
MODELLING OO SYSTEMS
OBJECT ORIENTED ANALYSIS (OOA/COAD-YOURDON)
31
32
33
34
35
36
Yourdon and Coad Diagram

As defined by Coad and Yourdon, an object is an ``abstraction'' of something in the
problem domain, reflecting capabilities of a system to keep information about it,
interact with it, or both; and, an ``encapsulation'' of attribute values and their exclusive
services.
37
The vector stencils library Yourdon and Coad Notation from the solution OOAD contains
specific symbols of the Yourdon and Coad notation such as data store symbol, data
process symbol, loop symbol for ConceptDraw PRO diagramming and vector drawing
software.
EXAPLE: A Coad and Yourdon object model for the banking system
OBJECT ORIENTED DESIGN (OOD/BOOCH)

Object Oriented Design (OOD):
 An analysis model created using object oriented analysis is transformed by object
oriented design into a design model that works as a plan for software creation.
 OOD results in a design having several different levels of modularity i.e., The major
system components are partitioned into subsystems (a system level “modular”), and
data their manipulation operations are encapsulated into objects (a modular form
that is the building block of an OO system.).
 In addition, OOD must specify some data organization of attributes and a procedural
description of each operation.
38
1. The Subsystem Layer:

It represents the subsystem that enables software to achieve user
requirements and implement technical frameworks that meet user needs.
2. The Class And Object Layer:
It represents the class hierarchies that enable the system to develop using
generalization and specialization. This layer also represents each object.
3. The Message Layer:
It represents the design details that enable each object to communicate
with its partners. It establishes internal and external interfaces for the system.
4. The Responsibilities Layer:
It represents the data structure and algorithmic design for all the
attributes and operations for each object.
The different terms related to object design are:
1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every entity
has some attributes associated with it and has some methods to perform on the
attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other
action needed to perform the function. Messages are often implemented as
procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data
and operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and methods
from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate superclasses.This property of OOD is called an
inheritance. This makes it easier to define a specific class and to create generalized
classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name. This is known
as polymorphism, which allows a single interface is performing functions for
different types. Depending upon how the service is invoked, the respective portion
of the code gets executed.
39
Booch OOD Diagram
The vector stencils library Booch OOD from the solution Software Engineering contains
specific symbols of the Booch method such as class symbols, association symbols,
aggregation symbols.
Examples for OOSE Method
HIERARCHICAL OBJECT ORIENTED DESIGN (HOOD)
40
41
OBJECT MODELING TECHNIQUE (OMT)

Software Engineering | Object Modeling Technique (OMT)
Object Modeling Technique (OMT) is real world based modeling approach
for software modeling and designing. It was developed basically as a method to
develop object-oriented systems and to support object-oriented programming. It
describes the static structure of the system.
42
Object Modeling Technique is easy to draw and use. It is used in many

applications like telecommunication, transportation, compilers etc.
It is also used in many real world problems. OMT is one of the most popular
object oriented development techniques used now-a-days. OMT was developed
by James Rambaugh.
 OMT is one of the precursors to the Unified Modeling Language (UML). There are
three main diagrams in OMT: object, dynamic, and functional.
 The OMT dynamic models resemble UML sequence and UML statechart diagrams.
Also the notation of classes is the same as the class symbol that is used by UML.
Figure 1. A notation of a class.
 The OMT object model illustrates the static relationship among classes
and objects in a system. This diagram is similar to the UML object and
class diagrams.
Figure 2. OMT Object Diagram.

Purpose of Object Modeling Technique:
 To test physical entity before construction of them.
 To make communication easier with the customers.
 To present information in an alternative way i.e. visualization.
 To reduce the complexity of software.
 To solve the real world problems.
Object Modeling Technique’s Models:
There are three main types of models that has been proposed by OMT:
1. ObjectModel:
Object Model encompasses the principles of abstraction, encapsulation,
modularity, hierarchy, typing, concurrency and persistence.
Object Model basically emphasizes on the object and class. Main concepts
related with Object Model are classes and their association with attributes.
Predefined relationships in object model are aggregation and
generalization (multiple inheritance).
43
2. DynamicModel:
Dynamic Model involves states, events and state diagram (transition
diagram) on the model.
Main concepts related with Dynamic Model are states, transition
between states and events to trigger the transitions. Predefined relationships in
object model are aggregation (concurrency) and generalization.
3. FunctionalModel:
Functional Model focuses on the how data is flowing, where data is
stored and different processes.
Main concepts involved in Functional Model are data, data flow, data
store, process and actors. Functional Model in OMT describes the whole processes
and actions with the help of data flow diagram (DFD).
Phases of Object Modeling Technique:
1. Analysis:
This the first phase of the object modeling technique. This phase
involves the preparation of precise and correct modelling of the real world
problems. Analysis phase starts with setting a goal i.e. finding the problem
statement. Problem statement is further divided into above discussed three models
i.e. object, dynamic and functional model.
2. SystemDesign:
This is the second phase of the object modeling technique and it
comes after the analysis phase. It determines all system architecture, concurrent
tasks and data storage. High level architecture of the system is designed during this
phase.
3. ObjectDesign:
Object design is the third phase of the object modelling technique and
after system design is over, this phase comes. Object design phase is concerned
with classification of objects into different classes and about attributes and
necessary operations needed. Different issues related with generalization and
aggregation are checked.
4. Implementation:
This is the last phase of the object modeling technique. It is all about
converting prepared design into the software. Design phase is translated into the
Implementation phase.
OMT Method
44
REQUIREMENTS ELICITATION
An Overview of Requirements Elicitation and Analysis
Requirements elicitaiton and analysis involves first collecting as many potential
requirements as possible, then refining them to form a complete, concise and consistent
set of high-quality functional and non-functional requirements, and then analyzing them
to start forming a preliminary model of the system to be developed.
Functional requirements are often modeled wih the aid of use-cases and
scenarios, while the analysis step starts to identify some of the candidate objects /
classes that will be needed in the system.
Requirements Elicitation Concepts

1 - Functional Requirements
Functional requirement describe the things that the system must DO. They can
often be derived from "stories" about how the system will be used, which may be in the
form of scenarios, use-cases, or just a simple description of operations.
2 - Nonfunctional Requirements
Nonfunctional requirements are other properties or characteristics that the
system must have, other than its basic functionality. Because non-functional
requirements are generally more difficult to identify, checklists of some kind are often
used to make sure that developers consider all possibilities and do not leave out
anything important.
For example:
o Functional
o Usability
o Reliability
o Performance
o Supportability
o Implementation requirements
o Interface requirements
o Operations requirements
o Packaging requirements
o Legal requirements
45
3 - Completeness, Consistency, Clarity, and Correctness

 The first step towards specifying requirements is to gather as many potential
requirements as possible, regardless of quality considerations.
 However before the final set of requirements can be accepted, both individual
requirements and the overall set of requirements must pass through a "quality
gateway" that only accepts high-quality requirements, and rejects others, ( or
sends them back for further review and refinement. ) For example, some of the
qualities that might be examined include:
4 - Realism, Verifiability, and Traceability

 Realistic - Is the requirement reasonably attainable?
 Verifiable / Measurable / Testable - If you cannot devise a test that will
determine whether or not a requirement has been met, then there is no point in
including the requirement. For this reason, requirements must also be specific.
Example: Bad: "The system must be easy to use". Better: "The system must be
easy enough to use that new users can successfully create and print a document
within 10 minutes of first starting the system."
 Traceable - Requirements should be traceable back to the source from which
they originated, and traceable forward to the classes and code that implements
them and to the tests that test for them. They may also include references to
external standards or other documents.
5 - Greenfield Engineering, Reengineering, and Interface Engineering
 Greenfield Engineering refers to projects that start with a fresh empty "green"
field.
 Reengineering projects involve modifying an existing system to make it better
somehow
 Interface Engineering projects do not change the underlying functionality of an
existing system, but improve its interface, either between the system and
humans or between the system and some other ( possibly third-party )
system(s).
46
Requirements Elicitation activities

1 - Identifying Actors
2 - Identifying Scenarios
 Four types of scenarios:
o As-is scenarios describe the current situation.
o Visionary scenarios describe a future system.
o Evaluation scenarios describe user tasks to be used to evaluate the
system.
o Training scenarios are used for tutorials and other training aids.
USE CASES
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.
UML & Use Cases
UML stands for Unified Modelling Language. They are diagrams to help aid the
creation, visualisation and documentation of various aspects of the software
engineering process.
For requirements, we use Use Cases. Use Cases come in pairs, so we have:
 Use Case Diagram: an overview of the system
 Use Case Description: details about each function (more later)
Actors and Use Cases
An Actor is something that performs use cases upon a system. An Actor is just an
entity, meaning it can be a Human or other artefacts that directly play an external role in
the system – as long as they either directly use the system or is used by the system.
For each Use Case we have to know entry conditions (preconditions) and Exit
conditions (post-conditions), So basically “What is true before the Use Case” and “What
is true after the Use Case”.
A use case in software engineering is a description of a system’s behavior as it responds
to a request that originates from outside of that system. In other words, a use case
describes “who” can do “what” with the system in question.
The use case technique is used to capture a system’s behavioral requirements by
detailing scenario-driven threads through the functional requirements.
47
Use Case Diagrams
This is a Use Case for a Library System.
Here we can see that the Actors of the system are the ‘Library Users’, ‘Library
Staff’ and ‘Suppliers’. And as with all Use Case Diagrams, Actors MUST be represented as
stick people.
Each class of interaction for the system is represented as a named eclipse, all
placed inside a box that is also named. This name is the name for the who system, eg
“Library System”.
What this diagram shows is that a Library user (a member of the public) can
search for articles, and then print them off using the system.
A member of the Library Staff can see Catalogue services, such as where they get
their books from and what they have in stock – on top of this, both Library Users and
Staff have user administration privileges.
The final actor – the Suppler, can only interact with the Catalogue Service, as they
do not have user administration privileges since they only supply the books to the
required Library.
Use Case Description
A Use Case description is a detailed description of for each of the classes of interaction
within a given Use Case Diagram:
Use Case Name Searching for an Article

Participating Library User
Actors
Flow of Events 1. User enters search terms
2. System searches’ articles from file
3. System displays all articles matching
terms
48
4. User searches for article from given list

and clicks on the one they need
5. System displays that article to the user
Alternative Flows 2.a System has no articles to search
2.b System informs user and exits
3.a System finds no articles matching users
terms
3.b System informs user and exits
4.a User can’t find article in the list
4.b User exits and tries more search terms
Entry Conditions User has correct user authentication and a
valid search term
Exit Conditions User finds correct article, or user exits
searching system due to article not being
found
SRS DOCUMENT
Software Requirement Specifications
 The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities
and is constructing when entire requirements are elicited and analyzed.
 SRS is a formal report, which acts as a representation of software that enables the
customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the
system requirements.
 The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It serves
several goals depending on who is writing it.
 First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various
situations and establish different purposes for the document altogether.
 The first case, SRS, is used to define the needs and expectation of the users. The
second case, SRS, is written for various purposes and serves as a contract document
between customer and developer.
Characteristics of good SRS

1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
(1). All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of
input data in all available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
49
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:
(1). The specified characteristics of real-world objects may conflicts. For
example,
(i) The format of an output report may be described in one requirement as tabular but
in another as textual.
(ii) One condition may state that all lights shall be green while another states that all
lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified
actions. For example,
(i) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.
(ii) One condition may state that "A" must always follow "B," while other requires that
"A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user input may be
called a "prompt" in one requirement's and a "cue" in another. The use of standard
terminology and descriptions promotes consistency.
4. Unambiguousness:
SRS is unambiguous when every fixed requirement has only one interpretation.
This suggests that each element is uniquely interpreted. In case there is a method used
with multiple definitions, the requirements report should determine the implications in
the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability:
The SRS is ranked for importance and stability if each requirement in it has an
identifier to indicate either the significance or stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable. Each
element should be identified to make these differences clear and explicit.
Another way to rank requirements is to distinguish classes of items as essential,
conditional, and optional.
6. Modifiability:
SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system to some extent. Modifications should be perfectly indexed
and cross-referenced.
7. Verifiability:
SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability:
The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.
There are two types of Traceability:
i. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
50
ii. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.
The forward traceability of the SRS is especially crucial when the software product
enters the operation and maintenance phase. As code and design document is modified,
it is necessary to be able to ascertain the complete set of requirements that may be
concerned by those modifications.
9. Design Independence:
There should be an option to select from multiple design alternatives for the
final system. More specifically, the SRS should not contain any implementation details.
10. Testability:
An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
11. Understandable by the customer:
An end user may be an expert in his/her explicit domain but might not be
trained in computer science. Hence, the purpose of formal notations and symbols should
be avoided too as much extent as possible. The language should be kept simple and
clear.
12. The right level of abstraction:
If the SRS is written for the requirements stage, the details should be explained
explicitly. Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of
abstraction modifies according to the objective of the SRS.
OOA
In the system analysis or object-oriented analysis phase of software
development, the system requirements are determined, the classes are identified and
the relationships among classes are identified.
The three analysis techniques that are used in conjunction with each other for
object-oriented analysis are object modelling, dynamic modelling, and functional
modelling.
Object Modelling
Object modelling develops the static structure of the software system in terms of
objects. It identifies the objects, the classes into which the objects can be grouped into
and the relationships between the objects. It also identifies the main attributes and
operations that characterize each class.
The process of object modelling can be visualized in the following steps −
 Identify objects and group into classes
 Identify the relationships among classes
 Create user object model diagram
 Define user object attributes
 Define the operations that should be performed on the classes
 Review glossary
Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to
time and external changes needs to be examined. This is the purpose of dynamic
modelling.
Dynamic Modelling can be defined as “a way of describing how an individual object
responds to events, either internal events triggered by other objects, or external events
triggered by the outside world”.
51
The process of dynamic modelling can be visualized in the following steps −

 Identify states of each object
 Identify events and analyze the applicability of actions
 Construct dynamic model diagram, comprising of state transition diagrams
 Express each state in terms of object attributes
 Validate the state–transition diagrams drawn
Functional Modelling
Functional Modelling is the final component of object-oriented analysis. The
functional model shows the processes that are performed within an object and how the
data changes as it moves between methods. It specifies the meaning of the operations of
object modelling and the actions of dynamic modelling. The functional model
corresponds to the data flow diagram of traditional structured analysis.
The process of functional modelling can be visualized in the following steps −
 Identify all the inputs and outputs
 Construct data flow diagrams showing functional dependencies
 State the purpose of each function
 Identify constraints
 Specify optimization criteria
IDENTIFICATION OF CLASSES AND RELATIONSHIPS

UML Class Diagram Relationships Explained with Examples
What are the Class Diagrams?
Class diagrams are the main building block in object-oriented modeling. They are
used to show the different objects in a system, their attributes, their operations and
the relationships among them.
Simple class diagram with attributes and operations

In the example, a class called “loan account” is depicted. Classes in class diagrams are
represented by boxes that are partitioned into three:
1. The top partition contains the name of the class.
2. The middle part contains the class’s attributes.
3. The bottom partition shows the possible operations that are associated with the
class.
The example shows how a class can encapsulate all the relevant data of a particular
object in a very systematic and clear way. A class diagram is a collection of classes
similar to the one above.
Relationships in Class Diagrams

Classes are interrelated to each other in specific ways. In particular, relationships
in class diagrams include different types of logical connections. The following are such
types of logical connections that are possible in UML:
52
 Association
 Directed Association
 Reflexive Association
 Multiplicity
 Aggregation
 Composition
 Inheritance/Generalization
 Realization
Association
Association
Is a broad term that encompasses just about any logical connection or relationship
between classes. For example, passenger and airline may be linked as above:
Directed Association
Directed Association
Refers to a directional relationship represented by a line with an arrowhead. The
arrowhead depicts a container-contained directional flow.
Reflexive Association
Reflexive Association
This occurs when a class may have multiple functions or responsibilities. For example, a
staff member working in an airport may be a pilot, aviation engineer, a ticket
dispatcher, a guard, or a maintenance crew member. If the maintenance crew member
is managed by the aviation engineer there could be a managed by relationship in two
instances of the same class.
Multiplicity
Multiplicity
Is the active logical association when the cardinality of a class in relation to another is
being depicted. For example, one fleet may include multiple airplanes, while one
commercial airplane may contain zero to many passengers. The notation 0..* in the
diagram means “zero to many”.
53
Aggregation
Aggregation
Refers to the formation of a particular class as a result of one class being aggregated or
built as a collection. For example, the class “library” is made up of one or more books,
among other materials. In aggregation, the contained classes are not strongly dependent
on the lifecycle of the container. To show aggregation in a diagram, draw a line from the
parent class to the child class with a diamond shape near the parent class.
Composition
Composition
The composition relationship is very similar to the aggregation relationship. with the
only difference being its key purpose of emphasizing the dependence of the contained
class to the life cycle of the container class. That is, the contained class will be
obliterated when the container class is destroyed.
For example, a shoulder bag’s side pocket will also cease to exist once the
shoulder bag is destroyed.
To show a composition relationship in a UML diagram, use a directional line connecting
the two classes, with a filled diamond shape adjacent to the container class and the
directional arrow to the contained class.
Inheritance / Generalization
Inheritance
Refers to a type of relationship wherein one associated class is a child of another by
virtue of assuming the same functionalities of the parent class. In other words, the child
class is a specific type of the parent class. To show inheritance in a UML diagram, a solid
line from the child class to the parent class is drawn using an unfilled arrowhead.
Realization
Realization
54
Denotes the implementation of the functionality defined in one class by another class.
To show the relationship in UML, a broken line with an unfilled solid arrowhead is
drawn from the class that defines the functionality of the class that implements the
function. In the example, the printing preferences that are set using the printer setup
interface are being implemented by the printer.
IDENTIFYING STATE AND BEHAVIOR
 Object oriented language allows us to decompose a problem /program into a
number of entities called Objects .
 The Data of an object can be accessed only by the method associated with the object .
Therefore we can say that : OBJECT/ CLASSES = DATA + METHODS .
 Real-world objects share two characteristics: They all have state and behavior. Dogs
have state (name, color, breed, hungry) and behavior (barking, fetching, wagging
tail).Identifying the state and behavior for real-world objects is a great way to begin
thinking in terms of object-oriented programming.
 Software objects are conceptually similar to real-world objects: they too consist of
state and related behavior. An object stores its state in fields (variables in some
programming languages) and exposes its behavior through methods (functions in
some programming languages). Methods operate on an object’s internal state and
serve as the primary mechanism for object-to-object communication.
 Hiding internal state and requiring all interaction to be performed through an
object’s methods is known as data encapsulation — a fundamental principle of
object-oriented programming.
 Data structures are designed such that they characterize the object.
 Methods that operate on the data of an object are tied together in the data structure.
 Objects may communicate with each other through methods.
 New data and methods can be easily added whenever necessary.
INTERACTION DIAGRAMS
What is Interaction Diagram?
Interaction Diagram are used in UML to establish communication
between objects. It does not manipulate the data associated with the particular
communication path. Interaction diagrams mostly focus on message passing and how
these messages make up one functionality of a system. Interaction diagrams are
designed to display how the objects will realize the particular requirements of a system.
The critical component in an interaction diagram is lifeline and messages.
55
Various UML elements typically own interaction diagrams. The details of

interaction can be shown using several notations such as sequence diagram, timing
diagram, communication/collaboration diagram. Interaction diagrams capture the
dynamic behavior of any system.
Notation of an Interaction Diagram

In UML, the interaction diagrams are used for the following purposes:
 Interaction diagrams are used to observe the dynamic behavior of a system.

 Interaction diagram visualizes the communication and sequence of message
passing in the system.
 Interaction Modelling diagram represents the structural aspects of various
objects in the system.
 Interaction diagram represents the ordered sequence of interactions within a
system.
 Interaction diagram provides the means of visualizing the real time data via
UML.
 UML Interaction Diagrams can be used to explain the architecture of an object-
oriented or a distributed system.
Important terminology
An interaction diagram contains lifelines, messages, operators, state invariants and
constraints.
Lifeline
A lifeline represents a single participant in an interaction. It describes how an instance
of a specific classifier participates in the interaction.
A lifeline represents a role that an instance of the classifier may play in the interaction.
Following are various attributes of a lifeline,
1. Name
It is used to refer the lifeline within a specific interaction.
A name of a lifeline is optional.
2. Type
It is the name of a classifier of which the lifeline represents an instance.
3. Selector
It is a Boolean condition which is used to select a particular instance that
satisfies the requirement.
Selector attribute is also optional.
56
Messages
A message is a specific type of communication between two lifelines in an interaction. A
message involves following activities,
1. A call message which is used to call an operation.
2. A message to create an instance.
3. A message to destroy an instance.
4. For sending a signal.
When a lifeline receives a call message, it acts as a request to invoke an operation that
has a similar signature as specified in the message. When a lifeline is executing a
message, it has a focus of control. As the interaction progresses over time, the focus of
control moves between various lifelines. This movement is called a flow of control.
Following are the messages used in a System Interaction Diagram:
Message Name Meaning

Synchronous The sender of a message keeps waiting for the
message receiver to return control from the message execution.
The sender does not wait for a return from the
Asynchronous
receiver; instead, it continues the execution of a next
message
message.
The receiver of an earlier message returns the focus of
Return message
control to the sender.
Object creation The sender creates an instance of a classifier.
Object
The sender destroys the created instance.
destruction
The sender of the message is outside the scope of
Found message
interaction.
The message never reaches the destination, and it is
Lost message
lost in the interaction.
State invariants and constraints
When an instance or a lifeline receives a message, it can cause it to change the
state. A state is a condition or a situation during a lifetime of an object at which it
satisfies some constraint, performs some operations, and waits for some event.
In interaction diagram, not all messages cause to change the state of an instance.
Some messages do not have the values of some attributes. It has no side effects on the
state of an object.
Operator
An operator specifies an operation on how the operands are going to be
executed. The operators in UML supports operations on data in the form of branching as
well as an iteration. Various operators can be used to ensure the use of iteration and
branching in the UML model. The opt and alt operators are used for branching
operations.
The loop operator is used to ensure the iteration operations in which a condition
is executed repeatedly until the satisfying result is produced. Break operator is used
inside the loop or iteration operations.
57
Following are the operators used in an interaction diagram:
Operator Name Meaning

An operand is executed if the condition is true.
Opt Option
e.g., If else
The operand, whose condition is true, is executed.
Alt Alternative
e.g., switch
It is used to loop an instruction for a specified
Loop Loop
period.
It breaks the loop if a condition is true or false, and
Break Break
the next instruction is executed.
Ref Reference It is used to refer to another interaction.
Par Parallel All operands are executed in parallel.
Iteration
In an interaction diagram, we can also show iteration using an iteration expression. An
iteration expression consists of an iteration specifier and an optional iteration clause.
There is no pre-specified syntax for UML iteration.
In iteration to show that messages are being sent in parallel, parallel iteration specifier
is used. A parallel iteration specifier is denoted by *//. Iteration in UML is achieved by
using the loop operator.
Branching
In an interaction diagram, we can represent branching by adding guard
conditions to the messages. Guard conditions are used to check if a message can be sent
forward or not. A message is sent forward only when its guard condition is true. A
message can have multiple guard conditions, or multiple messages can have the same
guard condition. Branching in UML is achieved with the help of alt and opt, operators.
SEQUENCE DIAGRAM
Sequence Diagram
A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place. We can also use
the terms event diagrams or event scenarios to refer to a sequence diagram. Sequence
diagrams describe how and in what order the objects in a system function. These
diagrams are widely used by businessmen and software developers to document and
understand requirements for new and existing systems.
Sequence Diagram Notations –
1. Actors – An actor in a UML diagram represents a type of role where it interacts
with the system and its objects. It is important to note here that an actor is always
outside the scope of the system we aim to model using the UML diagram.
Figure – notation symbol for actor
58
We use actors to depict various roles including human users and other external
subjects. We represent an actor in a UML diagram using a stick person notation. We
can have multiple actors in a sequence diagram.
Lifelines – A lifeline is a named element which depicts an individual participant in a
sequence diagram. So basically each instance in a sequence diagram is represented by
a lifeline. Lifeline elements are located at the top in a sequence diagram. The standard
in UML for naming a lifeline follows the following format – Instance Name : Class
Name
Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head is
located on top of a vertical dashed line (referred to as the stem) as shown above. If
we want to model an unnamed instance, we follow the same pattern except now the
portion of lifeline’s name is left blank.
2. Messages – Communication between objects is depicted using messages. The
messages appear in a sequential order on the lifeline. We represent messages using
arrows. Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories :
 Synchronous messages – A synchronous message waits for a reply before the

interaction can move forward. The sender waits until the receiver has completed
the processing of the message. The caller continues only when it knows that the
receiver has processed the previous message i.e. it receives a reply message. A
large number of calls in object oriented programming are synchronous. We use a
solid arrow head to represent a synchronous message.
59
 Asynchronous Messages – An asynchronous message does not wait for a reply

from the receiver. The interaction moves forward irrespective of the receiver
processing the previous message or not. We use a lined arrow head to represent
an asynchronous message.
 Create message – We use a Create message to instantiate a new object in the

sequence diagram. There are situations when a particular message call requires
the creation of an object. It is represented with a dotted arrow and create word
labelled on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would
require a new object of Order class to be created.
Figure – a situation where create message is used

 Delete Message – We use a Delete Message to delete an object. When an object
is deallocated memory or is destroyed within the system we use the Delete
Message symbol. It destroys the occurrence of the object in the system.It is
represented by an arrow terminating with a x.
For example – In the scenario below when the order is received by the user, the
object of order class can be destroyed.
60
Figure – a scenario where delete message is used

 Self Message – Certain scenarios might arise where the object needs to send a
message to itself. Such messages are called Self Messages and are represented
with a U shaped arrow.
Figure – self message

For example – Consider a scenario where the device wants to access its webcam. Such
a scenario is represented using a self message.
Figure – a scenario where a self message is used

 Reply Message – Reply messages are used to show the message being sent from
the receiver to the sender. We represent a return/reply message using an open
arrowhead with a dotted line. The interaction moves forward only when a reply
message is sent by the receiver.
61
Figure – reply message

For example – Consider the scenario where the device requests a photo from the
user. Here the message which shows the photo being sent is a reply message.
Figure – a scenario where a reply message is used

 Found Message – A Found message is used to represent a scenario where an
unknown source sends the message. It is represented using an arrow directed
towards a lifeline from an end point. For example: Consider the scenario of a
hardware failure.
Figure – found message

It can be due to multiple reasons and we are not certain as to what caused the
hardware failure.
62
Figure – a scenario where found message is used

 Lost Message – A Lost message is used to represent a scenario where the
recipient is not known to the system. It is represented using an arrow directed
towards an end point from a lifeline. For example: Consider a scenario where a
warning is generated.
Figure – lost message

The warning might be generated for the user or other software/object that the
lifeline is interracting with. Since the destination is not known before hand, we
use the Lost Message symbol.
Figure – a scenario where lost message is used

3. Guards – To model conditions we use guards in UML. They are used when we need
to restrict the flow of messages on the pretext of a condition being met. Guards play
an important role in letting software developers know the constraints attached to a
system or a particular process.
63
For example: In order to be able to withdraw cash, having a balance greater than
zero is a condition that must be met as shown below.
Figure – sequence diagram using a guard

A sequence diagram for an emotion based music player –
Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
 Visualise how messages and tasks move between objects or components in a
system.
Benefits of a Sequence Diagram
 Sequence diagrams are used to explore any real application or a system.
 Sequence diagrams are used to represent message flow from one object to
another object.
 Sequence diagrams are easier to maintain.
 Sequence diagrams are easier to generate.
 Sequence diagrams can be easily updated according to the changes within a
system.
 Sequence diagram allows reverse as well as forward engineering.
64
Drawbacks of a sequence diagram
 Sequence diagrams can become complex when too many lifelines are involved in
the system.
 If the order of message sequence is changed, then incorrect results are produced.
 Each sequence needs to be represented using different message notation, which
can be a little complex.
 The type of message decides the type of sequence inside the diagram.
COLLABORATION DIAGRAMS
A collaboration diagram, also known as a communication diagram, is an
illustration of the relationships and interactions among software objects in the
Unified Modeling Language (UML). These diagrams can be used to portray the dynamic
behavior of a particular use case and define the role of each object.
Collaboration diagrams are created by first identifying the structural elements
required to carry out the functionality of an interaction. A model is then built using the
relationships between those elements. Several vendors offer software for creating and
editing collaboration diagrams.
Notations of a collaboration diagram
A collaboration diagram resembles a flowchart that portrays the roles,
functionality and behavior of individual objects as well as the overall operation of the
system in real time. The four major components of a collaboration diagram are:
1. Objects- Objects are shown as rectangles with naming labels inside. The naming label
follows the convention of object name: class name. If an object has a property or state
that specifically influences the collaboration, this should also be noted.
2. Actors- Actors are instances that invoke the interaction in the diagram. Each actor
has a name and a role, with one actor initiating the entire use case.
3. Links- Links connect objects with actors and are depicted using a solid line between
two elements. Each link is an instance where messages can be sent.
4. messages- Messages between objects are shown as a labeled arrow placed near a
link. These messages are communications between objects that convey information
about the activity and can include the sequence number.
65
When to use a collaboration diagram

Collaboration diagrams should be used when the relationships among objects
are crucial to display. A few examples of instances where collaboration diagrams might
be helpful include:
 Modeling collaborations, mechanisms or the structural organization within a system
design.
 Providing an overview of collaborating objects within an object-oriented system.
 Exhibiting many alternative scenarios for the same use case.
 Demonstrating forward and reverse engineering.
 Capturing the passage of information between objects.
 Visualizing the complex logic behind an operation.
Benefits of Collaboration Diagram
 It is also called as a communication diagram.
 It emphasizes the structural aspects of an interaction diagram – how lifeline
connects.
 Its syntax is similar to that of sequence diagram except that lifeline don’t have
tails.
 Messages passed over sequencing is indicated by numbering each message
hierarchically.
 Sequence diagrams can be easily converted into a collaboration diagram as
collaboration diagrams are not very expressive.
 While modeling collaboration diagrams w.r.t sequence diagrams, some
information may be lost.
Drawbacks of a Collaboration Diagram
 Collaboration diagrams can become complex when too many objects are present
within the system.
 It is hard to explore each object inside the system.
 Collaboration diagrams are time consuming.
 The object is destroyed after the termination of a program.
UNIFIED MODELING LAGUAGE AND TOOLS

Unified Modeling Language (UML) is a general purpose modelling language.
The main aim of UML is to define a standard way to visualize the way a system has
been designed. It is quite similar to blueprints used in other fields of engineering.
UML is not a programming language, it is rather a visual language. We use
UML diagrams to portray the behavior and structure of a system. UML helps
software engineers, businessmen and system architects with modelling, design and
analysis. The Object Management Group (OMG) adopted Unified Modelling Language
as a standard in 1997.
UML is linked with object oriented design and analysis. UML makes the use of
elements and forms associations between them to form diagrams. Diagrams in UML
can be broadly classified as:
1. Structural Diagrams – Capture static aspects or structure of a system. Structural
Diagrams include: Component Diagrams, Object Diagrams, Class Diagrams and
Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system.
Behavior diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams
and Interaction Diagrams.
66
Object Oriented Concepts Used in UML –

1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize
our system. Modularity helps to divide our system into understandable components
so that we can build our system piece by piece. An object is the fundamental unit
(building block) of a system which is used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the
properties of their parent classes.
4. Abstraction – Mechanism by which implementation details are hidden from user.
5. Encapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in
different forms.
Structural UML Diagrams –
1. Class Diagram – The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems. We use class diagrams to
depict the static structure of a system by showing system’s classes,their methods
and attributes. Class diagrams also help us identify relationship between different
classes or objects.
2. Composite Structure Diagram – To represent the internal structure of a class and
its interaction points with other parts of the system. A composite structure diagram
represents relationship between parts and their configuration which determine
how the classifier (class, a component, or a deployment node) behaves. They
represent internal structure of a structured classifier making the use of parts, ports,
and connectorss.
3. Object Diagram – Object diagrams depict behaviour when objects have been
instantiated, we are able to study the behaviour of the system at a particular
instant. An object diagram is similar to a class diagram except it shows the
instances of classes in the system. An Object Diagram represents specific instances
of classes and relationships between them at a point of time.
67
4. Component Diagram – Component diagrams are used to represent the how the
physical components in a system have been organized. We use them for modelling
implementation details. Component Diagrams depict the structural relationship
between software system elements and help us in understanding if functional
requirements have been covered by planned development.
5. Deployment Diagram – Deployment Diagrams are used to represent system
hardware and its software.It tells us what hardware components exist and what
software components run on them.We illustrate system architecture as distribution
of software artifacts over distributed targets. An artifact is the information that is
generated by system software. They are primarily used when a software is being
used, distributed or deployed over multiple machines with different configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their
elements have been organized. A package diagram simply shows us the
dependencies between different packages and internal composition of packages.
Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand. They are primarily used to organise class and use case
diagrams.
Behavior Diagrams –
1. State Machine Diagrams – A state diagram is used to represent the condition of
the system or part of the system at finite instances of time. It’s a behavioral diagram
and it represents the behavior using finite state transitions. State diagrams are also
referred to as State machines and State-chart Diagrams . These terms are often
used interchangeably.So simply, a state diagram is used to model the dynamic
behavior of a class in response to time and changing external stimuli.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a
system. We can also use an activity diagram to refer to the steps involved in the
execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity
diagram.An activity diagram focuses on condition of flow and the sequence in
which it happens.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a
system or a part of a system. They are widely used to illustrate the functional
requirements of the system and its interaction with external agents(actors). A use
case is basically a diagram representing different scenarios where the system can
be used. A use case diagram gives us a high level view of what the system or a part
of the system does without going into implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between
objects in a sequential order i.e. the order in which these interactions take place.We
can also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in a
system function. These diagrams are widely used by businessmen and software
developers to document and understand requirements for new and existing
systems.
5. Communication Diagram – A Communication Diagram(known as Collaboration
Diagram in UML 1.x) is used to show sequenced messages exchanged between
objects. A communication diagram focuses primarily on objects and their
relationships. We can represent similar information using Sequence
diagrams,however, communication diagrams represent objects and links in a free
form.
68
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams which
are used to depict the behavior of objects over a time frame. We use them to show
time and duration constraints which govern changes in states and behavior of
objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a
sequence of actions and helps us simplify complex interactions into simpler
occurrences. It is a mixture of activity and sequence diagrams.
UML Tools
A UML tool is a software application that supports some or all of the
notation and semantics associated with the Unified Modeling Language (UML), which is
the industry standard general-purpose modeling language for software engineering.
Since UML is a Unified Modeling Language, it is used to create meaningful, object-
oriented models for a software application. It clearly represents the working of any
hardware/ software system. There are numerous tools, both commercial and open-
source, which are available for designing UML diagrams, are enlisted below:
1. StarUML
StarUML is an open-source software modeling tool, which is provided by MKLab. It has

come up with eleven different types of modeling diagrams. It also supports UML2.0
specified diagrams.
Features:
o It let you create Object, Use case, Deployment, Sequence, Collaboration, Activity,
and Profile diagrams.
o It is a UML 2.x standard compliant.
o It offers multiplatform support (MacOS, Windows, and Linux).
2. Umbrello
Umbrello is a Unified Modeling language tool, which is based on KDE technology. It

supports both reverse engineering and code generation for C++ and Java.
Features:
o It implements both structural and behavioral diagrams.

o It imports C++ and can export up to a wider range of languages.
69
3. UML designer tool
The UML designer tool helps in modifying and envisioning UML2.5 models. It allows you
to create all of the UML diagrams.
Features:
o It provides transparency to work on DSL as well as UML models.

o With the UML designer tool, the user can reuse the provided presentations.
o It implements Component, Class, and Composite structure diagrams.
o To start working with DSL, you can use UML legacy models.
4.ConceptDraw
ConceptDraw is a software, which is used in diagraming for creating business graphics

that include diagrams, flowcharts, Infographics, data envisioning, data presentation, and
project management documentation.
Features:
o It is used for creating UML diagrams, DFD, ERD, computer network topology, etc.
o It improves the interaction by empowering technical representation techniques.
o It provides a powerful and inclusive drawing tool.
5. WhitestarUML
Whitestar UML is a division of StarUML 5.0 that offers bug fixes and has improved its
compatibility with the latest operating systems, i.e., support of Unicode strings or
simply being developed and tested on Windows 7 and 8.
Features:
o It offers a refreshed user interface.
o It completely handles the functioning of Unicode strings.
o It provides support on Windows 7, 8, and 10.
o On-demand upload and download of units.
o It directly integrates the ERD profile and extends to generate and parse the SQL
tables.
70
UNIT – III
DESIGN PATTERNS
DESIGN PRINCIPLES
Principles of Object Oriented Design
 S - Single-responsiblity Principle
 O - Open-closed Principle
 L - Liskov Substitution Principle
 I - Interface Segregation Principle
 D - Dependency Inversion Principle
Introduction to SOLID Principles
SOLID is the acronym for a set of practices that, when implemented together,
makes the code more adaptive to change.
The acronym was meant to help us remember these principles easily. These
principles also form a vocabulary we can use while discussing with other team
members or as a part of technical documentation shared in the community.
SOLID principles form the fundamental guidelines for building object-oriented
applications that are robust, extensible, and maintainable.
Example: If a class SalesOrder keeps information about a sales order, and in addition
has a method saveOrder() that saves the SaleOrder in a database and a
method exportXML() that exports the SalesOrder in XML format, this design will violate
the SRP because there will be different types of users of this class and different reasons
for making changes to this class. A change made for one type of user, say change the
type of database, may require the re-test, recompilation, and re-linking of the class for
the other type of users.
A better design will be to have the SalesOrder class only keeps the information
about a sales order, and have different classes to save order and to export order,
respectively. Such a design will confirm to SRP.
Single Responsibility Principle
We may come across one of the principles of object-oriented design, Separation
of Concerns (SoC), that conveys a similar idea. The name of the SRP says it all:
“One class should have one and only one responsibility”
Open Closed Principle
OCP is the second principle which we should keep in mind while designing our
application. It states:
“Software components should be open for extension, but closed for modification”
It means that the application classes should be designed in such a way that
whenever fellow developers want to change the flow of control in specific conditions in
application, all they need to extend the class and override some functions and that’s it.
Liskov’s Substitution Principle
LSP is a variation of previously discussed open closed principle. It says:
“Derived types must be completely substitutable for their base types”
LSP means that the classes, fellow developers created by extending our class,
should be able to fit in application without failure. This is important when we resort
to polymorphic behavior through inheritance.
This requires the objects of the subclasses to behave in the same way as the
objects of the superclass. This is mostly seen in places where we do runtime type
identification and then cast it to appropriate reference type.
71
Interface Segregation Principle

This principle is my favorite one. ISP is applicable to interfaces as a single responsibility
principle holds to classes. ISP says:
“Clients should not be forced to implement unnecessary methods which they will not
use”
Example
The best place to look for IPS examples is Java AWT event handlers for handling
GUI events fired from keyboard and mouse. It has different listener classes for each kind
of event. We only need to write handlers for events, we wish to handle. Nothing is
mandatory.
Some of the listeners are –
 FocusListener
 KeyListener
 MouseMotionListener
 MouseWheelListener
 TextListener
 WindowFocusListener
Anytime, we wish to handle any event, just find out a corresponding listener and
implement it.
Dependency Inversion Principle
Most of us are already familiar with the words used in principle’s name. DI
principle says:
“Depend on abstractions, not on concretions”
In other words. we should design our software in such a way that various
modules can be separated from each other using an abstract layer to bind them
together.
Example
The classical use of this principle of bean configuration in Spring framework.
In the spring framework, all modules are provided as separate components
which can work together by simply injecting dependencies in other modules. This
dependency is managed externally in XML files.
These separate components are so well closed in their boundaries that we can
use them in other software modules apart from spring with the same ease. This has
been achieved by dependency inversion and open closed principles. All modules expose
only abstraction which is useful in extending the functionality or plug-in in another
module.
DESIGN PATTERNS
What is a Design pattern?
Design pattern is a solution approach to a common problem, It should be an
industry standard without language dependent
In software engineering, a design pattern is a general repeatable solution to a
commonly occurring problem in software design. A design pattern isn’t a finished design
that can be transformed directly into code. It is a description or template for how to solve
a problem that can be used in many different situations.
Design Patterns Classification:
 Creational design patterns
 Structural design patterns
 Behavioral design patterns
72
Creational Design Patterns:

Creational design patterns are concerned with the way of creating
objects. These design patterns are used when a decision must be made at the time of the
instantiation of a class (i.e. creating an object of a class).
This pattern can be further divided into class-creation patterns and object-
creational patterns. While class-creation patterns use inheritance effectively in the
instantiation process, object-creation patterns use delegation effectively to get the job
done.
73
1. T HE A BSTRAC T FAC TO RY PA TTE RN

The Abstract Factory Pattern goes a step further and moves to a higher level of
abstraction (hence the name). In this case, a client has no clue what kind of factory is
used. Abstract factory provides an interface for creating groups of dependent objects,
which are used by the client, without giving their exact implementation.
For the creation of specific products, which are available for the user-defined
interface, factories based on Factory Method Pattern or the Prototype Pattern are often
used (which is not discussed here).
The main difference between Factory Method Pattern and Abstract Factory
Pattern is the fact that in the former a client receives one product, whereas in the latter
a client gets the whole group of products.
Below presented diagram will facilitate understanding of the Abstract Factory concept:
2. Builder Design Pattern

Builder Pattern says that "construct a complex object from simple objects using
step-by-step approach"
It is mostly used when object can't be created in single step like in the de-serialization of
a complex object.
Advantage of Builder Design Pattern
The main advantages of Builder Pattern are as follows:
o It provides clear separation between the construction and representation of an
object.
o It provides better control over construction process.
o It supports to change the internal representation of objects.
74
UML for Builder Pattern Example
3. T HE F ACTORY ME THOD P A TTE RN

The Factory Method pattern is one of the best known design patterns.
Its task is to hide details of creating objects from clients and, at the same time,
provide interface to generate them. Classes implementing interface decide about class of
creating object.
A client expects a secured implementation of an interface or abstract class, but is
not interested in a specific implementation. However, a programmer can easily expand
the portfolio of a factory with additional object classes.
75
4. Prototype Design Pattern

Prototype Pattern says that cloning of an existing object instead of creating
new one and can also be customized as per the requirement.
This pattern should be followed, if the cost of creating a new object is expensive
and resource intensive.
Advantage of Prototype Pattern
The main advantages of prototype pattern are as follows:
o It reduces the need of sub-classing.
o It hides complexities of creating objects.
o The clients can get new objects without knowing which type of object it will be.
o It lets you add or remove objects at runtime.
Usage of Prototype Pattern
o When the classes are instantiated at runtime.
o When the cost of creating an object is expensive or complicated.
o When you want to keep the number of classes in an application minimum.
o When the client application needs to be unaware of object creation and
representation.
5. T HE S INGL ETO N PA TTER N
The Singleton pattern provides at most one instance of a given class and global
access to its references. Very often is presented as an anti-pattern as it breaks two
SOLID rules (single responsibility principle and open/closed principle), sometimes
it is overused and very often is treated as object substitute of a global variable. It also
happens to be problematic during implementation in multi-threaded environment.
Use this pattern if your application requires global access to the same resource.
Structural Design Patterns:

 Structural design patterns are concerned with how classes and objects can be
composed, to form larger structures.
 The structural design patterns simplifies the structure by identifying the
relationships.
 These patterns focus on, how the classes inherit from each other and how they
are composed from other classes.
1. Adapter Pattern
 An Adapter Pattern says that just "converts the interface of a class into
another interface that a client wants".
 In other words, to provide the interface according to client requirement while
using the services of a class with a different interface.
 The Adapter Pattern is also known as Wrapper.
76
Advantage of Adapter Pattern

o It allows two or more previously incompatible objects to interact.
o It allows reusability of existing functionality.
Usage of Adapter pattern:
o When an object needs to utilize an existing class with an incompatible interface.
o When you want to create a reusable class that cooperates with classes which
don't have compatible interfaces.
o When you want to create a reusable class that cooperates with classes which
don't have compatible interfaces.
UML for Adapter Pattern:
2. Bridge Pattern
 A Bridge Pattern says that just "decouple the functional abstraction from the
implementation so that the two can vary independently".
 The Bridge Pattern is also known as Handle or Body.
Advantage of Bridge Pattern
o It enables the separation of implementation from the interface.
o It improves the extensibility.
o It allows the hiding of implementation details from the client.
Usage of Bridge Pattern
o When you don't want a permanent binding between the functional abstraction
and its implementation.
o When both the functional abstraction and its implementation need to extended
using sub-classes.
o It is mostly used in those places where changes are made in the implementation
does not affect the clients.
77
UML for Bridge Pattern:
3. Composite Pattern
A Composite Pattern says that just "allow clients to operate in generic manner on
objects that may or may not represent a hierarchy of objects".
Advantage of Composite Design Pattern
o It defines class hierarchies that contain primitive and complex objects.
o It makes easier to you to add new kinds of components.
o It provides flexibility of structure with manageable class or interface.
Usage of Composite Pattern
o When you want to represent a full or partial hierarchy of objects.
o When the responsibilities are needed to be added dynamically to the individual
objects without affecting other objects. Where the responsibility of object may
vary from time to time.
78
o
4. Decorator Pattern
 A Decorator Pattern says that just "attach a flexible additional
responsibilities to an object dynamically".
 In other words, The Decorator Pattern uses composition instead of inheritance to
extend the functionality of an object at runtime.
 The Decorator Pattern is also known as Wrapper.
Advantage of Decorator Pattern
o It provides greater flexibility than static inheritance.
o It enhances the extensibility of the object, because changes are made by coding
new classes.
o It simplifies the coding by allowing you to develop a series of functionality from
targeted classes instead of coding all of the behavior into the object.
Usage of Decorator Pattern
o When you want to transparently and dynamically add responsibilities to objects
without affecting other objects.
o When you want to add responsibilities to an object that you may want to change
in future.
o Extending functionality by sub-classing is no longer practical.
79
UML for Decorator Pattern:
5. Facade Pattern
 A Facade Pattern says that just "just provide a unified and simplified
interface to a set of interfaces in a subsystem, therefore it hides the
complexities of the subsystem from the client".
 In other words, Facade Pattern describes a higher-level interface that makes the
sub-system easier to use.
 Practically, every Abstract Factory is a type of Facade.
Advantage of Facade Pattern
o It shields the clients from the complexities of the sub-system components.
o It promotes loose coupling between subsystems and its clients.
Usage of Facade Pattern:
o When you want to provide simple interface to a complex sub-system.
o When several dependencies exist between clients and the implementation
classes of an abstraction.
80
UML for Facade Pattern:
6. Flyweight Pattern
A Flyweight Pattern says that just "to reuse already existing similar kind of objects
by storing them and create new object when no matching object is found".
Advantage of Flyweight Pattern
o It reduces the number of objects.
o It reduces the amount of memory and storage devices required if the objects are
persisted
Usage of Flyweight Pattern
o When an application uses number of objects
o When the storage cost is high because of the quantity of objects.
o When the application does not depend on object identity.
7. Proxy Pattern
 Simply, proxy means an object representing another object.
 According to GoF, a Proxy Pattern "provides the control for accessing the
original object".
 So, we can perform many operations like hiding the information of original
object, on demand loading etc.
 Proxy pattern is also known as Surrogate or Placeholder.
Advantage of Proxy Pattern
o It provides the protection to the original object from the outside world.
Usage of Proxy Pattern:
o It can be used in Virtual Proxy scenario---Consider a situation where there is
multiple database call to extract huge size image. Since this is an expensive
operation so here we can use the proxy pattern which would create multiple
proxies and point to the huge size memory consuming object for further
processing. The real object gets created only when a client first
requests/accesses the object and after that we can just refer to the proxy to
reuse the object. This avoids duplication of the object and hence saving memory.
o It can be used in Protective Proxy scenario---It acts as an authorization layer to
verify that whether the actual user has access the appropriate content or not. For
example, a proxy server which provides restriction on internet access in office.
81
Only the websites and contents which are valid will be allowed and the
remaining ones will be blocked.
o It can be used in Remote Proxy scenario---A remote proxy can be thought about
the stub in the RPC call. The remote proxy provides a local representation of the
object which is present in the different address location. Another example can be
providing interface for remote resources such as web service or REST resources.
o It can be used in Smart Proxy scenario---A smart proxy provides additional
layer of security by interposing specific actions when the object is accessed. For
example, to check whether the real object is locked or not before accessing it so
that no other objects can change it.
UML for Proxy Pattern:
Behavioral Design Patterns:

 Behavioral design patterns are concerned with the interaction and
responsibility of objects.
 In these design patterns, the interaction between the objects should be in
such a way that they can easily talk to each other and still should be loosely
coupled.
 That means the implementation and the client should be loosely coupled in order
to avoid hard coding and dependencies.
1. Chain Of Responsibility Pattern
 In chain of responsibility, sender sends a request to a chain of objects. The
request can be handled by any object in the chain.
 A Chain of Responsibility Pattern says that just "avoid coupling the sender of a
request to its receiver by giving multiple objects a chance to handle the
request". For example, an ATM uses the Chain of Responsibility design pattern
in money giving process.
82
 In other words, we can say that normally each receiver contains reference of
another receiver. If one object cannot handle the request then it passes the same
to the next receiver and so on.
Advantage of Chain of Responsibility Pattern
o It reduces the coupling.
o It adds flexibility while assigning the responsibilities to objects.
o It allows a set of classes to act as one; events produced in one class can be sent to
other handler classes with the help of composition.
Usage of Chain of Responsibility Pattern:
o When more than one object can handle a request and the handler is unknown.
o When the group of objects that can handle the request must be specified in
dynamic way.
2. Command Pattern
 A Command Pattern says that "encapsulate a request under an object as a
command and pass it to invoker object.
 Invoker object looks for the appropriate object which can handle this command
and pass the command to the corresponding object and that object executes the
command".
 It is also known as Action or Transaction.
Advantage of command pattern
o It separates the object that invokes the operation from the object that actually
performs the operation.
o It makes easy to add new commands, because existing classes remain
unchanged.
Usage of command pattern:
o When you need parameterize objects according to an action perform.
o When you need to create and execute requests at different times.
o When you need to support rollback, logging or transaction functionality.
83
3. Interpreter Pattern
 An Interpreter Pattern says that "to define a representation of grammar of a
given language, along with an interpreter that uses this representation to
interpret sentences in the language".
 Basically the Interpreter pattern has limited area where it can be applied. We can
discuss the Interpreter pattern only in terms of formal grammars but in this area
there are better solutions that is why it is not frequently used.
 This pattern can applied for parsing the expressions defined in simple grammars
and sometimes in simple rule engines.
Advantage of Interpreter Pattern
o It is easier to change and extend the grammar.
o Implementing the grammar is straightforward.
Usage of Interpreter pattern:
o When the grammar of the language is not complicated.
o When the efficiency is not a priority.
84
4. Iterator Pattern
 According to GoF, Iterator Pattern is used "to access the elements of an
aggregate object sequentially without exposing its underlying
implementation".
 The Iterator pattern is also known as Cursor.
 In collection framework, we are now using Iterator that is preferred over
Enumeration.
Advantage of Iterator Pattern
o It supports variations in the traversal of a collection.
o It simplifies the interface to the collection.
Usage of Iterator Pattern:
o When you want to access a collection of objects without exposing its internal
representation.
o When there are multiple traversals of objects need to be supported in the
collection.
85
5. Mediator Pattern
 A Mediator Pattern says that "to define an object that encapsulates how a set of
objects interact".
 Mediator pattern is used to reduce communication complexity between multiple
objects or classes.
 This pattern provides a mediator class which normally handles all the
communications between different classes and supports easy maintainability of
the code by loose coupling.
Advantage:
o It decouples the number of classes.
o It simplifies object protocols.
o It centralizes the control.
o The individual components become simpler and much easier to deal with
because they don't need to pass messages to one another.
Usage:
o It is commonly used in message-based systems likewise chat applications.
o When the set of objects communicate in complex but in well-defined ways.
86
UML for Mediator Pattern:
6. Memento Pattern
 A Memento Pattern says that "to restore the state of an object to its previous
state". But it must do this without violating Encapsulation. Such case is useful in
case of error or failure.
 The Memento pattern is also known as Token.
 Undo or backspace or ctrl+z is one of the most used operation in an editor.
Memento design pattern is used to implement the undo operation. This is done
by saving the current state of the object as it changes state.
Advantage:
o It preserves encapsulation boundaries.
o It simplifies the originator.
Usage:
o It is used in Undo and Redo operations in most software.
o It is also used in database transactions.
87
UML for Memento Pattern:
7. Observer Pattern
 An Observer Pattern says that "just define a one-to-one dependency so that when
one object changes state, all its dependents are notified and updated
automatically".
 The observer pattern is also known as Dependents or Publish-Subscribe.
Advantage:
o It describes the coupling between the objects and the observer.
o It provides the support for broadcast-type communication.
Usage:
o When the change of a state in one object must be reflected in another object
without keeping the objects tight coupled.
o When the framework we writes and needs to be enhanced in future with new
observers with minimal chamges.
88
UML for Observer Pattern:
8. State Pattern
 A State Pattern says that "the class behavior changes based on its state".
 In State Pattern, we create objects which represent various states and a context
object whose behavior varies as its state object changes.
 The State Pattern is also known as Objects for States.
Advantage:
o It keeps the state-specific behavior.
o It makes any state transitions explicit.
Usage:
o When the behavior of object depends on its state and it must be able to change
its behavior at runtime according to the new state.
o It is used when the operations have large, multipart conditional statements that
depend on the state of an object.
89
UML for State Pattern:
9. Strategy Pattern
 A Strategy Pattern says that "defines a family of functionality, encapsulate each
one, and make them interchangeable".
 The Strategy Pattern is also known as Policy.
Advantage:
o It provides a substitute to subclassing.
o It defines each behavior within its own class, eliminating the need for conditional
statements.
o It makes it easier to extend and incorporate new behavior without changing the
application.
Usage:
o When the multiple classes differ only in their behaviors.e.g. Servlet API.
o It is used when you need different variations of an algorithm.
90
UML for Strategy Pattern:
10. Template Pattern

 A Template Pattern says that "just define the skeleton of a function in an
operation, deferring some steps to its subclasses".
Advantage:
o It is very common technique for reusing the code.This is only the main benefit of
it.
Usage:
o It is used when the common behavior among sub-classes should be moved to a
single common class by avoiding the duplication.
UML for Template Pattern:
91
What are all the benefits of the design pattern?

1. Design patterns can speed up the development process by providing tested, proven
development paradigms.
2. Reusing the design patterns helps to prevent subtle issues that can cause major
problems and it also improves code readability.
3. Design pattern provides general solutions, documented in a format that doesn’t
specifics tied to a particular problem.
4. In addition to that patterns allows developers to communicate well-known, well-
understood names for software interactions, Common design patterns can be
improved over time, making them more robust than ad-hoc design.
5. A standard solution to a common programming problem enables large scale reuse of
software.
Usage of Design Pattern
Design Patterns have two main usages in software development.
1. Common platform for developers
Design patterns provide a standard terminology and are specific to particular
scenario. For example, a singleton design pattern signifies use of single object so all
developers familiar with single design pattern will make use of single object and they
can tell each other that program is following a singleton pattern.
2. Best Practices
Design patterns have been evolved over a long period of time and they provide
best solutions to certain problems faced during software development. Learning these
patterns helps unexperienced developers to learn software design in an easy and faster
way.
GRASP
What is grasp pattern ?
GRASP (General Responsibility Assignment Software Patterns) is a design
pattern in object-oriented software development used to assign responsibilities
for different modules of code. ... GRASP assigns nine types of roles to classes and
objects in order to make for clear delineation of responsibilities.
92
93
94
95
96
97
98
99
100
101
GOF
What is Gang of Four (GOF)?
In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides published a book titled Design Patterns - Elements of Reusable Object-
Oriented Software which initiated the concept of Design Pattern in Software
development.
These authors are collectively known as Gang of Four (GOF). According to these
authors design patterns are primarily based on the following principles of object
orientated design.
 Program to an interface not an implementation
 Favor object composition over inheritance
Design patterns provide solutions to common software design problems. In the

case of object-oriented programming, design patterns are generally aimed at solving the
problems of object generation and interaction, rather than the larger scale problems of
overall software architecture. They give generalised solutions in the form of templates
that may be applied to real-world problems.
Design patterns are a powerful tool for software developers. However, they
should not be seen as prescriptive specifications for software. It is more important to
understand the concepts that design patterns describe, rather than memorising their
exact classes, methods and properties. It is also important to apply patterns
appropriately. Using the incorrect pattern for a situation or applying a design pattern to
a trivial solution can overcomplicate your code and lead to maintainability issues.
GoF Design Pattern Types
GoF Design Patterns are divided into three categories:
1. Creational: The design patterns that deal with the creation of an object.
2. Structural: The design patterns in this category deals with the class structure such as
Inheritance and Composition.
3. Behavioral: This type of design patterns provide solution for the better interaction
between objects, how to provide lose coupling, and flexibility to extend easily in future.
Creational Design Patterns
There are 5 design patterns in the creational design patterns category.
Pattern
Description
Name
The singleton pattern restricts the initialization of a class to ensure that

Singleton
only one instance of the class can be created.
The factory pattern takes out the responsibility of instantiating a object

Factory
from the class to a Factory class.
Abstract
Allows us to create a Factory for factory classes.
Factory
Creating an object step by step and a method to finally get the object
Builder
instance.
Creating a new object instance from another similar instance and then
Prototype
modify according to our requirements.
102
Structural Design Patterns

There are 7 structural design patterns defined in the Gangs of Four design patterns
book.
Pattern
Description
Name
Provides an interface between two unrelated entities so that they can

Adapter
work together.
Used when we have to implement a part-whole hierarchy. For example, a

Composite
diagram made of other pieces such as circle, square, triangle, etc.
Provide a surrogate or placeholder for another object to control access to

Proxy
it.
Caching and reusing object instances, used with immutable objects. For
Flyweight
example, string pool.
Creating a wrapper interfaces on top of existing interfaces to help client

Facade
applications.
The bridge design pattern is used to decouple the interfaces from

Bridge implementation and hiding the implementation details from the client
program.
The decorator design pattern is used to modify the functionality of an

Decorator
object at runtime.
Behavioral Design Patterns
There are 11 behavioral design patterns defined in the GoF design patterns.
Pattern Name Description
used to create a template method stub and defer some of the steps of
Template Method
implementation to the subclasses.
used to provide a centralized communication medium between

Mediator
different objects in a system.
Chain of used to achieve loose coupling in software design where a request

Responsibility from the client is passed to a chain of objects to process them.
useful when you are interested in the state of an object and want to
Observer
get notified whenever there is any change.
Strategy pattern is used when we have multiple algorithm for a

Strategy specific task and client decides the actual implementation to be used
at runtime.
Command Pattern is used to implement lose coupling in a request-

Command
response model.
103
State design pattern is used when an Object change it’s behavior

State
based on it’s internal state.
Visitor pattern is used when we have to perform an operation on a

Visitor
group of similar kind of Objects.
defines a grammatical representation for a language and provides an

Interpreter
interpreter to deal with this grammar.
used to provide a standard way to traverse through a group of

Iterator
Objects.
The memento design pattern is used when we want to save the state
Memento
of an object so that we can restore later on.
DYNAMIC OBJECT MODELING

What is dynamic Modelling?
Dynamic Modeling represents the temporal aspects of a system, capturing the
control elements through which the behavior of objects can be understood over time. ...
It is necessary to model only those objects with a definite lifecycle or those which
exhibit significant behavior.
Dynamic Modelling describes those aspect of the system that are concerned
with time and sequencing of the operations. It is used to specify and implement the
control aspect of the system. Dynamic model is represented graphically with the help of
state diagrams.
Dynamic modelling in object oriented analysis and design
Dynamic Modelling describes those aspect of the system that are concerned
with time and sequencing of the operations. It is used to specify and implement the
control aspect of the system. Dynamic model is represented graphically with the help of
state diagrams.
It is also known as state modelling. State model consist of multiple state
diagrams, one for each class with temporal behavior that is important to an application.
State diagram relates with events and states. Events represents external functional
activity and states represents values objects.
Events:
Event conveys information from one object to another.
The events are of three types: Signal event, Change event, and Time event.
These are explained as following below.
1. Signal event:
A signal event is an particular occurrence in time. A signal is a explicit one-way
transmission of information from one object to another.A signal event is the event of
sending or receiving signal.
When an object send signal to another object it await for acknowledgement but
acknowledgement signal is the separate signal under the control of second object,
which may or may not choose to send it.The UML notation is (<>) written inside the
name at top of the box and in another section list all the signal attributes.Eg:
104
2. Change event:
It is caused by the satisfaction of a boolean expression.The intent of the change event
is that the expression is tested continually whenever the expression changes from
false to true.The UML notation for a change event is the keyword when followed by a
parenthesized boolean expression.
Eg:
when(battery power < lower limit)
when(room temperature < heating/cooling point )
3. Time event:
It is caused by occurrence of an absolute or the elapse of time interval.The UML
notation for absolute time is the keyword when followed by a parenthesized
expression involving time and for the time interval is keyword after followed by a
parenthesized expression that evaluates time duration.
Eg:
when(Date = mar 2, 2005)
after(50 seconds)
State:
A state is an abstraction of attribute values and links of an object. Values and
links are combined together into a state according to their entire behavior. The
response of object according to input event is called state. A state corresponds to the
interval between two events received by an object. The state of the event depends on
the past event. So basically, state represents intervals of time. The UML notation for the
state is a round box containing an optional state name list, list the name in boldface,
center the name near the top of the box, capitalize the first letter. Eg:
The following are the important points needs to be remember about state.
1. Ignore attributes that do not affect the behavior of object.
2. The objects in the class have finite number of possible states.
3. Each object can be in one state at a time.
4. ALL events are ignored in a state, except those for which behavior is explicitly
prescribed.
5. Both events and states depend upon level of abstraction.
105
STATIC OBJECT MODELING

What is static modelling?
Static modeling is used to specify structure of the objects that exist in the
problem domain. These are expressed using class, object and USECASE diagrams. But
Dynamic modeling refers representing the object interactions during runtime. It is
represented by sequence, activity, collaboration and statechart diagrams.
The static model represents the relations between real-world objects in

analysis and design, including their attributes and operations. The static
representation does not take into account events and instruction sequencing that take
place during execution of the implemented design model.
Class Diagram
ASSOCIATIONS
106
1-1 ASSOCIATION
MANY ASSOCIATION
MANY-MANY ASSOCIATION
107
COMPOSITION AND AGGREGATION HIERARCHIES
EXAMPLE – COMPOSITION
EXAMPLE – AGGREGATION
108
GENERALIZATION/SPECICALIZATION HIERARCHY
EXAMPLE-GENERALIZATION
PRELIMINARY CLASS DESIGN
APPROACH TO STATIC MODELING
109
PRELIMINARY CLASS IDENTIFICATION
APPLICATION CLASS STEREOTYPES
ANALYSIS CLASSES: LEVEL OF DETAIL
QUALITY FACTORS OF ANALYSIS CLASSES
110
IDENTIFYING <<BOUNDARY>> CLASSES
SYSTEM CONTEXT CLASS DIAGRAM
EXAPLE –CONTEXT DIAGRAM
IDENTIFYING ENTITY CLASSES
111
EXAMPLE-ENTITY CLASS
IDENTIFYING CONTROL CLASSES
EXAMPLE CONTROL OBJECT
112
IDENTIFYING ALGORITHM CLASSES
SEXAPLE- ALGORITHM OBJECT
113
UNIT – IV
SYSTEM TESTING
SOFTWARE TESTING:
Testing : Software testing is a process of identifying the correctness of software
by considering its all attributes (Reliability, Scalability, Portability, Re-usability,
Usability) and evaluating the execution of software components to find the software
bugs or errors or defects.
Types of Software testing
1. Manual Testing:
The process of checking the functionality of an application as per the customer
needs without taking any help of automation tools is known as manual testing. While
performing the manual testing on any application, we do not need any specific
knowledge of any testing tool, rather than have a proper understanding of the product
so we can easily prepare the test document.
Manual testing can be further divided into three types of testing, which are as follows:
o White box testing
o Black box testing
o Gray box testing
White-box testing:- The white box testing is done by Developer, where they check
every line of a code before giving it to the Test Engineer. Since the code is visible for the
Developer during the testing, that's why it is also known as White box testing.
Black box testing:-The black box testing is done by the Test Engineer, where they can
check the functionality of an application or the software according to the customer
/client's needs. In this, the code is not visible while performing the testing; that's why it
is known as black-box testing.
Gray Box testing:-Gray box testing is a combination of white box and Black box testing.
It can be performed by a person who knew both coding and testing. And if the single
person performs white box, as well as black-box testing for the application, is known as
Gray box testing.
114
2. Automation testing:
Automation testing is a process of converting any manual test cases into the test
scripts with the help of automation tools, or any programming language is known as
automation testing. With the help of automation testing, we can enhance the speed of
our test execution because here, we do not require any human efforts. We need to write
a test script and execute those scripts
What are the benefits of Software Testing?
Here are the benefits of using software testing:
 Cost-Effective: It is one of the important advantages of software testing. Testing
any IT project on time helps you to save your money for the long term. In case if
the bugs caught in the earlier stage of software testing, it costs less to fix.
 Security: It is the most vulnerable and sensitive benefit of software testing.
People are looking for trusted products. It helps in removing risks and problems
earlier.
 Product quality: It is an essential requirement of any software product. Testing
ensures a quality product is delivered to customers.
 Customer Satisfaction: The main aim of any product is to give satisfaction to
their customers. UI/UX Testing ensures the best user experience.
SOFTWARE VERIFICATION TECHNIQUES
Verification Methods in Software Verification
What is Software Verification?
Reviewing of any software for the purpose of finding faults is known as software
verification. Verification is the process of checking that a software achieves its goal
without any bugs.
It is the process to ensure whether the product that is developed is right or not.
The reviewing of a document can be done from the first phase of software development
i.e. software requirement and analysis phase where the end product is the SRS
document.
There are many methods for practicing the verification of the software like peer
reviews, walkthroughs, inspections, etc that can help us in the prevention of potential
faults otherwise, it may lead to the failure of software.
Methods of Verification :
1. Peer Reviews:
The very easiest method and informal way of reviewing the documents or the
programs/software for the purpose of finding out the faults during the verification
process is the peer-review method.
In this method, we give the document or software programs to others and ask
them to review those documents or software programs where we expect their views
about the quality of our product and also expect them to find the faults in the
program/document.
The activities that are involved in this method may include SRS document
verification, SDD verification, and program verification. In this method, the reviewers
may also prepare a short report on their observations or findings, etc.
Advantages:
 You can expect some good results without spending any significant resources.
 It is very efficient and significant in its nature.
Disadvantages:
 Lead to bad results if the reviewer doesn’t have sufficient knowledge.
115
2. Walk – through:
Walk-throughs are the formal and very systematic type of verification method as
compared to peer-review. Participants are not expected to prepare anything. The
presenter is responsible for preparing the meeting. The document(s) is/are distributed
to all participants. At the time of the meeting of the walk-through, the author introduces
the content in order to make them familiar with it and all the participants are free to ask
their doubts.
Advantages:
 It may help us to find potential faults.
 It may also be used for sharing documents with others.
Disadvantages:
 The author may hide some critical areas and unnecessarily emphasize some specific
areas of his / her interest.
3. Inspections:
Inspections are the most structured and most formal type of verification method
and are commonly known as inspections. A team of three to six participants is
constituted which is led by an impartial moderator.
Every person in the group participates openly, actively, and follows the rules
about how such a review is to be conducted. Everyone may get time to express their
views, potential faults, and critical areas. After the meeting, a final report is prepared
after incorporating necessary suggestions by the moderator.
Advantages:
 It can be very effective for finding potential faults or problems in the documents like
SRS, SDD, etc.
 The critical inspections may also help in finding faults and improve these documents
which can in preventing the propagation of a fault in the software development life
cycle process.
Disadvantages:
 They take time and require discipline.
 It requires more cost and also needs skilled testers.
Applications of Verification Methods:
The above three verification methods are very popular and have their own
strengths and weaknesses. We can compare these methods on various specific issues as
given below:
No. of Pre-
S.no Method Presenter Members requisites Report Strength Weakness
Output is
dependent
on the
ability of
No Not Less- the
1. Peer reviews 0 1 or 2 prerequisite Required Expensive reviewer
116
The
The only report is Find few
presenter is prepared faults and
2 to 7 required to by the Knowledge not very
2. Walkthrough Author members be prepared presenter sharing expensive
Expensive
All The and
participants report is requires
Author are prepared Effective very
and other 3 to 6 required to by the but may skilled
3. Inspection member members be prepared moderator get faults members
Hence, Verification is likely more effective than validation but it may find some faults
that are somewhat impossible to find during the validation process. But at the same
time, it allows us to find faults at the earliest possible phase/time of software
development.
OBJECT ORIENTED CHECKLIST:-

Object Oriented Testing : Introduction
 Whenever large scale systems are designed, object oriented testing is done
rather than the conventional testing strategies as the concepts of object oriented
programming is way different from that of conventional ones.
 The whole object oriented testing revolves around the fundamental entity
known as “class”.
 With the help of “class” concept, larger systems can be divided into small well
defined units which may then be implemented separately.
 The object oriented testing can be classified as like conventional systems. These
are called as the levels for testing.
Object Oriented Testing : Levels / Techniques
 The levels of object oriented testing can be broadly classified into three
categories. These are:
Object Oriented Testing : Techniques
117
1. Class Testing
o Class testing is also known as unit testing.
o In class testing, every individual classes are tested for errors or bugs.
o Class testing ensures that the attributes of class are implemented as per
the design and specifications. Also, it checks whether the interfaces and
methods are error free of not.
2. Inter-Class Testing
o It is also called as integration or subsystem testing.
o Inter class testing involves the testing of modules or sub-systems and
their coordination with other modules.
3. System Testing
o In system testing, the system is tested as whole and primarily functional
testing techniques are used to test the system. Non-functional
requirements like performance, reliability, usability and test-ability are
also tested.
FUNCTIONAL TESTING
Functional Testing : Introduction

 Functional Testing is a type of testing that can be used to assess the features and
functionality of the system or software product.
 Functional testing has a special feature with the help of which each and every
function of a software product so that it can be verified with requirement
specifications.
Functional Testing : The Need
 Checking a software product for its functionalities is the prime objective of
functional testing. It mainly focuses on:
1. Basic Usability: It deals with basic usability testing of software product
which involves basic functionalities of user interface and navigation
through pages.
2. Mainline Functions: Main functions and features are tested of the
software product.
3. Accessibility: To check, how much the software product is accessible to
users.
4. Error Conditions: Error conditions either generate warnings or displays
error messages, if any.
Functional Testing : Process
118
Functional Testing : Techniques

 There are five major techniques for functional testing. These are:
Functional Testing : Techniques

1. Unit Testing: In unit testing, Independent units are tested using functional and
structural techniques. Every unit is tested individually.
2. Integration Testing: In integration testing, two or more units are combined
together and then testing is carried out to test the integration related issues of
various units. Integration units can further be subdivide as:
o Bottom up approach.
o Top down approach.
o Sandwich approach.
3. System Testing: In system testing, the system is tested as whole and primarily
functional testing techniques are used to test the system. Non-functional
requirements like performance, reliability, usability and test ability are also tested.
4. Regression Testing: Regression testing is the process of retesting the modified part
of the software and ensuring that no new error have been introduced into
previously tested code due to these modifications as whenever we modify any
software, we need to retest it.
5. Acceptance Testing: Once unit, integration and system testing are done, acceptance
testing is initialized. It is done by the customers for the purpose of accepting the
final product and its compliance with the requirements.
STRUCTURAL TESTING
Structural testing is a type of software testing which uses the internal design
of the software for testing or in other words the software testing which is performed
by the team which knows the development phase of the software, is known as
structural testing.
Structural testing is basically related to the internal design and implementation of the
software i.e. it involves the development team members in the testing team. It
basically tests different aspects of the software according to its types. Structural
testing is just the opposite of behavioral testing.
119
Types of Structural Testing:

There are 4 types of Structural Testing:
Control Flow Testing:

Control flow testing is a type of structural testing that uses the programs’s
control flow as a model. The entire code, design and structure of the software have to
be known for this type of testing.
Often this type of testing is used by the developers to test their own code and
implementation. This method is used to test the logic of the code so that required
result can be obtained.
Data Flow Testing:
It uses the control flow graph to explore the unreasonable things that can
happen
to data.
The detection of data flow anomalies are based on the associations between
values and variables. Without being initialized usage of variables. Initialized variables
are not used once.
Slice Based Testing:
It was originally proposed by Weiser and Gallagher for the software
maintenance. It is useful for software debugging, software maintenance, program
understanding and quantification of functional cohesion. It divides the program into
different slices and tests that slice which can majorly affect the entire software.
Mutation Testing:
Mutation Testing is a type of Software Testing that is performed to design new
software tests and also evaluate the quality of already existing software tests.
Mutation testing is related to modification a program in small ways. It focuses to help
the tester develop effective tests or locate weaknesses in the test data used for the
program.
Advantages of Structural Testing:
 It provides thorough testing of the software.
 It helps in finding out defects at an early stage.
 It helps in elimination of dead code.
 It is not time consuming as it is mostly automated.
Disadvantages of Structural Testing:
 It requires knowledge of the code to perform test.
 It requires training in the tool used for testing.
 Sometimes it is expensive.
120
Structural Testing Tools:

 JBehave
 Cucumber
 Junit
 Cfix
CLASS TESTING
121
122
123
124
MUTATION TESTING
Mutation Testing is a type of Software Testing that is performed to design new
software tests and also evaluate the quality of already existing software tests.
Mutation testing is related to modification a program in small ways. It focuses to help
the tester develop effective tests or locate weaknesses in the test data used for the
program.
Mutation Testing is a White Box Testing.

Mutation testing can be applied to design models, specifications, databases,
tests, and XML. It is a structural testing technique, which uses the structure of the code
to guide the testing process. It can be described as the process of rewriting the source
code in small ways in order to remove the redundancies in the source code.
Objective of Mutation Testing:
The objective of mutation testing is:
 To identify pieces of code that are not tested properly.
 To identify hidden defects that can’t be detected using other testing methods.
 To discover new kinds of errors or bugs.
 To calculate the mutation score.
 To study error propagation and state infection in the program.
 To assess the quality of the test cases.
125
Types of Mutation Testing:

Mutation testing is basically of 3 types:
1. Value Mutations:
In this type of testing the values are changed to detect errors in the program.
Basically a small value is changed to a larger value or a larger value is changed to a
smaller value. In this testing basically constants are changed.
Example:
Initial Code:
int mod = 1000000007;
int a = 12345678;
int b = 98765432;
int c = (a + b) % mod;
Changed Code:
int mod = 1007;
int a = 12345678;
int b = 98765432;
int c = (a + b) % mod;
2. Decision Mutations:
In decisions mutations are logical or arithmetic operators are changed to
detect errors in the program.
Example:
Initial Code:
if(a < b)
c = 10;
else
c = 20;
Changed Code:
if(a > b)
c = 10;
else
c = 20;
3. Statement Mutations:
In statement mutations a statement is deleted or it is replaces by some other
statement.
Example:
Initial Code:
if(a < b)
c = 10;
else
c = 20;
Changed Code:
if(a < b)
d = 10;
else
d = 20;
Advantages of Mutation Testing:
 It brings a good level of error detection in the program.
 It discovers ambiguities in the source code.
126
Disadvantages of Mutation Testing:

 It is highly costly and time-consuming.
 It is not able for Black Box Testing.
LEVELS OF TESTING
Testing itself may be defined at various levels of SDLC. The testing process runs
parallel to software development. Before jumping on the next stage, a stage is tested,
validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or
issues left in the software. Software is tested on various levels –
Unit testing:
While coding, the programmer performs some tests on that unit of program to
know if it is error free. Testing is performed under white-box testing approach. Unit
testing helps developers decide that individual units of the program are working as per
requirement and are error free.
Integration testing:
Even if the units of software are working fine individually, there is a need to find
out if the units if integrated together would also work without errors. For example,
argument passing and data updation etc.
System testing:
The software is compiled as product and then it is tested as a whole. This can be
accomplished using one or more of the following tests:
Functionality testing - Tests all functionalities of the software against the
requirement.
Performance testing - This test proves how efficient the software is. It tests the
effectiveness and average time taken by the software to do desired task. Performance
testing is done by means of load testing and stress testing where the software is put
under high user and data load under various environment conditions.
Security & Portability - These tests are done when the software is meant to work
on various platforms and accessed by number of persons.
Acceptance testing:
When the software is ready to hand over to the customer it has to go through
last phase of testing where it is tested for user-interaction and response. This is
important because even if the software matches all user requirements and if user does
not like the way it appears or works, it may be rejected.
Alpha testing - The team of developer themselves perform alpha testing by using
the system as if it is being used in work environment. They try to find out how user
would react to some action in software and how the system should respond to inputs.
Beta testing - After the software is tested internally, it is handed over to the
users to use it under their production environment only for testing purpose. This is not
as yet the delivered product. Developers expect that users at this stage will bring minute
problems, which were skipped to attend.
Regression testing:
Whenever a software product is updated with new code, feature or
functionality, it is tested thoroughly to detect if there is any negative impact of
the added code. This is known as regression testing.
127
STATIC AND DYNAMIC TESTING TOOLS
What is Static Testing?

Static Testing is a type of software testing in which software application is
tested without code execution. Manual or automated reviews of code, requirement
documents and document design are done in order to find the errors. The main
objective of static testing is to improve the quality of software applications by finding
errors in early stages of software development process.
Static testing involves manual or automated reviews of the documents. This
review is done during an initial phase of testing to catch Defect early in STLC. It
examines work documents and provides review comments. It is also called Non-
execution testing or verification testing.
Examples of Work documents-
 Requirement specifications
 Design document
 Source Code
 Test Plans
 Test Cases
 Test Scripts
 Help or User document
 Web Page content
Static Testing Techniques:
 Informal Reviews: This is one of the type of review which doesn’t follow any
process to find errors in the document. Under this technique, you just review the
document and give informal comments on it.
 Technical Reviews: A team consisting of your peers, review the technical
specification of the software product and checks whether it is suitable for the
project. They try to find any discrepancies in the specifications and standards
followed. This review concentrates mainly on the technical documentation related to
the software such as Test Strategy, Test Plan and requirement specification
documents.
 Walkthrough: The author of the work product explains the product to his team.
Participants can ask questions if any. A meeting is led by the author. Scribe makes
note of review comments
 Inspection: The main purpose is to find defects and meeting is led by a trained
moderator. This review is a formal type of review where it follows a strict process to
find the defects. Reviewers have a checklist to review the work products.They
record the defect and inform the participants to rectify those errors.
128
 Static code Review: This is a systematic review of the software source code without
executing the code. It checks the syntax of the code, coding standards, code
optimization, etc. This is also termed as white box testing.This review can be done at
any point during development.
What is Dynamic Testing?
Under Dynamic Testing, a code is executed. It checks for functional behavior of
software system, memory/cpu usage and overall performance of the system. Hence the
name “Dynamic”
The main objective of this testing is to confirm that the software product works
in conformance with the business requirements. This testing is also called an Execution
technique or validation testing.
Dynamic testing executes the software and validates the output with the
expected outcome. Dynamic testing is performed at all levels of testing and it can be
either black or white box testing.
Dynamic Testing Techniques:
 Unit Testing: Under Unit Testing, individual units or modules are tested by the
developers. It involves testing of source code by developers.
 Integration Testing: Individual modules are grouped together and tested by the
developers. The purpose is to determine what modules are working as expected
once they are integrated.
 System Testing: System Testing is performed on the whole system by checking
whether the system or application meets the requirement specification
document.
Also, Non-functional testing like performance, Security Testing fall under the category of
dynamic testing.
Difference between Static and Dynamic Testing:
Static Testing Dynamic Testing
Testing was done without
Testing is done by executing the program
executing the program
This testing does the verification
Dynamic testing does the validation process
process
Static testing is about Dynamic testing is about finding and fixing the
prevention of defects defects
Static testing gives an
Dynamic testing gives bugs/bottlenecks in the
assessment of code and
software system.
documentation
Static testing involves a
checklist and process to be Dynamic testing involves test cases for execution
followed
This testing can be performed
Dynamic testing is performed after compilation
before compilation
129
Static testing covers the

Dynamic testing techniques are Boundary Value
structural and statement
Analysis & Equivalence Partitioning.
coverage testing
Cost of finding defects and fixing
Cost of finding and fixing defects is high
is less
Requires loads of meetings Comparatively requires lesser meetings
SOFTWARE MAINTENANCE
Software Maintenance is the process of modifying a software product after it
has been delivered to the customer. The main purpose of software maintenance is to
modify and update software applications after delivery to correct faults and to
improve performance.
Need for Maintenance
Software Maintenance must be performed in order to:
 Correct faults.
 Improve the design.
 Implement enhancements.
 Interface with other systems.
 Accommodate programs so that different hardware, software, system features, and
telecommunications facilities can be used.
 Migrate legacy software.
 Retire software.
Challenges in Software Maintenance:
The various challenges in software maintenance are given below:
 The popular age of any software program is taken into consideration up to ten to
fifteen years. As software program renovation is open ended and might maintain
for decades making it very expensive.
 Older software program’s, which had been intended to paintings on sluggish
machines with much less reminiscence and garage ability can not maintain
themselves tough in opposition to newly coming more advantageous software
program on contemporary-day hardware.
 Changes are frequently left undocumented which can also additionally reason
greater conflicts in future.
 As era advances, it turns into high priced to preserve vintage software program.
 Often adjustments made can without problems harm the authentic shape of the
software program, making it difficult for any next adjustments.
Types of Software Maintenance Services
There are four different types of software maintenance, which are defined
for various reasons and purposes. A software product may have to undergo one
or more types of maintenance throughout the software maintenance life cycle.
130
1. Adaptive Maintenance
Adaptive software maintenance is the process of conversion in the system
to keep the software compatible with changing business needs and technical
evolution. This type of software maintenance primarily focuses on software
frameworks. It is made in response to new operating systems, platforms, and
hardware to retain continuity with the software.
Adaptive software maintenance is about changing software in response to
changes in its environment.
The primary goal of adaptive software maintenance is to update and modify the
software when:
 The operating system on which your software executes is evolving (due to
technology, laws, policies, rules, operating system, etc.)
 End-users require the product to work with new hardware or software.
 You’ve foreseen software defects that will harm your customers in the future.
2. Perfective Maintenance
Perfective Maintenance is a process of modifying all elements,
functionalities, and abilities to enhance system operations and performance. The
software’s receptiveness and usability are solved by perfective software
maintenance. It includes altering current software functionality by improving,
removing, or inserting new features or functions.
Perfective software maintenance focuses on functional enhancements to improve
the user experience.
If you want to update the software system to improve its value as per the user
requirements, you can execute the perfective software maintenance. This
includes:
 Performance enhancement
 Enhanced user interfaces and software usability
 Better software functionality and performance
3. Corrective Maintenance
Identifying errors in the existing solution and correcting them to make it
works more accurately. This software maintenance activities aim to eliminate and
fix bugs or issues in the software. Corrective software maintenance is usuall y
done in the form of small updates frequently.
In a nutshell, corrective software maintenance occurs when there are
errors and faults in logic, code, and design.
Corrective software maintenance is about correcting software bugs, errors, and
defects.
131
You can implement corrective software maintenance when:

 Software doesn’t function properly due to some faulty logic flow, wrong
implementation, invalid or incomplete tests, etc.
 Users face issues with the software once it is published.
4. Preventive Maintenance
Preventive software maintenance service helps in preventing the system
from any forthcoming vulnerabilities. Preventive maintenance defines
improvements of the software, which is done to safeguard the software for the
future. It is carried out to prevent the product from any potential software
alteration. Preventive maintenance also makes it easier to scale or maintain your
code and handle your legacy system.
Preventive Software Maintenance defines the adaptions and modifications
of the software that mitigate the deterioration risk.
Preventive maintenance offers:
 Document updation as per the existing state of the system
 Code optimization for better software execution
 Reconstructing or reducing the code of the software to make it understandable
Software Maintenance Processes
In the life cycle of software development, a software maintenance plan is a
very crucial phase. Hence, it is executed in the system through a well -planned
software maintenance process which is known as Software Maintenance Life
Cycle (SMLC). SMLC is implemented in seven different phases. Those are:
Phase 1 – Identification
As the name goes, in this phase of the software maintenance life cycle, the
modifications are ‘identified’. Before implementing the changes for the requests
raised, the modifications are first analyzed and classified according to the
attention or maintenance it requires. This phase can be automated or manually
done by a user.
Phase 2 – Analysis
The practicality and feasibility of each verified modification request ar e
planned to incorporate changes in the software. The analysis includes validated
changes or input where the cost of modification is also estimated.
Phase 3 – Design
The new framework of the software is determined according to the result
of the analysis. Survey or test software is also developed for the purpose of safety
and security.
Phase 4 – Implementation
This is where the main or new software framework is implemented; as in,
the codes are crafted, and in the new support system, specifications are added.
Phase 5 – System Testing
In this testing, the implementation of codes and specifications are tested.
This stage determines if any further changes or additions are required in the ne w
model of software.
Phase 6 – Acceptance Testing
This stage is performed by third-party end-users. They run a dummy
software test, also known as a dry run test, to check if the implemented
specifications are working properly, which was mentioned in the mo dification
request.
132
Phase 7 – Delivery
As and when the testing phase is cleared and the developers get a green
signal from the third-party users, they deliver the software to the primary users.
Software Maintenance Models
There are many software maintenance models, but the most important models
are:
 Quick-Fix Model
 Iterative Enhancement Model
 Re-Use Oriented Model
Quick-Fix Model
Just how it sounds, the main aim of this model is to search for glitches and
fix them as soon as possible. The main advantage of the quick-fix model is that it
works very rapidly at a low price. The approach of this model is to modify the
coding with minimal consideration.
Iterative Enhancement Model
The primary nature of the changes in this model is iterative. Based on the
analysis of the existing system, the changes are incorporated in this model. It
requires complete documentation of the software that is available before making
any changes.
Re-Use Oriented Model
In this model, the part of the existing system that is in the position of using
is identified; hence it is called the ‘re-use-oriented model’. After analyzing, this
model goes through changes or enhancements as required.
Key Strategies for Successful Software Maintenance

There are two main techniques or strategies that we should consider for
successful software maintenance in software engineering.
Documentation – The process involves containing information related to code
operation. In addition, it also includes solutions to problems that may occur in
the near future. This makes the task of upgradation considerably easier.
QA (Quality Analysis) – Coming second in the list, the QA process can be
integrated either before the launch or during the planning stage itself. This will
make sure to deploy software without any errors or bugs.
133
REGRESSION TESTING
Regression Testing is the process of testing the modified parts of the code and
the parts that might get affected due to the modifications to ensure that no new errors
have been introduced in the software after the modifications have been made.
Regression means return of something and in the software field, it refers to the return
of a bug.
When to do regression testing?
 When a new functionality is added to the system and the code has been modified to
absorb and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is debugged to
fix it.
 When the code is modified to optimize its working.
Process of Regression Testing:
Firstly, whenever we make some changes to the source code for any reasons
like adding new functionality, optimization, etc. then our program when executed fails
in the previously designed test suite for obvious reasons. After the failure, the source
code is debugged in order to identify the bugs in the program.
After identification of the bugs in the source code, appropriate modifications
are made. Then appropriate test cases are selected from the already existing test suite
which covers all the modified and affected parts of the source code.
We can add new test cases if required. In the end regression testing is
performed using the selected test cases.
Techniques for the selection of Test cases for Regression Testing:

 Select all test cases: In this technique, all the test cases are selected from the
already existing test suite. It is the most simple and safest technique but not much
efficient.
 Select test cases randomly: In this technique, test cases are selected randomly
from the existing test-suite but it is only useful if all the test cases are equally good
in their fault detection capability which is very rare. Hence, it is not used in most of
the cases.
134
 Select modification traversing test cases: In this technique, only those test cases
are selected which covers and tests the modified portions of the source code the
parts which are affected by these modifications.
 Select higher priority test cases: In this technique, priority codes are assigned to
each test case of the test suite based upon their bug detection capability, customer
requirements, etc. After assigning the priority codes, test cases with highest
priorities are selected for the process of regression testing.
Test case with highest priority has highest rank. For example, test case with
priority code 2 is less important than test case with priority code 1.
Tools for regression testing: In regression testing, we generally select the test cases
form the existing test suite itself and hence, we need not to compute their expected
output and it can be easily automated due to this reason. Automating the process of
regression testing will be very much effective and time saving.
Most commonly used tools for regression testing are:
 Selenium
 WATIR (Web Application Testing In Ruby)
 QTP (Quick Test Professional)
 RFT (Rational Functional Tester)
 Winrunner
 Silktest
Advantages of Regression Testing:
 It ensures that no new bugs has been introduced after adding new functionalities to
the system.
 As most of the test cases used in Regression Testing are selected from the existing
test suite and we already know their expected outputs. Hence, it can be easily
automated by the automated tools.
 It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:

 It can be time and resource consuming if automated tools are not used.
 It is required even after very small changes in the code.
135
UNIT – V
SOFTWARE QUALITY AND METRICS
Definitions
Software metrics is a collective term used to describe the very wide range of
activities concerned with measurement in software engineering. These activities range
from producing numbers that characterize properties of software code (these are the
classic software ’metrics’) through to models that help predict software resource
requirement and software quality.
There’s two main concepts to define at this point : the measurement activity and
the software metrics.
So metrics origin goes back to the sixties with the Lines of Code (LOC) metric
used to measure programmer’s productivity and program quality. The main aim was to
provide information to support quantitative managerial decision-making during the
software lifecycle.
NEED OF OBJECT ORIENTED SOFTWARE ESTIMATION
What is needed for software estimation?
Ensure the estimate includes software support to systems engineering, system
and sub-system requirements definition, configuration management, quality
assurance, program management, system integration, and system test as
appropriate.
Software Estimation Process Considerations
The software estimating process consists of a series of activities that include estimating
the size of the software to be developed, modified, or reused; applying estimating
models and techniques; and analyzing, crosschecking, and reporting the results. The
following steps should be considered as part of any Software Size Estimating process:
 Develop a notional architecture for the system, and identify program
requirements likely to be satisfied by software.
 Identify potential Commercial off-the-Shelf (COTS), Government off-the-Shelf
(CGOTS), and other sources of Non-Developmental Items (NDI) software.
 Identify existing software that will be modified, including the size of the overall
software as well as the size of the expected modifications.
 Identify software that will be newly developed for this program to provide
functionality not available from existing software, or to adapt/integrate all the
necessary software components.
 Obtain software size information for all software elements, where size is
carefully defined and measured in one of the two standard software size
measures: non-comment Source Lines of Code (SLOC) or function points.
 Assess the uncertainty in the new and modified software sizes, based on
historical data (if available) and engineering judgment.
 Apply growth factors to new/modified and reuse software, based on past
experience and the level of uncertainty.
 Account for all remaining uncertainties as estimate risks.
 Improve the estimate over time.
136
LORENZ AND KIDD ESTIMATION

Mark Lorenz and Jeff Kidd in 1994 introduced eleven metrics to quantify
software quality evaluation which were applicable to class diagrams. The metrics were
categorized into three groups namely
(i). Class Size Metrics
(ii). Class Inheritance Metrics
(iii). Class Internals Metrics.
Each of these groups further contained metrics, which are listed as below:
(i). Class Size Metrics:- The Class size metrics dealt with quantifying a class by
counting the Number of Public Methods (NPM), Number of Methods (NM), Number of
Public Variables (NPV), Number of Variables per class (NV), Number of Class Variables
(NCV) and Number of Class Methods (NCM).
(ii). Class Inheritance Metrics:- Inheritance based quality measurement metrics
become part of class inheritance metrics namely, Number of Methods Inherited (NMI),
Number of Methods Overridden (NMO) and Number of New Methods (NNA).
(iii).Class Internals Metrics:- General features of classes are evaluated using class
internals metrics. Average Parameters per Method (APM) and Specialization IndeX (SIX)
are computed in this category. The Lorenz and Kidd Suite are criticized for being mere
counts of class properties. Counting the number of public methods and variables in
different ways does not evaluate quality factors.
Lorenz and Kidd Metrics
USE CASE POINTS METHOD

A Use-Case is a series of related interactions between a user and a system that
enables the user to achieve a goal.
Use-Cases are a way to capture functional requirements of a system. The user of
the system is referred to as an ‘Actor’. Use-Cases are fundamentally in text form.
Use-Case Points – Definition
Use-Case Points (UCP) is a software estimation technique used to measure the
software size with use cases. The concept of UCP is similar to FPs.
The number of UCPs in a project is based on the following −
 The number and complexity of the use cases in the system.
 The number and complexity of the actors on the system.
o Various non-functional requirements (such as portability, performance,
maintainability) that are not written as use cases.
137
o The environment in which the project will be developed (such as the

language, the team’s motivation, etc.)
Estimation with UCPs requires all use cases to be written with a goal and at
approximately the same level, giving the same amount of detail. Hence, before
estimation, the project team should ensure they have written their use cases with
defined goals and at detailed level. Use case is normally completed within a single
session and after the goal is achieved, the user may go on to some other activity.
Use-Case Points Counting Process
The Use-Case Points counting process has the following steps −
 Calculate unadjusted UCPs
 Adjust for technical complexity
 Adjust for environmental complexity
 Calculate adjusted UCPs
Step 1: Calculate Unadjusted Use-Case Points.
You calculate Unadjusted Use-Case Points first, by the following steps −
 Determine Unadjusted Use-Case Weight
 Determine Unadjusted Actor Weight
 Calculate Unadjusted Use-Case Points
Step 1.1 − Determine Unadjusted Use-Case Weight.
Step 1.1.1 − Find the number of transactions in each Use-Case.
If the Use-Cases are written with User Goal Levels, a transaction is equivalent to a step
in the Use-Case. Find the number of transactions by counting the steps in the Use-Case.
Step 1.1.2 − Classify each Use-Case as Simple, Average or Complex based on the
number of transactions in the Use-Case. Also, assign Use-Case Weight as shown in the
following table –
Use-Case Complexity Number of Transactions Use-Case Weight
Simple ≤3 5
Average 4 to 7 10
Complex >7 15
Step 1.1.3 − Repeat for each Use-Case and get all the Use-Case Weights. Unadjusted
Use-Case Weight (UUCW) is the sum of all the Use-Case Weights.
Step 1.1.4 − Find Unadjusted Use-Case Weight (UUCW) using the following table −
Use-Case Use-Case Number of Product
Complexity Weight Use-Cases
Simple 5 NSUC 5 × NSUC
Average 10 NAUC 10 × NAUC
Complex 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 ×

NCUC
NSUC is the no. of Simple Use-Cases.
NAUC is the no. of Average Use-Cases.
NCUC is the no. of Complex Use-Cases.
138
Step 1.2 − Determine Unadjusted Actor Weight.

An Actor in a Use-Case might be a person, another program, etc. Some actors, such as a
system with defined API, have very simple needs and increase the complexity of a Use-
Case only slightly.
Some actors, such as a system interacting through a protocol have more needs and
increase the complexity of a Use-Case to a certain extent.
Other Actors, such as a user interacting through GUI have a significant impact on the
complexity of a Use-Case. Based on these differences, you can classify actors as Simple,
Average and Complex.
Step 1.2.1 − Classify Actors as Simple, Average and Complex and assign Actor Weights
as shown in the following table −
Actor Complexity Example Actor Weight
Simple A System with defined API 1
Average A System interacting through a Protocol 2
Complex A User interacting through GUI 3

Step 1.2.2 − Repeat for each Actor and get all the Actor Weights. Unadjusted Actor
Weight (UAW) is the sum of all the Actor Weights.
Step 1.2.3 − Find Unadjusted Actor Weight (UAW) using the following table −
Actor Actor Number of Product
Complexity Weight Actors
Simple 1 NSA 1 × NSA
Average 2 NAA 2 × NAA
Complex 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA
NSA is the no. of Simple Actors.

NAA is the no. of Average Actors.
NCA is the no. of Complex Actors.
Step 1.3 − Calculate Unadjusted Use-Case Points.
The Unadjusted Use-Case Weight (UUCW) and the Unadjusted Actor Weight (UAW)
together give the unadjusted size of the system, referred to as Unadjusted Use-Case
Points.
Unadjusted Use-Case Points (UUCP) = UUCW + UAW
The next steps are to adjust the Unadjusted Use-Case Points (UUCP) for Technical
Complexity and Environmental Complexity.
139
Step 2: Adjust For Technical Complexity

Step 2.1 − Consider the 13 Factors that contribute to the impact of the Technical
Complexity of a project on Use-Case Points and their corresponding Weights as given
in the following table –
Factor Description Weight
T1 Distributed System 2.0
T2 Response time or throughput performance objectives 1.0
T3 End user efficiency 1.0
T4 Complex internal processing 1.0
T5 Code must be reusable 1.0
T6 Easy to install .5
T7 Easy to use .5
T8 Portable 2.0
T9 Easy to change 1.0
T10 Concurrent 1.0
T11 Includes special security objectives 1.0
T12 Provides direct access for third parties 1.0
T13 Special user training facilities are required 1.0

Step 2.2 − For each of the 13 Factors, assess the project and rate from 0 (irrelevant) to
5 (very important).
Step 2.3 − Calculate the Impact of the Factor from Impact Weight of the Factor and the
Rated Value for the project as
Impact of the Factor = Impact Weight × Rated Value
Step (2.4) − Calculate the sum of Impact of all the Factors. This gives the Total
Technical Factor (TFactor) as given in table below −
Factor Description Weight Rated Value Impact (I =
(W) (0 to 5) (RV) W × RV)
T1 Distributed System 2.0
T2 Response time or 1.0

throughput performance
objectives
140
T3 End user efficiency 1.0
T4 Complex internal 1.0

processing
T5 Code must be reusable 1.0
T6 Easy to install .5
T7 Easy to use .5
T8 Portable 2.0
T9 Easy to change 1.0
T10 Concurrent 1.0
T11 Includes special security 1.0

objectives
T12 Provides direct access for 1.0

third parties
T13 Special user training 1.0

facilities are required
Total Technical Factor (TFactor)

Step 2.5 − Calculate the Technical Complexity Factor (TCF) as −
TCF = 0.6 + (0.01 × TFactor)
Step 3: Adjust For Environmental Complexity

Step 3.1 − Consider the 8 Environmental Factors that could affect the project execution
and their corresponding Weights as given in the following table −
Factor Description Weight
F1 Familiar with the project model that is used 1.5
F2 Application experience .5
F3 Object-oriented experience 1.0
F4 Lead analyst capability .5
F5 Motivation 1.0
F6 Stable requirements 2.0
F7 Part-time staff -1.0
F8 Difficult programming language -1.0

Step 3.2 − For each of the 8 Factors, assess the project and rate from 0 (irrelevant) to 5
(very important).
141
Step 3.3 − Calculate the Impact of the Factor from Impact Weight of the Factor and the
Rated Value for the project as
Impact of the Factor = Impact Weight × Rated Value
Step 3.4 − Calculate the sum of Impact of all the Factors. This gives the Total
Environment Factor (EFactor) as given in the following table –
Factor Description Weight Rated Value Impact (I =
(W) (0 to 5) (RV) W × RV)
F1 Familiar with the project 1.5

model that is used
F2 Application experience .5
F3 Object-oriented 1.0
experience
F4 Lead analyst capability .5
F5 Motivation 1.0
F6 Stable requirements 2.0
F7 Part-time staff -1.0
F8 Difficult programming -1.0

language
Total Environment Factor (EFactor)

Step 3.5 − Calculate the Environmental Factor (EF) as −
1.4 + (-0.03 × EFactor)
Step 4: Calculate Adjusted Use-Case Points (UCP)
Calculate Adjusted Use-Case Points (UCP) as −
UCP = UUCP × TCF × EF
Advantages of Use-Case Points
 UCPs are based on use cases and can be measured very early in the project life
cycle.
 UCP (size estimate) will be independent of the size, skill, and experience of the
team that implements the project.
 UCP based estimates are found to be close to actuals when estimation is
performed by experienced people.
 UCP is easy to use and does not call for additional analysis.
 Use cases are being used vastly as a method of choice to describe requirements.
In such cases, UCP is the best suitable estimation technique.
Disadvantages of Use-Case Points
 UCP can be used only when requirements are written in the form of use cases.
 Dependent on goal-oriented, well-written use cases. If the use cases are not well
or uniformly structured, the resulting UCP may not be accurate.
 Technical and environmental factors have a high impact on UCP. Care needs to
be taken while assigning values to the technical and environmental factors.
 UCP is useful for initial estimate of overall project size but they are much less
useful in driving the iteration-to-iteration work of a team.
142
CLASS POINT METHOD

Class Point Approach (CPA) was introduced by Gennaro Cost- agliola et al. in 1998.
This was based on the function point analysis approach to represent the internal
attributes of a software system in terms of counting. The basic idea of the CPA technique
is quantification of classes in a program.
The process of Class Point size estimation is composed of three main phases,
corresponding to analogous phases in the FP approach.
1. Identification and Classification of User Classes
During the first step of the Class Point counting, the design specifications are
analyzed in order to identify and classify the classes. Generally, four types of system
components can be distinguished, namely the problem domain type (PDT), the human
interaction type (HIT), the data management type (DMT), and the task management
type (TMT).
The PDT component contains classes representing real-world entities in the
application domain of the system. Thus, taking as an example a distributed information
system for accident management as described, typical PDT classes are Incident,
FieldOfficer, and EmergencyReport.
The classes of HIT type are designed to satisfy the need for information
visualization and human-computer interaction. With regard to the previous example,
the classes EmergencyReportForm and ReportEmergencyButton belong to this type.
The DMT component encompasses the classes that offer functionality for data
storage and retrieval. In the example, a DMT component is the IncidentManagement
subsystem containing classes responsible for issuing SQL queries in order to store and
retrieve records representing Incidents in the database.
Finally, TMT classes are designed for task management purposes, thus they are
responsible for the definition and control of tasks such as ManageEmergencyControl
and ReportEmergencyControl. Moreover, such component also includes classes
responsible for the communication between subsystems allocated to different
computers, and classes responsible for the communication with external systems. As a
matter of fact, Message and Connection are typical classes falling within this component.
2. Evaluation of a Class Complexity Level
In the Class Point approach, the behavior of each class component is taken into
account in order to evaluate its complexity level. The difference between the CP1 and
CP2 measures lies in the way such a complexity level is determined.
In particular, in CP1 the number of external methods and the number of services
requested are taken into account; whereas, in CP2, the number of attributes is also
exploited.
The Number of External Methods (NEM) measures the size of the interface of a
class and is determined by the number of locally defined public methods. The Number
of Services Requested (NSR) provides a measure of the interconnection of system
components. It is again applicable to a single class and is determined by the number of
different services requested from other classes. Both measures are available in design
documentation.
Indeed, activities that characterize any OO design process include the
identification of the classes with their attributes and methods.
A measure similar to NSR was proposed by Li and Henry. Such a measure,
named Message Passing Coupling (MPC), was introduced to measure the
interdependence among classes determined by the number of messages sent by each
class.
143
Compared to MPC, the NSR counting requires less detail and can be performed
during analysis and early design. As for CP1, the complexity level of a class is assigned
based on the NSR and NEM range values according to Table.
Each class is then weighted in agreement with its type and its level of
complexity. For example, if a class has more than nine NEM and the NSR value is not less
than 2, it is assigned a high complexity level.
When computing CP2, the number of attributes is also taken into account in
order to evaluate the complexity level of a class. Thus, in CP2, the measure NOA has
been considered as an additional parameter giving rise to Tables 3a, 3b, and 3c. Each
table is related to a fixed NSR range and indexed on NEM and NOA.
3. Estimating the Total Unadjusted Class Point
144
4. Technical Complexity Factor Estimation

The Technical Complexity Factor (TCF) is determined by assigning the degree of
influence (ranging from 0 to 5) that 18 general system characteristics have on the
application, from the designer’s point of view. The estimates given for the degrees of
influence are recorded in the Processing Complexity table illustrated in Fig. 1.
The sum of the influence degrees related to such general system characteristics
forms the Total Degree of Influence (TDI), which is used to determine the TCF according
to the following formula:
The CP count can vary with respect to the unadjusted count from -45 percent
(corresponding to a null TDI) to +45 percent (corresponding to all degrees set to 5), due
to the adjustment factor.
A Class Point calculation worksheet (Fig. 6) is shown in the Appendix.
145
It is worth noting that the Technical Complexity Factor is determined by taking into
account the characteristics that are considered in the FP method and some additional
characteristics especially conceived for object-oriented systems, namely:
User Adaptivity
Rapid Prototyping
Multiuser Interactivity
Multiple Interfaces
146
FUNCTION POINT METHOD

OBJECT ORIENTED FUNCTION POINT
Function Points
Goals of the Function Points
• Function points are a measurement of the software product based on the user’s
function information treatment.
• Function points measure software by counting number of functionality of the
information’s treatment associated with external and control data, output and files
types.
• This particular treatment is adjusted for the global function of information treatment
by applying an adjustment based on the software characteristics.
Reliability of the function point’s method
• Correctness : from the same data and rules, the same results must always be
obtained.
• Repetitiveness : it doesn’t matter the person who makes the measurement,
results must always be exactly the same at different time. According industrial
experiments the observed accuracy is more or less 95%.
A Function Point (FP) is a unit of measurement to express the amount of
business functionality, an information system (as a product) provides to a user. FPs
measure software size. They are widely accepted as an industry standard for functional
sizing.
For sizing software based on FP, several recognized standards and/or public
specifications have come into existence. As of 2013, these are −
147
ISO Standards
 COSMIC − ISO/IEC 19761:2011 Software engineering. A functional size
measurement method.
 FiSMA − ISO/IEC 29881:2008 Information technology - Software and systems
engineering - FiSMA 1.1 functional size measurement method.
 IFPUG − ISO/IEC 20926:2009 Software and systems engineering - Software
measurement - IFPUG functional size measurement method.
 Mark-II − ISO/IEC 20968:2002 Software engineering - Ml II Function Point
Analysis - Counting Practices Manual.
 NESMA − ISO/IEC 24570:2005 Software engineering - NESMA function size
measurement method version 2.1 - Definitions and counting guidelines for the
application of Function Point Analysis.
Object Management Group Specification for Automated Function Point
Object Management Group (OMG), an open membership and not-for-profit
computer industry standards consortium, has adopted the Automated Function Point
(AFP) specification led by the Consortium for IT Software Quality.
It provides a standard for automating FP counting according to the guidelines of
the International Function Point User Group (IFPUG).
Function Point Analysis (FPA) technique quantifies the functions contained within
software in terms that are meaningful to the software users. FPs consider the number
of functions being developed based on the requirements specification.
Function Points (FP) Counting is governed by a standard set of rules, processes and
guidelines as defined by the International Function Point Users Group (IFPUG). These
are published in Counting Practices Manual (CPM).
Elementary Process (EP)
Elementary Process is the smallest unit of functional user requirement that −
 Is meaningful to the user.
 Constitutes a complete transaction.
 Is self-contained and leaves the business of the application being counted in a
consistent state.
Functions
There are two types of functions −
 Data Functions
 Transaction Functions
Data Functions
There are two types of data functions −
 Internal Logical Files
 External Interface Files
Data Functions are made up of internal and external resources that affect the system.
Internal Logical Files
Internal Logical File (ILF) is a user identifiable group of logically related data or
control information that resides entirely within the application boundary. The primary
intent of an ILF is to hold data maintained through one or more elementary processes
of the application being counted. An ILF has the inherent meaning that it is internally
maintained, it has some logical structure and it is stored in a file.
External Interface Files

External Interface File (EIF) is a user identifiable group of logically related data
or control information that is used by the application for reference purposes only.
148
The data resides entirely outside the application boundary and is maintained in
an ILF by another application. An EIF has the inherent meaning that it is externally
maintained, an interface has to be developed to get the data from the file.
Transaction Functions
There are three types of transaction functions.
 External Inputs
 External Outputs
 External Inquiries
Transaction functions are made up of the processes that are exchanged between the
user, the external applications and the application being measured.
External Inputs
External Input (EI) is a transaction function in which Data goes “into” the application
from outside the boundary to inside. This data is coming external to the application.
 Data may come from a data input screen or another application.
 An EI is how an application gets information.
 Data can be either control information or business information.
 Data may be used to maintain one or more Internal Logical Files.
 If the data is control information, it does not have to update an Internal Logical
File.
External Outputs
External Output (EO) is a transaction function in which data comes “out” of the
system. Additionally, an EO may update an ILF. The data creates reports or output files
sent to other applications.
External Inquiries
External Inquiry (EQ) is a transaction function with both input and output
components that result in data retrieval.
Definition of RETs, DETs, FTRs
Record Element Type
A Record Element Type (RET) is the largest user identifiable subgroup of
elements within an ILF or an EIF. It is best to look at logical groupings of data to help
identify them.
149
Data Element Type

Data Element Type (DET) is the data subgroup within an FTR. They are unique
and user identifiable.
File Type Referenced
File Type Referenced (FTR) is the largest user identifiable subgroup within the
EI, EO, or EQ that is referenced to.
The transaction functions EI, EO, EQ are measured by counting FTRs and DETs that they
contain following counting rules. Likewise, data functions ILF and EIF are measured by
counting DETs and RETs that they contain following counting rules. The measures of
transaction functions and data functions are used in FP counting which results in the
functional size or function points.
RISK MANAGEMENT
What is Risk Management?
Risk management is the process of identifying, assessing, and prioritizing the
risks to minimize, monitor, and control the probability of unfortunate events.
Risk Management Process:
Risk Management process can be easily understood with use of the following
workflow:
Risk Management Practices:

 Software Risk Evaluation (SRE)
 Continuous Risk Management (CRM)
 Team Risk Management (TRM)
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel,
resource, and customer-related problems. A vital project risk is schedule slippage. Since
the software is intangible, it is very tough to monitor and control a software project. It is
very tough to control something which cannot be identified. For any manufacturing
program, such as the manufacturing of cars, the plan executive can recognize the
product taking shape.
2. Technical risks: Technical risks concern potential method, implementation,
interfacing, testing, and maintenance issue. It also consists of an ambiguous
specification, incomplete specification, changing specification, technical uncertainty,
and technical obsolescence. Most technical risks appear due to the development team's
insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an excellent product that
no one need, losing budgetary or personnel commitments, etc.
150
Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of
the project program, the business and technical environment in which the plan is
being developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely
tough to identify in advance.
Principle of Risk Management
1. Global Perspective: In this, we review the bigger system description, design,
and implementation. We look at the chance and the impact the risk is going to
have.
2. Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
3. Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about the
risks.
4. Integrated management: In this method risk management is made an integral
part of project management.
5. Continuous process: In this phase, the risks are tracked continuously
throughout the risk management paradigm.
SOFTWARE QUALITY MODELS
What are software quality models?
Software Quality Models are a standardised way of measuring a software
product. ... Product revision deals with maintainability, flexibility and testability,
product operation is about correctness, reliability, efficiency and integrity.
Following are few models that explains what kind of quality criteria is to be followed.
Mc Call's Model
Mccall Model is the first quality model developed, which defines a layout of the
various aspects that define the product's quality. It defines the product quality in the
following manner – Product Revision, Product Operation, Product Transition. Product
revision deals with maintainability, flexibility and testability, product operation is about
correctness, reliability, efficiency and integrity.
Boehm Model
This model describes how easily and reliably a software product can be used.
This model actually elaborates the aspects of McCall model in detail. It begins with the
characteristics that resorts to higher level requirements. The model's general utility is
divided into various factors - portability, efficiency and human engineering, which are
the refinement of factors like portability and utility. Further maintainability is refined
into testability, understandability and modifiability.
FURPS Model
This model categorises requirements into functional and non-functional
requirements. The term FURPS is an acronym for Functional requirement(F) which
relies on expected input and output, and in non functional requirements (U) stands
for Usability which includes human factors, aesthetic, documentation of user
material of training, (R) stands for reliability(frequency and severity of failure, time
among failure), (P) stands for Performance that includes functional requirements,
and finally (S) stands for supportability that includes backup, requirement of design
and implementation etc.
151
Ghezzi Model
This model states that the internal qualities of a software help the software
developers to attain a collaborative result both in terms of external and internal
qualities of a software. The overall qualities can be accuracy, flexibility, integrity,
maintainability, portability, reliability, re-usability and usability.
IEEE Model
It is a standard which defines various specifications for software maintenance,
thus providing a quality model. This model gives a variety of measurement
techniques for various qualitative factors like efficiency, functionality,
maintainability, portability, reliability and usability.
Dromey's Quality Model
This model emphasises on evaluating one software's quality with another. It
helps to find out defects if any, and also to point out the factors that caused such
defects. This model is designed on the basis of the relationship that exist between
software properties and its quality attributes.
SATC's Model
SATC is an acronym for Software Assurance Technology Centre. Its objective is to
improve software quality by defining metrics program which helps to meet the basic
needs with least expenditure. This model tests a quality model by evaluating the
results of the metrics used, and also on the basis of discussions based on the project.
This model defines set of goals and process attributes based on the structure of ISO
9126-1 quality model.
ISO 9126-1 Quality Model
This model has two primary categories – internal and external quality attributes
and quality in use attributes. The internal quality attributes are the properties of the
system the evaluation of which can be done without executing it. Whereas the
external quality attributes are those that are evaluated by observing the system
during execution.
Capability Maturity Model
One of the most important quality models of software quality maintenance. The
model lays down a very simple approach to define the quality standards. It has five
levels namely – initial, repeatable, defined, managed, optimizing.
Importance of software quality models :
 With the growing number of customer's demand for software systems, the
expectations for quality has also grown in terms of how reliable a software product will
be.
 As we know a software application is quite complex in nature, hence the task of
verifying whether a specific functionality has been implemented or not, becomes quite
difficult. Therefore software developers often divide the tasks in the form of
deliverables, that is, defining a benchmark to mark the completion of one specific task.
 If the errors in some of the previous phases are not rectified on time, then it may
lead to that error being carried over to the next consecutive phases, which may have a
serious problem in the later stages of the project.
ANALYZING THE METRIC DATA
After collecting relevant data, we have to analyze it in an appropriate way. There are
three major items to consider for choosing the analysis technique.
 The nature of data
 The purpose of the experiment
 Design considerations
152
The Nature of Data

To analyze the data, we must also look at the larger population represented by
the data as well as the distribution of that data.
Sampling, population, and data distribution
Sampling is the process of selecting a set of data from a large population. Sample
statistics describe and summarize the measures obtained from a group of experimental
subjects.
Population parameters represent the values that would be obtained if all
possible subjects were measured.
The population or sample can be described by the measures of central tendency
such as mean, median, and mode and measures of dispersion such as variance and
standard deviation. Many sets of data are distributed normally as shown in the
following graph.
As shown above, data will be evenly distributed about the mean. which is the
significant characteristics of a normal distribution.
Other distributions also exist where the data is skewed so that there are more data
points on one side of the mean than other. For example: If most of the data is present
on the left-hand side of the mean, then we can say that the distribution is skewed to the
left.
The Purpose of the Experiment
Normally, experiments are conducted −
 To confirm a theory
 To explore a relationship
To achieve each of these, the objective should be expressed formally in terms of the
hypothesis, and the analysis must address the hypothesis directly.
To confirm a theory
The investigation must be designed to explore the truth of a theory. The theory
usually states that the use of a certain method, tool, or technique has a particular effect
on the subjects, making it better in some way than another.
There are two cases of data to be considered: normal data and non-normal
data.
If the data is from a normal distribution and there are two groups to compare
then, the student’s t test can be used for analysis. If there are more than two groups to
compare, a general analysis of variance test called F-statistics can be used.
If the data is non-normal, then the data can be analyzed using Kruskal-Wallis
test by ranking it.
To explore a relationship
Investigations are designed to determine the relationship among data points
describing one variable or multiple variables.
There are three techniques to answer the questions about a relationship: box plots,
scatter plots, and correlation analysis.
153
 A box plot can represent the summary of the range of a set of data.
 A scatter plot represents the relationship between two variables.
 Correlation analysis uses statistical methods to confirm whether there is a true
relationship between two attributes.
o For normally distributed values, use Pearson Correlation Coefficient to
check whether or not the two variables are highly correlated.
o For non- normal data, rank the data and use the Spearman Rank
Correlation Coefficient as a measure of association. Another measure
for non-normal data is the Kendall robust correlation coefficient,
which investigates the relationship among pairs of data points and can
identify a partial correlation.
If the ranking contains a large number of tied values, a chi-squared test on a
contingency table can be used to test the association between the variables.
Similarly, linear regression can be used to generate an equation to describe the
relationship between the variables.
For more than two variables, multivariate regression can be used.
Design Considerations
The investigation’s design must be considered while choosing the analysis
techniques. At the same time, the complexity of analysis can influence the design
chosen. Multiple groups use F-statistics rather than Student’s T-test with two groups.
For complex factorial designs with more than two factors, more sophisticated test of
association and significance is needed.
Statistical techniques can be used to account for the effect of one set of variables
on others, or to compensate for the timing or learning effects.
METRICS FOR MEASURING SIZE AND STRUCTURE
Size measures
Object-Oriented systems generally grow in size between requirements analysis
and the testing phase. So different research have been done on this topics. Pfleeger used
objects and methods as a basic size measurements which is more accurate than
COCOMO according to commercial applications.
An other method has been developed by Lorenz and Kidd. They defined nine
aspects of size that reflect how the class characteristics affect the product. They propose
the following aspects :
Number of scenario scripts (NSS) : It’s the number of scenario scripts counted
in the use cases. This measure is correlated with application size and the number of
tests. NSS mainly allow to predict development and testing efforts.
Number of key classes : This measure evaluate the high-design effort.
Number of support classes : This measures evaluates the low-level design.
Average number of support classes per key class : This measure gives an idea
of the system’s structure.
Number of subsystems : This one provide more information on the system’s
structure.
Class size : This measure include the number of operations and attributes.
Number of operations overridden by a class : Allow to evaluate inheritance
effects.
Number of operations added by a subclass : Measures also the inheritance
effects.
154
Measuring the Structure

Measurement of structural properties of a software is important for estimating
the development effort as well as for the maintenance of the product. The structure of
requirements, design, and code helps understand the difficulty that arises in converting
one product to another, in testing a product, or in predicting the external software
attributes from early internal product measures.
Types of Structural Measures
The structure of software has three parts. They are −
 Control-flow structure − It is the sequence in which instructions are executed
in a program.
 Data-flow structure − It is the behavior of the data as it interacts with the
program.
 Data structure − It is the organization of the data elements in the form of lists,
queue, stacks, or other well-defined structures along with algorithm for
creating, modifying, or deleting them.
Measuring Control-Flow Structure
The control flow measures are usually modeled with directed graph, where each
node or point corresponds to program statements, and each arc or directed edge
indicates the flow of control from one statement to another. Theses graphs are called
control-flow graph or directed graph.
If ‘m’ is a structural measure defined in terms of the flow graph model, and if
program A is structurally more complex than program B, then the
measure m(A) should be greater than m(B).
Measuring Data-Flow Structure
Data flow or information flow can be inter-modular (flow of information within
the modules) or intra-modular (flow of information between individual modules and
the rest of the system).
According to the way in which data is moving through the system, it can be classified
into the following −
 Local direct flow − If either a module invokes a second module and passes
information to it or the invoked module returns a result to the caller.
 Local indirect flow − If the invoked module returns information that is
subsequently passed to a second invoked module.
 Global flow − If information flows from one module to another through a global
data structure.
Information flow complexity can be expressed according to Henry and Kafura as,
Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))2
Where,
 Fan-in (M) − The number of local flows that terminate at M + the number of
data structures from which the information is retrieved by M.
 Fan–out (M) − The number of local flows that emanate from M + the number of
data structures that are updated by M.
Measuring Data Structure
Data structure can be both local and global.
Locally, the amount of structure in each data item will be measured. A graph-
theoretic approach can be used to analyze and measure the properties of individual
data structures. In that simple data types such as integers, characters, and Booleans are
viewed as primes and the various operations that enable us to build more complex
data structures are considered.
155
Data structure measures can then be defined hierarchically in terms of values

for the primes and values associated with the various operations.
Globally, a count of the total number of user-defined variables will be measured.
MEASURING SOFTWARE QUALITY
Measuring Software Quality using Quality Metrics
In Software Engineering, Software Measurement is done based on some Software
Metrics where these software metrics are referred to as the measure of various
characteristics of a Software.
In Software engineering Software Quality Assurance (SAQ) assures the quality of
the software. Set of activities in SAQ are continuously applied throughout the software
process. Software Quality is measured based on some software quality metrics.
There is a number of metrics available based on which software quality is measured.
But among them, there are few most useful metrics which are most essential in software
quality measurement. They are –
1. Code Quality
2. Reliability
3. Performance
4. Usability
5. Correctness
6. Maintainability
7. Integrity
8. Security
1. Code Quality –
Code quality metrics measure the quality of code used for the software project
development. Maintaining the software code quality by writing Bug-free and
semantically correct code is very important for good software project development. In
code quality both Quantitative metrics like the number of lines, complexity, functions,
rate of bugs generation, etc, and Qualitative metrics like readability, code clarity,
efficiency, maintainability, etc are measured.
2. Reliability –
Reliability metrics express the reliability of software in different conditions. The
software is able to provide exact service at the right time or not is checked. Reliability
can be checked using Mean Time Between Failure (MTBF) and Mean Time To Repair
(MTTR).
3. Performance –
Performance metrics are used to measure the performance of the software. Each
software has been developed for some specific purposes. Performance metrics measure
the performance of the software by determining whether the software is fulfilling the
user requirements or not, by analyzing how much time and resource it is utilizing for
providing the service.
4. Usability –
Usability metrics check whether the program is user-friendly or not. Each
software is used by the end-user. So it is important to measure that the end-user is
happy or not by using this software.
5. Correctness –
Correctness is one of the important software quality metrics as this checks
whether the system or software is working correctly without any error by satisfying the
user. Correctness gives the degree of service each function provides as per developed.
156
6. Maintainability –
Each software product requires maintenance and up-gradation. Maintenance is
an expensive and time-consuming process. So if the software product provides easy
maintainability then we can say software quality is up to mark. Maintainability metrics
include time requires to adapt to new features/functionality, Mean Time to Change
(MTTC), performance in changing environments, etc.
7. Integrity –
Software integrity is important in terms of how much it is easy to integrate with
other required software’s which increases software functionality and what is the
control on integration from unauthorized software’s which increases the chances of
cyberattacks.
8. Security –
Security metrics measure how much secure the software is? In the age of cyber
terrorism, security is the most essential part of every software. Security assures that
there are no unauthorized changes, no fear of cyber attacks, etc when the software
product is in use by the end-user.
OBJECT ORIENTED METRICS
Object Oriented Metrices in Software Engineering
These are used to determine success or failure of a person also to quantify the
improvements in the software throughout its process. These metrics can be used to
reinforce good OO programming technique which lead to more reliable code. Object-
oriented software engineering metrics are units of measurement that are used to
characterize:
 object-oriented software engineering products, e.g., designs source code, and the
test cases.
 object-oriented software engineering processes, e.g., designing and coding.
 object-oriented software engineering people, e.g., productivity of an individual
designer.
Why are Object-Oriented Software Engineering Metrics Different?
OOSE is different because of the following reasons as depicted in the following figure:
Localization : It is the process of placing items in close physical nearness to each

other.
 Functional decomposition processes localize information around functions.
 Data-driven approaches localize information around data.
 Object-oriented approaches localize information around objects.
In object-oriented software , from the name suggests the localization is based on
objects. This means:
 Although we may speak of the functionality provided by an object, atleast some of
our metrics identification and gathering effort must recognize the “object” as basic
unit of software.
157
 Within systems of objects, localization between functionality and objects is not one-
to-one relationships. For example, there are many objects for one function and also
one object can have many functions.
Encapsulation : It is the packaging of a collection of items.
 Low-level examples of encapsulation include records and arrays.
 Subprograms are mid level mechanisms for encapsulation.
 There are still very long encapsulation mechanisms for the object-oriented
programming languages, e.g., C++’s, classes, Ada’s packages, and Modula 3’s
modules.
 Objects encapsulates:
 Knowledge of state
 Advertised capabilities
 Other objects
 Exceptions
 Constants
 Concepts
Information Hiding: It is the suppression or hiding of the objects.
 We show only the information which is needed to accomplish our goals.
 Degree of information hiding ranges from partially restricted visibility to total
invisibility.
 Encapsulation and information hiding are not same thing e.g., an item can be
encapsulated but still be to totally visible.
It plays a direct role in such metrics as object coupling and the degree of information
hiding.
Inheritance: It is mechanism where one object acquires the characteristics from one,
or more , other objects.
 Some object-oriented languages support only single inheritance.
 Some object-oriented languages support only multiple inheritance.
 Inheritance type and their semantics vary from language to language.
There are many object-oriented software engineering metrices which are based on
inheritance e.g.,
 number of children
 number of parents
 class hierarchy nesting level
Abstraction: It is the mechanism where we focus only on important details of a
concept, while ignoring the in essential details.
 It is a relative concept.
 There are also different categories of abstraction, e.g., functional data, process and
object abstraction.
 Objects are treated as high-level entities in object abstraction.
Classes: There are three commonly used views on the definition for “class”.
 Class as a cookie cutter: For the structurally identically items, a class is a pattern,
template, or a blueprint. The items which can be created using class are called
instances.
 Class as an instance factory: Basically class is a thing which contains both a pattern
and a mechanism for creating items based on that pattern and instances are like
individual items that are “manufactured” by using class creation mechanism.
 A class is a set of all the items which are created using a specific pattern, i.e., the
class is the set of all instances of that pattern.
158

OOSE

Uploaded by

Copyright:

Available Formats

OOSE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOSE

Uploaded by

Copyright:

Available Formats

MC4102 OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT I SOFTWARE DEVELOPMENT AND PROCESS MODELS

Introduction to Software Development – Challenges – An Engineering Perspective – Object

UNIT II MODELLING OO SYSTEMS

Object Oriented Analysis (OOA / Coad-Yourdon), Object Oriented Design (OOD/Booch),

UNIT III DESIGN PATTERNS

UNIT IV SYSTEM TESTING

Software testing: Software Verification Techniques – Object Oriented Checklist :-

UNIT V SOFTWARE QUALITY AND METRICS

Introduction to Software Development

1.“Software development refers to a set of computer science activities

3. Software itself is the set of instructions or programs that tell a computer

There are three basic types:

 System software to provide core functions such as operating systems, disk

Types of Software Devolpment

Challenge 1: Project Infrastructure

Challenge 2: Design Influences

Challenge 3: Security Infrastructure

 Look beyond technology to improve the security of the software

What is an engineering perspective?

A collection of short articles and opinions on a variety of subjects, though

Software Engineering Definition

Software engineering is the application of various approaches and practices

 Another trait most successful engineers possess is the ability to effectively

Back-end engineers rely on different databases, caches, programming languages

Full Stack Engineer

In an object-oriented system, all data is represented as discrete objects with

Encapsulation is defined as wrapping up or combining the data and code into

Inheritance is defined as one object derives or inherits the properties and

Inheritance promotes re-usability.

Polymorphism means many forms. More generally it is defined as one interface

Structured Paradigm Vs Object Oriented Paradigm

In programming languages following structured paradigm or procedural

Object Oriented Paradigm

It is the responsibility of John object to process the message getApples(10) and

1>>Requirements Analysis and Resource Planning

This is actually a continuous process of software development, and testing is

6>>Maintenance and Updates

Iterative Development Process

During the five iteration steps, the following activities occur:

o Analyze or review the system requirements.

Advantages of the iterative development

Disadvantages of the iterative development

Familiarity with technology

Software Development Life Cycle (SDLC)

Stage4: Developing the project

Life Cycle Models

The Rapid Application Development (RAD model) is based on iterative development

It focuses on input-output source and destination of the information. It

It involves the following phases:

On basis of the flow of information and distribution between various

The information collected from business modeling is refined into a set of

Testing and Turnover:

As prototypes are individually tested during every iteration, the overall

2. It is useful when you have to 2.Not all application is

3.It is adaptable and flexible to 3.When technical risk is high, it is

Spiral Model (SDM)

Incremental Model is a process of software development where requirements

Implementation phase enables the coding phase of the development system. It

o Errors are easy to be recognized. o Need for good planning