Structured Programming Summary

Just as architects design buildings by employing the collective wisdom of their profession, so should programmers design applications. Our field is younger than architecture, and our collective wisdom is considerably sparser. We have learned that structured programming produces applications that are easier than unstructured applications to understand, test, debug, modify and even prove correct in a mathematical sense.

Figure 6.20 uses UML activity diagrams to summarize C#'s control statements. The initial and final states indicate the single entry point and the single exit point of each control statement. Arbitrarily connecting individual symbols in an activity diagram can lead to unstructured applications. Therefore, the programming profession has chosen a limited set of control statements that can be combined in only two simple ways to build structured applications.

Figure 6.20. C#'s single-entry/single-exit sequence, selection and repetition statements.

(This item is displayed on page 254 in the print version)

For simplicity, only single-entry/single-exit control statements are usedthere is only one way to enter and only one way to exit each control statement. Connecting control statements in sequence to form structured applications is simple. The final state of one control statement is connected to the initial state of the nextthat is, the control statements are placed one after another in an application in sequence. We call this "controlstatement stacking." The rules for forming structured applications also allow for control statements to be nested.

Figure 6.21 shows the rules for forming structured applications. The rules assume that action states may be used to indicate any action. The rules also assume that we begin with the simplest activity diagram (Fig. 6.22) consisting of only an initial state, an action state, a final state and transition arrows.

Figure 6.21. Rules for Forming Structured Applications.

(This item is displayed on page 255 in the print version)

Rules for Forming Structured Applications

1

Begin with the simplest activity diagram (Fig. 6.22).

2

Any action state can be replaced by two action states in sequence.

3

Any action state can be replaced by any control statement (sequence of action states, if, if...else, switch, while, do...while, for or foreach, which we will see in Chapter 8).

4

Rules 2 and 3 can be applied as often as necessary in any order.

Figure 6.22. Simplest activity diagram.

(This item is displayed on page 255 in the print version)

Applying the rules in Fig. 6.21 always results in a properly structured activity diagram with a neat, building-block appearance. For example, repeatedly applying rule 2 to the simplest activity diagram results in an activity diagram containing many action states in sequence (Fig. 6.23). Rule 2 generates a stack of control statements, so let us call rule 2 the stacking rule. [Note: The vertical dashed lines in Fig. 6.23 are not part of the UMLwe use them to separate the four activity diagrams that demonstrate the application of rule 2 of Fig. 6.21.]

Figure 6.23. Repeatedly applying the stacking rule (Rule 2) of Fig. 6.21 to the simplest activity diagram.

(This item is displayed on page 255 in the print version)

Rule 3 is called the nesting rule. Repeatedly applying rule 3 to the simplest activity diagram results in an activity diagram with neatly nested control statements. For example, in Fig. 6.24, the action state in the simplest activity diagram is replaced with a double-selection (if...else) statement. Then rule 3 is applied again to the action states in the double-selection statement, replacing each of these action states with a double-selection statement. The dashed action-state symbols around each of the double-selection statements represent the action state that was replaced. [Note: The dashed arrows and dashed action state symbols shown in Fig. 6.24 are not part of the UML. They are used here to illustrate that any action state can be replaced with any control statement.]

Figure 6.24. Repeatedly applying the nesting rule (Rule 3) of Fig. 6.21 to the simplest activity diagram.

(This item is displayed on page 256 in the print version)

Rule 4 generates larger, more involved and more deeply nested statements. The diagrams that emerge from applying the rules in Fig. 6.21 constitute the set of all possible structured activity diagrams and hence the set of all possible structured applications. The beauty of the structured approach is that we use only eight simple single-entry/single-exit control statements (counting the foreach statement, which we introduce in Section 8.6) and assemble them in only two simple ways.

If the rules in Fig. 6.21 are followed, an "unstructured" activity diagram (like the one in Fig. 6.25) cannot be created. If you are uncertain about whether a particular diagram is structured, apply the rules of Fig. 6.21 in reverse to reduce the diagram to the simplest activity diagram. If you can reduce it, the original diagram is structured; otherwise, it is not.

Figure 6.25. "Unstructured" activity diagram.

(This item is displayed on page 257 in the print version)

Structured programming promotes simplicity. Bohm and Jacopini have shown that only three forms of control are needed to implement any algorithm:

  • sequence
  • selection
  • repetition

Sequence is trivial. Simply list the statements of the sequence in the order in which they should execute. Selection is implemented in one of three ways:

  • if statement (single selection)
  • if...else statement (double selection)
  • switch statement (multiple selection)

In fact, it is straightforward to prove that the simple if statement is sufficient to provide any form of selectioneverything that can be done with the if...else statement and the switch statement can be done by combining if statements (although perhaps not as clearly and efficiently).

Repetition is implemented in one of four ways:

  • while statement
  • do...while statement
  • for statement
  • foreach statement

It is straightforward to prove that the while statement is sufficient to provide any form of repetition. Everything that can be done with the do...while, for and foreach statements can be done with the while statement (although perhaps not as conveniently).

Combining these results illustrates that any form of control ever needed in a C# application can be expressed in terms of

  • sequence structure
  • if statement (selection)
  • while statement (repetition)

and that these can be combined in only two waysstacking and nesting. Indeed, structured programming is the essence of simplicity.

(Optional) Software Engineering Case Study Identifying Objects States and Activities in the ATM System

Preface

Index

    Introduction to Computers, the Internet and Visual C#

    Introduction to the Visual C# 2005 Express Edition IDE

    Introduction to C# Applications

    Introduction to Classes and Objects

    Control Statements: Part 1

    Control Statements: Part 2

    Methods: A Deeper Look

    Arrays

    Classes and Objects: A Deeper Look

    Object-Oriented Programming: Inheritance

    Polymorphism, Interfaces & Operator Overloading

    Exception Handling

    Graphical User Interface Concepts: Part 1

    Graphical User Interface Concepts: Part 2

    Multithreading

    Strings, Characters and Regular Expressions

    Graphics and Multimedia

    Files and Streams

    Extensible Markup Language (XML)

    Database, SQL and ADO.NET

    ASP.NET 2.0, Web Forms and Web Controls

    Web Services

    Networking: Streams-Based Sockets and Datagrams

    Searching and Sorting

    Data Structures

    Generics

    Collections

    Appendix A. Operator Precedence Chart

    Appendix B. Number Systems

    Appendix C. Using the Visual Studio 2005 Debugger

    Appendix D. ASCII Character Set

    Appendix E. Unicode®

    Appendix F. Introduction to XHTML: Part 1

    Appendix G. Introduction to XHTML: Part 2

    Appendix H. HTML/XHTML Special Characters

    Appendix I. HTML/XHTML Colors

    Appendix J. ATM Case Study Code

    Appendix K. UML 2: Additional Diagram Types

    Appendix L. Simple Types

    Index



    Visual C# How to Program
    Visual C# 2005 How to Program (2nd Edition)
    ISBN: 0131525239
    EAN: 2147483647
    Year: 2004
    Pages: 600

    Flylib.com © 2008-2020.
    If you may any questions please contact us: flylib@qtcs.net