Principles of Programming & Software Engineering

Slides:



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

Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
CMPT 225 Data Structures and Programming. Course information Lecturer: Jan Manuch (Jano), TASC TAs: Osama Saleh,
© Janice Regan Problem-Solving Process 1. State the Problem (Problem Specification) 2. Analyze the problem: outline solution requirements and design.
Software Engineering and Design Principles Chapter 1.
Introduction To System Analysis and Design
Design The goal is to design a modular solution, using the techniques of: Decomposition Abstraction Encapsulation In Object Oriented Programming this is.
Overview. Why data structures is a key course Main points from syllabus Survey Warmup program And now to get started...
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Copyright © 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley. Ver Data Abstraction & Problem Solving with C++ Fifth Edition by Frank.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park.
Chapter 1 Principles of Programming and Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Software Engineering Principles and C++ Classes
Data Abstraction: The Walls
1 ES 314 Advanced Programming Lec 2 Sept 3 Goals: Complete the discussion of problem Review of C++ Object-oriented design Arrays and pointers.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Data Structures and Programming.  John Edgar2.
Nyhoff, ADTs, Data Structures and Problem Solving with C++, Second Edition, © 2005 Pearson Education, Inc. All rights reserved Software.
Introduction To System Analysis and design
Copyright © 2002, Systems and Computer Engineering, Carleton University Intro.ppt * Object-Oriented Software Development Unit 1 Course.
Chapter 2: Approaches to System Development
Comp 245 Data Structures Software Engineering. What is Software Engineering? Most students obtain the problem and immediately start coding the solution.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
1 C++ Plus Data Structures Nell Dale Chapter 1 Software Engineering Principles Modified from the Slides made by Sylvia Sorkin, Community College of Baltimore.
© 2011 Pearson Addison-Wesley. All rights reserved. Addison Wesley is an imprint of Stewart Venit ~ Elizabeth Drake Developing a Program.
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
1 Life Cycle of Software Specification Design –Risk Analysis –Verification Coding Testing –Refining –Production Maintenance.
Software Development. Software Developers Refresher A person or organization that designs software and writes the programs. Software development is the.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Programming Life Cycle Problem analysisunderstand the problem Requirements definition specify what program will do High- and low-level designhow it meets.
Data Structures Using C++1 Chapter 1 Software Engineering Principles and C++ Classes.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Designing Classes Prelude © 2015 Pearson Education, Inc., Upper Saddle River, NJ. All rights reserved. Data Structures and Abstractions with Java, 4e Frank.
The basics of the programming process The development of programming languages to improve software development Programming languages that the average user.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Data Structures Using C++ 2E
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
CSI 1340 Introduction to Computer Science II Chapter 1 Software Engineering Principles.
Chapter 1 Data Abstraction: The Walls CS Data Structures Mehmet H Gunes Modified from authors’ slides.
Chapter 1 Software Engineering Principles. Problem analysis Requirements elicitation Software specification High- and low-level design Implementation.
Chapter 2 Principles of Programming and Software Engineering.
Principles of Programming. Achieving an Object-Oriented Design  Abstraction and Information Hiding  Object-Oriented Design  Functional Decomposition.
Chapter 2 Object-Oriented Paradigm Overview
Data Abstraction: The Walls
C++ Plus Data Structures
DATA ABSTRACTION AND PROBLEM SOLVING WITH C++
Data Abstraction: The Walls
Chapter 1 Data Abstraction: The Walls
Principles of Programming and Software Engineering
About the Presentations
Figure 1.1 The life cycle of software as a water wheel that can rotate from one phase to any of phase.
Figure 1.1 The life cycle of software as a water wheel that can rotate from one phase to any of phase.
Computer Programming.
Unit# 9: Computer Program Development
Need for the subject.
Chapter 2- Visual Basic Schneider
CS 1120: Computer Science II Software Life Cycle
Chapter 1 Introduction(1.1)
Algorithms and Problem Solving
CS 1120: Computer Science II Software Life Cycle
Chapter 2. Problem Solving and Software Engineering
Presentation transcript:

Principles of Programming & Software Engineering Chapter 2 Principles of Programming & Software Engineering © 2011 Pearson Addison-Wesley. All rights reserved

