1. Chapter 1 t Software Engineering and Computer Programming t Course presentations are available for view and downloading on the course web page: t http://www.d.umn.edu/~jallert

2. Goals t The goal of CS is the discovery of fundamental principles underlying computer programming t Software Engineering is about the construction of software systems t “pure” versus “applied” science t They also have many common interests

3. Computer Science t Dates from the 1940’s t Study of algorithms t Algorithm implementation t Tied to mathematics t Tries to discover principles underlying hardware and software

4. Software Engineering t Dates from late 1960’s t Develop models of systems t Major concerns are –efficiency –reliability t Applies CS principles to construct better systems

5. Basic processes for all CS professionals t Theory t Abstraction t Design

6. Theory t Definitions, axioms, theorems, proofs t Interpretation of results t Example: Analysis of algorithm efficiency

7. Abstraction t Developing models of the world –isolate the essential features of a problem –example: flipping a coin does not need to know denomination, metal, picture simulates only one of two random outcomes t Test problem approaches

8. Design t Requirements t Specifications t Program design t Program implementation t Testing t Analysis

9. The The concerns of the computer scientist and the software engineer Theory Abstraction Design Software engineer Computer scientist Data structures

10. Data Structures and ADT’s

11. Data structure t Definition: t A ‘data structure’ consists of –A base storage method (i.e. an array) –One or more algorithms that are used to access or modify that data

12. Program example t Here is a program demonstrating a dice data structure. t This first example is a procedural approach to the problem.

13. t // Code Example 1-1: t // dice program that does not use an t // abstract data type (adt) t // t // Compare this approach to cx1-2.cpp. t #include "dslib.h" t // standard header files for text t #include

