Research on system analysis approaches/ methods

- Move driven
- Structured
- Photocopying (discovery photo copying)

SYSTEMS DESIGN AND DEVELOPMENT

Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development.

Types of system design models

- Logical is concerned with what is required. It defines all the input to the systems, the output
to be produced, the processes that must be performed and constrains to be met.

- Physical design deals with how the requirements are satisfied. Describes how the data is
input, how it is stored and processed, how the output is produced, and the constraints that are
met

Qualities of a good design

 Use models to design systems- System design can be requirements based, function based, or
model based. Modelbased system design has an advantage of executable models that improve
efficiency and rigor
 Use hierarchical, top-down design
 Work on high-risk items first
 Prioritize- Prioritization will help with budget, schedule, system architecture, customer
satisfaction, and risk reduction
 Control the level of interacting entities- Objects should exchange inputs and outputs with other
objects at the same level, or perhaps at one level above or below
 Design the Interfaces-Interfaces between subsystems and interfaces between the main system and
the external world must be designed
 Do not optimize early-If you optimize early in the design process, you will have to reoptimize
every time the design changes. At the risk of being too specific, optimization should be done after
Critical Design Review
 Maintain an updated model of the system
 Develop stable intermediates- system development can be stop at predetermined points.
 Use evolutionary development- addition can be made to the design
 Understand your enterprise- Understand how the system you are designing fits into your
enterprise.
  State what, not how- State what function needs to be performed, not how to implement the
solution
 List functional requirements in the use cases
 Allocate each function to only one component
 Do not allow undocumented functions
 Provide observable states
 Rapid prototyping
 Develop iteratively and test immediately
 Create modules
 Create libraries of reusable objects
 Use open standards

System design components/ aspects of system design

(a) Design the Input: The types of forms to be used.
(b) Design the Output/ Reports-Is identifying reports and other output the system will
produce. Usually, designers sketch the form or display(screen) as they expect it to appear
when the system is complete.
(c) File Design/ Database

- Designers define the database and select storage devices, such as magnetic disk,
magnetic tape, or even paper files.

(d) Design the Processing

- The systems design also describes how the data will be processed. Individual data items and
calculation procedures are written in detail.

(e) Code design

System design tools

1. Decision tables
2. Structured English
3. ERDs ( Entity relationship diagram)
4. Structured charts
Entity-Relationship Modeling (Also known as Logical Data Structures)
1. Introduction

- A model is a representation of reality.

- Logical models show what a system is or does and depict the system independent of any technical
implementation.

- Physical models what a system is or does and also how the system is physically and technically
implemented.

- Data modeling is a technique for organizing and documenting a system’s data.

- Entity-Relationship modeling is a technique which can be used to analyze an organization’s data

requirements.

- The aim is to obtain a model which is a logical view of an organization’s data and serve as a
basis for computer implementation.

- Analysis of the proposed system will have provided the analyst with details of all the data items or
attributes

- The process uses a diagrammatic representation of the proposed tables identifying the table’s,
attributes and entities.

2. Components of an Entity Relationship Diagram

2.1 Entities

- An entity is something of importance to the system, about which data is held.

- An entity is a class of persons, places, objects, events, or concepts about which we need to
capture and store data.
- For example, in a student administration database entity could be Students; the entity type
would therefore be Student, whilst a particular occurrence of the entity type could be the Student
Chris Davies.

Identifying entities:

Entities are representations of data that is being stored. So if a DFD has been draw check there should be
an entity corresponding to each data store or file on the DFD.

Think about what groupings of data the user is going see.

An entity is something we are going to hold data about.

- An entity instance is a single occurrence of an entity.

- Example: instances of the entity STUDENT may include

- Betty Arnold

- John Taylor

- Bill Mac

An entity must have the following characteristics:

It must contain information of interest to the system i.e. the STUDENT entity contains information
concerning names, addresses, qualifications, exam results etc.;

It must be possible to have more than one occurrence i.e. the environment itself cannot be an entity as
there is only one occurrence;

Each occurrence must be uniquely identifiable - there must be a code or key for each entity instance.

2.2 Entity Attributes

-An attribute is a descriptive property or characteristic of an entity. i.e. a field.

- These are the data items associated with each entity.

Example - Student as an entity may have the following attributes:

Name:

Address:

DOB:

ADM Number:

2.3 Unique Identifiers

A unique attribute that identifies an entity.

2.4 Relationships

The association between Entities

Cardinality

- The degree of association between entities.

- A relationship’s cardinality defines the maximum number of entities of one type that can be associated
with an entity of another type.

There are three basic cardinalities

- One to one

- One to many

- Many to many

A one-to-one (1:1) relationship is when at most one instance of an entity A is associated with
one instance of entity B. For example, take the relationship between board members and offices,
where each office is held by one member and no member may hold more than one office.
A one-to-many (1:N) relationship is when for one instance of entity A, there are zero, one, or
many instances of entity B but for one instance of entity B, there is only one instance of entity A.
An example of a 1:N relationships is

