Chapter 11 Trisha Cummings. Structure Charts The recommended tool for designing a modular, top- down system is a structure chart. A structure chart is.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Chapter 3: Modules, Hierarchy Charts, and Documentation
ICS103 Programming in C Lecture 1: Overview of Computers & Programming
Computers Are Your Future
Quality Assurance Through Software Engineering Systems Analysis and Design, 7e Kendall & Kendall 16 © 2008 Pearson Prentice Hall.
Quality Assurance Through Software Engineering
Using Dataflow Diagrams
1 Software Design Introduction  The chapter will address the following questions:  How do you factor a program into manageable program modules that can.
PSEUDOCODE & FLOW CHART
Programming Logic and Design Fourth Edition, Introductory
Chapter 1 - An Introduction to Computers and Problem Solving
Chapter 2 - Problem Solving
Chapter 2- Visual Basic Schneider1 Chapter 2 Problem Solving.
Chapter 2 - Problem Solving
What is Software Design?  Introduction  Software design consists of two components, modular design and packaging.  Modular design is the decomposition.
Copyright Irwin/McGraw-Hill Software Design Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Software Design Deriving a solution which satisfies software requirements.
© Copyright 2011 John Wiley & Sons, Inc.
Quality Assurance Through Software Engineering
CS 201 Functions Debzani Deb.
Modules, Hierarchy Charts, and Documentation
Chapter 2: Developing a Program Extended and Concise Prelude to Programming Concepts and Design Copyright © 2003 Scott/Jones, Inc.. All rights reserved.
Programming Fundamentals (750113) Ch1. Problem Solving
COBOL for the 21 st Century Stern, Stern, Ley Chapter 1 INTRODUCTION TO STRUCTURED PROGRAM DESIGN IN COBOL.
Chapter 1 Program Design
Chapter 4 Sec. 4.1, 4.2, 4.4 Procedures (User-defined)
Chapter 3 Planning Your Solution
The Program Design Phases
Programming Logic and System Analysis
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Extended Prelude to Programming Concepts & Design, 3/e by Stewart Venit and.
1 CS101 Introduction to Computing Lecture 19 Programming Languages.
System Implementation System Implementation - Mr. Ahmad Al-Ghoul System Analysis and Design.
INFO415 Approaches to System Development: Part 2
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Structured COBOL Programming, Stern & Stern, 9th edition
Extended Prelude to Programming Concepts & Design, 3/e by Stewart Venit and Elizabeth Drake Chapter 2: Developing a Program.
INTRODUCTION TO PROGRAMMING STRUCTURE Chapter 4 1.
สาขาวิชาเทคโนโลยี สารสนเทศ คณะเทคโนโลยีสารสนเทศ และการสื่อสาร.
Mr C Johnston ICT Teacher BTEC IT Unit 06 - Lesson 01 Introduction to Computer Programming.
PROGRAMMING LANGUAGES Prof. Lani Cantonjos. PROGRAM - set of step-by-step instructions that tells or directs the computer what to do. PROGRAMMING LANGUAGE.
SOFTWARE DESIGN.
Programming Concepts Chapter 3.
Describe the Program Development Cycle. Program Development Cycle The program development cycle is a series of steps programmers use to build computer.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Systems analysis and design, 6th edition Dennis, wixom, and roth
System Implementation
INTRODUCTION TO COMPUTING CHAPTER NO. 04. Programming Languages Program Algorithms and Pseudo Code Properties and Advantages of Algorithms Flowchart (Symbols.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
Chapter 1 Program design Objectives To describe the steps in the program development process To introduce the current program design methodology To introduce.
First Steps in Modularization. Simple Program Design, Fourth Edition Chapter 8 2 Objectives In this chapter you will be able to: Introduce modularization.
CCSB223/SAD/CHAPTER131 Chapter 13 Designing the System Internals.
First Steps in Modularization. Simple Program Design, Fourth Edition Chapter 8 2 Objectives In this chapter you will be able to: Introduce modularization.
Computing Higher – SD Unit - Topic 8 – Procedure and Standard Algorithms P Lynch, St Andrew’s High School Unit 2 Software Development Process Topic.
Chapter 16 Quality Assurance Through Software Engineering Systems Analysis and Design Kendall & Kendall Sixth Edition.
Chapter 2 - VB 2005 by Schneider- modified by S. Jane '081 Chapter 2 - Problem Solving 2.1 Program Development Cycle 2.2 Programming Tools.
Systems Design.  Application Design  User Interface Design  Database Design.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
How Computers Solve Problems Computers also use Algorithms to solve problems, and change data into information Computers can only perform one simple step.
Introduction to Computer Programming Concepts M. Uyguroğlu R. Uyguroğlu.
 Problem Analysis  Coding  Debugging  Testing.
Algorithms and Flowcharts
System Design and Modeling
Chapter 2- Visual Basic Schneider
An Introduction to Visual Basic .NET and Program Design
Unit# 9: Computer Program Development
Chapter 2- Visual Basic Schneider
Chapter 2- Visual Basic Schneider
Introduction to Systems Analysis and Design Stefano Moshi Memorial University College System Analysis & Design BIT
Basic Concepts of Algorithm
Introduction to Programming
Presentation transcript:

Chapter 11 Trisha Cummings

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:

Resources ml ml charts.html charts.html of-pseudo-code-in-development/ of-pseudo-code-in-development/ PE/2005s1/other_resources/pseudocode_guide.h tml PE/2005s1/other_resources/pseudocode_guide.h tml /Notes/chap55/ch55_4.html /Notes/chap55/ch55_4.html