Unit II SYSTEM ANALYSIS AND DESIGN

System Development Methodologies

A system development methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. A wide variety of such frameworks
have evolved over the years, each with its own recognized strengths and weaknesses. One system
development methodology is not necessarily suitable for use by all projects. Each of the
available methodologies is best suited to specific kinds of projects, based on various technical,
organizational, project and team considerations.

Basic Principles:

Project is divided into sequential phases, with some overlap and splash back acceptable
between phases.
Emphasis is on planning, time schedules, target dates, budgets and implementation of an
entire system at one time.
Tight control is maintained over the life of the project through the use of extensive written
documentation, as well as through formal reviews and approval/signoff by the user and
information technology management occurring at the end of most phases before beginning
the next phase.

Systems Development Life Cycle (SDLC)

A structured step-by-step approach for developing an information system. A sequence of events

carried out by analysts, designers and users in the development and implementation of
Information system. One of the basic notions of the system development process is SDLC
models which stands for System Development Life Cycle models. SDLC – is a continuous
process, which starts from the moment, when it’s made a decision to launch the project, and it
ends at the moment of its full remove from the exploitation.

Typical activities in SDLC include:

The activities involved in each SDLC phase are:

SDLC PHASE ACTIVITIES

1. Preliminary Investigation / Feasibility • Feasibility Study

Study • Define the system to be developed
(Planning) • Set the project scope
• Develop the project plan

2. Determination of System Requirement • Gather business requirements

(Analysis)

3. Designing the System • Design the technical architecture

• Design system models

4. Development of System • Build technical architecture

• Build databases and programs

5. System Testing • Write test conditions

• Perform testing

6. System Implementation • Write user documentation

• Provide training

7. System Maintenance • Build a help desk

• Support system changes

SDLC MODELS / Methodologies

There is no one single SDLC model. They are divided into main groups, each with its features
and weaknesses.
Evolving from the first and oldest “waterfall” SDLC model, their variety significantly expanded.
The SDLC models diversity is predetermined by the wide number of product types – starting
with a web application development to a complex medical software. And if you take one of the
SDLC models mentioned below as the basis – in any case, it should be adjusted to the features of
the product, project, and company. The most used, popular and important SDLC models are
given below:

Types of System development life cycles (SDLC)

1. Waterfall Model
2. Iterative and Incremental Method
 3. Spiral Method (SDM)
4. V-Shaped Model
5. Agile Model
6. Prototyping Model

1. Waterfall SDLC Model

Waterfall – is a cascade SDLC model, in which development process looks like the flow, moving
step by step through the phases of analysis, projecting, realization, testing, implementation, and
support. This SDLC model includes gradual execution of every stage completely. This process is
strictly documented and predefined with features expected to every phase of this system
development life cycle model.

ADVANTAGES DISADVANTAGES

Simple to use and understand The software is ready only after the last stage is over

Management simplicity thanks to its rigidity: every High risks and uncertainty
phase has a defined result and process review

Development stages go one by one Not the best choice for complex and object-oriented projects

Perfect for the small or mid-sized projects where Inappropriate for the long-term projects
requirements are clear and not equivocal
ADVANTAGES DISADVANTAGES

Easy to determine the key points in the development The progress of the stage is hard to measure while it is still in
cycle the development

Easy to classify and prioritize tasks Integration is done at the very end, which does not give the
option of identifying the problem in advance

Use cases for the Waterfall SDLC model:

 The requirements are precisely documented
 Product definition is stable
 The technologies stack is predefined which makes it not dynamic
 No ambiguous requirements
 The project is short

2. Iterative SDLC Model

The Iterative SDLC model does not need the full list of requirements before the project starts.
The development process may start with the requirements to the functional part, which can be
expanded later. The process is repetitive, allowing to make new versions of the product for every
cycle. Every iteration (which last from two to six weeks) includes the development of a separate
component of the system, and after that, this component is added to the functional developed
earlier. Speaking with math terminology, the iterative model is a realization of the sequential
approximation method; that means a gradual closeness to the planned final product shape.
ADVANTAGES DISADVANTAGES

Some functions can be quickly developed at the Iterative model requires more resources than the waterfall
beginning of the development lifecycle model

