Download as pdf or txt
Download as pdf or txt
You are on page 1of 27

UNIT II SYSTEM ANALYSIS AND DESIGN

Case tools - System flow chart, Decision table, Data flow Diagram (DFD), Entity Relationship (ER),
Object Oriented Analysis and Design(OOAD), UML diagram.

INTRODUCTION:

The word ‘System’ is derived from the Greek word ‘Systema’. It is an organized
combination of resources working together to convert inputs into useful outputs.

A System is an orderly grouping of interdependent components linked together according


to a plan to achieve a specific objective.

System development generally have two major components , they are

1) System Analysis:
The process of gathering and interpreting facts, diagnosing problems and using
the information to recommend improvements to the system.
It specifies “What the system should do.”
2) System Design:
The process of planning a new system (or) one to replace (or) complement an
existing system.
Design state “How to accomplish the objective.”

STRUCTURED ANALYSIS TOOLS:

It is a set of techniques and graphical tools that allow the analyst to develop a new kind of
system specifications that are easily understandable to the user.

Structured Analysis tools are

1) System flow chart


2) Decision Table
3) Data Flow Diagram [DFD]
4) Entity Relationship [ER] Diagram

SYSTEM FLOW CHARTS

A flowchart is a pictorial representation of the sequence of operations in system.

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.
Flow chart Symbols:

ADVANTAGES: DISADVANTAGES:

 Conveys better meaning.  Time consuming


 Effective joining of a part of a system  Difficult to make changes
 Efficient Coding  Non-Standardization – No standard for
 Proper Documentation determining the amount of detail
 Proper Debugging
EXAMPLES:

To check whether the given number is even or odd To login to a system

Stop

Flow chart for Library Management System


DECISION TABLE

Decision table is a matrix representation of the logic of a decision , which


specifies the possible conditions for the decision and resulting actions.

 It is a convenient way to organize information in a systematic manner.


 It is a single representation of complex logical relationship between conditions and
actions.
 It is useful in situations where the resulting action depend on the occurrence of one or
several combinations of independent conditions.
 This technique is sometimes also referred to as a ‘cause-effect‘ table.

COMPONENTS / PARTS OF DECISION TABLE:

1) Stub: It is further divided into


i. Condition stub – Upper Left Quadrant - Lists all the conditions to be checked
ii. Action stub – Lower Left Quadrant – All actions to be carried out to meet such
conditions
2) Entry: It is divided into
i. Condition Entry – Upper Right Quadrant – Provide answers to questions asked in
condition stub quadrant
ii. Action Entry – Lower Right Quadrant – Appropriate actions resulting from answers
to the conditions in the condition entry quadrant

Conditions and
Rules
Actions

In Simple,
Conditions
Conditions  Condition rows (stubs):
Entries Lists conditions relevant to decision.
 Action rows (Stubs):
Actions that results from a given set of
conditions
Actions  Rules:
Actions Specify which actions are to be followed
Entries for a given set of conditions
EXAMPLE:

Types of Decision tables with Example:

1. Limited Entry Form:


If the condition in the condition stub have only two possible states –True or False (Y or N)

2. Extended Entry Form:


If the condition stub contains a condition which can have more than two possible states.

Here the symbol dash (-) is used to indicate that the condition is irrelevant for the
combinations of the conditions given. It reduces number of columns in the decision table.
3. ELSE Form:
For removing ambiguity, First only the rules representing the valid cases are shown in the
decision table and then to complete the decision table , a Dummy rule is written as the last rule ,
on the right of it.
This rule Represents “all the remaining possibilities”

STEPS IN CREATING DECISION TABLE:


1) Name all the conditions and values each condition can assume
2) Name all possible actions that can occur
3) List all possible rules based on every possible combination of conditions
4) Define the actions for each rule
5) Simplify decision table by removing indifferent conditions

