alyce brady, kalamazoo college software engineering friday, week 4

Alyce Brady, Kalamazoo College

Software Engineering

Friday, Week 4


Evolution of Software Engineering

• Single-person projects:

“Back of the envelope” design followed by coding, debugging

• Multiple-person projects:

More formal design, identify modules, code modules, group debugging of whole project


Engineering =

cost-effective solutions

to practical problems

by applying scientific knowledge

in building things

in service of mankind

Science

Production Engineering

Commercial

Craft

Mary Shaw, Carnegie Mellon University



• Improved quality:

– formal design (e.g., structured or object-oriented design)– identify modules– develop a test plan based on the design– code modules– develop test plan of individual module based on code– test modules in isolation– test integrated whole


Why Are All These Steps Necessary?

Writing a program is much easier than

writing a programming system, which is much easier than

writing a programming system product which is• documented thoroughly• usable in many environments• robust in its operations

F. Brooks estimated that each is at least 3 times more expensive than the previous.


Why Software Engineering?

Barry Boehm has estimated that specification errors repaired in later stages of software development can cost as much as

100 times

more to fix than if caught at specification time.



Software Lifecycle

– Requirements Analysis– System Specification– Design– Implementation (programming)– Unit Testing– Integration Testing

– Maintenance (fixing problems, adding enhancements)


Waterfall Lifecycle

Requirements

System Spec.

Design

Code, Unit Test

Integration Test


“Over-the-Wall” Lifecycle

Implementation Unit Testing Integration

Requirements System Spec. Design


Modified Waterfall Lifecycle

Requirements

System Spec.

Design

Code, Unit Test

Integration Test


Whirlpool Lifecycle

Req. Sys.Spec.

Design

CodeUnit Test

Integration


Levels of Abstraction

– Requirements Analysis– System Specification

– Design

– Implementation (programming)


Types of Testing

• “Black box” testing– based on Requirements Analysis, System Specification– test plan developed before design; run as part of

integration testing

• “Gray box” testing– based on Detailed Design– test plan developed before implementation; run as part

of integration testing (some may be part of unit testing)

• “White box” testing– based on Implementation (code)– unit testing


Levels of Abstraction

– Requirements Analysis– System Specification

– Design

– Implementation (programming)– Unit Testing

– Integration Testing

– Maintenance (fixing problems, adding enhancements)


Object Oriented Programming

• Based on modeling from the real world.

• It’s a way of thinking about a problem abstractly using real-world concepts, rather than computer concepts.

• JavaScript is object-based but not completely object-oriented.


Object-Oriented

• Organize software as a collection of discrete objects that have both behavior and information.

• Objects then interact with each other to perform their tasks.

• Objects have values (or information) and operations (or behaviors).


Object-Oriented

• The object values could be name or size.

• The object operations could be changing or displaying the values.

• The values and operations are grouped together to make a class.


Object-oriented Example

• Class: Car• Attributes (or values)

– Color– Make– Model

• Operations:– TurnRight– TurnLeft– Accelerate– Brake– Repair

• Object - Mike’s car is a new blue, Mazda 626 Car.

• Mike’s car then has values of color (blue), a make (Mazda), a model (626).

• Mike’s car then can do operations like TurnLeft, Accelerate, Brake and TurnRight.


In Class Exercise

• Design a class that describes a fish.

– What attributes would a fish have?

– What operations could a fish do?

• Create a new fish with attributes of its own and design a short series of actions the fish might do.

alyce brady, kalamazoo college software engineering friday, week 4

Documents