System Analysis & design

Faculty of Computers and Information

Academic Year 2014/ 2015Term (2)

Ass iut University

Year 2

Copyright 2014 – Dr. Hossam Ragab

10

Another important activity of the design phase is designing the programs that will perform the

system’s application logic. Programs can be quite complex, so analysts must create instructions and

guidelines for programmers that clearly describe what the program must do.

OBJECTIVES• Be able to revise logical DFDs into physical DFDs.

• Be able to create a structure chart.

• Be able to write a program specification.

• Be able to write instructions using pseudocode.

• Become familiar with event-driven programming.

Program Design

• Program design is the part of the design phase of the SDLC during which analysts determine;

– what programs will be written,

– create instructions for the programmers about how the code should be written, and

– identify how the pieces of code will fit together to form a program

• When the program design is developed, the following activities are performed;

1. First, the process of revising logical data flow diagrams into physical data flow diagrams is outlined.

2. Then, two techniques typically used together for describing programs are presented.

a) The structure chart depicts a program at a high level in graphic form.

b) The program specification contains a set of written instructions in more detail.

– Together, these techniques communicate how the application logic for the system needs to be developed.

• During analysis, the systems analysts identified the processes and data flows that are needed to support the functional requirements of the new system. (Logical data flow diagrams for the to-be system)

• During design, physical process models are created to show implementation details and explain how the final system will work.

• The physical DFD contains the same components as the logical DFD(e.g., data stores, data flows), and the same rules apply (e.g., balancing,

decomposition)

– The basic difference between the two models is that a physical DFDcontains additional details that describe how the system will be built

MOVING FROM LOGICAL TO PHYSICAL PROCESS MODELS

The Physical Data Flow Diagram

• There are five steps to be performed to move from logical to the physical DFD;

1) Add Implementation References

2) Draw a Human-Machine Boundary

3) Add System-Related Data Stores, Data Flows, and Processes

4) Update the Data Elements in the Data Flows

5) Update the Metadata in the Computer-Aided Software Engineering Repository

(“Metadata” is a set of data that describes and gives information about other data.)

1) Add Implementation References; begin with the existing logical DFD

and add references to the ways in which the data stores, data flows, and processes will be implemented. On physical DFDs;

– Data stores refer to files and/or database tables

– Processes refer to programs or human actions

– Data flows refer to the physical media for the data, e.g. paper reports, bar code scanning, input screens, or computer reports

The names for the various components on the physical DFD should contain references to these implementation details.

The Physical Data Flow Diagram

2) Draw a Human-Machine Boundary; Physical DFDs differentiate human and

computer interaction by a human-machine boundary, a line drawn on the model to separate human action from automated processes.

• The following criteria should be consider when drawing the boundary: cost, efficiency, and integrity.

– Piece of the system should be automated only if the cost of computerizing it is less than doing it manually.

– The system should be more efficient with the mode that is selected.

– Team should consider also the integrity of the information that is handled by the system.

3) Add System-Related Data Stores, Data Flows, and Processes; Add

to the DFD additional processes, stores, or flows that are specific to the implementation of the system and have little (or nothing) to do with the business process itself. These additions can be due to technical limitations or to the need for audits, controls, or exception handling.

– Technical limitations occur when technology cannot support the way in which the system is modeled logically.

– Audits, controls, or exception handling refers to putting checks and balances in place in the system in case something goes wrong

Logical DFD for Tune Source

Process 1: Search and Browse Tunes

Physical DFD for Tune Source

Process 1: Search and Browse Tunes (the How)

The Physical Data Flow Diagram

4) Update the Data Elements in the Data Flows; to update the elements in

the data flows. The data flows will appear to be identical in both the logical and physical DFDs, but the physical data flows may contain additional system-related data elements, for reasons similar to those described in the previous section.

5) Update the Metadata in the Computer-Aided Software Engineering Repository; Project team needs to make sure that the information

about the DFD components in the CASE repository is updated with implementation-specific information. This information can include when batch processes will be run and how often, names of the actual tables or files that are represented by data flows, and the sizes and projected growth rates of the data stores.

Self study .., Applying the Concepts at Tune Source (page 369, 370)

Designing Program

• Different design tool is necessary that simplifies the conversion of processes into program codes. Systems design approach can be looked as the bottom-up or top-down approach.– Bottom-Up Design: Bottom-up design refers to identifying the processes

that need computerization as they arise, analyze them and integrate into the system.