ADVANTAGES

 Easier to draw , understand and modify compared to Flowcharts


 Standard Format
 Redundancies and contradictions can be easily checked
 Logically complete and consistent , Problem oriented
 Detect Potential error in specifications.

DISADVANTAGES
 Need to know what conditions are relevant for testing
 Cannot be translated into program easily
 Scaling up can be massive : 2𝑛 for n conditions
DATA FLOW DIAGRAM [DFD]

A data-flow diagram is a graphical representation of the “flow” of data through an


information system. DFDs can also be used for the visualization of data processing.

Flow chart shows ”Flow of Control” , DFD shows “Flow of Data”

COMPONENTS/ELEMENTS OF DFD:

Process:- A process is a work performed on, or


in response to , incoming data flows or
conditions.

Data Flow:-A data flow represents an input of


data to a process or the output of data from a
process.

External Entity:-External Entity represents


sources of data to the system or destinations of
data from the system. It can be a person, a
department , a business or a machine.

Data Stores:- Data is kept in data store. A data


store is an “inventory” of data.

TYPES OF DFD:

 Logical data flow diagrams - are implementation-independent and describe the system,
rather than how activities are accomplished. It concentrates on system process and flow
of data in the system.
ADVANTAGES OF DFD :

1.Early implementation

2.Study Independence

3.Tool for communication

4.Reduces cost
 Physical data flow diagrams - are implementation-dependent and describe the actual
entities (devices, department, people, etc.) involved in the current system. It shows how
the data flow is actually implemented in the system
DISADVANTAGES OF
DFD :

1.Imprecise

2.Highly Subjective

3.Takes long time to create

4.Absence of control aspects

LEVELS OF DFD:

1) Level 0:
 Also known as context level DFD is the highest abstraction level in DFD.
 Contains only one process, representing entire system.
 This diagram does not contain any data stores.

2) Level 1:
 Depicts basic modules in the system and flow of data among various modules.
 Include up to 9 processes.
 Mention basic processes and sources of information.

Level 1 diagram of university course registration system


3) Level 2:
 Shows how data flows inside the modules mentioned in level 1.
 Higher level DFD transformed into lower level DFDs with deeper level of
understanding unless the desired of specification is achieved.

Level 2 diagram of university course registration system

RULES OF DFD

Example of online Shopping

LEVEL 0 LEVEL 1
ENTITY RELATIONSHIP [ER] DIAGRAMS

ERD pictorially represents the interrelationships of the database schema.

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.

NOTATIONS OF ER DIAGRAN:

1) Entity:. An entity is an object or component of data


ENTITY
about which you want to store information.

2) Weak Entity: ENTITY A weak entity is dependent on another entity


to exist

3) Attribute:

Attributes are the properties or characteristics of


Attribute an entity

4) Key Attribute:
It is the Unique, distinguishing characteristics of
Attribute the entity.

5) Multi Valued Attribute:

Attribute A Multi-Valued attribute can have more than


one value

6) Derived Attribute:

A derived attribute is based on another attribute


7) Relationships: It shows how entities share information in
database structure.
Relationship

8) Weak Relationship:

To connect weak entity with others weak


Relationship relationship is used

9) Mandatory One cardinality 10) Optional One cardinality cardinality specifies the
maximum number of
relationships and
ordinality specifies the
absolute minimum
11) Mandatory Many Cardinality 12) Optional Many Cardinality number of
relationships.

COMPONENTS OF ER DIAGRAM:

E-R diagram with multivalued and


derived attributes

Composite Attribute:

An attribute that is a combination of


other attributes is known as composite
attribute.
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 (1:1)

2. One to Many(1:m)

3. Many to One(m:1)

4. Many to Many(m:n)

Examples:

i)A bank record information about its customers and their accounts:

Name Number
Phone

Type Balance
Address
ssNo

Customers Owns Accounts

ii) Library Management System


ii)Car Insurance Company

driver

iii)Employee Management system (N/D 2016)