Problem Solving and Software Engineering Coding without a solution design increases debugging time A team of programmers is needed for a large software development project Teamwork requires: An overall plan Organization Communication Software engineering Provides techniques to facilitate the development of computer programs © 2011 Pearson Addison-Wesley. All rights reserved

What is Problem Solving? The process of taking the statement of a problem and developing a computer program that solves that problem A solution consists of: Algorithms Algorithm: a step-by-step specification of a method to solve a problem within a finite amount of time Ways to store data © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software The life cycle of a software A lengthy and continuing process Required for the development of good software Programmer can move from any phase of the cycle to any other phase © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Figure 2-1 The life cycle of software as a water wheel that can rotate from one phase to any other phase © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 1: Specification Aspects of the problem which must be specified: What is the input data? What data is valid and what data is invalid? Who will use the software, and what user interface should be used? What error detection and error messages are desirable? What assumptions are possible? Are there special cases? What is the form of the output? What documentation is necessary? What enhancements to the program are likely in the future? © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 1: Specification (Continued) Prototype program A program that simulates the behavior of portions of the desired software product Phase 2: Design Includes: Dividing the program into modules Specifying the purpose of each module Specifying the data flow among modules © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 2: Design (Continued) Modules Self-contained units of code Should be designed to be: Loosely coupled Highly cohesive Interfaces Communication mechanisms among modules © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 2: Design (Continued) Specifications of a method A contract between the method and the module that calls it Should not commit the method to a particular way of performing its task Include the method’s: Precondition A statement of the conditions that must exist at the beginning of the method Postcondition A statement of the conditions at the end of the method © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 3: Risk Analysis Building software entails risks Techniques exist to identify, assess, and manage the risks of creating a software product Phase 4: Verification Formal methods can be used to prove that an algorithm is correct Assertion A statement about a particular condition at a certain point in an algorithm Java’s assert statement: assert booleanExpression; © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 4: Verification (Continued) Invariant A condition that is always true at a particular point in an algorithm Loop invariant A condition that is true before and after each execution of an algorithm’s loop Can be used to detect errors before coding is started © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 4: Verification (Continued) The invariant for a correct loop is true: Initially, after any initialization steps, but before the loop begins execution Before every iteration of the loop After every iteration of the loop After the loop terminates Phase 5: Coding Involves: Translating the design into a particular programming language Removing syntax errors © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 6: Testing Involves: Removing the logical errors Test data should include: Valid data that leads to a known result Invalid data Random data Actual data © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 7: Refining the Solution During phases 1 through 6 A working program is developed under simplifying assumptions During phase 7 Refining sophistication is added, such as: More sophisticated input and output routines Additional features More error checks © 2011 Pearson Addison-Wesley. All rights reserved

The Life Cycle of Software Phase 8: Production Involves: Distribution to the intended users Use by the users Phase 9: Maintenance Involves Correcting user-detected errors Adding more features Modifying existing portions to suit the users better © 2011 Pearson Addison-Wesley. All rights reserved

What is a Good Solution? A solution is good if: The total cost it incurs over all phases of its life cycle is minimal The cost of a solution includes: Computer resources that the program consumes Difficulties encountered by those who use the program Consequences of a program that does not behave correctly Programs must be well structured and documented Efficiency is only one aspect of a solution’s cost © 2011 Pearson Addison-Wesley. All rights reserved

Achieving an Object-Oriented Design: Abstraction and Information Hiding A modular solution to a problem should specify what to do, not how to do it Abstraction Separates the purpose of a module from its implementation Procedural abstraction Separates the purpose of a method from its implementation © 2011 Pearson Addison-Wesley. All rights reserved

Abstraction and Information Hiding Figure 2-2 The details of the sorting algorithm are hidden from other parts of the solution. © 2011 Pearson Addison-Wesley. All rights reserved

Abstraction and Information Hiding Data abstraction Focuses of the operations of data, not on the implementation of the operations Abstract data type (ADT) A collection of data and a set of operations on the data An ADT’s operations can be used without knowing how the operations are implemented, if: the operations’ specifications are known Data structure A construct that can be defined within a programming language to store a collection of data © 2011 Pearson Addison-Wesley. All rights reserved