• Businesses often take this approach when a system requires integration of various software packages that can be purchased of the shelf.

– Top-Down Design: In this approach, the overall system is viewed as a hierarchical framework of subsystems (or modules). The advantage of this approach is to;

• Avoid the chaos of attempting to design a system "all at once."

• Allow parallel development of the subsystems by more than one programmer teams, which can save a great deal of time.

• Prevents the systems analyst to get involved into simple details, so the objective of the system is not forgotten.

DESIGNING PROGRAMS

Analysts follow the top-down modular approach.

– This approach helps orient programmers and conveys the big picture of what to do, making the detailed much easier to understand, as follows

1. Analysts create a high-level diagram that shows the various components of a program, how the components should be organized, and how the

components interrelate. This diagram, known as the structure chart.

• Structure chart illustrates the organization and interactions of the different pieces of code within the program to the analysts and programmers so that the program can be developed by many programmers working independently.

2. The Program specifications are written to describe exactly what needs

to be included in each program module, specifications include basic module information, special instructions for the programmer, and pseudocode.

• Pseudocode is a technique similar to structured English that is used to communicate what needs to be written, using programming structures and a generic language that is not program language specific

3. At the end of program design, the project team compiles the program design document, which includes all of the structure charts and program specifications that will be used to implement the system.

STRUCTURE CHART

• The structure chart is an important technique that helps the analyst design the program for the new system, it shows all the components of code that must be included in a program– at a high level,

– arranged in a hierarchical format that implies sequence (in what order components are

invoked),

– selection (under what condition a module is invoked), and

– iteration (how often a component is repeated).

• The components are usually read from top to bottom, left to right, and they are numbered by a hierarchical numbering scheme in which lower levels have an additional level of numbering (e.g., third

level of modules would be numbered 1.1.1, 1.1.2, 1.1.3… ).

• Structure charts help analysts create programs that are easy to understand and maintain, because the use of self-contained modules keeps changes from rippling throughout the programs. (historically have been used to create transaction-based mainframe applications)

Structure Chart Example

• Suppose that an academic system needs a program that will print a listing of students along with their grade point averages (GPAs), both for the current semester and overall, and you have been asked to create a structure chart shows communicates the basic components of this program and shows the interrelatedness of the modules.

In order to do so;• First, the program must retrieve the student grade records;

• then it must calculate the current and cumulative GPAs;

• finally, the grade list can be printed.

Structure Chart Example

• Looking at this structure chart, a programmer can tell that there are four main code modules involved in creating a student grade listing:– Getting the student grade records,

– Calculating current GPA,

– Calculating cumulative GPA,

– Printing the listing

• Also, there are various pieces of information that are either required by each module or created by it (e.g., the grade record, the cumulative GPA).

STRUCTURE CHART

• Syntax• Module; A structure chart is

composed of modules (lines of

program code that perform a single

function) that work together to form a program.

– Modules are depicted by a rectangle and connected by lines, which represent the passing of control

– A control module is a higher-level component that contains the logic for performing other modules

– the components that it calls and controls are considered subordinate modules.

– The Library Module is a collection of related functionality, (modules that reused, and have vertical lines on both sides of the rectangle)

control module

Subordinate Modules Library module

STRUCTURE CHART

Structure Chart Elements

• There are two symbols that describe special types of control that can appear on the structure chart. – The curved arrow, or loop, indicates that the execution of some or all

subordinate modules is repeated,

– The conditional line (depicted by a diamond) denotes that execution of one or more of the subordinate modules occurs in some cases but not in others.

STRUCTURE CHART

The curved arrow, or loopconditional line

STRUCTURE CHART

• The loops and conditional line affect the meaning of the diagram. First, the loop through the lines to modules 1.1, 1.2, and 1.3 means that, before the next two modules are invoked, the first three modules will be repeated until their functionality is completed (i.e., all of the student grades will be read and the two GPAs will be calculated before moving to the print modules).

• Second, the lines connected by the conditional line convey that both the dean’s list report and grade listing are not printed each time this program is run, but instead are performed upon the basis of some condition. Therefore, there are times when one or both of the print modules may not be invoked.

STRUCTURE CHART

• Syntax• Couples; shown by arrows, are

drawn on the structure chart to show that information is passed between modules, with the arrowhead indicating which way the information is being sent

– Data couples, shown by arrows with empty circles, are used to represent the passing of pieces of data or data structures to other

