Unit II Requirements and Design

The software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected
from client’s point of view.

Requirement Engineering
The process to gather the software requirements from client, analyze and document them
is known as requirement engineering. The goal of requirement engineering is to develop
and maintain sophisticated and descriptive ‘System Requirements Specification’
document.

Requirement Engineering Process It is a four step process,

Which includes –

 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation

Let us see the process briefly –

Feasibility study

When the client approaches the organization for getting the desired product developed,
it comes up with rough idea about what all functions the software must perform and
which all features are expected from the software. Referencing to this information, the
analysts does a detailed study about whether the desired system and its functionality are
feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of implementation,
contribution of project to organization, cost constraints and as per values and objectives
of the organization.
It explores technical aspects of the project and product such as usability, maintainability,
and productivity and integration ability. The output of this phase should be a feasibility
study report that should contain adequate comments and recommendations for the
management about whether or not the project should be undertaken.
Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user. Analysts and engineers communicate with the
client and end-users to know their ideas on what the software should provide and which
features they want the software to include.

Software Requirement Specification

SRS is a document created by the system analyst after the requirements are collected from
various stakeholders. SRS defines how the intended software will interact with hardware,
external interfaces, speed of operation, response time of system, portability of software
across various platforms, maintainability, speed of recovery after crashing, Security,
Quality, Limitations etc. The requirements received from client are written in natural
language. It is the responsibility of system analyst to document the requirements in
technical language so that they can be comprehended and useful by the software
development team.

SRS should come up with following features:

 User requirements are expressed in natural language.

 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this

document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly.
This results in huge increase in cost if not nipped in the bud.

Requirements can be checked against following conditions –

 If they can be practically implemented

 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Requirement Elicitation Process

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really
need.

Requirements elicitation Activities:

Requirements elicitation includes the subsequent activities. Few of them are listed
below –

 Knowledge of the overall area where the systems is applied.

 The details of the precise customer problem where the system are going to be
applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.

Requirements elicitation Activities:

Requirements elicitation includes the subsequent activities. Few of them are listed
below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system are going to be
applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.

Requirements elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below
–

1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5.
6. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.
1. Interviews:

Objective of conducting an interview is to understand the customer’s expectations from

the software.
It is impossible to interview every stakeholder hence representatives from groups are
selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be
asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.

2. Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their
priority if possible.

3. Facilitated Application Specification Technique:

It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.

A team oriented approach is developed for requirements gathering.

Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system\

Each participant prepares his/her list, different lists are then combined, redundant entries
are eliminated, team is divided into smaller sub-teams to develop mini-specifications and
finally a draft of specifications is written down using all the inputs from the meeting.
Structured Analysis

Structured Analysis is a development method that allows the analyst to understand the system and
its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an
existing system and develop a new system specification which can be easily understandable by
user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development. They
are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.
 It shows the flow of data between various functions of system and specifies how the current
system is implemented.
 It is an initial stage of design phase that functionally divides the requirement specifications
down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst or analyst
and system designer.
 It gives an overview of what data a system processes, what transformations are performed,
what data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user
wants a notational language for communication. However, it requires a large number of iterations
for obtaining the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Components of Data Flow Diagram:

Following are the components of the data flow diagram that are used to represent
source, destination, storage and flow of data.
 Entities:
Entities include source and destination of the data. Entities are represented by
rectangle with their corresponding names.
 Process:
The tasks performed on the data is known as process. Process is represented by
circle. Somewhere round edge rectangles are also used to represent process.
 Data Storage:
Data storage includes the database of the system. It is represented by rectangle with
both smaller sides missing or in other words within two parallel lines.
 Data Flow:
The movement of data in the system is known as data flow. It is represented with the
help of arrow. The tail of the arrow is source and the head of the arrow is
destination.

Types of DFD
DFDs are of two types:
Physical DFD and Logical DFD.
The following table lists the points that differentiate a physical DFD from a
logical DFD.
 Physical DFD Logical DFD

It is implementation dependent. It It is implementation independent. It

shows which functions are performed. focuses only on the flow of data between
processes.

It provides low level details of It explains events of systems and data

hardware, software, files, and people. required by each event.

It depicts how the current system It shows how business operates; not how
operates and how a system will be the system can be implemented.
implemented.

Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the descriptions
of all DFD data elements that is, details and definitions of data flows, data stores, data stored in
data stores, and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard feature.
For example, refer the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.
For example, refer the following decision tree −

Requirements validation
Requirements validation is the process of checking that requirements defined for
development, define the system that the customer really wants. To check issues related
to requirements, we perform requirements validation. We usually use requirements
validation to check error at the initial phase of development as the error may increase
excessive rework when detected later in the development process.

In the requirements validation process, we perform a different type of test to check the
requirements mentioned in the Software Requirements Specification (SRS), these
checks include:
 Completeness checks
 Consistency checks
 Validity checks
 Realism checks
 Ambiguity checks
 Verifiability

The output of requirements validation is the list of problems and agreed on actions of
detected problems. The lists of problems indicate the problem detected during the
process of requirement validation. The list of agreed action states the corrective action
that should be taken to fix the detected problem.

There are several techniques which are used either individually or in conjunction with
other techniques to check to check entire or part of the system:

1. Test case generation:

Requirement mentioned in SRS document should be testable, the conducted tests
reveal the error present in the requirement. It is generally believed that if the test is
difficult or impossible to design than, this usually means that requirement will be
difficult to implement and it should be reconsidered.
2. Prototyping:
In this validation techniques the prototype of the system is presented before the end-
user or customer, they experiment with the presented model and check if it meets
their need. This type of model is generally used to collect feedback about the
requirement of the user.
3. Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including
people from both the contractor organizations and the client side, the reviewer
systematically analyses the document to check error and ambiguity.
4. Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as no determinism,
missing cases, a type error, and circular definitions, in requirements specifications.
First, the requirement is structured in formal notation then CASE tool is used to
check in-consistency of the system, The report of all inconsistencies is identified
and corrective actions are taken.

5. Walk-through:
A walkthrough does not have a formally defined procedure and does not require a
differentiated role assignment.
 Checking early whether the idea is feasible or not.
  Obtaining the opinions and suggestion of other people.
 Checking the approval of others and reaching an agreement.

Computer aided software engineering (CASE)

Computer aided software engineering (CASE) is the implementation of computer

facilitated tools and methods in software development. CASE is used to ensure a high-
quality and defect-free software. CASE ensures a check-pointed and disciplined approach
and helps designers, developers, testers, managers and others to see the project milestones
during development.
CASE can also help as a warehouse for documents related to projects, like business plans,
requirements and design specifications. One of the major advantages of using CASE is
the delivery of the final product, which is more likely to meet real-world requirements as
it ensures that customers remain part of the process.

CASE illustrates a wide set of labor-saving tools that are used in software development.
It generates a framework for organizing projects and to be helpful in enhancing
productivity. There was more interest in the concept of CASE tools years ago, but less so
today, as the tools have morphed into different functions, often in reaction to software
developer needs. The concept of CASE also received a heavy dose of criticism after its
release.

CASE Tools:

The essential idea of CASE tools is that in-built programs can help to analyze developing
systems in order to enhance quality and provide better outcomes. Throughout the 1990,
CASE tool became part of the software lexicon, and big companies like IBM were using
these kinds of tools to help create software.
Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development life cycle.
Types of CASE Tools:

1. Diagramming Tools:

It helps in diagrammatic and graphical representations of the data and system

processes. It represents system elements, control flow and data flow among different
software components and system structure in a pictorial form.
For example, Flow Chart Maker tool for making state-of-the-art flowcharts.

2. Computer Display and Report Generators:

It helps in understanding the data requirements and the relationships involved.

3. Analysis Tools:

It focuses on inconsistent, incorrect specifications involved in the diagram and data

flow. It helps in collecting requirements, automatically check for any irregularity,
imprecision in the diagrams, data redundancies or erroneous omissions.
For example,
 (i) Accept 360, Accompa, CaseComplete for requirement analysis.

 (ii) Visible Analyst for total analysis.

4. Central Repository:
It provides the single point of storage for data diagrams, reports and documents
related to project management.
5. Documentation Generators:
It helps in generating user and technical documentation as per standards. It creates
documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

6. Code Generators:
It aids in the auto generation of code, including definitions, with the help of the
designs, documents and diagrams.

Advantages of the CASE approach:

 As special emphasis is placed on redesign as well as testing, the servicing cost of a

product over its expected lifetime is considerably reduced.

 The overall quality of the product is improved as an organized approach is

undertaken during the process of development.

 Chances to meet real-world requirements are more likely and easier with a
computer-aided software engineering approach.

 CASE indirectly provides an organization with a competitive advantage by helping

ensure the development of high-quality products.

Disadvantages of the CASE approach:

 Cost: Using case tool is a very costly. Mostly firms engaged in software development