The paralleled development can be applied Constant management is required

The progress is easy measurable Issues with architecture or design may occur because not all
the requirements are foreseen during the short planning stage

The shorter iteration is - the easier testing and Bad choice for the small projects
debugging stages are

It is easier to control the risks as high-risk tasks are The process is difficult to manage
completed first

Problems and risks defined within one iteration can be The risks may not be completely determined even at the final
prevented in the next sprints stage of the project

Flexibility and readiness to the changes in the Risks analysis requires involvement of the highly-qualified
requirements specialists

Use cases for the Iteration model:

 The requirements to the final product are strictly predefined
 Applied to the large-scale projects
 The main task is predefined, but the details may advance with the time

3. Spiral SDLC Model

Spiral model – is SDLC model, which
combines architecture and prototyping by
stages. It is a combination of the Iterative
and Waterfall SDLC models with the
significant accent on the risk analysis. The
main issue of the spiral model – is defining
the right moment to make a step into the
next stage. The preliminary set time frames
are recommended as the solution to this
issue. The shift to the next stage is done
according to the plan, even if the work on
the previous stage isn’t done yet. The plan is
introduced basing on the statistic data,
received during the previous projects even
from the personal developer’s experience.
ADVANTAGES DISADVANTAGES

Lifecycle is divided into small parts, and if the risk Can be quite expensive
concentration is higher, the phase can be finished
earlier to address the treats

The development process is precisely documented yet The risk control demands involvement of the highly-
scalable to the changes skilled professionals

The scalability allows to make changes and add new Can be ineffective for the small projects
functionality even at the relatively late stages

The earlier working prototype is done - sooner users Big number of the intermediate stages requires
can point out the flaws excessive documentation

Use cases for the Spiral model

 Customer isn’t sure about the requirements
 Major edits are expected during the development cycle
 The projects with mid or high-level risk, where it is important to prevent these risks
 The new product that should be released in a few stages to have enough of clients
feedback

4. V-shaped SDLC Model

V-shaped SDLC model is an expansion of

classic waterfall model and it’s based on
associated test stage for the every
development stage. This is a very strict
model and the next stage is started only after
the previous phase. This is also called
“Validation and verification” model. Every
stage has the current process control, to
make sure that the conversion to the next
stage is possible.
ADVANTAGES DISADVANTAGES

Every stage of V-shaped model has strict results so it’s easy to Lack of the flexibility
control

Testing and verification take place in the early stages Bad choice for the small projects

Good for the small projects, where requirements are static and clear Relatively big risks

Use cases for the V-shaped model:

 For the projects where an accurate product testing is required
 For the small and mid-sized projects, where requirements are strictly predefined
 The engineers of the required qualification, especially testers, are within easy reach.

5. Agile SDLC Model

In the agile methodology after every development iteration, the customer is able to see the result
and understand if he is satisfied with it or he is not. This is one of the advantages of the agile
software development life cycle model. One of its disadvantages is that with the absence of
defined requirements it is difficult to estimate the resources and development cost. Extreme
programming is one of the practical use of the agile model. The basis of such model consists of
short weekly meetings – Sprints which are the part of the Scrum approach.
ADVANTAGES DISADVANTAGES

Corrections of functional requirements are implemented into Difficulties with measuring the final cost because of
the development process to provide the competitiveness permanent changes

Project is divided by short and transparent iterations The team should be highly professional and client-
oriented

Risks are minimized thanks to the flexible change process New requirements may conflict with the existing
architecture

Fast release of the first product version With all the corrections and changes there is possibility
that the project will exceed expected time

Use cases for the Agile model:

 The users’ needs change dynamically
 Less price for the changes implemented because of the many iterations
 Unlike the Waterfall model, it requires only initial planning to start the project

6. Prototyping Model
It refers to the activity of creating prototypes of software applications, for example, incomplete
versions of the software program being developed. It is an activity that can occur in software
development and It used to visualize some component of the software to limit the gap of
misunderstanding the customer requirements by the development team. This also will reduce the
iterations may occur in the waterfall approach and hard to be implemented due to the inflexibility
of the waterfall approach. So, when the final prototype is developed, the requirement is
considered to be frozen.

