© Minder Chen, Structured design - 1 Produce Paycheck Retrieve Employee Record Global Data Store Offpage Calling Module Called Module System Device Module Module Name Normal Procedure (Subroutine) Call Module Name Library(Predefined) Module Global Data Store Used by Page-Jones Offpage Used by Page-Jones Sender Receiver Control Flag Data Structure Chart Notations

© Minder Chen, Structured design - 2 Module Module1 ' The argument x is passed by value ' The argument y is passed by reference Public Sub ABC(ByVal x As Integer, ByRef y As Integer) ' If ABC changes x, the changes do not affect a. ' If ABC changes y, the changes affect b. x = x + 1 y = y + 1 End Sub Public Sub Main() Dim a As Integer = 3 Dim b As Integer = 4 ABC(a, b) ' Call the procedure. Console.WriteLine("a = " & a) Console.WriteLine("b = " & b) ' You can force parameters to be passed by value, regardless of how ' they are declared, by enclosing the parameters in extra parentheses. ABC((x)) End Sub End Module

© Minder Chen, Structured design - 3 Dim a As Integer = 3 Dim b As Integer = 4 ABC(a, b) Console.WriteLine("a = " & a) Console.WriteLine("b = " & b) Public Sub ABC(ByVal x As Integer, ByRef y As Integer) x = x + 1 y = y + 1 End Sub x y 3 a 4 b 3 x y 3 5 Before After 4

© Minder Chen, Structured design - 4 A A,1A,2A,3 Call A,1 Call A,2 Call A,3 Sequence Structured Chart Notations A A,4A,3A,2A,1 Call A,1 IF Tx-Code = “A” Then Call A,2 ELSE IF Tx-Code = “B” Then Call A,3 ELSE IF Tx-Code =“C” THEN Call A,4 Decision A A,1A,2A,3A,4 Call A,1 Repeat Call A,2 Call A,3 Call A,4 Until EOF = “true” A A A,3 A,1 A,2 Statement X Statement T Statement Z Call A,1 Statement X Statement Y StatementZ Call A,3 Iteration Lexical Inclusion

© Minder Chen, Structured design - 5 Structured Chart Notations (Contd.) Notations used by Page-Jones Decision Iteration Lexical Inclusion (The Hat Symbol)

© Minder Chen, Structured design - 6 Structure Chart Notations Interface Table I/F# Input Output 1 A,B C 2 X Y,Z Interface Table 12 Asynchronous Activation of a Subtask Concurrent Activation Symbol Information Cluster A BC D Modules A, B, and C has exclusive access to Data D Program X Physical Packaging Boundary

© Minder Chen, Structured design - 7 Sample Structure Chart 2.0 Enter Customer payments 2.5 Display Customer payment 2.32 Verify Customer account 2.21 Get Customer record 2.11 Key invoice remittance 2.4 write Customer payment transaction 2.3 Update A/R master 2.2 Add Customer information 2.1 Key remittance 2.33 Rewrite A/R record 2.22 Verify Customer account 2.31 Get receivable record 2.12 Key monthly statement remittance Structure chart for program 2.0. Enter customer payment Exercise - 3 Remittance EOT Customer-ID Invoice- remittance Monthly- Statement- remittance Customer- sold-to- name Remittance Customer-sold- to-name Customer- payment Customer -ID Customer- number Customer- record No-record- on-file Valid- account A/R- record Old- A/R- record New-A/R- record No-record- on-file Valid account Posting-ok

© Minder Chen, Structured design - 8 How would you partition this system?

© Minder Chen, Structured design - 9 Type of Coupling Tightness of Coupling Goodness of Design Normal Coupling Data Coupling Stamp Coupling Control Coupling Common Coupling Content Coupling Loose Tight Good Bad

© Minder Chen, Structured design - 10 Normal Coupling A. Call B. A. Call B using X,Y. BB Module A and module B are normally coupled if - A calls B - B returns to A All information passed between them are through parameter passing X X Y Y

