Modular Decomposition, Abstraction and Specifications

Slides:



Advertisements
Similar presentations
EECE 310: Software Engineering Modular Decomposition, Abstraction and Specifications.
Advertisements

Addressing the Challenges of Current Software. Questions to Address Why? What? Where? How?
Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Chapter 6 C Arrays Acknowledgment The notes are adapted from those provided by Deitel & Associates, Inc. and Pearson Education Inc. Arrays are data structures.
1 ES 314 Advanced Programming Lec 2 Sept 3 Goals: Complete the discussion of problem Review of C++ Object-oriented design Arrays and pointers.
Specifications Liskov Chapter 9 SWE 619 Last Updated Fall 2008.
Introduction SWE 619. Why Is Building Good Software Hard? Large software systems enormously complex  Millions of “moving parts” People expect software.
Cs205: engineering software university of virginia fall 2006 Semantics and Specifying Procedures David Evans
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Chapter 3 Introduction to Collections – Stacks Modified
Unit III : Introduction To Data Structures and Analysis Of Algorithm 10/8/ Objective : 1.To understand primitive storage structures and types 2.To.
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
1 Ch. 1: Software Development (Read) 5 Phases of Software Life Cycle: Problem Analysis and Specification Design Implementation (Coding) Testing, Execution.
© Paul Ammann, 2008 Design by Contract Paul Ammann CS/SWE 332.
Ceg860 (Prasad)LADT1 Specification and Implementation of Abstract Data Types Algebraic Techniques.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
Chapter 3 Collections. Objectives  Define the concepts and terminology related to collections  Explore the basic structures of the Java Collections.
Programming Techniques Lec03 Procedural Abstraction Software Engineering Fall 2005.
Question of the Day  What three letter word completes the first word and starts the second one: DON???CAR.
Object-Oriented Design Concepts University of Sunderland.
Object Oriented Programming. OOP  The fundamental idea behind object-oriented programming is:  The real world consists of objects. Computer programs.
UNIT-IV Designing Classes – Access Layer ‐ Object Storage ‐ Object Interoperability.
Lecture 10 Collections Richard Gesick.
Recursion CSE 2320 – Algorithms and Data Structures
Chapter 0: Introduction
Data Abstraction: The Walls
Algorithms and Problem Solving
Searching.
EECE 310: Software Engineering
Types for Programs and Proofs
Input Space Partition Testing CS 4501 / 6501 Software Testing
GC211Data Structure Lecture2 Sara Alhajjam.
11.1 The Concept of Abstraction
Introduction to Algorithms
Specifications Liskov Chapter 9
Structural testing, Path Testing
Recursion CSE 2320 – Algorithms and Data Structures
Java Review: Reference Types
structures and their relationships." - Linus Torvalds
Design by Contract Fall 2016 Version.
Subroutines Idea: useful code can be saved and re-used, with different data values Example: Our function to find the largest element of an array might.
EECE 310: Software Engineering
Stacks.
Algorithm An algorithm is a finite set of steps required to solve a problem. An algorithm must have following properties: Input: An algorithm must have.
Unit-2 Divide and Conquer
Abstract Class As per dictionary, abstraction is the quality of dealing with ideas rather than events. For example, when you consider the case of ,
Generic programming in Java
SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
A Robust Data Structure
Programming We have seen various examples of programming languages
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Stacks.
Protocols CS 4311 Wirfs Brock et al., Designing Object-Oriented Software, Prentice Hall, (Chapter 8) Meyer, B., Applying design by contract, Computer,
Algorithms and Problem Solving
CMSC 202 Generics.
Introduction to Data Structure
Searching.
Interfaces.
CS1100 Computational Engineering
CMPE212 – Reminders Assignment 2 due next Friday.
Software Specifications
Searching.
structures and their relationships." - Linus Torvalds
Formal Methods Lecture 16 March 22, 2011 CS 315 Spring 2011
11.1 The Concept of Abstraction
Chapter 11 Abstraction - The concept of abstraction is fundamental in
Presentation transcript:

Modular Decomposition, Abstraction and Specifications EECE 309: Software Design Modular Decomposition, Abstraction and Specifications

Decomposition Goal: Create small programs that interact with one another in simple, well-defined ways, to reduce complexity Criteria for good decomposition Sub-problems at the same level of detail Each can be solved independently Can be combined to solve the original problem

Decomposition Example Large Unsolved Problem SP2 SP3 SP4 SP5 SP6 SP1 Combined solution

What often happens in practice ? Large Unsolved Problem SP1 SP2 SP3 SP7 SP4 SP5 SP9 Combined solution ?

Learning Objectives Define abstraction and types of abstraction List the standard elements of specification Write specifications in the standard format Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

Abstraction A way to do decomposition productively Definitions: Application of many-to-one mapping Simplification of the problem that hides irrelevant details, characteristics Grouping of related entities into distinct categories without worrying about the details