It has some types, such as:

 Throwaway prototyping: Prototypes that are eventually discarded rather than becoming
a part of the finally delivered software
  Evolutionary prototyping: prototypes that evolve into the final system through an
iterative incorporation of user feedback.
 Incremental prototyping: The final product is built as separate prototypes. In the end,
the separate prototypes are merged in an overall design.
 Extreme prototyping: used in web applications mainly. Basically, it breaks down web
development into three phases, each one based on the preceding one. The first phase is a
static prototype that consists mainly of HTML pages. In the second phase, the screens are
programmed and fully functional using a simulated services layer. In the third phase, the
services are implemented

The usage

This process can be used with any software developing life cycle model. While this shall be
chosen when you are developing a system has user interactions. So, if the system does not
have user interactions, such as a system does some calculations shall not have prototypes.

Advantages Disadvantages
 Insufficient analysis. User confusion of prototype
 Reduced time and costs, but this can be a and finished system.
disadvantage if the developer loses time in  Developer misunderstanding of user objectives.
developing the prototypes.  Excessive development time of the prototype.
 Improved and increased user involvement.  It is costly to implement the prototypes

Systems Analysis and Design

Systems development is systematic process which includes phases such as planning, analysis,
design, deployment, and maintenance.
Here, we will primarily focus on −

 Systems analysis  Systems design

Systems Analysis
It is a process of collecting and interpreting facts, identifying the problems, and decomposition
of a system into its components.
System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem solving technique that improves the system and ensures
that all the components of the system work efficiently to accomplish their purpose.
Analysis specifies what the system should do.
Systems Design
It is a process of planning a new business system or replacing an existing system by defining its
components or modules to satisfy the specific requirements. Before planning, you need to
understand the old system thoroughly and determine how computers can best be used in order to
operate efficiently.
System Design focuses on how to accomplish the objective of the system.
System Analysis and Design (SAD) mainly focuses on −
 Systems
 Processes
 Technology
An effective System Development Life Cycle (SDLC) should result in a high quality system
that meets customer expectations, reaches completion within time and cost evaluations, and
works effectively and efficiently in the current and planned Information Technology
infrastructure.
System Development Life Cycle (SDLC) is a conceptual model which includes policies and
procedures for developing or altering systems throughout their life cycles.
SDLC is used by analysts to develop an information system. SDLC includes the following
activities −
 requirements  deployment
 design  operations
 implementation  maintenance
 testing
Phases of SDLC
Systems Development Life Cycle is a systematic approach which explicitly breaks down the
work into phases that are required to implement either new or modified Information System.

Feasibility Study or Planning

 Define the problem and scope of existing system.
 Overview the new system and determine its objectives.
 Confirm project feasibility and produce the project Schedule.
 During this phase, threats, constraints, integration and security of system are also
considered.
 A feasibility report for the entire project is created at the end of this phase.
Analysis and Specification
 Gather, analyze, and validate the information.
  Define the requirements and prototypes for new system.
 Evaluate the alternatives and prioritize the requirements.
 Examine the information needs of end-user and enhances the system goal.
 A Software Requirement Specification (SRS) document, which specifies the software,
hardware, functional, and network requirements of the system is prepared at the end of this
phase.

System Design
 Includes the design of application, network, databases, user interfaces, and system interfaces.
 Transform the SRS document into logical structure, which contains detailed and complete set of
specifications that can be implemented in a programming language.
 Create a contingency, training, maintenance, and operation plan.
 Review the proposed design. Ensure that the final design must meet the requirements stated in SRS
document.
 Finally, prepare a design document which will be used during next phases.

Implementation
 Implement the design into source code through coding.
 Combine all the modules together into training environment that detects errors and defects.
 A test report which contains errors is prepared through test plan that includes test related tasks such as
test case generation, testing criteria, and resource allocation for testing.
 Integrate the information system into its environment and install the new system.

Maintenance/Support
 Include all the activities such as phone support or physical on-site support for users that is required
once the system is installing.
 Implement the changes that software might undergo over a period of time, or implement any new
