Chapter 1 t t t Software Engineering and

  • Slides: 50
Download presentation
Chapter 1 t t t Software Engineering and Computer Programming Course presentations are available

Chapter 1 t t t Software Engineering and Computer Programming Course presentations are available for view and downloading on the course web page: http: //www. d. umn. edu/~jallert

Goals t t The goal of CS is the discovery of fundamental principles underlying

Goals t t The goal of CS is the discovery of fundamental principles underlying computer programming Software Engineering is about the construction of software systems “pure” versus “applied” science They also have many common interests

Computer Science t t t Dates from the 1940’s Study of algorithms Algorithm implementation

Computer Science t t t Dates from the 1940’s Study of algorithms Algorithm implementation Tied to mathematics Tries to discover principles underlying hardware and software

Software Engineering t t t Dates from late 1960’s Develop models of systems Major

Software Engineering t t t Dates from late 1960’s Develop models of systems Major concerns are – efficiency – reliability t Applies CS principles to construct better systems

Basic processes for all CS professionals t t t Theory Abstraction Design

Basic processes for all CS professionals t t t Theory Abstraction Design

Theory t t t Definitions, axioms, theorems, proofs Interpretation of results Example: Analysis of

Theory t t t Definitions, axioms, theorems, proofs Interpretation of results Example: Analysis of algorithm efficiency

Abstraction t Developing models of the world – isolate the essential features of a

Abstraction t Developing models of the world – isolate the essential features of a problem – example: flipping a coin • does not need to know denomination, metal, picture • simulates only one of two random outcomes t Test problem approaches

Design t t t Requirements Specifications Program design Program implementation Testing Analysis

Design t t t Requirements Specifications Program design Program implementation Testing Analysis

The concerns of the computer scientist and the software engineer Computer scientist Abstraction Theory

The concerns of the computer scientist and the software engineer Computer scientist Abstraction Theory Data structures The Design Software engineer

Data Structures and ADT’s

Data Structures and ADT’s

Data structure t t Definition: A ‘data structure’ consists of – A base storage

Data structure t t Definition: A ‘data structure’ consists of – A base storage method • (i. e. an array) – One or more algorithms that are used to access or modify that data

Program example t t Here is a program demonstrating a dice data structure. This

Program example t t Here is a program demonstrating a dice data structure. This first example is a procedural approach to the problem.

t t t t // Code Example 1 -1: // dice program that does

t t t t // Code Example 1 -1: // dice program that does not use an // abstract data type (adt) // // Compare this approach to cx 1 -2. cpp. #include "dslib. h" // standard header files for text #include <stdlib. h>

