Chapter 1: Principles of Programming and Software Engineering

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

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

3. Software Engineering and Object-Oriented Design (2/2) • 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? • A team of programmers for a large software development project requires: • An overall plan. • Organization. • Communication. • Software engineering: • Provides techniques to facilitate the development of computer programs.

4. An Examination of Problem Solving • Problem solving: • 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): • A problem solution is a program consisting of a system of interactingclasses of objects. • 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).

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

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

7. Aspects of an Object-Oriented Solution (3/3) • When designing a solution, your challenge is to create a good set of modules. • 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.

8. Abstraction and Information Hiding (1/5) • Abstraction: • 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. • Modularity breaks a solution into modules. • Abstraction specifies each module clearly.

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

10. Abstraction and Information Hiding (3/5) • Data abstraction: • Is a concept. • To focus on what you will do to data, not on the implementation of the operations. • Abstract data type (ADT): • 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.

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

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

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

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

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

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

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

18. Applying the UML to OOA/D (1/9) • Unified Modeling Language (UML) • 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. • Enables members of a programming team to communicate visually with one another and gain a common understanding of the system being built.

19. Applying the UML to OOA/D (2/9) • UMLuse case for OOA. • A set of textual scenarios (stories) of the solution. • 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.

20. Applying the UML to OOA/D (3/9) • An example of a main success scenario: • 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.

21. Applying the UML to OOA/D (4/9) • An example of an alternate scenario: • 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.

22. Applying the UML to OOA/D (5/9) • UML sequence (interaction) diagram for OOD. • 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. • What must an object remember? • What must an object do for other objects?

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

24. Applying the UML to OOA/D (7/9) • UML class (static) diagramfor OOD. • 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.

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

26. Applying the UML to OOA/D (9/9) • UML syntax for the attribute of a class: • [visibility] name [:type] [=defaultValue] [{property}] • -address:string • UML syntax for the operation of a class: • [visibility] name([parameterList]) [:type] [{property}] • +changeAddress(in newAddr:string) • +getAddress():string {query} data type name of attribute or operation +: public, -: private function without type, a void function will not modify any of the data members

27. The Software Life Cycle • Describes the phases of software development from conception to deployment to replacement to deletion. • 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.

28. Iterative and Evolutionary Development (1/2) • Iterative development of a solution to a problem. • 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 portionof the problem domain. • Early iterations create the core of the system; further iterations build on that core.

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

30. Rational Unified Process (RUP) Development Phases (1/6) • An example of iterative and evolutionary development. • RUP uses the OOA/D tools we introduced. • Four development phases: • 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.

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

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

33. Rational Unified Process (RUP) Development Phases (4/6) • Elaboration phase: • Iteratively develop core architecture of system. • Address highest-risk aspects of system. • 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.

34. Rational Unified Process (RUP) Development Phases (5/6) • Construction phase: • 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: • testing with advanced end users. • System moves into a production environment.

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

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

37. Achieving a Better Solution • 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?

38. Evaluation of Designs and Solutions (1/4) • Cohesion: • A highly cohesive module performs one well-defined task. • The name of module promotes self-documenting, easy-to-understand code. • E.g., a function called sortshould 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!!

39. Evaluation of Designs and Solutions (2/4) • Coupling: • Modules with low coupling are independent of one another. • Dependent  calling other’s methods. • System of modules with low coupling is • 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. • Objects must collaborate to get work done. • But it should be kept to minimum.

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

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

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

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

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

45. Verification (1/3) • To prove that an algorithm is correct. • Assertion: A declaration about a particular condition at a certain point in an algorithm. • Preconditions and postconditions are examples of assertions. • To prove an algorithm: • 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.

46. Verification (2/3) • 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. • Can help you write and check correct loops. • The invariant for a loop is true at the following points: • 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. The invariant is true after each iteration.

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

48. What is a Good Solution? • A solution (program) 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. • 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.

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

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