requirements after the software is deployed at the customer location.
 It also includes handling the residual errors and resolve any issues that may exist in the system even
after the testing phase.
 Maintenance and support may be needed for a longer time for large systems and for a short time for
smaller systems.

Life Cycle of System Analysis and Design

The following diagram shows the complete
life cycle of the system during analysis and
design phase.
Role of System Analyst
The system analyst is a person who is thoroughly aware of the system and guides the system
development project by giving proper directions. He is an expert having technical and
interpersonal skills to carry out development tasks required at each phase.
He pursues to match the objectives of information system with the organization goal.
Main Roles
 Defining and understanding the requirement of user through various Fact finding techniques.
 Prioritizing the requirements by obtaining user consensus.
 Gathering the facts or information and acquires the opinions of users.
 Maintains analysis and evaluation to arrive at appropriate system which is more user friendly.
 Suggests many flexible alternative solutions, pick the best solution, and quantify cost and benefits.
 Draw certain specifications which are easily understood by users and programmer in precise and
detailed form.
 Implemented the logical design of system which must be modular.
 Plan the periodicity for evaluation after it has been used for some time, and modify the system as
needed.

Attributes of a Systems Analyst

The following figure shows the attributes a

systems analyst should possess −

 Ability to access trade-off

 Curiosity to learn about new organization
Interpersonal Skills Management Skills
 Interface with users and programmer.  Understand users jargon and practices.
 Facilitate groups and lead smaller teams.  Resource & project management.
 Managing expectations.  Change & risk management.
 Good understanding, communication,  Understand the management functions
selling and teaching abilities. thoroughly.
 Motivator having the confidence to solve
queries.

Technical Skills
Analytical Skills
 Knowledge of computers and software.
 System study and organizational  Keep abreast of modern development.
knowledge  Know of system design tools.
 Problem identification, problem analysis,  Breadth knowledge about new
and problem solving technologies.
 Sound commonsense
System Flowcharts
A system flowchart is a visual representation of processes, decisions, inputs and outputs that
together form a system.
What is a system flowchart?

System flowcharts are a way of displaying

how data flows in a system and how
decisions are made to control events.

To illustrate this, symbols are used. They are

connected together to show what happens to
data and where it goes.

Note that system flow charts are very similar

to data flow charts. Data flow charts do not
include decisions, they just show the path
that data takes, where it is held, processed,
and then output.

Symbols used in flowchart

Using system flowchart ideas

This system flowchart is a diagram for a
'cruise control' for a car. The cruise control
keeps the car at a steady speed that has been
set by the driver.

The flowchart shows what the outcome is if the car is going too fast or too slow. The system is
designed to add fuel, or take it away and so keep the car's speed constant. The output (the car's
new speed) is then fed back into the system via the speed sensor.

Other examples of uses for system diagrams include:

 aircraft control
 central heating
 automatic washing machines
 booking systems for airlines
Decision Tables
A Decision table represents conditions and the respective actions to be taken to address them, in
a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into a single
table and then by combining tables it delivers easy and convenient decision-making.
Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.
 It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Creating Decision Table

To create the decision table, the developer must follow basic four steps:

 Identify all possible conditions to be addressed

 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by eliminating
duplicate rules and actions.

Components of a Decision Table

 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be carried
out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.
The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,
 Y shows the existence of a condition.
 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs 10,000/- - Y Y N

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

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 −

Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an information system. It is
capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD
does not contain any control or branch elements.
Types of DFD

Data Flow Diagrams are either Logical or Physical.

 Logical DFD - This type of DFD concentrates on the system process, and flow of data in
the system.For example in a Banking software system, how data is moved between
different entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system. It is more specific and close to the implementation.

The following table lists the points that differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows which It is implementation independent. It focuses only on

functions are performed. the flow of data between processes.

It provides low level details of hardware, software, It explains events of systems and data required by
files, and people. each event.

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

DFD Components

DFD can represent Source, destination, storage and flow of data using the following set of
components -

 Entities - Entities are source and destination of information data. Entities are represented by a
rectangles with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-edged rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as a rectangle with
absence of both smaller sides or as an open-sided rectangle with only one side missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base
of arrow as its source towards head of the arrow as destination.
Levels of DFD
 Level 0 - Highest abstraction level DFD is
