Why do we need this course?

Why engineer software?Can’t we just hack at it, until we get

something that works?Many people/companies do this

anyway…Answer: can’t hack it if we care about

qualityIf a system is not put together in a well-

organized manner, the chance for bugs is greater

Another answer: You can’t just hack together a 106 LOC system

Complex systems are impossible to build in an ad-hoc manner

Introduction: software quality

Software is often buggyIn critical applications, bugs can lead

to drastic consequencesTherac-25 malfunctions killed or severely

injured several people in 1985-87Ariane 5 launcher crash on 4/6/1996Airbus problemsBanking software failuresMany more

The main reason for bugs is enormous complexity of software

Need techniques to cope with this complexity

Quality Issues

Software is now an integral part of every facet of our societal infrastructure

Air traffic controlTelecommunicationFinancial infrastructure

Poor quality software menaces the maintenance of that infrastructure

Software is the "Grand Enabler" holding the key to scientific and engineering challenges

Human genome projectSpace explorationWeather prediction

Why isn’t software quality up to snuff?

deliver prototypes"leave it to the marketplace"unsophisticated consumers

don't know what they wanttolerate high failure rates

"the computer is down"misled by "coverups" in banking, finance,

communicationslack of understanding of risks

Year 2000 (Y2K)

Software is everywhere

from Phillips:TV can have 600Kbytes of codeVCR has 265KbytesCell phone has 512KbytesCar radio has 64-256Kbytes

What is software?

CodeVarious design documentsUser manualsDevelopment plans, timelines, and

budgetsMaintenance documentsThe way of producing software

(process)

Desirable qualities of software systems

ReliabilityPerforms the required functions correctlyThe rate of failures is low

MaintainabilityUnderstandabilityChangeabilitySimplicity

ReusabilityThe solution to a problem should be as

general as possibleUser friendlinessEfficiency

Some interesting numbers

About 25% of s/w projects failFailure rate increases as the size of the

project increasesCosts about $100/LOC

Ranges between $10-$600Typical programmer produces about 30

LOCs a dayRanges between 10-100 LOCs

25 faults/KLOCRanges between 3-100 faults/KLOC

Software costs

Development costsgenerally measured in hundreds to

thousands of dollars per delivered LOCmany artifacts associated with a line of

codetesting and analysis is usually 50% of this

costMaintenance costs

2-3 times as much as development

Software Costs

code

reqts and design

testing

15%35%

50%

Development costs

Full lifecycle costs

maintenance

testing

code

reqts/design

Models

Software code is too complex to reason about it directly

Need a higher level representation, called design

Captures only the most important relevant characteristics of the problem

Needs to capture the behavior of the problem accurately

Software code must conform to its design

Software Engineering

Name coined at the NATO Science Committee Conference, October 1968

Engineering-- established, scientifically sound practices that well trained practitioners follow

Software Engineering-- the application of scientific knowledge to the the development and maintenance of software systems

Software-- ALL associated artifacts to assist with the development, operation, validation, and maintenance of programs/software systems

e.g., code, documentation, designs, requirements, user manuals, installation manuals, test cases, test results, bug reports, revision history, make files,...

The nature of software

Software is a complex, intricately interconnected data aggregate

Software Development is the process of creating such a complex product, while continuously assuring that it remains consistent

Software Engineering combines some of the approaches of classical engineering with some of the abstract approaches of mathematics

A software product is a complex web of intertwined software objects, connected by a multitude of diverse relations and constraintssome types of objects:

source codedesignstestcasesdocumentation

some types of relationships:is invoked byis derived fromis consistent withis a version of

Trends in Software Expansion (Bernstein, 1997)

ExpansionFactor

The ratioof machine

lines ofcode to asource lineof code

1

10

100

1000

1960 1965 1970 1975 1980 1985 1990 20001995

Order of Magnitude Increase Every Twenty Years

MachineInstructions

MacroAssembler

High LevelLanguage

DatabaseManager

On-line

RegressionTesting

Prototyping

4GL

SubsecondTime

Sharing

SmallScaleReuse

Object Oriented

Programming

Large ScaleReuse

142113

8175

4737.5

30

15

3

475638

Projection

What is novel about software, compared to other fields of engineering?product is unprecedentedly complexapplication horizons expand too fast--

with human demands/imaginationconstruction is human-intensive solutions require unusual rigor extremely malleable--can modify the

product all too easily

How to increase Software Quality

Treat software as a PRODUCT produced in a systematic way by a PROCESS designed and implemented to achieve explicit quality objectives

Build quality in Define software product formallyDefine software process formallyReason about the product and process

formallyIncorporate validation as integral steps in

the process

Software Lifecyclerequirements

design specs

coding

testing

maintenance

reqts. analysis

validation

validation

revalidation

adequacy

Waterfall Model

requirements-- a complete,consistent specification of what is needed

provides visibility for customers, developers, and managers

benchmark for testing and acceptancereduces misunderstandings

requirements analysisevaluate completeness and consistencyevaluate needs and constraintsevaluate feasibility and costs

development and maintenance costsProbability of success

Waterfall Model (continued)

design specifications--a description of how the requirements are to be realized

high-level architectural designlow-level detailed design

design validationtraceability between requirements and

design decisionsinternal consistency

Waterfall Model (continued)

code--realization of the design in executable instructions

code validation assure coding and documentation

standards have been maintainedinternal consistency

e.g., syntactic analysis, semantic analysis, type checking, interface consistency

consistency between design/requirements and code

Waterfall Model (continued)

testing--reveal problems, demonstrate behavior, assess reliability, evaluate non-functional requirements (e.g., performance, ease of use)