COMPUTER AIDED SOFTWARE ENGINEERING (CASE) TOOLS
It is a generic term used to denote automated support associated with the software
development activities.

CASE Tools are computerized software development tools that support the developer
when performing one or more phases of the software life cycle and/or support software
maintenance.

Characteristics of CASE tools:

1.Standard Methodology

2.Flexibility

3.Strong Integration

4.Integration with testing software

5.Support for Reverse Engineering

6.On-line Help

Components of CASE Tools:

CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a central
place of storage where product specifications, requirement documents, related reports
and diagrams, other useful information regarding management is stored. Central
repository also serves as data dictionary.

 Upper Case Tools - Upper CASE tools are used


in planning, analysis and design stages of SDLC.
 Lower Case Tools - Lower CASE tools are used
in implementation, testing and maintenance.
 Integrated Case Tools - Integrated CASE tools
are helpful in all the stages of SDLC, from
Requirement gathering to Testing and
documentation.
CASE tools can be grouped together if they have
similar functionality, process activities and
capability of getting integrated with other tools.

Scope of Case Tools


The scope of CASE tools goes throughout the
SDLC.
Types of CASE tools include:

 Diagramming Tools: Help in diagrammatic and graphical representations of the data and
system processes.
 Computer Display and Report Generators: Help in understanding the data
requirements and the relationships involved.
 Analysis Tools: Focus on inconsistent, incorrect specifications involved in the diagram
and data flow.
 Central Repository: Provides the single point of storage for data diagrams, reports and
documents related to project management. Central repository also serves as data dictionary.
 Documentation Generators: Help in generating user and technical documentation as per
standards.
 Code Generators: Aid in the auto generation of code, including definitions, with the
help of the designs, documents and diagrams.

Uses of CASE tools

 Improve productivity of their software engineers


 Reduce time to develop applications
 Improve documentation
 Automate system analysis

Use of CASE tools in SDLC

of Information System

Disadvantages
Advantages
 Some tools are expensive
 They integrate the development done
during each phase of system development  All software engineers need to be
trained to use these tools
 They permit effective communication with
users  A lot of time is wasted in using the
tools
 They are useful as communication aids
with users of the system  Software developed using CASE tools
are of poor quality
Architecture of CASE Environment:

A CASE tool will comprise of the following architectural components:

1) A database (to store the information)


2) An Object management system (to manage changes to the information)
3) A tools control mechanism (to coordinate the use of CASE tools)
4) A user interface (to provide consistent pathway between actions made by user and tools)

The user interface layer


 Incorporates a standardized interface tool kit with a common presentation protocol.
 The interface tool kit contains software for human/computer interface management and a
library of display objects that provide mechanism for communication between the interface and
individual CASE tools.
 The presentation protocol is the set of guidelines that gives all CASE tools the same look and
feel.
The tools layer
 Incorporates a set of tools management services with the CASE tools.
 Tools management services (TMS) control the behavior of tools within the environment.
 TMS performs multitask synchronization and communication, coordinates the flow of
information from the repository and object management system into the tools, accomplishes
security and auditing functions, and collects metrics on tool usage.
The object management layer (OML)
 Performs the configuration management functions .
 Integration services—a set of standard modules that couple tools with the repository.
 Configuration management services- enables the identification of all configuration objects,
performing version control, and providing support for change control, audits, and status
accounting.
The shared repository layer
 the CASE database and the access control functions that enable the object management layer to
interact with the database.
 Data integration is achieved by the object management and shared repository layers.
OBJECT ORIENTED ANALYSIS AND DESIGN [OOAD]
OOAD methodology focuses attention on solving the problems associated with building
modern software systems.

Object-oriented analysis and design (OOAD) is a technical approach used in the


analysis and design of an application or system through the application of the object-
oriented paradigm and concepts including visual modeling.
This is applied throughout the development life cycle of the application or system.

