Research on system design 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.