ECE 264 Object-Oriented Software Development

1. ECE 264Object-Oriented Software Development Instructor: Dr. Honggang Wang Spring 2013 Lecture 2: Software Design Cycle, Requirements Specification and C++ Basics

2. Lecture outline • Announcements/reminders • Class folder now set up on M:\ drive • Should have folder under M:\ECE-264\<username> • For MSDN account, e-mail Andrew Smart (andrew.smart@umassd.edu) • MUST contact Andrew using your UMassD e-mail • After 2 weeks • Software design cycle • General overview • Software engineering steps • Types of testing • Requirements specifications • Introduce UML, use case diagrams • C++ basics ECE 264: Lecture 2

3. Pretest review • Pretest intended to review the following • Control structures (if/else, switch, loops) • Basic data types • Array accesses • C output • First three topics use exactly the same syntax in C++! • We’ll cover C++ output starting in lecture 3 ECE 264: Lecture 2

4. Pretest review: if/else statements int x, y; . . . if (x < 5) { y = x + 1; } else { y = x – 2; } 1. At the end of the if/else statement above, if x = 4, y is equal to: a. 1 b. 2 c. 4 d. 5 2. Now, if x = 5, y is equal to: a. -2 b. 3 c. 5 d. 6 ECE 264: Lecture 2

5. Pretest review: loops int x = 1; int i = 0; while (i <= 3) { x = x * 2; i++; } 3. Fill in the blank: The body of the while loop executes ______ times. a. 2 b. 3 c. 4 d. an infinite number of 4. The final value of x is: a. 2 b. 3 c. 8 d. 16 5. Which of the following is a for loop that can replace the while loop and produce the same result for x? a. for (i = 1; i < 4; i++) b. for (i = 0; i < 3; i++) c. for (x = 0; x <= 3; x++) d. for (i = 3; i >= 0; i--) ECE 264: Lecture 2

6. Pretest review: arrays, I/O int A[5] = {0, 7, 13, 12, 5}; for (i = 0; i < 5; i++) { printf(“A[%d] + 3 = %d\n”, i, A[i] + 3); } 6. In the first iteration, the program will display the following text on the screen: a. A[%d] + 3 = %d\n b. A[i] + 3 = A[i] + 3 c. A[0] + 3 = 3 d. A[1] + 3 = 10 7. The value of A[4] is: a. 4 b. 5 c. 12 d. non-existent Notes: http://www.cplusplus.com/reference/clibrary/cstdio/printf/ ECE 264: Lecture 2

7. Pretest review: switch statements switch (var) { case 0: case 1: x = x + var; break; case 2: x = x – var; case 3: x = x * var; break; default: x = var; } Assume x always equals 5 at the start of the switch statement. What is the value of x at the end of the statement if: 8. var = 1? a. 1 b. 4 c. 5 d. 6 9. var = 2? a. 2 b. 3 c. 6 d. 7 10. var = 5? a. 0 b. 5 c. 10 d. 25 ECE 264: Lecture 2

8. Software design cycle • Software engineering: application of systematic approach to development, operation, and maintenance of software • Not just programming! • Lots of management involved • Traditional software design cycle • Requirements engineering • Design • Programming • Integration • Delivery • Maintenance ECE 264: Lecture 2

9. Software engineering cycle phases • Requirements: Client needs • Translate these into requirements specification • Design: • Developers translate requirements to actual product • Iterative process • Start with broad outline: what’s the overall functionality we need? • Break that down into smaller pieces: what modules are needed? What details are needed for each module? How do modules interact? • Final result of this stage: design specification • Can include • Verbal description of design, both at high & low level • UML diagrams showing varying levels of detail about project ECE 264: Lecture 2

10. Software engineering cycle phases (cont.) • Programming: Write the actual code • Translate the design spec into language of choice • May have multiple programmers handling different modules • Integration: Merge modules together • The different pieces of software are merged together. Testing is crucial in this phase to ensure the software works and meets all the requirements of the clients. • Delivery: Get product to client • Client typically conducts acceptance testing to ensure product meets requirements • Maintenance: • Fix remaining bugs • Modify product to meet new requirements ECE 264: Lecture 2

11. Testing • Testing is key from design stage on • Unit testing: does a given module function in the expected manner? • You use unit testing every time you debug an individual method, class, etc. • Integration testing: do modules fit together? • Multiple functions calling one another; compatibility among classes; merging files from different parts of the program • System testing: does whole system work together? • Acceptance testing: user-designed tests with developer support to ensure product meets requirements • Good idea to formulate testing plans in design stage • As you determine design spec, think about how you’re going to test your software ECE 264: Lecture 2

12. Use case modeling • Often preceded by “requirements gathering” • Formal name for “figure out what the clients want” • Can be done through use case modeling • Formally model interactions of user(s) with system • Can then go from use cases to requirements specification • Take general use cases and break down into more specific examples • Formalize these steps into a specification for actions • May also have to specify data to be stored, states to be kept, etc. ECE 264: Lecture 3

13. Use case diagrams • Textbook example: ATM system • Assume we’re designing software for basic ATM • Given hardware description of user interface • Screen to display messages • Keypad for numeric input • Assume account # must be entered • Cash dispenser • Deposit slot • For what operations might someone want to use this ATM? ECE 264: Lecture 3