OOAD comprises of Object Oriented Analysis[OOA] and Object Oriented Design[OOD]


OOA:
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. OOA TO OOD

OOD:
Object–Oriented Design (OOD) involves implementation of the conceptual model
produced during object-oriented analysis.
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”.
The implementation details generally include −
ADVANTAGES:
 Restructuring the class data (if necessary),
 Implementation of methods, i.e., internal data structures and algorithms,
 Implementation of control, and
 Implementation of associations.
Components in OOAD:

1. Object: An Object is an instance of a class.


 It represents a tangible real world entity. Eg.: a library member, an employee
2. 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.
Eg.: Vehicle is a class for Motorbikes, cars and buses
3. Information Hiding:
 The ability to protect some components of the object from external entities.
 This enables a variable to be declared as private or protected to the owing class.
4. Inheritance:
 The ability for a class to extend or override functionality of another class.
 The existing classes - the base classes/parent classes/super-classes
 the new classes - the derived classes/child classes/subclasses

Types of Inheritance
 Single Inheritance − A subclass derives from a single
super-class.
 Multiple Inheritance − A subclass derives from more
than one super-classes.
 Multilevel Inheritance − A subclass derives from a
super-class which in turn is derived from another
class and so on.
 Hierarchical Inheritance − A class has a number of
subclasses each of which may have subsequent
subclasses, continuing for a number of levels, so as to
form a tree structure.
 Hybrid Inheritance − A combination of multiple and
multilevel inheritance so as to form a lattice structure.
5. Interface:
 The ability to defer the implementation of a method.
 The ability to define the functions or methods signatures without implementing
them.
6. Polymorphism:
 Means the ability of an object to take multiple forms.
 Polymorphism allows objects with different internal structures to have a common
external interface.
Eg: Both cat and dog are animals with same method makeNoise() but they are
making noise in different in ways.

7. Encapsulation
 Encapsulation is the process of binding both attributes and methods together within a
class.
UNIFIED MODELING LANGUAGE [UML]
The Unified Modeling Language (UML) is a graphical language for OOAD that gives a
standard way to write a software system’s blueprint. It helps to visualize, specify, construct, and
document the artifacts of an object-oriented system. It is used to depict the structures and the
relationships in a complex system.
UML can be described as a general purpose visual modeling language to visualize, specify
and document software systems.
BUILDING BLOCKS OF UML:
The building blocks of UML can be defined as −

 Things
 Relationships
 Diagrams

THINGS:

Things are the most important building blocks of UML. Things can be −

 Structural
 Behavioral
 Grouping
 Annotational

STRUCTURAL THINGS

Structural things define the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.
 Class − Class represents a set of objects having similar responsibilities.

 Interface − Interface defines a set of operations, which specify the responsibility of a


class.

 Collaboration −Collaboration defines an interaction between elements.

Collaboration
 Use case −Use case represents a set of actions performed by a system for a specific goal.

 Component −Component describes the physical part of a system.

 Node − A node can be defined as a physical element that exists at run time.

BEHAVIORAL THINGS:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things −
 Interaction − Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.

 State machine − State machine is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change

GROUPING THINGS:

Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available −
 Package − Package is the only one grouping thing available for gathering structural and
behavioral things.
ANNOTATIONAL THINGS:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and


comments of UML model elements. Note - It is the only one Annotational thing available. A
note is used to render comments, constraints, etc. of an UML element.

RELATIONSHIP:

Relationship is another most important building block of UML. It shows how the elements are
associated with each other and this association describes the functionality of an application.
There are four kinds of relationships available.

 Dependency - Dependency is a relationship between two things in which change in one


element also affects the other.

 Association - Association is basically a set of links that connects the elements of a UML
model. It also describes how many objects are taking part in that relationship.

 Generalization - Generalization can be defined as a relationship which connects a


specialized element with a generalized element. It basically describes the inheritance
relationship in the world of objects.

 Realization - Realization can be defined as a relationship in which two elements are