Abstraction Types By Parameterization By Specification Abstracts from the identity of the data By Specification Abstracts from implementation details to the behavior users can depend on Isolates modules from one another’s implementations Provides a clear contract between the user and the implementer of module

Abstraction by Parameterization Write the procedure once, but change its parameters Generalizes modules so they can be used many times Fundamental technique used in programming Example: Recipe for making pasta (Serves 2 people) Step 1: Boil 2 cups of water in a sauce-pan Step 2: Add 6 cups of pasta when water comes to a boil Step 3: Sautee 5 grams of vegetables in an another pan Step 4: Mix the sauteed vegetables with the cooked pasta Step 5: Add pasta sauce, cheese and salt to taste But, what if we wanted to make pasta for 5 people ? Should we develop a new recipe from scratch ?

Abstraction by Specification Hide implementation details of a module and focus instead on what it does (rather than how it does it) Specify the behavior that module’s users can depend on Can generalize across multiple implementations Change module’s behavior without changing its usage Example: Recipe for making pasta (Serves 2) Step 1: Boil 2 cups of water in a sauce-pan Step 2: Add 6 cups of pasta when water comes to a boil Step 3: Sautee 5 grams of vegetables in an another pan Step 4: Mix sauteed vegetables with the cooked pasta Step 5: Add pasta sauce, cheese and salt to taste

Benefits of Abstraction by Specification Locality -- the implementation of an abstraction can be read or written without needing to examine the implementations of any other abstractions. 2. Modifiability -- an abstraction can be re-implemented without requiring changes to any abstractions that use it.

Learning Objectives Define abstraction and types of abstraction List the standard elements of specification Write specifications in the standard format Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

Specification Tells the client of an abstraction what the client is expected to do Tells the implementer of an abstraction what implementation must do to satisfy the client Contract between client and implementer Client will rely only on behavior in specification Implementer only needs to provide this behavior Implementer is free to change implementation

Specifications: Formal Vs Informal Formal Specs Informal Specs Written in a mathematically precise language Have only one meaning or a finite set of meanings Can be understood by humans and machines Automated tools can check code against specifications Written in an informal language (English) Have different meanings depending on the reader Can be understood only by humans (for the most part) Manual effort needed to check code against specs In this class, we will write informal specifications, but you will write formal specs in the assignments

Recipes: Analogy A good specification is like a recipe and has the following components: What is being done ? What is required ? How to do it ? Are there things that one needs to look for ? Any other things to note Recipes are written in a standard format defined by the Chef’s Association.

How to write procedural specifications ? Choose a name for the procedure that is descriptive Procedural specifications should consist of: REQUIRES: What does the procedure need ? MODIFIES: What data does the procedure modify ? EFFECTS: What does the procedure produce at the end ? The code for the procedure is not part of its specification, but must match the specification