unit testingintegration testingsystem testingacceptance testingregression testing

testing validationadequacy of the testcases

Waterfall Model (continued)

maintenance--the process of modifying existing software while leaving its primary functionality intact

corrective maintenance-- fix problems (20%) adaptive maintenance-- add new functionality/enhance

existing features (30%) perfective maintenance-- improve product (50%)

e.g., performance, maintainability

3 primary steps understand existing software change existing software revalidate existing software

maintenance involves all the previous phases of the lifecycle

Is the waterfall model an appropriate process model? recognizes distinct activities clearly oversimplifies the process

wait, wait, wait, surprise model

actual processes are more complex numerous iterations among phases not purely top down decomposition into subsystems

many variations of the waterfall model prototyping re-engineering risk reduction ...

Barriers to engineering software

Industry’s short term focusShortage of skilled personnelInadequate investment in R&DPoor technology transfer modelsInsufficient standards

Industry’s short term focus

"bottom line orientation"emphasis on time to market

not life cyclereturn on investment

startups cannot invest in R&D until product established in marketplace

without the R&D, takes too long for next or improved product

market strategy driven by investors who want impressive short term gains

Industry’s short term focus

software housesintensely competitiveoften don't use own technologykeep development cost down, fix later

unsophisticated industrieslack of technical expertiselack of administrative experience

overselling the technology

Barriers to engineering software

industry’s short term focus shortage of skilled personnelinadequate investment in R&D

PITAC (Kennedy-Joy) ReportUS SW GNP is $228B but less than 1%

spent on R&DPoor technology transfer models

tend to "toss over the fence"Lack of standards

What do we need?

Scientific basisOrganized disciplineR&D strategyTrained professionalsTechnology transfer strategiesQuality control

Certification and Licensing?

Currently, software engineering is not one of the 36 engineering professions recognized and licensed in the United States.

48 states prohibit using the term "engineer" without a license

Texas has forced universities to stop MSSE Tennessee prohibits the use of "software

engineering" in business literature and advertising New Jersey considered, but did not pass, a

regulation that would have required licensing of all SW professionals

IEEE/CS & ACM established Commission on Software Engineering in 1993

High-level Goals of Software Engineeringimprove productivity

reduce resourcese.g., time, cost, personnel

improve predictabilityimprove maintainabilityimprove quality

Basic OO terms: object and class

Objectrepresents anything that can be distinctly

identifiedhas a unique identity

what does it represent?Has a unique state

what is it doing?Has a set of possible behaviors

what are all possible things it can be doing?

Classrepresents a set of objects with similar

characteristics and behaviorin other words, the type of an object

Class notation

UMLClass Name

field 1…field n

method 1…method n

Example: class Tree

UML Java

Class Tree { private float height_; private int noOfBranches_; private Classification species_;

public void die() { … } public void germinate() { … } public void grow(Date untilDate) { … } public void shedLeaves() { … }}

Interaction among objects

An OO program is a collection of communicating objects

This communication happens via message passing

To send a message to object b, object a has to call a method of b

b.<method name>(<parameter 1>…<parameter k>);

Modules

A module is a part of an applicationA module captures some well-defined

functionalityModules can be defined hierarchically

A module can contain a number of lower-level modules

A module consists of entitiesFunctionsAlgorithmsObjectsLower-level modules

A module can be a class

Important OO principles: cohesion and couplingCohesion refers to how well the

entities of a class fit togetherHigh cohesion, good

entities are highly relatedLow cohesion, bad

entities are not highly relatedCoupling refers to the amount of

dependency among the modulesHigh coupling, bad

the amount of information that one module should reveal to another is excessive

Low coupling, good

Important OO principles: abstraction and encapsulationAbstraction in terms of a module

represents the amount of information that the users of this module need to be able to use it

The smaller this amount of information, the better

Encapsulation is the principle of not making “internal” information visible to the users

Also known as information hidingEncapsulation improves abstraction

Internal changes can be made without affecting the way that users use this module

Important OO principles: interface

Interface to a module is the amount of information that this module makes visible

Abstraction can be characterized as complexity of the interface

Interface represents a contract between the module and its users

the module: “Here are all the services that I can provide to you”

UML notationModule Interface Module

Important OO principles: inheritance

The idea is to define a relationship where class A is more general than class B

B inherits from AB is a subclass of AA is a superclass of BB is a kind of A

Example:

Inheritance (cont.)

Multiple levels of inheritance are possible

Subclasses inherit attributes and methods of their superclasses

Important OO principles: polymorphism

A related but different kinds of functionality can be implemented by several different modules

If the interfaces to all these modules are the same, they can be used in exactly the same way

In the program, a module being used can be changed dynamically, as long as the interface remains the same

Important OO concepts: aggregation

Aggregation is a relationship where one class is a part of another

Important OO concepts: association

Association is a general relationship among two classes

Class diagram for a game of dice

Modeling dynamic behaviors: state and sequence diagramsStatic behavior represents

relationships among classesClass diagrams

inheritanceaggregationassociation

Dynamic behavior represents interactions among objects

State diagramsSequence diagrams

State diagrams

Represent all possible behaviors of an object

Consist of states and transitionsAt any moment of time, an object is in some state

Doing somethingHaving certain qualities

A transition represents the object moving from one state to another

Transitions are triggered by eventsMay have guards and side-effects

Has a start stateMay have a final state

States can be composite, called hyperstates

State diagram example: Game class

Sequence diagrams

Illustrate interaction of several objects

Annotations

Annotations, or comments, may be added to any part of any UML diagram

Notation:

This class serves as avery general type ofa car. You have toinstantiate one of its

children

Car