connected. One element describes some responsibility, which is not implemented and the
other one implements them. This relationship exists in case of interfaces.

What are the graphical notations used in UML? Classes, Objects, Interface, Collaboration, use case,
active classes, components and Nodes.
UML DIAGRAM
UML Diagram is the graphical presentation of set of elements, most often rendered as a
connected graph of vertices (things) and paths(relationships).
UML defines various kinds of diagrams to cover most of the aspects of a system and to
understand the system in a better and simple way.
Types of UML diagram:
Types of UML diagrams

Structural Diagram Behavioral Diagram

 Class Diagram  Use Case Diagram


 Object Diagram  Interaction Diagram
 Component Diagram  State-chart Diagram
 Deployment Diagram  Activity Diagram

STRUCTURAL DIAGRAM

 The structural diagrams represent the static aspect of the system.


 These static parts are represents by classes, interfaces, objects, components and nodes.

1. CLASS DIAGRAM:

 Class diagrams are the most common and widely used diagrams in UML.
 Class diagram consists of classes, interfaces, associations, and collaboration.
 Class diagrams basically represent the object-oriented view of a system, which is static
in nature. Hence, it is generally used for development purpose.
 Active class is used in a class diagram to represent the concurrency of the system.
2. OBJECT

 Object diagrams can be described as an instance of class diagram.


 Object diagrams are a set of objects and their relationship is just like class diagrams.
 They also represent the static view of the system.
 The usage of object diagrams is similar to class diagrams but they are used to build
prototype of a system from a practical perspective.
John – Objectname
John:Student
Student - classname
Stud_No.=101

Stud_Name=John

Stud_Age=20

Year_Admission=2019

Course_Name=MBA

3. COMPONENT DIAGRAM

 Used to model physical aspects of the system


 Component diagrams represent a set of components and their relationships during
design phase. These components consist of classes, interfaces, or collaborations.
 Component diagrams represent the implementation view of a system.

4. DEPLOYMENT DIAGRAM

 Deployment diagrams are a set of nodes and their relationships. These nodes are
physical entities where the components are deployed.
 Deployment diagrams are used for visualizing the deployment view of a system. This
is generally used by the deployment team.
Deployment diagram for Online Banking transaction system

 It is used to visualize the topology of the physical components of a system where the
software components are deployed.

BEHAVIORAL DIAGRAM

The UML’s behavioral diagrams are used to visualize, specify, construct and document
the dynamic aspects of a system.

1. USE CASE DIAGRAM


 Use case diagrams are a set of use cases, actors, and their relationships. They
represent the use case view of a system.
 A use case represents a particular functionality of a system.
 It is a graphical representation of User’s interaction with System
2. INTERACTION DIAGRAM

 This diagram is used to describe some type of interactions among the different
elements in the model. This interaction is a part of dynamic behavior of the system.
 This interactive behavior is represented in UML by two diagrams
*Sequence diagram - on time sequence of messages
*Collaboration diagram. - the structural organization of the objects that send
and receive messages
SEQUENCE DIAGRAM –
 deals with the sequence of messages flowing from one object to another.
 Interaction among the components of a system is very important from
implementation and execution perspective.
 visualize the sequence of calls in a system to perform a specific functionality.
COLLABORATION DIAGRAM
 structural organization of a system and the messages sent/received.
 the specific purpose of collaboration diagram is to visualize the organization of objects
and their interaction.

3. STATE-CHART DIAGRAM
 Used to model dynamic nature of the system
 Describes different states of an object during its lifetime. And these stares are
changed by internal/external events in real time system
 Visualize the reaction of a system by internal/external factors.
4. ACTIVITY DIAGRAM
 Activity diagram is basically a flowchart to represent the flow from one activity to
another activity.
 The activity can be described as an operation of the system.
 The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent.
 Activity diagrams are used to visualize the flow of controls in a system.

You might also like