t t t t int main() { int die 1, die 2, total; randomize();

t t t t int main() { int die 1, die 2, total; randomize(); // pseudorandom number generator die 1 = random(6) + 1; // random(6) returns random number // between 0 and 5 die 2 = random(6) + 1; total = die 1 + die 2; cout << "first die: " << die 1; cout << “ second die: " << die 2; cout << endl; cout << "total for roll is: ”; cout << total << endl; return 0; }

Data structures dilemma t Possible dice data structures – two integers, each between 1

Data structures dilemma t Possible dice data structures – two integers, each between 1 and 6 – simple to implement, simple operations t Deck of cards data structure – more difficult, especially operations t Air traffic control system – very difficult – needs a model – high level of “software engineering”

Abstract Data Type (ADT) t t Gives us a tool to use to control

Abstract Data Type (ADT) t t Gives us a tool to use to control complexity Definition: a collection of data and operations – Data characteristics • DOES NOT include method of representation – Operations • DOES NOT include how implemented

Definition of ADT t An Abstract Data Type (ADT) is – a well-specified collection

Definition of ADT t An Abstract Data Type (ADT) is – a well-specified collection of data • known as the characteristics, or data state – and a group of operations that can be performed upon the data • known as behaviors or operations – member functions (C++) – methods (Java)

About ADTs t The ADT’s specification describes – what data can be stored •

About ADTs t The ADT’s specification describes – what data can be stored • (the characteristics of the ADT), – and how it can be used • (the operations), – but not how it is implemented or represented in the program.

Decoupling t t t ADTs do not specify how the data structure will be

Decoupling t t t ADTs do not specify how the data structure will be implemented There may be many ways The data specification has been decoupled from the implementation. This means that software development can be less complex (fewer details to consider) Also, software development is more flexible (the actual structure is not fixed)

Dice ADT t Characteristics (data state): • Represents a pair of 6 -sided dice,

Dice ADT t Characteristics (data state): • Represents a pair of 6 -sided dice, that can be rolled to get a random sum between 2 and 12. t Operations: – int roll() • Precondition: none. • Task: A random value between 1 and 6 is stored for each of the dice. • Returns: The sum of the two dice values, lying between 2 and 12.

Dice ADT operations (con’t) – int die 1() • Precondition: The dice have been

Dice ADT operations (con’t) – int die 1() • Precondition: The dice have been rolled at least once. • Postcondition: None. • Returns: The value of the first die. – int die 2() • Precondition: The dice have been rolled at least once. • Postcondition: None. • Returns: The value of the second die.

A program using a Dice ADT t t t // // // Illustrates solution

A program using a Dice ADT t t t // // // Illustrates solution to a "dice simulation", using abstract data types. Dice ADT Characteristics: Represents a pair of 6 -sided dice, that can be rolled to get a random sum between 2 and 12.

Dice ADT operations comments t t t t // // Operations: int roll() Preconditions:

Dice ADT operations comments t t t t // // Operations: int roll() Preconditions: none Postcondition: random value from 1 -6 is stored for each of the dice. Returns: sum of the two dice values, lying between 2 and 12

die 1() and die 2() operations t t t t t // int die

die 1() and die 2() operations t t t t t // int die 1() // Precondition: dice have been rolled // at least once. // Postcondition: None // Returns: The value of the first die. // int die 2() // Precondition: dice have been rolled // at least once. // Postcondition: None // Returns: The value of the second die.

Dice ADT program t t t t t // // // Note on encapsulation:

Dice ADT program t t t t t // // // Note on encapsulation: The representation of the dice is contained within global variables - we'll see shortly a better way to do this. #include <iostream. h> #include <stdlib. h> #include "dslib. h" int dice_1, dice_2;

Roll() t t t t t int roll() {// note -- you don't really

Roll() t t t t t int roll() {// note -- you don't really want to call // randomize every time you roll the dice, // but for this simplified design you // don’t have much choice. randomize(); dice_1 = random(6) + 1; dice_2 = random(6) + 1; return dice_1 + dice_2; }

die 1() and die 2() t t t t t int die 1() {

die 1() and die 2() t t t t t int die 1() { return dice_1; } int die 2() { return dice_2; } // end of Dice ADT

Client Code (the main program) t t t int main() // test program to

Client Code (the main program) t t t int main() // test program to demonstrate Dice ADT { cout << "The value rolled is: ”; cout << roll() << endl; cout << "The first die was: ”; cout << die 1() << endl; cout << "The second die was: ”; cout << die 2() << endl; return 0; }

Exercise 1 -4, p. 9 t t t Some games for young children use

Exercise 1 -4, p. 9 t t t Some games for young children use colored squares on a board and a spinner that, in effect, picks one of the colors at random. Suppose that the game has five colors - red, green, blue, yellow and orange. Design a spinner ADT. Do not write any code, just the ADT.

Spinner problem t What is the data state (characteristics) of this ADT? – enumerated

Spinner problem t What is the data state (characteristics) of this ADT? – enumerated type: colors – spinner - of type colors t What are the operations – spin (randomly chooses a color)

Spin() operation t Precondition: – none t Postcondition: – none t Returns: – the

Spin() operation t Precondition: – none t Postcondition: – none t Returns: – the value of the spinner

The Software Life Cycle

The Software Life Cycle

The waterfall model of software development t t t Initiation Analysis Design Implementation Testing

The waterfall model of software development t t t Initiation Analysis Design Implementation Testing Maintenance

Initiation t t Feasibility study Examination of alternatives Cost-benefit analysis Make-or-buy study

Initiation t t Feasibility study Examination of alternatives Cost-benefit analysis Make-or-buy study

Analysis t t t Determines the exact requirements of the system Systems analyst (liaison

Analysis t t t Determines the exact requirements of the system Systems analyst (liaison between domain experts and software engineers) Domain experts know the goals and purposes of the software Software engineers will build the system Analyst creates functional specifications document

Functional specifications t t Specifies exact functions the system must provide Specifies special requirements

Functional specifications t t Specifies exact functions the system must provide Specifies special requirements – minimum performance limits t Legal requirements which must be met

Design t t Uses functional specifications as a blueprint Systems architect Deliverable is a

Design t t Uses functional specifications as a blueprint Systems architect Deliverable is a technical, or coding specification This is the most critical step in the process – bad design may be impossible to implement – difficult to maintain (i. e. Y 2 K)

Implementation t t t Writing the code Must meet coding specifications Develop system and

Implementation t t t Writing the code Must meet coding specifications Develop system and user documentation

Testing t Must start with a test plan – sample input: expected output –

Testing t Must start with a test plan – sample input: expected output – compares observed to expected t t May use separate staff Final line of defense against unreliable software

Maintenance t Latent errors – Only become apparent after testing is finished t Adaptive

Maintenance t Latent errors – Only become apparent after testing is finished t Adaptive maintenance – Changes to fit new environments – new OS, hardware, software t Enhancements – improved functionality – often for least experienced programmers

The waterfall model of software development Initiation Analysis Design Implementation Testing Maintenance

The waterfall model of software development Initiation Analysis Design Implementation Testing Maintenance

The waterfall model: A summary of the players and the deliverables

The waterfall model: A summary of the players and the deliverables

Critiques of waterfall method t t t Expensive Slow Unrealistic No emphasis on prototypes

Critiques of waterfall method t t t Expensive Slow Unrealistic No emphasis on prototypes No connection with end users

Prototyping t t Often built with 4 GL to provide GUI May only be

Prototyping t t Often built with 4 GL to provide GUI May only be a shell – no functionality t Implementation – Direct – Parallel – Phased – Pilot

Reusability t t Programmers often “reinvent the wheel” No equivalent of “interchangeable parts” Software

Reusability t t Programmers often “reinvent the wheel” No equivalent of “interchangeable parts” Software often not reusable in other apps OOP addresses these concerns – inheritance t New design techniques: design patterns – provide a library of recurring designs – example: STL in C++ – we will not use the STL in this class

Documentation t t How much? On what? What form? Three levels of documenters –

Documentation t t How much? On what? What form? Three levels of documenters – Technical writers – System documentation • Software engineers/programmers • Internal and external – Client documentation

Internal documentation t Precondition – The assumed state of the data structures t Postcondition

Internal documentation t Precondition – The assumed state of the data structures t Postcondition – The effects on the data structures – What the function has done t Returns – The value(s) returned

Why C++? t t t Easy data abstraction OOP More features than C

Why C++? t t t Easy data abstraction OOP More features than C

Evolution t ADT concept – Specification and implementation of a data structure aren’t the

Evolution t ADT concept – Specification and implementation of a data structure aren’t the same – But they are related and should be kept together – Pascal, C and other procedural languages do not allow this. – Languages like Modula-2 and ADA allow you to make ‘modules’ containing both

Evolution (continued) t t t C++ supports the module concept by allowing you define

Evolution (continued) t t t C++ supports the module concept by allowing you define classes and instantiate them as objects Objects may be created that inherit characteristics from other objects You can use an object without knowing how it is implemented – Exact implementation may take many forms (polymorphism)