a department has many employees; each employee is assigned to one department.

A many-to-many (M:N) relationship is when for one instance of entity A, there are zero, one, or
many instances of entity B and for one instance of entity B there are zero, one, or many instances
of entity A. An example is employees may be assigned to no more than three projects at a time;
every project has at least two employees assigned to it.

Components of ER Diagrams:

 rectangles representing entity sets.

 ellipses representing attributes.

 diamonds representing relationship sets.

 lines linking attributes to entity sets and entity sets to relationship sets.

Example:

- The entity types such as EMP and PROJ are depicted as rectangular boxes, and the
relationship types such as WORK-FOR are depicted as a diamond-shaped box.

- The attributes such as EMP#, NAME, and PHONE are depicted as ellipse.

- The cardinality information of relationship is also expressed. For example, the “1” or “N” on
the lines between the entity types and relationship types indicated the upper limit of the
entities of that entity type participating in that relationship.
Review Questions

Question 1. For each of the following pairs of rules, identify two entity types and one
relationship. State the cardinality and existence of the relationship in each case. Draw the
ER diagram.

1. A department employs many persons. A person is employed by, at most, one department.

2. A manager manages, at most, one department. A department is managed by, at most, one
manager.

3. An author may write many books. A book may be written by many authors.

4. A team consists of many players. A player plays for only one team.

5. A lecturer teaches, at most, one course. A course is taught by exactly one lecturer.

6. A flight-leg connects two airports. An airport is used by many flight-legs.

7. A purchase order may be for many products. A product may appear on many purchase orders.

8. A customer may submit many orders. An order is for exactly one customer.
 Question 2: Draw an ER diagram for the following. Be sure to indicate the existence and
cardinality for each relationship.

A college runs many classes. Each class may be taught by several teachers, and a teacher may teach
several classes. A particular class always uses the same room. Because classes may meet at different
times or on different evenings, it is possible for different classes to use the same room.
 SYSTEM DEVELOPMENT METHODOLOGIES

 Structured
 traditional
 object oriented

STRUCTURED
Structured approach is a development method that allows 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
 Decision Tables
 Structured English
 Pseudocode

TRADITIONAL

Each phase begins only when the one before it is completed. Often the traditional approach is
revised for the development of large transaction, processing systems. E.g. in waterfall model
(analysis, design, implementation, testing and maintenance) and spiral model

Phases are:

 Preliminary investigation,
 system analysis
 system design
  system acquisition
 system implementation

OBJECT ORIENTED (OO)

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.
Polymorphism and Dynamic Binding
Polymorphism is the ability to take on many different forms. It applies to both objects and
operations. A polymorphic object is one who true type hides within a super or parent class.
In polymorphic operation, the operation may be carried out differently by different classes of
objects. It allows us to manipulate objects of different classes by knowing only their common
properties.
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 or Program is organized by having number of classes
functions. and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

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

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

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

It is suitable for real time system, embedded system It is suitable for most business applications, game
and projects where objects are not the most useful level development projects, which are expected to
of abstraction. 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 clearly In this approach, projects can be difficult to manage
identifiable phases. due to uncertain transitions between phase.

System analysis methods

Prototyping

JSD

SSDAM structured system analysis method

FUNCTIONAL DECOMPOSITION

Structured Systems Analysis and Design Method. SSADM with ConceptDraw

DIAGRAM

Structured Systems Analysis and Design Method (SSADM) is the method which is used
at projecting and analysis of information systems. SSADM is based on the data flow
diagrams. At the early stages of projecting at description of models (functional,
informational and event-trigger) the top-down method is used.
At the description of data flows out of the system and into the system DFD, which
denote boundaries of the system, are used.
At the description of data models LDS (Logical Data Structure) diagrams are used. LDS
describes which data the system operates with. It is created for existing system and is
added at the development of the new one.
For modelling events, happened in the system, ELN (Entity Life History) diagrams are
used. These diagrams support states indications and the possibility of description not
only consecutive but parallel or reiterative events and also description of the choice of
events course. ELN describes how data change in the system in the course of time at
different variants of events.
Thus, the most important SSADM elements are flows modelling with the help of DFD,
data logic modelling with the help of LDS and description of entities behavior.
Analysis, projecting and documenting of information system accordingly to SSADM
involves 6 main stages. Each stage is divided into several steps, which define tasks that
should be fulfilled at the given stage. The system is studied for getting system
requirements. Detailed project is created on the logic level and then transformed into
physical project.
SSADM stages:

 Analysis of the existing system or estimation of practicability.

 Requirements definition.
 Definition of technical requirements and device equipment cost.
 Development of logical data model.
 Projecting of logical requirements. Specification of requirements.
 Physical projecting.

The advantages of SSADM

1. Multiple angles of analysis
2. Less chance of misunderstnding
3. Rigid control- very structured and takes control of every step of creatio process
4.