© Minder Chen, Structured design - 11 UPDATE CUSTOMER MASTER FILE GET VALID INPUT VALIDATE CUSTOMER TRANSACTION UPDATE MASTER PUT CUSTOMER MASTER GET INPUT GET CUSTOMER MASTER GET CUSTOMER TRANS Transaction Transaction is valid Transaction Master Record Acct Number Master Record Updated Master Record Master Record Valid Trans- action Updated Master Record Valid Trans- action

© Minder Chen, Structured design - 12 Data Coupling Calculate Monthly payment of a House Calculate Mortgage Payment Mortgage PaymentLoan Amount Term Interest Rate Module A and module B are data coupled if - A calls B - B returns to A - All information passed between them are through parameter passing - Each parameter is a data element

© Minder Chen, Structured design - 13 Stamp Coupling Calculate Monthly Payment of a House Calculate Mortgage Payment Mortgage Payment Customer Loan Record Two module A and B are data coupled if - A calls B - B returns to A - All information passed between them are through parameter passing - A composite piece of data is passed from one module to another

© Minder Chen, Structured design - 14 Control Coupling Produce paycheck Retrieve Employee Record Produce paycheck Retrieve Employee Record Employee ID Employee Record Employee ID Tell the operator that “The Employee Record Is Not Found” Employee Record Not Found Control FlagDescriptive Flag

© Minder Chen, Structured design - 15 Scale of Cohesion Types of CohesionVisibility Strength of Cohesion Maintainability Functional Black box Sequential Not-quite so Communicational black box Procedural Gray Temporal box Logical Transparent Coincidental or white box Strong Weak Good Bad

© Minder Chen, Structured design - 16 Structure Chart and DFD This module is sequentially cohesive. This module is communicationally cohesive.

© Minder Chen, Structured design - 17 Simplify Communicational Cohesion Get Employee Name Calculate YTD Total Deduction Get Employee Name Calculate YTD Total Deduction Get Employee Name Calculate YTD Total Deduction Employee Name Employee YTD Total Deduction Employee ID Employee YTD Total Deduction Employee Name

© Minder Chen, Structured design - 18 Determine Module Cohesion Type of Cohesion Does activities performed by the module related to a single problem-related task What relates the elements within the module ? Neither data nor control Is sequence important ? Data Flow of control Is sequence important ? Are the activities performed by the elements in the same category? YES NO Functional Sequential Communicational Procedural Temporal Logical Coincidental

© Minder Chen, Structured design - 19 DETERMINE CUSTOMER DETAILS Customer Account Number Customer Name Customer Loan Status Customer Account Number Customer Name A Communicationally Cohesive Module at the Bottom of a Structure Chart A Communicationally Cohesive Module Halfway Up a Structure Chart Each of These Functionally Cohesive Module is at the Bottom of a Structure Customer Name Customer Account Number EVALUATE LOAN STATUS FIND CUSTOMER NAME

© Minder Chen, Structured design - 20 A Functionally Cohesive Module Very High in a Structure Chart Satellite Trajectory Elevation Ranges Azimuths Times GET RANGES GET TIMES GET AZIMUTHS GET ELEVATION GET SATELLITE TRAJECTORY

© Minder Chen, Structured design - 21 The Impact of Module Numbers on Cost Intermodule Effects (Coupling) Cost Due to Intramodule Effects (Cohesion) High Low Cost Number of Modules SmallLarge

© Minder Chen, Structured design - 22 Four Basic Types of Modules Coordinate control Transform (Process) Efferent (Output) Afferent (Input)

© Minder Chen, Structured design - 23 Idea System Shape of a Structure Chart Afferent branch Transform branch Efferent branch

© Minder Chen, Structured design - 24 Boulding’s Explanation of GST "(General Systems Theory) does not seek, of course, to establish a single, self contained 'general theory' of practically everything which will replace the theories of particular disciplines. Such a theory would be almost without content, for we always pay for generality by sacrificing content, and we can say about practically everything is almost nothing. Somewhere however between the specific that has no meaning and the general that has no content there must be, for each purpose and at each level of abstraction, an optimum degree of generality. It is the contention of the General Systems Theorists that this optimum degree of generality is not always reached by the particular sciences." Source:

