Se3

2. ◦ A data dictionary is a structured repository of information about the data within a system. It lists all data
flows and the contents of data stores from a Data Flow Diagram (DFD) model. Its primary purpose is to
provide a standardized, consistent, and well-defined vocabulary for all data items used in a software project.
◦ Purpose of a Data Dictionary
◦ A data dictionary is essential in software development for several reasons:
◦ Standardized Terminology: It establishes a consistent vocabulary for all data items, preventing confusion in
large projects where multiple developers may use different terms for the same data.
◦ Structured Definitions: It helps developers understand the composition of data structures during
implementation, as composite data items are defined by their component elements.
◦ Impact Analysis: The dictionary facilitates impact analysis by allowing developers to trace the effects of
changes to data items on various processes and vice versa. This is particularly useful for assessing the impact
of a bug fix or a change in an input value's data type.

3. Operators for Data Definition
◦ + : denotes composition of two data items, e.g. a+b represents data a and b.
◦ [,,] : represents selection, i.e. any one of the data items listed inside the square bracket can occur. For
example, [a,b] represents either a occurs or b occurs.
◦ () : the contents inside the bracket represent optional data which may or may not appear. Function-
Oriented Software Design 247 a+(b) represents either a or a+ b occurs.
◦ {} : represents iterative data definition, e.g. {name}5 represents five name data. {name}* represents zero
or more instances of name data.
◦ = : represents equivalence, e.g. a=b+c means that a is a composite data item comprising of both b and c.
◦ /**/ : Anything appearing within /* and */ is considered as comment.

4. Structured Design
Structured design is a methodology that converts the results of structured analysis, specifically the DFD model, into a structure chart. This
chart visually represents the software's architecture, showing the system's modules, their dependencies, and the data passed between them. It
focuses on the modular structure and module interactions, not on the procedural details of how a specific function is achieved.
Key Components of a Structure Chart
◦ The basic building blocks of a structure chart are:
◦ Rectangular Boxes: These represent individual modules within the system. The name of the module is written inside the box.
◦ Module Invocation Arrows: An arrow connecting two modules indicates that control is passed from one module to another during
execution. The arrow points in the direction of the control flow. It doesn't specify how many times a module is called or the order of
module invocation.
◦ Data Flow Arrows: Small arrows placed alongside the module invocation arrows represent data being passed between modules. They are
annotated with the name of the data item and point in the direction of the data flow.
◦ Library Modules: Represented by a rectangle with double edges, these are frequently called modules. When a module is invoked by
many other modules, it is often designated as a library module.
◦ Selection: A diamond symbol is used to show that one of several modules will be invoked based on a specific condition.
◦ Repetition: A loop around the control flow arrows indicates that the connected modules are invoked repeatedly.

5. ◦ Structure Chart Principles
◦ A valid structure chart must adhere to the following rules:
◦ Single Root Module: There must be one and only one module at the very top of the chart, referred to as
the root.
◦ No Circular Relationships: A module can't invoke another module that, in turn, invokes the first module
(e.g., if Module A calls Module B, Module B cannot call Module A). This ensures a hierarchical, layered
structure where lower-level modules are not aware of higher-level modules.

6. Flow chart vs structure chart
. Representation of Modules
•A flow chart depicts the flow of control in a program, showing the steps and decisions of an algorithm. It can be
difficult to identify individual program modules from a flow chart.
•A structure chart explicitly represents the modules of a system as a tree-like hierarchy. It shows which modules call
other modules, providing a clear visual of the software's architecture
Data Interchange
•A flow chart does not represent data interchange between different parts of a program. Its symbols and arrows are
primarily concerned with control flow.
•A structure chart, by contrast, uses data flow arrows alongside the module invocation arrows to show which data
items are passed from one module to another.
Sequential Ordering
•A flow chart is inherently sequential. The arrows dictate a step-by-step, ordered execution of tasks.
•A structure chart suppresses this sequential ordering. While it shows module dependencies (A calls B), it doesn't
specify the order in which multiple child modules are invoked or if a module is called once or many times. This allows
the designer to focus on the modular structure rather than the execution sequence.

7. Transforming a DFD to a Structure Chart
◦ Transforming a DFD into a structure chart involves two main strategies: Transform Analysis and
Transaction Analysis. These techniques help convert the functional representation of a system (DFD)
into a modular, hierarchical structure (structure chart).
◦ The choice between the two strategies depends on how the input data is processed within the DFD.
◦ Transform Analysis: This method is used when all incoming data is processed in a similar way. In a
DFD, this means all input data flows converge on a single processing bubble. This technique is typically
used for simple, low-level processing that can be implemented with a small amount of code.
◦ Transaction Analysis: This is applied when input data flows are processed in different ways. Each
unique processing path or "transaction" corresponds to a distinct functionality of the system. Transaction
analysis is useful for DFDs that handle multiple types of inputs, each leading to a different sequence of
operations.

