Chapter 1 Principles of Programming and Software Engineering

Chapter 1: Principles of Programming and Software Engineering Chien Chin Chen Department of Information Management National Taiwan University

Software Engineering and Object-Oriented Design (1/2) o Where did you begin when you wrote your last program? n o Most of us simply begin to write code. n o After reading or writing the problem specification? Then spend a lot of time in debugging and praying for correct results. Coding without a solution design increases debugging time. 2

Software Engineering and Object-Oriented Design (2/2) o o Certainly, with this kind of training (or struggling), our programming skills are better now than when we wrote our first program. But what if we are writing a really large program? n A team of programmers for a large software development project requires: o o An overall plan. Organization. Communication. Software engineering: n Provides techniques to facilitate the development of computer programs. 3

An Examination of Problem Solving o Problem solving: n o The process of taking the statement of a problem and developing a computer program that solves that problem. Object-oriented analysis and design (OOA/D): n A problem solution is a program consisting of a system of interacting classes of objects. o o n Each object has characteristics (attributes) and behaviors (funcitons) related to the solution. A class is a set of objects having the same type. OOA/D helps us to discover and describe these objects and classes (to construct a solution, i. e. , program). 4

Aspects of an Object-Oriented Solution (1/3) o A solution is a C++ program consisting of Modules. n Module: o o o A single, stand-alone function. A method of a class. A class. Several functions or classes working closely together. Other blocks of code. 5

Aspects of an Object-Oriented Solution (2/3) o Functions and methods (or modules) implement algorithms. n n Algorithm: a step-by-step recipe for performing a task within a finite period of time. Algorithms often operate on a collection of data. 6

Aspects of an Object-Oriented Solution (3/3) o When designing a solution, your challenge is to create a good set of modules. n n o Modules must store, move, and alter data. Modules use algorithms to communicate with one another. Problem solving is to organize data collection and provide efficient operations on the data. 7

Abstraction and Information Hiding (1/5) o Abstraction: n n n o Is a concept. Separates the purpose of a module from its implementation. Specifications for each module are written before implementation. Modularity and abstraction complement each other. n n Modularity breaks a solution into modules. Abstraction specifies each module clearly. 8

Abstraction and Information Hiding (2/5) o Functional abstraction: n Is a concept. To separate the purpose of a function from its implementation. C++ standard library function, cout. n Is essential to team projects. n n o You will have to use modules (functions) written by others, frequently without knowledge of their implementations. 9

Abstraction and Information Hiding (3/5) o Data abstraction: n n o Is a concept. To focus on what you will do to data, not on the implementation of the operations. Abstract data type (ADT): n n n Is a data type. A collection of data and a set of operations on the data. Organized in a way that the specification of the data and the specification of the operations is separated from the representation (how the data is stored) of the data and the implementation of the operations. 10

Abstraction and Information Hiding (4/5) o Data structure: n Implementation of ADT. A construct that you can define within a programming language to store a collection of data. n E. g. , Pointer-based or array-based ADT list. n 11

Abstraction and Information Hiding (5/5) o Information hiding n n Abstraction helps to hide details within a module. Public view of a module: o n Described by its specifications. Private view of a module: o o Implementation details that the specifications should not describe. Ensure that no other module can tamper with these hidden details. 12

Principles of Object-Oriented Programming (OOP) (1/2) o o Object-oriented languages enable us to build classes of objects. A class combines: n Attributes (characteristics) of objects of a single type o o n Typically data. Called data members. Behaviors (operations) o o Typically operate on the data. Called methods or member functions. 13

Principles of Object-Oriented Programming (2/2) o Three principles of object-oriented programming: n Encapsulation: o o n Inheritance: o o n Objects combine data and operations. Hides inner details. Classes can inherit properties from other classes. Existing classes can be reused. Polymorphism: o Objects can determine appropriate operations at execution time. 14

Object-Oriented Analysis and Design (1/3) o Analysis n n Process to identify an understanding (requirements) of the problem. What a solution (program) must do. o n Not how to implement the solution. Generates an accurate understanding of what end users will expect the solution to be. 15