© Minder Chen, Structured design - 25 Idea System Shape of a Structure Chart High fan-out High fan-in

© Minder Chen, Structured design - 26 The Procedure of Deriving Structure Charts from Data Flow Diagrams Evaluate a detailed DFD Type of DFD Identify central transform of the DFD Map to transaction structure Map to transform structure Refined the Structure Chart Identify transaction types and transaction center of the DFD Transaction Analysis Transform Analysis

© Minder Chen, Structured design - 27 P OUTPUT FUNCTION C P INPUT FUNCTION B P INPUT FUNCTION D P OUTPUT FUNCTION A P INPUT FUNCTION C P OUTPUT FUNCTION B P TRANSFORM FUNCTION A P TRANSFORM FUNCTION B P INPUT FUNCTION A BOUNDARY B A DDATA STORE D DDATA STORE B DDATA STORE E M L K J I H G F E D C B A Afferent Central Transform Efferent Transform Analysis

© Minder Chen, Structured design - 28 TRANSFORM FUNCTION A TRANSFORM FUNCTION B INPUT FUNCTION A INPUT FUNCTION D INPUT FUNCTION B OUTPUT FUNCTION A INPUT FUNCTION C OUTPUT FUNCTION C BOSS CENTRAL TRANSFORM CONTROLLER OUTPUT FUNCTION B E & F J & I J G & H E, F, & G I J G I F K E C

© Minder Chen, Structured design - 29 Transaction Analysis DFD Get Customer Transactio n Process Customer Transaction Change Customer Record Add New Customer Get Customer Transaction Delete Customer Record Tx-Code Structure Chart Customer Information System Main Menu 1. Add New Customer 2. Change Customer Record 3. Delete Customer Record A Transaction Selection Screen

© Minder Chen, Structured design - 30 Determine Implementation Boundaries Manual Real-time Batch On-line

© Minder Chen, Structured design - 31 Processor Model: Allocation of essential Model Components to Processors Essential Model Processor 1 Processor 2 Processor 3 Processor Level Implementation Model    Netware LAN  UNIX Server T1 TCP/IP Mainframe Allocating processes and data stores to processors

© Minder Chen, Structured design - 32 Source: Developing Web Applications with Microsoft Visual Basic.NET and Microsoft Visual C#.NET Testing Test plan objectives –Is thoroughly tested –Meets requirements –Does not contain defects Test plan covers –Tools –Who –Schedule –Test result analysis –What is being tested? Test cases Automated testing –Reproducible –Measurable

© Minder Chen, Structured design - 33 Stubs and Drivers Driver Module 1Module 2 Module M StubModule 2 StubsStubs are non-functional components that provide the class, property, or method definition used by the other component. Stubs are a kind of outline of the code you will create later. DriversTo test two components that need to work together through a third component that has not been written yet, you create a driver. Drivers are simply test components that make sure two or more components work together. Later in the project, testing performed by the driver can be performed by the actual component. The most common build problem occurs when one component tries to use another component that has not yet been written. This occurs with modular design because the components are often created out of sequence.

© Minder Chen, Structured design - 34 Test typeObjectives Unit test Each independent piece of code works correctly Integration test All units work together without errors Regression test Newly added features do not introduce errors to other features that are already working Load test (also called stress test) The product continues to work under extreme usage Platform test The product works on all of the target hardware and software platforms Types of Tests

© Minder Chen, Structured design - 35 Regression and Regression Test Regression testing is the process of validating modified parts of the software and ensuring that no new errors are introduced into previously tested code. the error is called a regression.Unit and integration tests form the basis of regression testing. As each test is written and passed, it gets checked into the test library for a regularly scheduled testing run. If a new component or a change to an existing component breaks one of the existing unit or integration tests, the error is called a regression.

© Minder Chen, Structured design - 36

© Minder Chen, Structured design - 37