Presentation on theme: "Chapter 11 Trisha Cummings. Structure Charts The recommended tool for designing a modular, top- down system is a structure chart. A structure chart is."— Presentation transcript:
Structure Charts The recommended tool for designing a modular, top- down system is a structure chart. A structure chart is a diagram consisting of rectangular boxes, which represent the modules, and connecting arrows. Structure charts encourage top-down design and support the concepts of modularity and top-down structured design. Top-down structured design deals with the size and complexity of an application by breaking it up into a hierarchy of modules that result in an application that is easier to implement and maintain.
Top-down design allows the systems analyst to ascertain overall organizational objectives along with ascertaining how they are best met in an overall system. Then, the analyst moves to dividing that system into subsystems and their requirements. The modular programming concept is useful for the top-down approach: once the top-down approach is taken, the whole system is broken into logical, manageable-sized modules, or subprograms. (The bottom-up approach to design, on the other hand, refers to identifying the processes that need computerization as they arise, analyzing them as systems, and either coding them or purchasing packaged software to address the immediate problem.)
Modular design is the decomposition of a program or application into modules. A module is a group of executable instructions (code) with a single point of entry and a single point of exit. A module could be a subroutine, subprogram, or main program. It also could be a smaller unit of measure such as a paragraph in a COBOL program. Data passed between structure chart modules has either Data Coupling where only the data required by the module is passed, or Stamp Coupling where more data than necessary is passed between modules. The modules in a structure chart fall into three categories:
Control modules, determining the overall program logic Transformational modules, changing input into output Specialized modules, performing detailed, functional work A lower level module should not be required to perform any function of the calling, higher level module. This would be "improper subordination." A structure chart is a graphic tool that shows the hierarchy of program modules and interfaces between them. Structure charts include annotations for data flowing between modules.
Modules are represented by rectangles or boxes that include the name of the module. The highest level module is called the system, root, supervisor, or executive module. It calls the modules directly beneath it which in turn call the modules beneath them. A connection is represented by an arrow and denotes the calling of one module by another. The arrow points from the calling (higher) module to the called (subordinate) module. – Note: The structure charts drawn in the Kendall and Kendall text book do not include the arrowhead on the connections between modules. Kendall and Kendall draw plain lines between module boxes. A data couple indicates that a data field is passed from one module to another for operation and is depicted by an arrow with an open circle at the end. – A flag, or control couple, is a data field (message, control parameter) that is passed from one module to another and tested to determine some condition. Control flags are depicted by an arrow with a darkened circle at the end. Sometimes a distinction is made between a control switch (which may have two values, e.g., yes-no, on-off, one-zero, etc.) and a control flag (which may have more than two values).
Case Maker Automatically generate structure charts based on the Yourdon structured design methodology. Structure charts are graphical representations of the subroutine and function hierarchy in the program's Procedure Division. By viewing structure charts, you can identify and fully understand the strengths and weaknesses of the program structure. Instantly view source code for paragraphs, Perform statements, and Go To statements in LegacyAid text editor
Nick Halstead's Blog: Uses of Pseudo Code in Development Pseudo code “Writing pseudo code and program code separately simplifies the overall task by splitting it into two simpler tasks. While writing the algorithm the developer can focus on solving the problem, not how it is written in a particular language. Once the pseudo code is written and has been checked; writing the real code becomes much simpler, the programmer is only concerned with converting the pseudo code into the appropriate program code.”
This will be useful in relation to programmer interviewing but also for general reference for when to use Pseudo code in normal development. For any complicated development task whether it be a single method or a whole project. It is important that every possible effort is taken to reduce complexity. Extra complexity without need can mean more mistakes are made so breaking a single tasks into two simpler tasks generally results in less complex code and less mistakes. Writing pseudo code and program code separately simplifies the overall task by splitting it into two simpler tasks. While writing the algorithm the developer can focus on solving the problem, not how it is written in a particular language. Once the pseudo code is written and has been checked; writing the real code becomes much simpler, the programmer is only concerned with converting the pseudo code into the appropriate program code.
Pseudo code defined Pseudo code (or Structured English) is used to specify program logic in a (somewhat) English like manner, that aims to be independent of any particular programming language. This simplifies program development by separating it into two main parts, logic design and coding. The use of pseudo code allows the programmer to focus on the logic of the program rather than implementation details such as how data is displayed. Once the logic is developed, coding becomes the translation of the pseudo code into the required programming language.
Advantages of Pseudo Code You don’t have to understand a particular programming language to understand Pseudo Code. It is written in semi-structured, somewhat English like manner. Pseudo code is written so that code based on it should be able to be written in any language (language independent). Using the algorithm the program could be written in C++, C, PHP, Ruby, Java or Visual Basic. Pseudo code can also assist in the natural breaking down of a programming problem into a smaller one that is easier to understand.
The Disadvantages of Pseudo Code The disadvantages of pseudo code may start with its lack of standards. One person’s logic instructions may not seem as logical to the next. Given the unstructured nature of pseudo code, it is few rules and is hard to standardize. Another disadvantage over other modeling tools like flowcharts may be pseudo codes inability to show logic flows or the bigger picture. Whereas flowcharts provide an overview of logic and can be understood at a higher level, pseudo code is far more detail oriented and requires more concentration and practice to see the bigger picture.
How to write Pseudo Code First you may want to make a list of the main tasks that must be accomplished. Then, focus on each of those tasks. You should try to break each main task down into very small tasks that can each be explained with a short phrase. In my experience it is a bad idea to go too close to the correlation of one-to-one between pseudo code and real code. The reason being that your pseudo code is there to help plan the structure but not to help resolve the details that fall out of real world programming.
The use of variables within pseudo code should be restricted if possible but when it is necessary you should show the initialization of the variables. Overall, remember that the purpose of pseudo code is to help the programmer efficiently write code. Therefore, you must attempt to add enough detail and analysis to the pseudo code. It can be that the pseudo code is being written by one programmer and the real code by another.
Event-driven Programming When you perform an action on a graphical component you generate an event. In event-driven programming the program responds to events. The program responds to events that the user generates in interacting with GUI components. The order of events is controlled by the user.
For example, you can generate an event by clicking on a button: Or you could click on a button: