1. J. Michael Moore Software Design CSCE 110 Influenced by material developed by James Tam & Jennifer Welch

2. J. Michael Moore Activities in the lifetime of a piece of software Requirements Gathering/Analysis Design Implementation (Coding) Testing Deployment / Maintenance The phases are not sequential. There is not a clear demarcation between the different activities. Often you have to go back and modify the results of a previous phase Different models and approaches Waterfall Iterative Agile Extreme programming Software Development

3. J. Michael Moore Requirements Gathering/Analysis Identify the needs of the user and what the system should (and should not) do. Explicit and Implicit requirements The resulting set of requirements describe the application (e.g., data must not be available to unauthorized people). Convert into more detailed descriptions (e.g., 10 character passwords).

4. J. Michael Moore Software Design Break system into manageable units, or modules. Modular design is key to the ability to create large systems.

5. J. Michael Moore Implementation Write the code. (most of what we do in this course)

6. J. Michael Moore Testing Test each module in isolation. Test the modules all together (integration testing). Make sure every line of code is tested.

7. J. Michael Moore Deployment / Maintenance Deploy the software Maintain Fix bugs Modify to satisfy changing requirements

8. J. Michael Moore Software Development What you should do in this class. What many of you will probably end up doing that will be reflected in your grades. Activities in the lifetime of a piece of software Requirements Gathering/Analysis Design Implementation (Coding) Testing Deployment / Maintenance

9. J. Michael Moore Why Use Modular Decomposition Benefits of procedural abstraction (i.e. breaking things into modules): Separation of concerns - concentrate on one task at a time Saves effort and space if the same (or similar) code needs to be repeated. Helps programmer see common / similar aspects of the code so the solution is easier to visualize Easier to test the program Easier to maintain (if modules are independent, then changes in one module should not impact other modules) Drawback Complexity – understanding and setting up inter-module communication may appear daunting at first Tracing the program may appear harder as execution appears to “jump” around between modules.

10. J. Michael Moore Bottom-up design Start by identifying individual tasks at the bottom level and then combine them to solve the main problem. Disadvantages: —how do you know the required individual tasks initially? —Trying to address all the details of a large problem all at once may prove to be overwhelming. Advantage: —favors reusing existing code.

11. J. Michael Moore Top-down design Start with high level idea of solution, and successively refine it. Favors hierarchical organization, with modules inside modules. Advantage: —divide and conquer the problem Disadvantage: —design decisions made at high levels are set in stone for lower levels

12. J. Michael Moore Top Down Design 1.Outline the major parts (structure) 2.Implement the solution for each part My autobiography Chapter 1: The humble beginnings Chapter 2: My rise to greatness … Chapter 1: The humble beginnings It all started seven and one score years ago with a log-shaped work station…

13. J. Michael Moore Top-Down Approach: Breaking Down A Large Problem Figure extracted from Computer Science Illuminated by Dale N. and Lewis J. General approach Approach to part of problem Specific steps of the solution Abstract/ General Particular Top Bottom Approach to part of problem Specific steps of the solution

14. J. Michael Moore Modules Information that is passed between calling module A and called module B with parameters and return values. Some modules we have already seen writeln readln trunc sqrt Types of modules that can be implemented in Pascal Procedures Functions Places you’ll see procedures and functions referenced Definition: This is where the statements for the module are placed Call: This is where the module is instructed to run, i.e. where execution of the module begins

15. J. Michael Moore Modules Modules can call other modules: Modules A includes a statement to call module B When execution of A reaches the call, control is transferred to the beginning of B The statements of B are executed until the end of B Control is transferred back to A, just after the call to B

16. J. Michael Moore Modules What should be made into a module? A relatively small piece of code that accomplishes a well-defined task.

17. J. Michael Moore Design: Finding Candidate Modules The process of going from a problem description (words that describe what a program is supposed to do) to writing a program that fulfills those requirements cannot be summarized in just a series of steps that fit all scenarios. The first step is to look at verbs either directly in the problem description (indicates what actions the program should entail) or those which can be inferred from the problem description. Each action may be implemented as a module but complex actions may have to be decomposed further into several additional modules (i.e. sub-modules).

18. J. Michael Moore Example Problem Design a program that will perform a simple interest calculation. The program should prompt the user for the appropriate values, perform the calculation and display the values onscreen.

19. J. Michael Moore Top Down Approach: Breaking A Programming Problem Down Into Parts (Modules) Calculate Interest Get informationDo calculationsDisplay results

20. J. Michael Moore Making Change (Paraphrased from the book “Pascal: An introduction to the Art and Science of Programming” by Walter J. Savitch. Problem statement: Design a program to make change. Given an amount of money, the program will indicate how many quarters, dimes and pennies are needed. The cashier is able to determine the change needed for values of a dollar and above. Actions that may be needed: Action 1: Prompting for the amount of money Action 2: Computing the combination of coins needed to equal this amount Sub-action 2A: Compute the number of quarters to be given out. Sub-action 2B: Compute the number of dimes to be given out Sub-action 2C: Compute the number of pennies to be given out. Action 3: Output: Display the number of coins needed

21. J. Michael Moore Structure Diagram Of The Modules inputAmount Change program (main) computeChange outputCoins amount quarters dimes pennies quarters dimes pennies amount

22. J. Michael Moore Outline Of The Modules inputAmount Change program (main) computeChange outputCoins amount quarters dimes pennies quarters dimes pennies computeQuarters computeDimes computePennies amountLeft dimes amountamountLeft quarters amountLeft pennies amount