known as Level 0 DFD, which depicts the
entire information system as one diagram
concealing all the underlying details.
Level 0 DFDs are also known as context
level DFDs.

 Level 1 - The Level 0 DFD is broken down into

more specific, Level 1 DFD. Level 1 DFD
depicts basic modules in the system and flow of
data among various modules. Level 1 DFD also
mentions basic processes and sources of
information.

 Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of
understanding unless the desired level of specification is achieved.

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

Context Diagram

A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then goes
onto giving more details of the processes with the top-down approach.
The context diagram of mess management is shown below.

Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities
and relationship among them. We can map real world scenario onto ER database model. ER
Model creates a set of entities with their attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be represented as
follows :

 Entity - An entity in ER Model is a real world being, which has some properties
called attributes. Every attribute is defined by its corresponding set of values,
called domain.
For example, Consider a school database. Here, a student is an entity. Student has
various attributes like name, id, age and class etc.
The ER model defines the conceptual view of a database. It works around real-world entities
and the associations among them. At view level, the ER model is considered a good option for
designing databases.

Entity
An entity can be a real-world object, either animate or inanimate, that can be easily identifiable.
For example, in a school database, students, teachers, classes, and courses offered can be
considered as entities. All these entities have some attributes or properties that give them their
identity.
An entity set is a collection of similar types of entities. An entity set may contain entities with
attribute sharing similar values. For example, a Students set may contain all the students of a
school; likewise a Teachers set may contain all the teachers of a school from all faculties. Entity
sets need not be disjoint.

Attributes
Entities are represented by means of their properties, called attributes. All attributes have
values. For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

Relationship
The association among entities is called a relationship. For example, an employee works_at a
department, a student enrolls in a course. Here, Works_at and Enrolls are called relationships.

Relationship Set

A set of relationships of similar type is called a relationship set. Like entities, a relationship too
can have attributes. These attributes are called descriptive attributes.

Entity Relationship Diagram

An Entity–relationship model (ER model) describes the structure of a database with the help of
a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model is a
design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.
A simple ER Diagram:
In the following diagram we have two
entities Student and College and their
relationship. The relationship between
Student and College is many to one as a
college can have many students however a
student cannot study in multiple colleges at
the same time. Student entity has attributes
such as Stu_Id, Stu_Name & Stu_Addr and
College entity has attributes such as Col_ID
& Col_Name.

Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these terms
in detail in the next section(Components of a ER Diagram) of this guide so don’t worry too much
about these terms now, just go through them once.

Rectangle : Represents Entity sets.

Ellipses : Attributes
Diamonds : Relationship Set
Lines : They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines : Total participation of an entity in a relationship set

Components of a ER Diagram

As shown in the diagram, an ER diagram

has three main components:
1. Entity
2. Attribute
3. Relationship

1. Entity
An entity is an object or component of data. An entity is represented as rectangle in an ER
diagram.
For example: In the following ER diagram
we have two entities Student and College
and these two entities have many to one
relationship as many students study in a
single college. We will read more about
relationships later, for now focus on entities.

Weak Entity:
An entity that cannot be uniquely identified
by its own attributes and relies on the
relationship with other entity is called weak
entity. The weak entity is represented by a
double rectangle. For example – a bank
account cannot be uniquely identified
without knowing the bank to which the
account belongs, so bank account is a weak
entity.

2. Attribute
An attribute describes the property of an entity. An attribute is represented as Oval in an ER
diagram. There are four types of attributes:
1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute
1. Key attribute:
A key attribute can uniquely identify an
entity from an entity set. For example,
student roll number can uniquely identify a
student from a set of students. Key attribute
is represented by oval same as other
attributes however the text of key attribute
is underlined.

2. Composite attribute:
An attribute that is a combination of other
attributes is known as composite attribute.
For example, In student entity, the student
address is a composite attribute as an
address is composed of other attributes such
as pin code, state, country.
3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented
with double ovals in an ER Diagram. For example – A person can have more than one phone
numbers so the phone number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is E-R diagram with multivalued and
dynamic and derived from another attribute. derived attributes:
It is represented by dashed oval in an ER
Diagram. For example – Person age is a
derived attribute as it changes over time and
can be derived from another attribute (Date
of birth).