8. Transform analysis
◦ Transform analysis is a method for converting a Data Flow Diagram (DFD) into a structure chart by dividing the DFD into three parts:
input, processing, and output. This technique is used when all data is processed in a similar fashion.
◦ The Steps of Transform Analysis
◦ Identify DFD Components: The DFD is partitioned into three distinct sections:
◦ Input (Afferent Branch): This part handles the conversion of raw, physical input data (e.g., characters from a terminal) into a logical format (e.g.,
internal tables or lists).
◦ Output (Efferent Branch): This section converts processed data from its logical form into a physical output (e.g., a printed report or a screen
display).
◦ Central Transform: The remaining part of the DFD, located between the afferent and efferent branches, represents the core processing of the
system where the main logical transformations occur.
◦ Initial Structure Chart Creation: A top-level structure chart is created with a single root module. This root module calls three main
functional components: one for the central transform, one for the afferent branch, and one for the efferent branch.
◦ Refine the Structure Chart (Factoring): The high-level functional components are broken down into sub-components, a process
known as factoring. This step involves adding modules for specific tasks like reading/writing data, handling errors, and managing
initialization and termination. Factoring continues until all bubbles (processes) from the original DFD are represented as modules in
the structure chart.

9. Transaction analysis
◦ Transaction analysis is a design strategy used to transform a DFD into a structure chart, particularly for transaction-
driven systems. It differs from transform analysis because it handles a variety of input data, each leading to a distinct
processing path or "transaction."
◦ Key Concepts
◦ Transactions: A transaction is a specific piece of work a user performs with the software (e.g., "issue book," "return
book," "query book"). Each transaction corresponds to a different computational path within the DFD.
◦ Transaction-Driven Systems: In these systems, incoming data can be routed to different processing bubbles. Each
unique processing path constitutes a separate transaction.
◦ How to Apply Transaction Analysis
◦ Identify Input Data: First, identify all data entering the DFD. The number of bubbles on which the input data flows
are incident generally indicates the number of transactions. Some transactions may not require input data, and
identifying these depends on experience.
◦ Trace Transactions: For each identified transaction, trace its path from input to output through the DFD. All the
bubbles traversed for a single transaction belong together and will be mapped to a single module in the structure chart.
◦ Create the Structure Chart:
◦ Draw a single root module.
◦ Below this root module, draw a separate module for each identified transaction.
◦ The structure chart will typically include a transaction-center module responsible for determining the type of
transaction and routing control to the appropriate transaction module. The transaction-center module uses a tag
associated with the input data to identify its type.

10. ◦ A super market needs to develop a software that would help it to automate a scheme that it plans to
introduce to encourage regular customers. In this scheme, a customer would have first register by
supplying his/ her residence address, telephone number, and the driving license number. Each customer
who registers for this scheme is assigned a unique customer number (CN) by the computer. A customer
can present his CN to the checkout staff when he makes any purchase. In this case, the value of his
purchase is credited against his CN. At the end of each year, the supermarket intends to award surprise
gifts to 10 customers who make the highest total purchase over the year. Also, it intends to award a 22
caret gold coin to every customer whose purchase exceeded `10,000. The entries against the CN are reset
on the last day of every year after the prize winners’ lists are generated.

11. ◦ Detailed design is the phase where the modules defined in the structure chart are specified in detail. This
involves designing the pseudocode for processing and defining the specific data structures for each
module. These details are typically documented in Module Specifications (MSPEC).
◦ MSPEC: This document is usually written in structured English.
◦ For non-leaf modules, the MSPEC describes the conditions under which tasks are delegated to lower-level
modules.
◦ For leaf-level modules, the MSPEC provides an algorithmic description of how primitive processing steps are
performed.
◦ To create a module's MSPEC, designers must refer to the DFD model and the Software Requirements
Specification (SRS) to fully understand its functionality.

12. Design Review
◦ After the detailed design is complete, a formal design review is conducted by a team to check the design documents.
This team typically includes individuals with expertise in design, implementation, testing, and maintenance, who may
not be part of the core development team. The review aims to ensure the quality and readiness of the design for
implementation.
◦ The review team checks the design documents for several critical aspects:
◦ Traceability: They verify that every bubble in the DFD can be mapped to a corresponding module in the structure
chart and vice versa. They also check if each functional requirement in the SRS can be traced to a bubble in the DFD.
◦ Correctness: The team assesses if all the algorithms and data structures specified in the detailed design are correct.
◦ Maintainability: The design is evaluated for its ease of maintenance in the future.
◦ Implementation: The team determines if the design can be easily and efficiently implemented.
◦ Once the designers have addressed all the points raised by the reviewers, the design document is approved for
implementation.