Elements of Software Analysis and Design - Structured Approaches - Structured Analysis - Functional Oriented Design 10/24/2015ICS 413 – Software Engineering1

Elements of Software Analysis and Design

- Structured Approaches- Structured Analysis

- Functional Oriented Design

04/20/23 ICS 413 – Software Engineering 1

2

Introduction • Function-oriented design techniques are

very popular:– currently in use in many software development

organizations.

• Function-oriented design techniques: – start with the functional requirements specified

in the SRS document.

04/20/23 ICS 413 – Software Engineering

3

Introduction • During the design process:

– high-level functions are successively decomposed: • into more detailed functions.

– finally the detailed functions are mapped to a module structure.


4

Introduction • Successive decomposition of high-

level functions: – into more detailed functions. –Technically known as top-down

decomposition.


5

Introduction • SA/SD methodology:

– has essential features of several important function-oriented design methodologies --- • if you need to use any specific design

methodology later on, • you can do so easily with small additional

effort.


6

SA/SD (Structured Analysis/Structured Design)

• SA/SD technique draws heavily from the following methodologies:– Constantine and Yourdon's methodology – Hatley and Pirbhai's methodology – Gane and Sarson's methodology– DeMarco and Yourdon's methodology

• SA/SD technique can be used to perform– high-level design.


7

Overview of SA/SD Methodology

• SA/SD methodology consists of two distinct activities: – Structured Analysis (SA) – Structured Design (SD)

• During structured analysis:– functional decomposition takes place.

• During structured design:– module structure is formalized.


8

Functional decomposition

• Each function is analyzed:–hierarchically decomposed into more

detailed functions. –simultaneous decomposition of high-

level data • into more detailed data.


9

Structured analysis

• Transforms a textual problem description into a graphic model.–done using data flow diagrams

(DFDs).–DFDs graphically represent the

results of structured analysis.


10

Structured design

• All the functions represented in the DFD:– mapped to a module structure.

• The module structure:–also called as the software

architecture:


11

Detailed Design

• Software architecture:–refined through detailed design.–Detailed design can be directly

implemented: • using a conventional programming

language.


12

Structured Analysis vs. Structured Design

• Purpose of structured analysis:– capture the detailed structure of the

system as the user views it. • Purpose of structured design:

– arrive at a form that is suitable for implementation in some programming language.


13

Structured Analysis vs. Structured Design

• The results of structured analysis can be easily understood even by ordinary customers:– does not require computer knowledge– directly represents customer’s perception of the

problem – uses customer’s terminology for naming different

functions and data.• The results of structured analysis can be reviewed

by customers:– to check whether it captures all their requirements.


14

Structured Analysis

• Based on principles of:– Top-down decomposition approach.– Divide and conquer principle:

• each function is considered individually (i.e. isolated from other functions)

• decompose functions totally disregarding what happens in other functions.

– Graphical representation of results using• data flow diagrams (or bubble charts).


Function-oriented design

• Design with functional units which transform inputs to outputs


Objectives

• To explain how a software design may be represented as a set of functions which share state

• To introduce notations for function-oriented design

• To illustrate the function-oriented design process by example

• To compare sequential, concurrent and object-oriented design strategies


Topics covered

• data-flow design• Structural decomposition• Detailed design• A comparison of design strategies


Function-oriented design

• Practiced informally since programming began• Thousands of systems have been developed

using this approach• Supported directly by most programming

languages• Most design methods are functional in their

approach• CASE tools are available for design support


A function-oriented view of design

F2F1 F3

F4 F5

Shared memory


Natural functional systems

• Some systems are naturally function-oriented• Systems which maintain minimal state

information i.e. where the system is concerned with processing independent actions whose outcomes are not affected by previous actions

• Information sharing through parameter lists• Transaction processing systems fall into this

category. Each transaction is independent


ATM software designloop

loop Print_input_message (” Welcome - Please enter your card”) ; exit when Card_input ; end loop ; Account_number := Read_card ; Get_account_details (PIN, Account_balance, Cash_available) ; if Validate_card (PIN) then loop Print_operation_select_message ; case Get_button is when Cash_only => Dispense_cash (Cash_available, Amount_dispensed) ; when Print_balance => Print_customer_balance (Account_balance) ; when Statement => Order_statement (Account_number) ; when Check_book =>

Order_checkbook (Account_number) ; end case ; Eject_card ; Print (“Please take your card or press CONTINUE”) ; exit when Card_removed ; end loop ; Update_account_information (Account_number, Amount_dispensed) ; else Retain_card ; end if ;end loop ;


Functional and object-oriented design

• For many types of application, object-oriented design is likely to lead to a more reliable and maintainable system

• Some applications maintain little state - function-oriented design is appropriate

• Standards, methods and CASE tools for functional design are well-established

• Existing systems must be maintained - function-oriented design will be practiced well into the 21st century


Functional design process

• Data-flow design– Model the data processing in the system using data-

flow diagrams• Structural decomposition

– Model how functions are decomposed to sub-functions using graphical structure charts

• Detailed design– The entities in the design and their interfaces are

described in detail. These may be recorded in a data dictionary and the design expressed using a PDL


Structured Systems Analysis and Structured Design (SSA/SD)

• Creators: Ed Yourdon, Larry Constantine, Tom DeMarco.• Based on stepwise refinement.• SSA process:

– Construct initial DFD to provide top-level description of the problem (this is its context diagram).

– Elaborate this into a layered hierarchy of DFDs, supported by a data dictionary.

• SD process:– Use Transaction Analysis to divide the DFD into tractable units.– Perform a Transform Analysis on the DFD for each transaction, producing a

Structure Chart for that transaction.– Merge the Structure Charts to create the basic implementation plans.– Refine them to include any necessary error-handling, initialization, and other

exceptions.


SSA/SD details• DFD decomposition

– Functional decomposition.– Event-partitioning – a thread of actions associated with each event is

identified and used to form a simple bubble in the DFD (like a use case).• Two purposes of DFDs

– Physical DFDs – describe system in terms of concrete objects (names, actual forms, etc.)

– Logical DFDs – more abstract terms for operations and data flow.• Heuristics for creating DFDs:

– Consider the inputs and outputs of the system.– Work inwards from these.– Label carefully – be careful with terms.– Ignore exceptions and errors at this point.– Don’t flowchart – too detailed.


SSA/SD details• Transaction analysis

– Identification of transactions that are involved in the problem as a whole.– Components of a transaction:

• Event – triggers the transaction.• Stimulus – how the system is informed of the event.• Activity – what the system does as a result of the stimulus.• Response – output of the system.• Effect – impact of system’s output on its environment.

• Transform analysis– Transforms the DFD of a transaction into a Structure Chart.– Start with the “central transform” the DFD bubble that lies at the center of

input and output data flow. This becomes the top level of the chart.– The inputs and outputs to the central transform form the next level of the

chart.


SSA/SD transaction and transform analysis


Documents

Elements of Software Analysis and Design - Structured Approaches - Structured Analysis - Functional Oriented Design 10/24/2015ICS 413 – Software Engineering1