3. Relationship
A relationship is represented by diamond shape in ER diagram, it shows the relationship among
entities. There are four types of relationships:
1. One to One 3. Many to One
2. One to Many 4. Many to Many

1. One to One Relationship

When a single instance of an entity is
associated with a single instance of another
entity then it is called one to one
relationship. For example, a person has only
one passport and a passport is given to one
person.

2. One to Many Relationship

When a single instance of an entity is

associated with more than one instances of
another entity then it is called one to many
relationship. For example – a customer can
place many orders but a order cannot be
placed by many customers.
3. Many to One Relationship
When more than one instances of an entity is
associated with a single instance of another
entity then it is called many to one
relationship. For example – many students
can study in a single college but a student
cannot study in many colleges at the same
time.

4. Many to Many Relationship

When more than one instances of an entity is

associated with more than one instances of
another entity then it is called many to many
relationship. For example, a can be assigned
to many projects and a project can be
assigned to many students.

Total Participation of an Entity set

A Total participation of an entity set
represents that each entity in entity set must
have at least one relationship in a
relationship set. For example: In the below
diagram each college must have at-least one
associated Student.

Generalization is a process in which the common attributes of more than one entities form a
new entity. This newly formed entity is called generalized entity.
Generalization Example
Lets say we have two entities Student and The ER diagram before generalization
Teacher. looks like this:
Attributes of Entity Student are: Name,
Address & Grade
Attributes of Entity Teacher are: Name,
Address & Salary

These two entities have two common attributes: Name and Address, we can make a generalized
entity with these common attributes. Lets have a look at the ER model after generalization.
 OOAD - Object Oriented Analysis & Design
A Brief History
The object-oriented paradigm took its shape from the initial concept of a new programming
approach, while the interest in design and analysis methods came much later.
 The first object–oriented language was Simula (Simulation of real systems) that was developed in
1960 by researchers at the Norwegian Computing Center.
 In 1970, Alan Kay and his research group at Xerox PARK created a personal computer named
Dynabook and the first pure object-oriented programming language (OOPL) - Smalltalk, for
programming the Dynabook.
 In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainly presented a
design for the programming language, Ada. In the ensuing editions, he extended his ideas to a
complete object–oriented design method.
 In the 1990s, Coad incorporated behavioral ideas to object-oriented methods.
The other significant innovations were Object Modelling Techniques (OMT) by James
Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson.

Object-Oriented Analysis
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s object
model, which comprises of interacting objects.
The main difference between object-oriented analysis and other forms of analysis is that in
object-oriented approach, requirements are organized around objects, which integrate both data
and functions. They are modelled after real-world objects that the system interacts with. In
traditional analysis methodologies, the two aspects - functions and data - are considered
separately.
Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that
examines requirements from the perspective of the classes and objects found in the vocabulary
of the problem domain”.
The primary tasks in object-oriented analysis (OOA) are −

 Identifying objects
 Organizing the objects by creating object model diagram
 Defining the internals of the objects, or object attributes
 Defining the behavior of the objects, i.e., object actions
 Describing how the objects interact
The common models used in OOA are use cases and object models.
Object-Oriented Design
Object–Oriented Design (OOD) involves implementation of the conceptual model produced
during object-oriented analysis. In OOD, concepts in the analysis model, which are
technology−independent, are mapped onto implementing classes, constraints are identified and
interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description
of how the system is to be built on concrete technologies.
The implementation details generally include −

 Restructuring the class data (if necessary),

 Implementation of methods, i.e., internal data structures and algorithms,
 Implementation of control, and
 Implementation of associations.
Grady Booch has defined object-oriented design as “a method of design encompassing the
process of object-oriented decomposition and a notation for depicting both logical and physical
as well as static and dynamic models of the system under design”.