Object-Oriented Analysis and Design (2/3) o Object-oriented analysis (OOA) n Expresses an understanding of the problem and the requirements of a solution in terms of objects within the problem domain. o n Objects can represent n Real-world objects. e. g. , car, rabbit. n Software systems. e. g. , stack, queue. n Ideas. OOA describes objects and their interactions among one another. 16

Object-Oriented Analysis and Design (3/3) o Design: n n o Explores (describes) a solution to a problem. To fulfill the requirements discovered during analysis. Object-oriented design (OOD): n Describes a solution in terms of software objects and how objects will collaborate with one another to fulfill the requirements of the problem. n n n Collaboration call each other’s operations. Collaborations should be meaningful and minimal. During OOD, you may create one or more models of a solution. o o Some emphasize interactions among objects. Others emphasize relationships among objects. 17

Applying the UML to OOA/D (1/9) o Unified Modeling Language (UML) n n n A tool for exploration and communication during the design of a solution. Models a problem domain in terms of objects and independently of a programming language. Visually represents object-oriented solutions as diagrams. o Enables members of a programming team to communicate visually with one another and gain a common understanding of the system being built. 18

Applying the UML to OOA/D (2/9) o UML use case for OOA. n A set of textual scenarios (stories) of the solution. o o o n Each scenario describes the system’s behavior under certain circumstances from the perspective of the user. Main success scenario (happy path): interaction between user and system when all goes well. Alternate scenarios: interaction between user and system under exceptional circumstances. Find noteworthy objects (nouns in the stories), attributes, and associations within the scenarios. 19

Applying the UML to OOA/D (3/9) o An example of a main success scenario: n n n n Customer asks to withdraw money from a bank account. Bank identifies and authenticates customer. Bank gets account type, account number, and withdrawal amount from customer. Bank verifies that account balance is greater than withdrawal amount. Bank generates receipt for the transaction. Bank counts out the correct amount of money for customer. Customer leaves bank. 20

Applying the UML to OOA/D (4/9) o An example of an alternate scenario: n n Customer asks to withdraw money from a bank account. Bank identifies, but fails to authenticate customer. Bank refuses to process the customer’s request. Customer leaves bank. 21

Applying the UML to OOA/D (5/9) o UML sequence (interaction) diagram for OOD. n n Models the scenarios in a use case. Shows the interactions among objects over time. Lets you visualize the messages sent among objects in a scenario and their order of occurrence. Helps to define the responsibilities of the objects. o o What must an object remember? What must an object do for other objects? 22

Applying the UML to OOA/D (6/9) objects identified in OOA their order of occurrence interaction activation bar lifeline 23 Figure 1 -2 Sequence diagram for the main success scenario

Applying the UML to OOA/D (7/9) o UML class (static) diagram for OOD. n n n Represents a conceptual model of a class of objects in a language-independent way. Shows the name, attributes, and operations of a class. Shows how multiple classes are related to one another. 24

Applying the UML to OOA/D (8/9) name attributes operations association relationship multiplicities containment relationship (a more specific type of association) generalization relationship (inheritance) Figure 1 -5 A UML class diagram 25 of a banking system

Applying the UML to OOA/D (9/9) o UML syntax for the attribute of a class: n n [visibility] name [: type] [=default. Value] [{property}] -address: string +: public, -: private o name of attribute or operation data type UML syntax for the operation of a class: n n n [visibility] name([parameter. List]) [: type] [{property}] +change. Address(in new. Addr: string) function without type, +get. Address(): string {query} a void function will not modify any of the data members 26

The Software Life Cycle o Describes the phases of software development from conception to deployment to replacement to deletion. n n n We will examine the phases from project conception to deployment to end users. Software needs maintenance to correct errors and add features. Eventually software is retired. 27

Iterative and Evolutionary Development (1/2) o Iterative development of a solution to a problem. n n Many short, fixed-length iterations. Each iteration builds on the previous iteration until a complete solution is achieved. Each iteration cycles through analysis, design, implementation, testing, and integration of a small portion of the problem domain. Early iterations create the core of the system; further iterations build on that core. 28