– Control couples, drawn with the use of arrows with filled-in circles, are used to pass parameters or system-related messages back and forth among modules (also called a flag) control flags should be passed from subordinates to control modules, but not the other way around.

e.g. module 1.1 sends an end-of-file parameter when program reaches end of student grade file

Building the Structure Chart

• Process models are used as the starting point for structure charts. There are three basic kinds of processes on a process model, afferent, central, and efferent.

– Afferent processes are processes that provide inputs into the system

– Central processes perform critical functions in the operation of the system,

– Efferent processes deal with system outputs

• Transaction structure; used when each module performs one of a group of individual transactions and contains a control module that calls subordinate modules, each of which handles a particular transaction.

– Transaction structures often occur where the actual system contains menus or submenus, and they are usually found higher up in the levels of a structure chart

• Transform Structure; is the second type of module structure, which has a control module that calls several subordinate modules in sequence, after which something “happens.”

– These modules are related because together they form a process that transforms some input into an output

Transform and Transaction Structures

Creating a structure chart

• Creating a structure chart is usually a four-step process;1. Identify Modules and Levels

2. Identify Special Connections

3. Add Couples

4. Revise Structure Chart

Self study .., Applying the Concepts at Tune Source (page 380 - 384)

Design Guidelines

• Measures of good design include cohesion, coupling, and appropriate levels of fan-in and/or fan-out

Build Modules with High Cohesion – Cohesion refers to how well the lines of code within each structure chart

module relate to each other.

– A module that performs a single function or task has a high degree of cohesion and is desirable

Design Guidelines

Build Loosely Coupled Modules • Coupling involves how closely modules are interrelated, and the second

guideline for good structure chart design states that modules should be loosely coupled.

Coupling measures relationships and interdependence among modules. Modules that are relatively

independent of data communication are loosely coupled

Loosely coupled modules are easier to maintain because they are independent.

If one module refers to the internal logic of another module, the two modules are termed tightly coupled.

Types of Coupling

• There are five types of coupling, each falling on different parts of a good-to bad continuum.

• Data coupling occurs when modules pass parameters or specific pieces of data to each other, and this is a form of coupling that you want to see on your structure chart.

• A bad coupling type is content coupling, whereby one module actually refers to the inside of another module.

Design Guidelines

Create High Fan-In• Fan-in describes the number of control modules that communicate with a

subordinate . a module with high fan-in has many different control modules that call it.

• Structures with high fan-in improve the reusability of modules and make it easier for programmers to recode when changes are made or mistakes are uncovered, because a change can be made in one place.

Avoid High Fan-Out • Although we desire a subordinate to have multiple control modules, we

want to avoid a large number of subordinates associated with a single

control. • The general rule of thumb is to limit a control module’s subordinates to

approximately seven.

Examples of Fan-In and Fan-Out(IRA individual retirement account)

High Fan-In;

Low Fan-In;

High Fan-Out;

Low Fan-Out

Assess the Chart for Quality;

Library modules have been created whenever possible.

The diagram has a high fan-in structure.

Control modules have no more than seven subordinates.

Each module performs only one function (high cohesion).

Modules sparingly share information (loose coupling).

Data couples that are passed are actually used by the accepting module.

Control couples are passed from “low to high.”

Each module has a reasonable amount of code associated with it.

Design Guidelines

PROGRAM SPECIFICATION

Once the big picture of how the program should be put together, analyst then must describe the individual modules in enough detail so that programmers can take over and begin writing code.

Modules on the structure chart are described by the use of program specifications write one program specification for each module

Specifications must be very clear and easy to understand, or else programmers will be slowed down trying to decipher vague or incomplete instructions.

Syntax• There is no formal syntax for a program specification,

however, most program specification forms contain four components that convey the information that programmers will need to write the appropriate code.

– Program Information

– Events

– Inputs and Outputs

– Pseudocode

PROGRAM SPECIFICATION

Syntax• Program Information contains basic

program information, such as the name of the module, its purpose, the deadline, the programmer, and the target programming language.

• Events are things that happens or takes place, trigger the functionality in the program (e.g. Clicking the mouse generates a mouse event; pressing a key generates a keystroke event)

• Inputs and Outputs specification describe the inputs and outputs to the program, which are identified by the data couples and control couples found on the structure chart.

• Pseudocode is a text-based outline of a program, used to describe logical structures, including sequential, conditional, and iterations of programs.

Logical Steps of

Sales Commission

“Pseudocode”