14. t int main() t { int die1, die2, total; t randomize(); t // pseudorandom number generator t die1 = random(6) + 1; t // random(6) returns random number t // between 0 and 5 t die2 = random(6) + 1; t total = die1 + die2; t cout << "first die: " << die1; t cout << “ second die: " << die2; t cout << endl; t cout << "total for roll is: ”; t cout << total << endl; t return 0; }

15. Data structures dilemma t Possible dice data structures –two integers, each between 1 and 6 –simple to implement, simple operations t Deck of cards data structure –more difficult, especially operations t Air traffic control system –very difficult –needs a model –high level of “software engineering”

16. Abstract Data Type (ADT) t Gives us a tool to use to control complexity t Definition: a collection of data and operations –Data characteristics DOES NOT include method of representation –Operations DOES NOT include how implemented

17. Definition of ADT t An Abstract Data Type (ADT) is –a well-specified collection of data known as the characteristics, or data state –and a group of operations that can be performed upon the data known as behaviors or operations –member functions (C++) –methods (Java)

18. About ADTs t The ADT’s specification describes –what data can be stored (the characteristics of the ADT), –and how it can be used (the operations), –but not how it is implemented or represented in the program.

19. Decoupling t ADTs do not specify how the data structure will be implemented t There may be many ways t The data specification has been decoupled from the implementation. t This means that software development can be less complex (fewer details to consider) t Also, software development is more flexible (the actual structure is not fixed)

20. Dice ADT t Characteristics (data state): Represents a pair of 6-sided dice, that can be rolled to get a random sum between 2 and 12. t Operations: –int roll() Precondition: none. Task: A random value between 1 and 6 is stored for each of the dice. Returns: The sum of the two dice values, lying between 2 and 12.

21. Dice ADT operations (con’t) –int die1() Precondition: The dice have been rolled at least once. Postcondition: None. Returns: The value of the first die. –int die2() Precondition: The dice have been rolled at least once. Postcondition: None. Returns: The value of the second die.

22. A program using a Dice ADT t // Illustrates solution to a t // "dice simulation", using t // abstract data types. t // t // Dice ADT t // t // Characteristics: t // Represents a pair of 6-sided dice, t // that can be rolled to get a t // random sum between 2 and 12. t //

23. Dice ADT operations comments t // Operations: t // int roll() t // Preconditions: none t // Postcondition: random value from 1-6 t // is stored for each of the dice. t // Returns: sum of the two dice values, t // lying between 2 and 12

24. die1() and die2() operations t // int die1() t // Precondition: dice have been rolled t // at least once. t // Postcondition: None t // Returns: The value of the first die. t // int die2() t // Precondition: dice have been rolled t // at least once. t // Postcondition: None t // Returns: The value of the second die.

25. Dice ADT program t // Note on encapsulation: t // The representation of the t // dice is contained within global t // variables - we'll see shortly a better t // way to do this. t #include t #include "dslib.h" t int dice_1, dice_2;

26. Roll() t int roll() t {// note -- you don't really want to call t // randomize every time you roll the dice, t // but for this simplified design you t // don’t have much choice. t randomize(); t dice_1 = random(6) + 1; t dice_2 = random(6) + 1; t return dice_1 + dice_2; t }

27. die1() and die2() t int die1() t { t return dice_1; t } t int die2() t { t return dice_2; t } t // end of Dice ADT

28. Client Code (the main program) t int main() t // test program to demonstrate Dice ADT t { t cout << "The value rolled is: ”; t cout << roll() << endl; t cout << "The first die was: ”; t cout << die1() << endl; t cout << "The second die was: ”; t cout << die2() << endl; t return 0; t }

29. Exercise 1-4, p. 9 t Some games for young children use colored squares on a board and a spinner that, in effect, picks one of the colors at random. Suppose that the game has five colors - red, green, blue, yellow and orange. t Design a spinner ADT. t Do not write any code, just the ADT.

30. Spinner problem t What is the data state (characteristics) of this ADT? –enumerated type: colors –spinner - of type colors t What are the operations –spin (randomly chooses a color)

31. Spin() operation t Precondition: –none t Postcondition: –none t Returns: –the value of the spinner

32. The Software Life Cycle

33. The waterfall model of software development t Initiation t Analysis t Design t Implementation t Testing t Maintenance

34. Initiation t Feasibility study t Examination of alternatives t Cost-benefit analysis t Make-or-buy study

35. Analysis t Determines the exact requirements of the system t Systems analyst (liaison between domain experts and software engineers) t Domain experts know the goals and purposes of the software t Software engineers will build the system t Analyst creates functional specifications document

36. Functional specifications t Specifies exact functions the system must provide t Specifies special requirements –minimum performance limits t Legal requirements which must be met

37. Design t Uses functional specifications as a blueprint t Systems architect t Deliverable is a technical, or coding specification t This is the most critical step in the process –bad design may be impossible to implement –difficult to maintain (i.e. Y2K)

38. Implementation t Writing the code t Must meet coding specifications t Develop system and user documentation

39. Testing t Must start with a test plan –sample input: expected output –compares observed to expected t May use separate staff t Final line of defense against unreliable software

40. Maintenance t Latent errors –Only become apparent after testing is finished t Adaptive maintenance –Changes to fit new environments –new OS, hardware, software t Enhancements –improved functionality –often for least experienced programmers

41. The waterfall model of software development Initiation Analysis Design Implementation Testing Maintenance

42. The waterfall model: A summary of the players and the deliverables

43. Critiques of waterfall method t Expensive t Slow t Unrealistic t No emphasis on prototypes t No connection with end users

44. Prototyping t Often built with 4GL to provide GUI t May only be a shell –no functionality t Implementation –Direct –Parallel –Phased –Pilot

45. Reusability t Programmers often “reinvent the wheel” t No equivalent of “interchangeable parts” t Software often not reusable in other apps t OOP addresses these concerns –inheritance t New design techniques: design patterns –provide a library of recurring designs –example: STL in C++ –we will not use the STL in this class

46. Documentation t How much? On what? What form? t Three levels of documenters –Technical writers –System documentation Software engineers/programmers Internal and external –Client documentation

47. Internal documentation t Precondition –The assumed state of the data structures t Postcondition –The effects on the data structures –What the function has done t Returns –The value(s) returned

48. Why C++? t Easy data abstraction t OOP t More features than C

49. Evolution t ADT concept –Specification and implementation of a data structure aren’t the same –But they are related and should be kept together –Pascal, C and other procedural languages do not allow this. –Languages like Modula-2 and ADA allow you to make ‘modules’ containing both

50. Evolution (continued) t C++ supports the module concept by allowing you define classes and instantiate them as objects t Objects may be created that inherit characteristics from other objects t You can use an object without knowing how it is implemented –Exact implementation may take many forms (polymorphism)