What do you Mean by Structured Analysis.

The structured analysis technique uses function-based decomposition while modeling the problem. It focuses on the functions performed in the problem domain and the data consumed and produced by these functions.

The structured analysis method helps the analyst decide what type of information to obtain at different points in analysis, and it helps organize information so that the analyst is not overwhelmed by the complexity of the problem.

It is a top-down refinement approach, which was originally called structured analysis and specification and was proposed for producing the specifications. However, we will limit our attention to the analysis aspect of the approach. Before we describe the approach, let us describe the data flow diagram and data dictionary on which the technique relies heavily.

Data Flow Diagrams and Data Dictionary

Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. Data flow diagrams (DFDs) are quite general and are not limited to problem analysis for software engineering discipline. DFDs are very useful in understanding a system and can be effectively used during analysis.

A DFD shows the flow of data through a system. It views a system as a function that transforms the inputs into desired outputs. Any complex system will not perform this transformation in a “single step”, and data will typically undergo a series of transformations before it becomes the output.

The DFD aims to capture the transformation that take place within a system to the input data so that eventually the output data is produced. The agent that performs the transformation of data from one state to another is called a process (or a bubble). So, a DFD shows the movement of data through the different transformations or processes in the system.

The processes are shown by named circles and data flows are represented by named arrows entering or leaving the bubbles. A rectangle represents a source or sink and is a pet originator or consumer of data. A source or sink is typically outside the main system of study. An example of a DFD for a system that pays workers.

In this DFD there is one basic input data flow, the weekly timesheet, which originates from the source worker. His basic output is the paycheck, the sink for which is also the worker, In this system, first the employee’s record is retrieved, using the employee ID, which is contained in the timesheet.

From the employee record, the rate of payment and overtime are obtained. These rates and the regular and overtime hours (from the timesheet) are used to compute the pay. After the total pay the tax-rate file is used. The amount of tax deducted is recorded in the employee and company records. Finally, the payback is issued for the net pay. The amount paid is also recorded in company records.

This DFD is an abstract description of the system for handling payment. It does not matter if the system is automated or manual. This diagram could very well be for a manual system where the computations are all done with calculators and not represented in this DFD.

For example, what happens if the error in the weekly timesheet is not shown in this DFD. This is done to avoid getting bogged down with details while constructing a DFD for the overall system. If more details are desired, the DFD can be further refined.

It should be pointed out that a DFD is not a flowchart. A DFD represents the flow of data. While a flowchart shows the flow of control, a DFD does not represent procedural information. So, while drawing a DFD, one must not get involved in procedural details, and procedural thinking must be consciously avoided.

For example, considerations of loops and decisions must be ignored. In drawing the DFD, the designer has to specify the major transforms in the path of the data flowing.

While analyzing the problem domain the problem can be partitioned with respect to its functionality or with respect to objects. Object oriented modeling for (object-oriented analysis) uses the latter approach. During analysis, an object represents some entity or some concept in the problem domain.

An object contains some state information and provides some services to entities outside the objects. The state of the object can be accessed or modified only through the services they provide. Some objects also interact with the users through their services such that the users get the desired services.

Hence the goal of modeling is to identify the objects that exist in the problem domain, define the objects by specifying what state information they encapsulate and what services they provide, and identify relationships that exist between objects, such that the overall model is such that it supports the desired user services. Such a model of a system is called its object model.