on a small scale do not invest in CASE tools because they think that the benefit of
CASE are justifiable only in the development of large systems.
 Learning Curve: In most cases, programmer’s productivity may fall in the initial
phase of implementation, because user need time to learn the technology. Many
consultants offer training and on-site services that can be important to accelerate the
learning curve and to the development and use of the CASE tools.
 Tool Mix: It is important to build an appropriate selection tool mix to urge cost
advantage CASE integration and data integration across all platforms is extremely
important.

Principles of Software Design

Software Design is also a process to plan or convert the software requirements into a
step that are needed to be carried out to develop a software system. There are several
principles that are used to organize and arrange the structural components of Software
design. Software Designs in which these principles are applied affect the content and the
working process of the software from the beginning.
These principles are stated below:
Principles Of Software Design:
1. Should not suffer from “Tunnel Vision” –
While designing the process, it should not suffer from “tunnel vision” which means
that is should not only focus on completing or achieving the aim but on other effects
also.

2. Traceable to analysis model –

The design process should be traceable to the analysis model which means it should
satisfy all the requirements that software requires to develop a high-quality product.

3. Should not “Reinvent The Wheel” –

The design process should not reinvent the wheel that means it should not waste
 time or effort in creating things that already exist. Due to this, the overall
development will get increased.

4. Minimize Intellectual distance –

The design process should reduce the gap between real-world problems and
software solutions for that problem meaning it should simply minimize intellectual
distance.

5. Exhibit uniformity and integration –

The design should display uniformity which means it should be uniform throughout
the process without any change. Integration means it should mix or combine all
parts of software i.e. subsystems into one system.

6. Accommodate change –
The software should be designed in such a way that it accommodates the change
implying that the software should adjust to the change that is required to be done as
per the user’s need.

7. Degrade gently –
The software should be designed in such a way that it degrades gracefully which
means it should work properly even if an error occurs during the execution.

8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning that during the
evaluation, the quality of the design needs to be checked and focused on.
9. Review to discover errors –
The design should be reviewed which means that the overall evaluation should be
done to check if there is any error present or if it can be minimized.

10. Design is not coding and coding is not design –

Design means describing the logic of the program to solve any problem and coding
is a type of language that is used for the implementation of a design.
Data design

Data design is the first design activity, which results in less complex, modular and efficient
program structure. The information domain model developed during analysis phase is
transformed into data structures needed for implementing the software.

The data objects, attributes, and relationships depicted in entity relationship diagrams and
the information stored in data dictionary provide a base for data design activity. During the data
design process, data types are specified along with the integrity rules required for the data. For
specifying and designing efficient data structures, some principles should be followed. These
principles are listed below.

1. The data structures needed for implementing the software as well-as the operations that can
be applied on them should be identified.
2. A data dictionary should be developed to depict how different data objects interact with each
other and what constraints are to be imposed on the elements of data structure.
3. Stepwise refinement should be used in data design process and detailed design decisions
should be made later in the process.
4. Only those modules that need to access data stored in a data structure directly should be
aware of the representation of the data structure.
5. A library containing the set of useful data structures along with the operations that can be
performed on them should be maintained.
6. Language used for developing the system should support abstract data types.
The structure of data can be viewed at three levels, namely, program component level, application
level, and business level. At the program component level, the design of data structures and the
algorithms required to manipulate them is necessary, if high-quality software is desired.

At the application level, it is crucial to convert the data model into a database so that the specific
business objectives of a system could be achieved. At the business level, the collection of
information stored in different databases should be reorganized into data warehouse,
which enables data mining that has an influential impact on the business.

Architectural Design
Architectural design is of crucial importance in software engineering during which the essential
requirements like reliability, cost, and performance are dealt with. This task is cumbersome as
the software engineering paradigm is shifting from monolithic, stand-alone, built-from-scratch
systems to componentized, evolvable, standards-based, and product line-oriented systems.

Though the architectural design is the responsibility of developers, some other people like user
representatives, systems engineers, hardware engineers, and operations personnel are also
involved. All these stakeholders must also be consulted while reviewing the architectural design
in order to minimize the risks and errors.

Architectural Design Representation

Architectural design can be represented using the following models.

1. Structural model: Illustrates architecture as an ordered collection of program components

2. Dynamic model: Specifies the behavioral aspect of the software architecture and indicates
how the structure or system configuration changes as the function changes due to change in
the external environment
3. Process model: Focuses on the design of the business or technical process, which must be
implemented in the system
4. Functional model: Represents the functional hierarchy of a system
 5. Framework model: Attempts to identify repeatable architectural design patterns
