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

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

  • View
    226

  • Download
    2

Embed Size (px)

Citation preview

J. Michael Moore

Software Design

CSCE 110

Influenced by material developed by James Tam & Jennifer Welch

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

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).

J. Michael Moore

Software Design

• Break system into manageable units, or modules.

• Modular design is key to the ability to create large systems.

J. Michael Moore

Implementation

• Write the code. (most of what we do in this course)

J. Michael Moore

Testing

• Test each module in isolation.

• Test the modules all together (integration testing).

• Make sure every line of code is tested.

J. Michael Moore

Deployment / Maintenance

• Deploy the software

• Maintain• Fix bugs

• Modify to satisfy changing requirements

J. Michael Moore

Software Development

What you should do in this class.

What many of you will probably end up doingthat will be reflected in

your grades.

• Activities in the lifetime of a piece of software• Requirements Gathering/Analysis

• Design

• Implementation (Coding)

• Testing

• Deployment / Maintenance

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.

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.

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

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…

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

Approach to part of problem

Specific steps of the solution

Specific steps of the solution

Specific steps of the solution

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

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

J. Michael Moore

Modules

• What should be made into a module?• A relatively small piece of code that accomplishes a well-defined

task.

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).

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.

J. Michael Moore

Top Down Approach: Breaking A Programming Problem Down

Into Parts (Modules)

Calculate Interest

Get information Do calculations Display results

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

J. Michael Moore

Structure Diagram Of The Modules

inputAmount

Change program (main)

computeChange outputCoins

amount amount quarters

dimes

pennies

quarters

dimes

pennies

amount

J. Michael Moore

Outline Of The Modules

inputAmount

Change program (main)

computeChange outputCoins

amount amount quarters

dimes

pennies

quarters

dimes

pennies

computeQuarters computeDimes computePennies

amountLeft amountLeft

dimes

amount amountLeft

quarters

amountLeft amountLeft

pennies

amount