why do we need this course?
DESCRIPTION
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 quality If a system is not put together in a well-organized manner, the chance for bugs is greater - PowerPoint PPT PresentationTRANSCRIPT
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