Software engineering and design principles
1 / 16

Software Engineering and Design Principles - PowerPoint PPT Presentation

  • Uploaded on

Software Engineering and Design Principles. Chapter 1. Definition. A data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently. Introduction. Why Data Structures?

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Engineering and Design Principles' - umika

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software engineering and design principles

Software Engineering and Design Principles

Chapter 1


A data structure is a particular way of storing and organizing data in a computer so that it can be used efficiently


  • Why Data Structures?

  • There are only three important ideas which must be mastered to write interesting programs.

  • Iteration - Do, While, Repeat, If

  • Data Representation - variables and pointers

  • Subprograms and Recursion - modular design and abstraction


  • A data type is a well-defined collection of data with a well-defined set of operations on it.

  • A data structure is an actual implementation of a particular abstract data type.

  • In this course we will learn to implement such abstract data types by building data structures from arrays, stacks, linked lists, etc.

Good programming practice
Good programming practice

  • Have a plan, follow the plan

  • Start small

    • Compile and test often

  • Build up one feature at a time

  • Look for the objects

  • Gleefully throw stuff away!

    • Refactor for better design

  • Adhere to the lazy programmer model

    • Do only the minimal amount of work to get the job done

  • Provide enough documentation, but not too much

Programming proverbs
Programming Proverbs

  • KISS - ``Keep it simple, stupid.'' - Don't use fancy features when simple ones suffice.

  • RTFM - ``Read the fascinating manual.'' - Most complaints from the compiler can be solved by reading the book. Logical errors are something else.

  • Make your documentation short but sweet. - Always document your variable declarations, and tell what each subprogram does.

  • Every subprogram should do something and hide something - If you cannot concisely explain what your subprogram does, it shouldn't exist. This is why I write the header comments before I write the subroutine.

  • Program defensively - Add the debugging statements and routines at the beging, because you know you are going to need them later.

  • A good program is a pretty program. - Remember that you will spend more time reading your programs than we will.

Principles of good design
Principles of Good Design

  • Strong Cohesion: Each module (function) should perform one well-defined task.

  • Advantages

    • Facilitates reuse in other projects

    • Easy to maintain

    • Robust

  • Example – a function to search for an integer in an array.

Principles of good design1
Principles of Good Design

  • Loose Coupling: Modules (functions) should be independent of one another (to facilitate plug and play)

  • Advantages:

    • More adaptable system is functions don’t depend on each other

    • Easier to understand

    • Increased reusability

    • Increased cohesion

  • Some coupling will be needed!

Principles of good design2
Principles of Good Design

  • Good Interfaces: Class methods allow you to do everything you need to do, and nothing extra

    • A class interface declares publicly accessible methods (and data)

      • Describes only way for programmers to interact with the class

    • Classes should be easy to understand, and so have few methods

      • Desire to provide power is at odds with this goal

    • Complete interface

      • Provides methods for any reasonable task consistent with the responsibilities of the class

      • Important that an interface is complete

    • Minimal interface

      • Provides only essential methods

      • Classes with minimal interfaces are easier to understand, use, and maintain

      • Less important than completeness

Pre and post conditions
Pre and Post Conditions

  • Precondition: Conditions that must exist at the beginning of a function

  • Postcondition: Conditions at the end of the function.

    Thought of as a promise. If the preconditions are met by the calling function, the function promises the postconditions will be true when the function returns.

Operation contracts conditions
Operation Contracts/Conditions

  • Specify data flow among modules

    • What data is available to a module?

    • What does the module assume?

    • What actions take place?

    • What effect does the module have on the data?

Operation contracts
Operation Contracts

First draft specifications

sort(anArray, num)

// Sorts an array.

// Precondition: anArray is an array of num  integers; num > 0.

// Postcondition: The integers in anArray are  sorted.

Operation contracts1
Operation Contracts

Revised specifications

sort(anArray, num)

// Sorts an array into ascending order.

// Precondition: anArray is an array of num

// integers; 1 <= num <= MAX_ARRAY, where

// MAX_ARRAY is a global constant that specifies

// the maximum size of anArray.

// Postcondition: anArray[0] <= anArray[1] <= ...

// <= anArray[num-1], num is unchanged.


  • Assertion: A statement about a particular condition at a certain point in an algorithm

    • Preconditions and postconditions are examples of assertions

  • Invariant: A condition that is always true at a certain point in an algorithm

  • Loop invariant: A condition that is true before and after each execution of an algorithm’s loop

    • Can be used to detect errors before coding is started


  • Loop invariant (continued)

    • The invariant for a correct loop is true:

      • Initially, after any initialization steps, but before the loop begins execution

      • Before every iteration of the loop

      • After every iteration of the loop

      • After the loop terminates

Principles of oo programming
Principles of OO Programming

  • Encapsulation: data and methods combined in one object

    • Also called information hiding

  • Inheritance: Objects can inherit properties from other object

  • Polymorphism: Some object properties are determined at run time.