Abstraction and Information Hiding Public view of a module Described by its specifications Private view of a module Consists of details which should not be described by the specifications Principle of information hiding Hide details within a module Ensure that no other module can tamper with these hidden details © 2011 Pearson Addison-Wesley. All rights reserved

Object-Oriented Design Object-oriented approach to modularity Produces a collection of objects that have behaviors Object An instance of a class Combines data and operations on that data Encapsulation A technique that hides inner details Methods encapsulate actions Objects encapsulate data as well as actions © 2011 Pearson Addison-Wesley. All rights reserved

Object-Oriented Design Principles of object-oriented programming (OOP) Encapsulation Objects combine data and operations Inheritance Classes can inherit properties from other classes Polymorphism Objects can determine appropriate operations at execution time © 2011 Pearson Addison-Wesley. All rights reserved

Functional Decomposition Object-oriented design (OOD) Produces modular solutions for problems that primarily involve data Identifies objects by focusing on the nouns in the problem statement Functional Decomposition (FD) Produces modular solutions for problems in which the emphasis is on the algorithms Identifies actions by focusing on the verbs in the problem statement A task is addressed at successively lower levels of detail © 2011 Pearson Addison-Wesley. All rights reserved

Functional Decomposition Figure 2-4 A structure chart showing the hierarchy of modules © 2011 Pearson Addison-Wesley. All rights reserved

General Design Guidelines Use OOD and FD together Use OOD for problems that primarily involve data Use FD to design algorithms for an object’s operations Consider FD to design solutions to problems that emphasize algorithms over data Focus on what, not how, when designing both ADTs and algorithms Consider incorporating previously written software components into your design © 2011 Pearson Addison-Wesley. All rights reserved

Modeling Object-Oriented Designs Using IML Unified Modeling Language (UML): language to express OO designs Class diagrams include name, data, operations Text-based notation: more complete specifications © 2011 Pearson Addison-Wesley. All rights reserved

A Summary of Key Issues in Programming Modularity Favorable impact on program development Modifiability Use of methods and named constants Ease of Use Considerations for the user interface Program should prompt the user for input A program should always echo its input The output should be well labeled and easy to read © 2011 Pearson Addison-Wesley. All rights reserved

A Summary of Key Issues in Programming Fail-Safe Programming Fail-safe program A program that will perform reasonably no matter how anyone uses it Types of errors: Errors in input data Errors in the program logic © 2011 Pearson Addison-Wesley. All rights reserved

A Summary of Key Issues in Programming Style Five issues of style Extensive use of methods Use of private data fields Error handling Readability Documentation © 2011 Pearson Addison-Wesley. All rights reserved

A Summary of Key Issues in Programming Debugging Programmer must systematically check a program’s logic to determine where an error occurs Tools to use while debugging: Watches Breakpoints System.out.println statements Dump methods © 2011 Pearson Addison-Wesley. All rights reserved

Summary Software engineering studies ways to facilitate the development of computer programs Software life cycle consists of: Specifying the problem Designing the algorithm Analyzing the risks Verifying the algorithm Coding the programs Testing the programs Refining the solution Using the solution Maintaining the software © 2011 Pearson Addison-Wesley. All rights reserved

Summary A loop invariant is a property of an algorithm that is true before and after each iteration of a loop An evaluation of the quality of a solution must take into consideration The solution’s correctness The solution’s efficiency The time that went into the development of the solution The solution’s ease of use The cost of modifying and expanding the solution © 2011 Pearson Addison-Wesley. All rights reserved

Summary A combination of object-oriented and functional decomposition techniques will lead to a modular solution The final solution should be as easy to modify as possible A method should be as independent as possible and perform one well-defined task A method should always include an initial comment that states its purpose, its precondition, and its postcondition © 2011 Pearson Addison-Wesley. All rights reserved

Summary A program should be as fail-safe as possible Effective use of available diagnostic aids is one of the keys to debugging To make it easier to examine the contents of complex data structures while debugging, dump methods that display the contents of the data structures should be used © 2011 Pearson Addison-Wesley. All rights reserved