Iterative and Evolutionary Development (2/2) o Each iteration has a duration called the timebox. n o o Chosen at beginning of project, typically 2 to 4 weeks. Each iteration makes relatively few changes to the previous iteration. End users can provide feedback at the end of each iteration. n The feedback influences the next iteration and can change the direction of development so a more correct solution is reached. 29

Rational Unified Process (RUP) Development Phases (1/6) o An example of iterative and evolutionary development. o RUP uses the OOA/D tools we introduced. o Four development phases: n n Inception: feasibility study, project vision, time/cost estimates. Elaboration: refinement of project vision, time/cost estimates, and iterative development of core system. Construction: iterative development of remaining system. Transition: testing and deployment of the system. 30

Rational Unified Process (RUP) Development Phases (2/6) not an iteration Figure 1 -7 RUP development phases 31

Rational Unified Process (RUP) Development Phases (3/6) o Inception phase: n Define the scope of the project. n Decide whether the project is feasible. n Identify highest-risk aspects of solution. n n Generate a core set of use case scenarios (about 10% of total number). Choose iteration timebox length. 32

Rational Unified Process (RUP) Development Phases (4/6) o Elaboration phase: n Iteratively develop core architecture of system. n Address highest-risk aspects of system. o o n n Most potential for system failure, so deal with them first. If a solution is going to fail, little time, money, and effort has been wasted. Extends over at least 2 iterations to allow for feedback. Each iteration progresses through OO analysis and design (use case scenarios, sequence diagrams, class diagrams), coding, testing, integration, and feedback. 33

Rational Unified Process (RUP) Development Phases (5/6) o Construction phase: n n o Begins once most of the system requirements are formalized. Develops the remaining system. Each iteration requires less analysis and design. Focus is on implementation and testing. Transition phase: n n testing with advanced end users. System moves into a production environment. 34

Rational Unified Process (RUP) Development Phases (6/6) OOA/D testing Figure 1 -8 Relative amounts of work done in each development phase 35

What About the Waterfall Method of Development? o o Develops a solution sequentially by moving through phases: requirements analysis, design, implementation, testing, deployment. Hard to correctly specify a system without early feedback. n o Wrong analysis leads to wrong solution. Outdated and should not be used!! 36

Achieving a Better Solution o o o Analysis and design improve solutions. If you generated many correct but different solutions, what aspects of one solution make it better than another? What aspects lead to better solutions? 37

Evaluation of Designs and Solutions (1/4) o Cohesion: n n A highly cohesive module performs one well-defined task. The name of module promotes self-documenting, easy-tounderstand code. o n n o E. g. , a function called sort should do nothing but sort. Easy to reuse in other software projects. Easy to revise or correct. Robust: less likely to be affected by change; performs well under unusual conditions. Promotes low coupling. Guideline: if a module (class or function) has too many responsibilities, it should be split into multiple modules. Designing good modules is more art than science!!38

Evaluation of Designs and Solutions (2/4) o Coupling: n Modules with low coupling are independent of one another. o n System of modules with low coupling is o o n Dependent calling other’s methods. Easier to change: A change to one module won’t affect another. Easier to understand. Easier to reuse. Has increased cohesion. Coupling cannot be and should not be eliminated entirely. o o Objects must collaborate to get work done. But it should be kept to minimum. 39

Evaluation of Designs and Solutions (3/4) o Minimal and complete interfaces: n Interface of a class: o n Complete interface: o o n declares publicly accessible methods (and data). Provides methods for any reasonable task consistent with the responsibilities of the class. Very important. Minimal interface: o o o Easy to understand a class. Provides only essential methods. Less important than completeness. 40

Evaluation of Designs and Solutions (4/4) n Signature: the interface for a method or function. o o o Name of method/function. Arguments (number, order, type). Qualifiers such as const. bool List: : retrieve(int index, int &data. Item) const 41

Operation Contracts (1/3) o Contract shows the responsibilities of one module to another. n o Begin the contract during analysis, finish during design. n o Use to document code, particularly in header files. Does not describe how the module will perform its task. A module’s operation contract specifies its: n n Purpose. Assumptions. Input. Output. 42