encountered in similar types of application. This leads to an increase in the level of
abstraction.

Architectural design document gives the developers a solution to the problem stated in the
Software Requirements Specification (SRS). Note that it considers only those requirements in
detail that affect the program structure. In addition to ADD, other outputs of the architectural
design are listed below.

1. Various reports including audit report, progress report, and configuration status accounts
report
2. Various plans for detailed design phase, which include the following
3. Software verification and validation plan
4. Software configuration management plan
5. Software quality assurance plan
6. Software project management plan.

Component-based architecture

Component-based architecture focuses on the decomposition of the design into individual

functional or logical components that represent well-defined communication interfaces containing
methods, events, and properties. It provides a higher level of abstraction and divides the problem
into sub-problems, each associated with component partitions.

What is a Component?
A component is a modular, portable, replaceable, and reusable set of well-defined functionality
that encapsulates its implementation and exporting it as a higher-level interface.

A component is a software object, intended to interact with other components, encapsulating

certain functionality or a set of functionalities. It has an obviously defined interface and conforms
to a recommended behavior common to all components within an architecture.
Views of a Component
A component can have three different views − object-oriented view, conventional view, and
process-related view.

Object-oriented view

A component is viewed as a set of one or more cooperating classes. Each problem domain class
(analysis) and infrastructure class (design) are explained to identify all attributes and operations
that apply to its implementation. It also involves defining the interfaces that enable classes to
communicate and cooperate.

Conventional view

It is viewed as a functional element or a module of a program that integrates the processing logic,
the internal data structures that are required to implement the processing logic and an interface that
enables the component to be invoked and data to be passed to it.

Process-related view

In this view, instead of creating each component from scratch, the system is building from existing
components maintained in a library. As the software architecture is formulated, components are
selected from the library and used to populate the architecture.

 A user interface (UI) component includes grids, buttons referred as controls, and utility
components expose a specific subset of functions used in other components.
 Other common types of components are those that are resource intensive, not frequently
accessed, and must be activated using the just-in-time (JIT) approach.
 Many components are invisible which are distributed in enterprise business applications
and internet web applications such as Enterprise JavaBean (EJB), .NET components, and
CORBA components.
Characteristics of Components
 Reusability − Components are usually designed to be reused in different situations in
different applications. However, some components may be designed for a specific task.
 Replaceable − Components may be freely substituted with other similar components.
  Not context specific − Components are designed to operate in different environments and
contexts.
 Extensible − A component can be extended from existing components to provide new
behavior.
 Encapsulated − A A component depicts the interfaces, which allow the caller to use its
functionality, and do not expose details of the internal processes or any internal variables
or state.
 Independent − Components are designed to have minimal dependencies on other
components.

Principles of Component−Based Design

 The software system is decomposed into reusable, cohesive, and encapsulated component
units.
 Each component has its own interface that specifies required ports and provided ports; each
component hides its detailed implementation.
 A component should be extended without the need to make internal code or design
modifications to the existing parts of the component.
 Depend on abstractions component do not depend on other concrete components, which
increase difficulty in expendability.
 Connectors connected components, specifying and ruling the interaction among
components. The interaction type is specified by the interfaces of the components.
 Components interaction can take the form of method invocations, asynchronous
invocations, broadcasting, message driven interactions, data stream communications, and
other protocol specific interactions.
 For a server class, specialized interfaces should be created to serve major categories of
clients. Only those operations that are relevant to a particular category of clients should be
specified in the interface.
 A component can extend to other components and still offer its own extension points. It is
the concept of plug-in based architecture. This allows a plugin to offer another plugin API.
Component-Level Design Guidelines
Creates a naming conventions for components that are specified as part of the architectural model
and then refines or elaborates as part of the component-level model.

 Attains architectural component names from the problem domain and ensures that they have
meaning to all stakeholders who view the architectural model.
 Extracts the business process entities that can exist independently without any associated
dependency on other entities.
 Recognizes and discover these independent entities as new components.
 Uses infrastructure component names that reflect their implementation-specific meaning.
 Models any dependencies from left to right and inheritance from top (base class) to bottom
(derived classes).
 Model any component dependencies as interfaces rather than representing them as a direct
component-to-component dependency.
Advantages
 Ease of deployment − As new compatible versions become available, it is easier to replace
existing versions with no impact on the other components or the system as a whole.
 Reduced cost − The use of third-party components allows you to spread the cost of