Procedural Specifications Factorial: Fact(n) = 1 * 2 *3 …. * n * (n- 1) static int Fact(int n) { // REQUIRES: n >= 0 // MODIFIES: None (this can be dropped) // EFFECTS: Returns the factorial of n // where fact(n) = 1 * 2 * … * n … }

Multiple Implementations Using Iteration Using recursion public static int fact(int N ) { int result = 1; for (int i =1; i<=N; i++) { result = result * i; } return result; public static int fact(int N) { int result; if (N==0) result = 1; else result = N * fact(N – 1); return result; } Both implementations satisfy the specification. (Do they have the same behavior (why or why not) ?)

Learning Objectives Define abstraction and types of abstraction List the standard elements of specification Write specifications in the standard format Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

Sorting Routine: Informal Spec Take an array as argument, sort it in place What kind of arrays do we want to handle ? Arrays of ints (primitive type) Array should be non-null No need to say that array elements are non-null public static void sort( int[] a ) { // REQUIRES: // MODIFIES: // EFFECTS:

REQUIRES clause Should only capture the requirements on array that are not implied by the type signature Do not need to say anything about the types of the arguments, unless they cannot be inferred Do not mention the return type of the procedure public static void sort( int[] a ) { // REQUIRES: Array a not be Null }

MODIFIES Clause Modifies clause only specifies what objects (on heap) are modified by the procedure Does not include return value of procedure Does not say anything about how it is modified public static void sort( int[] a ) { // REQUIRES: Array a not be Null // MODIFIES: Array a

EFFECTS Clause Specifies the EFFECT of the procedure on the caller Include both return value and heap objects Include any exceptions thrown by the procedure Must say what modifications are made and how public static void sort( int[] a ) { // REQUIRES: Array a not be Null // MODIFIES: Array a // EFFECTS: Rearranges the elements of a in // ascending order (i.e., lowest to highest)

Group Activity Write a specification for the sort program that sorts an array of String objects (in alphabetical order) public static void sort( String[] a ) { // REQUIRES: // MODIFIES: // EFFECTS:

One Solution: Group Activity public static void sort( String[] a ) { // REQUIRES: a is not NULL && // Elements of a are not NULL // MODIFIES: Array a // EFFECTS: Re-arranges the elements of array a // in alphabetical order (i.e., lowest to highest) // Uses String.compareTo for determining order

Group Activity (continued)… How would your specification change if the sort procedure needs to return a new array ?

Learning Objectives Define abstraction and types of abstraction List the standard elements of specification Write specifications in the standard format Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

Procedural Specifications: Example 1 public class Vectors { //OVERVIEW: Provides useful standalone procedures // for manipulating vectors public static void removeDuplicates ( Vector v ) { // REQUIRES: No element of vector v is null // MODIFIES: v // EFFECTS: Removes all duplicate elements from v; // uses equals method to determine duplicates. // The order of the remaining elements may change }

Procedural Specification: Example 2 Does the following implementation satisfy the specification ? public static void removeDuplicates ( Vector v ) // REQUIRES: No element of vector v is null // MODIFIES: v // EFFECTS: Removes all duplicate elements from v; // uses equals method to determine duplicates. // The order of the remaining elements may change v.clear(); }

Procedural Specifications: Example 3 public class Vectors { //OVERVIEW: Provides useful standalone procedures // for manipulating vectors public static void removeDuplicates ( Vector v ) { // REQUIRES: No element of vector v is null // MODIFIES: v // EFFECTS: Removes all duplicate elements from v; // uses the equals method to determine duplicates. // The order of the remaining elements may change // but the set of elements formed by the new vector is // identical to the set of elements formed by the old one }

What’s the problem ? The original specification was too weak Any implementation could satisfy it, even incorrect ones The specification should be sufficiently restrictive to allow only correct implementations If it is important to you, then write it down From the point of view of the client Make sure you can use the specification

Remember … Specifications are many-to-one mappings Many implementations may satisfy a specification But some may be wrong because the specification is not restrictive enough ! A specification is like a contract. If the implementer can get away by doing less and yet satisfy the specification, they may choose to ! It is your responsibility to put it in the specification

Learning Objectives Define abstraction and types of abstraction Write specifications in the standard format Write precise specifications that are sufficiently restrictive, but not too restrictive Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

What makes a good specification ? Sufficiently restrictive Minimally constraining Clear – no room for ambiguity These guidelines are necessarily vague, so let us see some examples

Sufficiently Restrictive public static int search (int[] a, int x) // REQUIRES: a is not null // EFFECTS: Examines each of a[0], a[1], ... , in order and returns the index of the element that equals to x. What’s wrong with the above specification ? What if there is more than one element equal to x ? What if there is no element equal to x ? How will you fix these issues ?

Minimally Constraining Do you really care that the procedure examines each element in turn ? Also, do you need the first element that equals x ? Precludes non-linear implementations such as binary search public static int search (int[] a, int x) // REQUIRES: a is not null // EFFECTS: Examines each of a[0], a[1], ... , in some order and // returns the index of an element that equals to x. // If no such element is found, it returns - 1

Note the use of i.e. to indicate redundancy Clarity The above specification is NOT clear. Do we return an element whose index is x, or do we return the index of an element that equals x. This is the problem with natural language. So we need to be more clear. public static int search (int[] a, int x) // REQUIRES: a is not null // EFFECTS: Examines each of a[0], a[1], ... , in some order and // returns the index of an element that equals to x. // i.e., returns an i, such that a[i] = x and 0 <=i <a.length // if no such element is found, it returns -1. Note the use of i.e. to indicate redundancy

Learning Objectives Define abstraction and types of abstraction List the standard elements of specification Write specifications in the standard format Differentiate between “good” and “bad” specifications Develop implementations to satisfy a specification

Implementation Do NOT handle cases in the REQUIRES clause EFFECTS clause is satisfied only if REQUIRES holds Do NOT modify entities not in MODIFIES clause Do only what the EFFECTS clause says, no more Clients should rely upon specification, not implementation If EFFECTS clause is underspecified, then it’s a problem in the specification and needs to be fixed

Group Activity - 1 Develop implementation for the specification below (write legibly on a separate sheet) public static int search (int[] a, int x) // REQUIRES: a is not null // EFFECTS: Examines each of a[0], a[1], ... , and returns // the index of any array element that equals to x. // i.e., returns an i, such that a[i] = x and 0 <=i <a.length // If no such element is found, returns -1.

Group Activity - 2 Write the implementation of a procedure replace that uses search and has the following specification: public static void replace(int[] a, int x, int y) { // MODIFIES: a // EFFECTS: Replaces all instances of element // x in the array a[] with that of y }