Structured Analysis and Design (SA/SD)
When the software systems keep getting bigger and more complex, you need a way to represent the model systematically. Structured Design and Structured Analysis, often referred to as SA/SD, is an excellent way to improve the quality of your System and reduce the risk of System failure.
SA/ SD is simply a diagrammatic way to showcase your complete System and help the client understand the entire design. After you get a whole idea of what the System is supposed to do, you should create a structured plan for the same. SA/SD also establishes all the needed documentation and management requirements, allowing easy access to look at and maintain the System.
Method of Structured Design
The primary method for Structured Design is to represent the System in the form of a network of different functions, where each of the parts means each section and performs a specified task.
This approach uses a variety of blocks and arrows to denote the relations between all the parts of your structure.
SA/SD is even used to denote the manufacturing procedure and the complex software systems.
In the late 1960s, Larry Constantine developed the technique of Structured design (SD), which usually focuses on building the modules and creating the module hierarchy to represent the idea for your IT System.
Module hierarchy can be created optimally by keeping the two basic rules in mind: Cohesion and Coupling.
Cohesion deals with grouping functions with similar tasks in the same module, and Coupling determines the flow of information among the different modules in our design.
A sound module hierarchy is easily understandable and reduces the complexity of your final design of the System.
On the other hand, Structured Analysis (SA) is the process of interpreting the design of a System represented as DFDs of modules that was created using the structured methodology.
Structured Design and Structured Analysis are used together to focus on defining the system boundaries by using the graphical representation. SA/ SD are together known as SAD, which primarily deals with three points:
- System
- Process
- Technology
The two major phases involved in the SAD approach are:
- Analysis Phase: This phase involves the different diagrams used for the representation and the data dictionary to identify the data.
- Design Phase: This phase includes the structure Chart and the pseudo-code for the easy understanding of the developer.
Let us discuss each of the elements involved in the SAD approach individually.
1. Design Phase:
- Data Flow Diagram
This representation is used to define the flow of data in our final complete System, i.e. how the information would be passed from each module to the other. We can use the operators AND (&&) & OR (||) to represent more than one input or output at any stage. For example, one can use the OR operator in the output link of any module where the instance would lead to two different choice paths like on confirming an order; you would be given a choice to pay now or pay on delivery in an e-commerce system.
- Data Dictionary
When some data cannot be represented in the form of Data Flow Diagrams, it is represented using a data dictionary.
A Data dictionary stores the data and has a relevant meaning for each data item.
A physical data dictionary can also be added to the System design for the data elements that flow between different processes and/ or entities.
We can also use the logical data dictionary for some types of data elements.
- State Transition Diagram
This diagram is a lot similar to the dynamic model; in this type of representation, the state of our System transitions with the occurrence of each event. A state transition Diagram also states the amount of time that would be required by the function to execute and access the data once it has been triggered by an event. This model specifies all the states the System could have and which event would trigger which function.
- ER Diagram
Also known as Entity-Relation Diagram. This model is quite famous for designing the database in the form of entities and their relationships.
2. Analysis Phase:
- Structure Chart
A structure Chart is created using the information retrieved from the data flow diagrams. This is primarily used to specify how the processes are allocated to the CPU.
The modules in the structure chart are arranged randomly, and any of the processes from the data flow diagram can be chosen as the central point. The complete formation of the Structure Chart only depends on what the analyst thinks and understands. Some of the main drawbacks of using the structure chart are that these are very hard to maintain, verify or amend. Checking the completeness and consistency of the structure chart is also a hassle.
- Pseudo Code
This is basically an overview and simple idea of how the implementation of the System would look in a very informal manner just for the sake of the developer's understanding.
These were the two phases that we discussed in deep that are used in the SAD approach for System Design.