development and maintenance.
 Ease of development − Components implement well-known interfaces to provide defined
functionality, allowing development without impacting other parts of the system.
  Reusable − The use of reusable components means that they can be used to spread the
development and maintenance cost across several applications or systems.
 Modification of technical complexity − A component modifies the complexity through
the use of a component container and its services.
 Reliability − The overall system reliability increases since the reliability of each individual
component enhances the reliability of the whole system via reuse.
 System maintenance and evolution − Easy to change and update the implementation
without affecting the rest of the system.
 Independent − Independency and flexible connectivity of components. Independent
development of components by different group in parallel. Productivity for the software
development and future software development.

Object Oriented Approach

In the object-oriented approach, the focus is on capturing the structure and behavior of information
systems into small modules that combines both data and process. The main aim of Object Oriented
Design (OOD) is to improve the quality and productivity of system analysis and design by making
it more usable.

In analysis phase, OO models are used to fill the gap between problem and solution. It performs
well in situation where systems are undergoing continuous design, adaption, and maintenance. It
identifies the objects in problem domain, classifying them in terms of data and behavior.

The OO model is beneficial in the following ways −

 It facilitates changes in the system at low cost.

 It promotes the reuse of components.
 It simplifies the problem of integrating components to configure large system.
 It simplifies the design of distributed systems.
Elements of Object-Oriented System

Let us go through the characteristics of OO System −

  Objects − An object is something that is exists within problem domain and can be identified
by data (attribute) or behavior. All tangible entities (student, patient) and some intangible
entities (bank account) are modeled as object.
 Attributes − They describe information about the object.
 Behavior − It specifies what the object can do. It defines the operation performed on
objects.
 Class − A class encapsulates the data and its behavior. Objects with similar meaning and
purpose grouped together as class.
 Methods − Methods determine the behavior of a class. They are nothing more than an
action that an object can perform.
 Message − A message is a function or procedure call from one object to another. They are
information sent to objects to trigger methods. Essentially, a message is a function or
procedure call from one object to another.

Features of Object-Oriented System

An object-oriented system comes with several great features which are discussed below.

Encapsulation

Encapsulation is a process of information hiding. It is simply the combination of process and data
into a single entity. Data of an object is hidden from the rest of the system and available only
through the services of the class. It allows improvement or modification of methods used by objects
without affecting other parts of a system.

Abstraction

It is a process of taking or selecting necessary method and attributes to specify the object. It focuses
on essential characteristics of an object relative to perspective of user.

Relationships

All the classes in the system are related with each other. The objects do not exist in isolation, they
exist in relationship with other objects.

There are three types of object relationships −

  Aggregation − It indicates relationship between a whole and its parts.
 Association − In this, two classes are related or connected in some way such as one class
works with another to perform a task or one class acts upon other class.
 Generalization − The child class is based on parent class. It indicates that two classes are
similar but have some differences.
Inheritance

Inheritance is a great feature that allows to create sub-classes from an existing class by inheriting
the attributes and/or operations of existing classes.

Structured Approach Vs. Object-Oriented Approach

The following table explains how the object-oriented approach differs from the traditional
structured approach −

Structured Approach Object Oriented Approach

It works with Top-down approach. It works with Bottom-up approach.

Program is divided into number of submodules Program is organized by having number of

or functions. classes and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

Structured design programming usually left Object oriented design programming done
until end phases. concurrently with other phases.

Structured Design is more suitable for It is suitable for in-house development.

offshoring.
 It shows clear transition from design to Not so clear transition from design to
implementation. implementation.

It is suitable for real time system, embedded It is suitable for most business applications,
system and projects where objects are not the game development projects, which are
most useful level of abstraction. expected to customize or extended.

DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart
diagram, and use cases all contribute.

In this, projects can be managed easily due to In this approach, projects can be difficult to
clearly identifiable phases. manage due to uncertain transitions between
phase.

Unified Modeling Language (UML)

UML is a visual language that lets you to model processes, software, and systems to express the
design of system architecture. It is a standard language for designing and documenting a system
in an object oriented manner that allow technical architects to communicate with developer.

It is defined as set of specifications created and distributed by Object Management Group. UML
is extensible and scalable.

The objective of UML is to provide a common vocabulary of object-oriented terms and

diagramming techniques that is rich enough to model any systems development project from
analysis through implementation.

UML is made up of −

 Diagrams − It is a pictorial representations of process, system, or some part of it.

 Notations − It consists of elements that work together in a diagram such as connectors,
symbols, notes, etc.
Example of UML Notation for class