Operation Contracts (2/3) o Precondition: n o Statement of conditions that must exist before a module executes. Postcondition: n Statement of conditions that exist after a module executes. Example of module contract: purpose sort(an. Array, num) // Sorts an array. // Precondition: an. Array is an array of num integers; num > 0. // Postcondition: The integers in an. Array are sorted. Precondition & postcondition pretty vague, 43 sort? descending or ascending order?

Operation Contracts (3/3) o Revised specifications: sort(an. Array, num) // Sorts an array into ascending order. // Precondition: an. Array is an array of num // integers; 1 <= num <= MAX_ARRAY, where // MAX_ARRAY is a global constant that specifies // the maximum size of an. Array. // Postcondition: an. Array[0] <= an. Array[1] <=. . . // <= an. Array[num-1], num is unchanged. Documentation is very important!! You, the programmer, may forget everything about your programs. 44

Verification (1/3) o o To prove that an algorithm is correct. Assertion: A declaration about a particular condition at a certain point in an algorithm. n o Preconditions and postconditions are examples of assertions. To prove an algorithm: n n n Start with a precondition. Demonstrate that each assertion before a step in the algorithm leads to the assertion after the step. Until you reach the postcondition. 45

Verification (2/3) o o Invariant: A condition that is always true at a certain point in an algorithm. Loop invariant: A condition that is true before and after each execution (iteration) of an algorithm’s loop. n o Can help you write and check correct loops. The invariant for a loop is true at the following points: n n Initially, after any initialization steps, but before the loop begins execution. Before every iteration of the loop. The invariant is true after After every iteration of the loop. each iteration. After the loop terminates. 46

Verification (3/3) // compute the sum of item[0], //. . . , item[n-1] for n>= 1 int sum = 0; int j = 0; o The invariant is true here. o while(j<n) { sum += item[j]; j++; } Loop invariant: n sum is the sum of elements item[0] through item[j-1]. In addition, You also have to show that the loop will terminate!! n The value of j: o 0, 1, …, eventually equal n. The invariant is true here. 47

What is a Good Solution? o A solution (program) is good if: n n The total cost it incurs over all phases of its life cycle is minimal. The cost of a solution includes: o o n n Computer resources that the program consumes. n Time & memory. Difficulties encountered by users. The effort of changes (bug fixes or spec modification). … Efficiency is one aspect of a solution’s cost. Usually, good structure and documentation are the utmost important factors of today’s programs. 48

Key Issues in Programming o o o o Modularity. Style. Modifiability. Ease of Use. Fail-safe programming. Debugging. Testing. 49

Key Issues in Programming: Modularity o Modularity has a favorable impact on: n n n Constructing programs. Debugging programs. Reading programs. Modifying programs. Eliminating redundant code. 50

Key Issues in Programming: Style Use of private data members. Proper use of reference arguments. o o n Pass-by-value, pass-by-reference, pass-by-constantreference. Avoidance of global variables in modules. Error handling. o o n E. g. , check for invalid input or argument values. Readability. o n Good choice of identifiers. o n Good indentation. o o Nouns for class names. Verbs for method names. Use tabs, blank lines for a better layout of you programs. Documentation. 51

Key Issues in Programming: Modifiability o o After each iteration during the development of a program, the design (and the program) will change to some degree. Modifiability is easier through the use of: n Named constants. o n const int DATA_SIZE 200; The typedef statement. o typedef float My. Data. Type typedef long double My. Data. Type; 52

Key Issues in Programming: Ease of Use o In an interactive environment, the program should prompt the user for input in a clear manner. n n o E. g. , “please enter your account number. ” A program should always echo its input. The output should be well labeled and easy to read. NAME Jones Smith Harris ACC# 223 111 44 SAVINGS $1088. 19 -------$2222. 22 53

Key Issues in Programming: Fail-Safe Programming (1/4) o o Fail-safe programs will perform reasonably no matter how anyone uses it. Enforce preconditions. Check invariants. Functions (modules) should check the values of their arguments. 54

Key Issues in Programming: Fail-Safe Programming (2/4) /** * * int { Computes the factorial of an integer. @pre n >= 0. @post None. @param n The given integer. @return n * (n – 1) *. . . * 1 if n > 0; 1 if n == 0. */ factorial (int n) int fact = 1; what if n is negative? for(int i=n; i>1; --i) fact *= i; return fact; } 55