Object-Oriented Programming
Object-oriented programming (OOP) is a programming paradigm based upon objects (having
both data and methods) that aims to incorporate the advantages of modularity and reusability.
Objects, which are usually instances of classes, are used to interact with one another to design
applications and computer programs.
The important features of object–oriented programming are −

 Bottom–up approach in program design

 Programs organized around objects, grouped in classes
 Focus on data with methods to operate upon object’s data
 Interaction between objects through functions
 Reusability of design through creation of new classes by adding features to existing classes
Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi,
C#, Perl, Python, Ruby, and PHP.
Grady Booch has defined object–oriented programming as “a method of implementation in
which programs are organized as cooperative collections of objects, each of which represents
an instance of some class, and whose classes are all members of a hierarchy of classes united
via inheritance relationships”.
The object model visualizes the elements in a software application in terms of objects. In this
chapter, we will look into the basic concepts and terminologies of object–oriented systems.
Objects and Classes
The concepts of objects and classes are intrinsically linked with each other and form the
foundation of object–oriented paradigm.

Object

An object is a real-world element in an object–oriented environment that may have a physical or

a conceptual existence. Each object has −
 Identity that distinguishes it from other objects in the system.
 State that determines the characteristic properties of an object as well as the values of the properties
that the object holds.
 Behavior that represents externally visible activities performed by an object in terms of changes in its
state.
Objects can be modelled according to the needs of the application. An object may have a
physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a
project, a process, etc.

Class

A class represents a collection of objects having same characteristic properties that exhibit
common behavior. It gives the blueprint or description of the objects that can be created from it.
Creation of an object as a member of a class is called instantiation. Thus, object is an instance of
a class.
The constituents of a class are −
 A set of attributes for the objects that are to be instantiated from the class. Generally, different objects
of a class have some difference in the values of the attributes. Attributes are often referred as class
data.
 A set of operations that portray the behavior of the objects of the class. Operations are also referred as
functions or methods.

UML
UML (Unified Modeling Language) is a standard language for specifying, visualizing, constructing,
and documenting the artifacts of software systems. UML was created by the Object Management
Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997. It was
initially started to capture the behavior of complex software and non-software system and now it has
become an OMG standard.

UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.
UML was created by the Object Management Group (OMG) and UML 1.0 specification draft
was proposed to the OMG in January 1997.
OMG is continuously making efforts to create a truly industry standard.
 UML stands for Unified Modeling Language.
 UML is different from the other common programming languages such as C++, Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.
 UML can be described as a general purpose visual modeling language to visualize, specify, construct,
and document software system.
 Although UML is generally used to model software systems, it is not limited within this boundary. It
is also used to model non-software systems as well. For example, the process flow in a
manufacturing unit, etc.
UML is not a programming language but tools can be used to generate code in various
languages using UML diagrams. UML has a direct relation with object oriented analysis and
design. After some standardization, UML has become an OMG standard.

Goals of UML
A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-
oriented concepts were introduced much earlier than UML. At that point of time, there were no
standard methodologies to organize and consolidate the object-oriented development. It was
then that UML came into picture.
There are a number of goals for developing UML but the most important is to define some
general purpose modeling language, which all modelers can use and it also needs to be made
simple to understand and use.
UML diagrams are not only made for developers but also for business users, common people,
and anybody interested to understand the system. The system can be a software or non-software
system. Thus it must be clear that UML is not a development method rather it accompanies with
processes to make it a successful system.
In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment.

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a conceptual
model? and why a conceptual model is required?
 A conceptual model can be defined as a model which is made of concepts and their relationships.
 A conceptual model is the first step before drawing a UML diagram. It helps to understand the
entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements −
 UML building blocks
 Rules to connect the building blocks
 Common mechanisms of UML
Role of UML in OO Design
UML is a modeling language used to model software and non-software systems. Although
UML is used for non-software systems, the emphasis is on modeling OO software applications.
Most of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before understanding
the UML in detail, the OO concept should be learned properly. Once the OO analysis and
design is done, the next step is very easy. The input from OO analysis and design is the input to
UML diagrams.

UML Diagrams
UML diagrams are the ultimate output of the entire discussion. All the elements, relationships
are used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the
other elements are used to make it complete.
UML includes the following nine diagrams, the details of which are described in the subsequent
chapters.

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 State chart diagram
 Deployment diagram
 Component diagram