14. Use case modeling • Source: http://newportoregon.gov/dept/npd/atmsafety.asp ECE 264: Lecture 3

15. Fig. 2.18Use case diagram for the ATM system from the user’s perspective.

16. From use case to requirements spec. • What steps occur before accessing account? • Screen displays basic welcome message • Enter account # • Screen prompts user to enter PIN • Screen displays main menu if PIN correct; error otherwise (and returns to welcome) • What steps should we take to withdraw money? • Choose “Withdraw money” option from menu • Screen displays amounts to be withdrawn, option to cancel, potentially option to enter different amount • Based on user input, system either proceeds with withdrawal or cancel • To proceed, must check two conditions: account has enough money, and ATM has enough cash available • Display error message if either condition is not true • Supply money and debit account otherwise ECE 264: Lecture 3

17. UML diagrams • Use case diagram is example of Unified Modeling Language (UML) diagram • General-purpose modeling language • Uses graphical techniques to create abstract system models • Can use UML to describe • Requirements: how can someone use system? • Design: both at high and low level • Overall and specific structures • Overall and specific behaviors ECE 264: Lecture 3

18. UML diagrams • Thirteen types of UML diagram • Model either system structure or system behavior • We’ll focus on: • Use case diagram: model interactions between system and external entities in terms of system capabilities • Class diagram: shows classes: building blocks of system • State machine diagram: models way in which object changes state (i.e., attributes change value) • Activity diagram: models actions performed and specifies order for an object • Communication diagram: shows interaction between objects; focus on what interactions occur • Sequence diagram: shows interaction between objects; focus on when interactions occur ECE 264: Lecture 3

19. Basic Program 1 // Adapted from figure 2.1 in text // Text-printing program #include <iostream> // Allows program to // output data to the screen using std::cout; // function main begins program execution int main() { // display message cout << "Welcome to C++!\n"; return 0;// indicate program ended successfully } // end function main ECE 264: Lecture 3

20. Namespaces; using Directive • The using directive instructs the compiler to use files defined within a specific namespace • Namespaces allow us to declare different scopes • Typically written right after the relevant header file(s) • Example: using namespace std; • std is the name of the Standard C++ namespace • Including this line allows you to avoid specifying namespace for every identifier in your headers … • … but allows everything in the std namespace • Compromise: list namespace members actually used • using std::cout; • Otherwise, you’d have to write “std::cout” every time ECE 264: Lecture 3

21. Input/output streams • C++ has three standard input/output streams • cin is the standard input (e.g., keyboard) • cout is the standard output • cerr is the standard error ECE 264: Lecture 3

22. Input/output streams (cont.) • Standard output • Use the stream output operator << to direct data to cout • General Form: cout << expression << expression; • Note: An expression is a C++ constant, identifier, formula, or function call. • endl can be used to place an output character in the buffer and flush the buffer ECE 264: Lecture 3

23. Modifying Our First C++ Program • Two examples • Print text on one line using multiple statements (Fig. 2.3) • Each stream insertion resumes printing where the previous one stopped • Print text on several lines using a single statement (Fig. 2.4) • Each newline escape sequence positions the cursor to the beginning of the next line • Two newline characters back-to-back outputs a blank line ECE 264: Lecture 3

24. Modified program: two cout statements // Adapted from figure 2.3 in text // Printing a line of text with multiple statements #include <iostream> // Allows program to // output data to the screen using std::cout; // function main begins program execution int main() { // display message cout << "Welcome " cout << "to C++!\n"; return 0;// indicate program ended successfully } // end function main ECE 264: Lecture 3

25. Modified program: multiple output lines // Adapted from figure 2.4 in text // Printing multiple lines of text with one statement #include <iostream> // Allows program to // output data to the screen using std::cout; // function main begins program execution int main() { // display message cout << "Welcome\nto\n\nC++!\n"; return 0;// indicate program ended successfully } // end function main ECE 264: Lecture 3

26. Another C++ Program: Adding Integers • Variable • Is a location in memory where a value can be stored • Common data types (fundamental, primitive or built-in) • int – for integer numbers • char – for characters • double – for floating point numbers • Declare variables with data type and name before use • int integer1; • int integer2; • int sum; ECE 264: Lecture 3

27. Input streams • Standard input • Use the stream input operator >> to direct keyboard input to variables • General Form: cin >> identifier>>identifier; • Input value must be compatible with identifier type ECE 264: Lecture 3

28. Basic program 2 // Adapted from figure 2.5 in text // Addition program that displays the sum of two integers. #include <iostream> using std::cout; using std::cin; using std::endl; int main() { // variable declarations int number1; int number2; int sum; // prompt user for data and read into appropriate variables cout << "Enter first integer: "; cin >> number1; cout << "Enter second integer: "; cin >> number2; sum = number1 + number2; // add the numbers; store result in sum cout << "Sum is " << sum << endl; // display sum; end line return 0;// indicate that program ended successfully } // end function main ECE 264: Lecture 3

29. Final notes • Next time • Continue with C++ basics • More examples of basic I/O • Acknowledgements: this lecture borrows heavily from lecture slides provided with the following texts: • Deitel & Deitel, C++ How to Program, 8th ed. • Etter & Ingber, Engineering Problem Solving with C++, 2nd ed. ECE 264: Lecture 3