Key Issues in Programming: Fail-Safe Programming (3/4) Test for invalid input data. o void read. Grade(Table. Type grade. Data) { int group, number; // input values for(group = LOW_END; group <= HIGH_END; ++group) grade. Data[group] = 0; for(cin >> group >> number; (group != 0) || (number != 0); cin >> group >> number) { grade. Data[group] += number; } } grade. Data 0 0 LOW_END=0 . . . what if group is out of the range and number is negative ? 0 HIGH_END=10 56

Key Issues in Programming: Fail-Safe Programming (4/4) bool read. Grade(Table. Type grade. Data) { bool data. Correct = true; // no data error found as yet int group, number; // input values for(group = LOW_END; group <= HIGH_END; ++group) grade. Data[group] = 0; for(cin >> group >> number; (group != 0) || (number != 0); cin >> group >> number) { if( (group >= LOW_END) && (group <= HIGH_END) && (number >= 0) ) grade. Data[group] += number; else data. Correct = false; } return data. Correct; } grade. Data 0 0 . . . 0 57 LOW_END=0 HIGH_END=10

Key Issues in Programming: Debugging (1/2) o o Even experienced programmers have to spend a lot of time on debugging. Tools to use while debugging: n n n Single-stepping. Watches. Breakpoints. cout statements Dump functions. o o (my favorite, with function getchar). For complex data structures. TO BE A GOOD PROGRAMMER, YOU MUST BE A GOOD DEBUGGER!! 58

Key Issues in Programming: Debugging (2/2) o Debugging loops: for( index = start; index <= stop; ++index ) { // check values of index and key variables // at the beginning of iteration. . . // check values of index and key variables // at the end of iteration } o Debugging if statements: if( expression ) { cout << “Condition is true”; . . . } else { cout << “Condition is false”; . . . } 59

Key Issues in Programming: Testing (1/4) o o Programs need to be tested to make sure that they correctly solve the requirements of the current iteration. Levels: n n Unit testing: Test individual modules. Integration testing: Test interactions among modules. System testing: Test entire program, go well with external systems. Acceptance testing: Show that system complies with requirements. 60

Key Issues in Programming: Testing (2/4) o Types: n Open-box (white-box or glass-box) testing. o o n Closed-box (black-box or functional) testing. o o o Test knowing the implementation. Test all lines of code (decision branches, etc. ). Test knowing only the specifications. Develop test data to evaluate all possible inputs and arguments. Developing test data. n n Include boundary values of inputs or arguments. Need to know expected results. 61

Key Issues in Programming: Testing (3/4) o Techniques n assert macros to check invariants o n assert(expr), aborts a program and displays error messages if expr is false. Write a block of code to test a module. o o When finish testing, disable, but do not remove, code used for testing. Boolean variables: o Macro: const bool TESTING = false; #define TESTING if (TESTING) { // Testing code in here. } #ifdef TESTING // Testing code in here #endif 62

Key Issues in Programming: Testing (4/4) o Stubs n o An incompletely implemented method that simply acknowledges that it was called. Drivers n A module that tests another module. 63

Summary (1/3) o Software engineering n o Software life cycle n o Phases through which software progresses, from conception to deployment to replacement to deletion. Loop invariant n o Techniques to facilitate development of programs. Property that is true before and after each iteration of a loop. Evaluating the quality of a solution n Correctness, efficiency, development time, ease of use, cost of modification. 64

Summary (2/3) o Abstraction n o o Focus on what a module does, not how. UML is a modeling language used to express OO designs visually. A solution should be easy to modify n n Modular. Independent of implementation of its modules. 65

Summary (3/3) o o Each function/method should be as independent as possible and perform one well-defined task. Documentation n o o Each function/method should include a comment: purpose, precondition, and postcondition. A program should be as fail-safe as possible. Effective use of available diagnostic aids is one of the keys to debugging. n Use “dump functions” to help to examine and debug the contents of data structures. 66

Homework o Exercises 5, 6, 10, and 11. (due date: 10/8) 67