Developing Software That Matters I

Developing Software that Matters

Franco Gasperoni
gasperon@act-europe.fr
http://libre.act-europe.fr/Software_Matters

© ACT Europe under the GNU Free Documentation License

Course Home page

►http://libre.act-europe.fr/Software_Matters
• All the course slides are there (PDF and PowerPoint)

http://libre.act-europe.fr 2

Copyright Notice

► © ACT Europe under the GNU Free Documentation License

► Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
License, Version 1.1 or any later version published by the Free
Software Foundation; provided its original author is mentioned and
the link to http://libre.act-europe.fr/ is kept at the bottom of every
non-title slide. A copy of the license is included in available at:

http://www.fsf.org/licenses/fdl.html


Course Objectives
► Help you build software
systems that are more:
• Dependable
• Adaptable
• Fun to develop

► Comparing ways to
structure software
► Show problems & pitfalls in
• Functionality-oriented
C-derived languages
• C, C++, Java • Object-oriented
• Structural problems
with both approaches

► Show how Ada 95 addresses these issues
• Engineering principles we can take from
Ada and apply in other languages

Interesting Links
► http://www.fsf.org
• The site of the GNU project and the Free Software Foundation
► http://libre.act-europe.fr
• Interesting Free Software projects written in Ada 95
► http://www.adahome.com/Tutorials/Lovelace/lovelace.htm
• Lovelace, on line Ada 95 tutorial
► http://archive.adaic.com/docs/reports/cada/cada_art.html
• Comparing Development Costs of C and Ada
► http://www.eiffel.com/
• The official site of the Eiffel programming language
► http://www.misra.org.uk/misra-c.htm
• Guidelines for the Use of the C Language in Vehicle Based Software
► http://www.elj.com/cppcv3/
• A critique of C++
► http://www.cs.mdx.ac.uk/harold/srf/javaspae.html
• A critique of Java
► http://www.web-hits.org/txt/codingunmaintainable.html
• How to write unmaintainable code

Interesting Books

► Programming in Ada 95, by John Barnes (Addison Wesley)
► High Integrity Ada: The SPARK Approach, by John Barnes (Addison Wesley)
► Object-Oriented Software Construction, by Bertrand Meyer (Prentice Hall)
► Objects Unencapsulated: Java, Eiffel, and C++, by Ian Joyner (Prentice Hall)
► Extreme Programming Explained, by Kent Beck (Addison Wesley)
► C Traps and Pitfalls, by Andrew Koenig (Addison Wesley)
► Effective C++, by Scott Myers (Addison Wesley)
► Java Pitfalls, by Michael C. Daconta et al., (Wiley)


Course Assumptions

► You are interested in the field of software development

► You have written computer programs in at least one
imperative languages
• E.g. Ada, C, C++, Eiffel, Fortran, Java, Pascal, …

► Have a basic knowledge of C
• … for the section on problems & pitfalls in C-related languages


Background on
Software Construction Processes


Your Software Development Experience

► What is the largest software system that you have built?

► How did you build it?
• What process?
• What programming language?
• What tools?
• Did you use version control tools?

► How long will the software be used for?
• Who will fix, change, or adapt the software that you wrote?


Software Development Phases
Requirements
What needs to be done

Testing
Check that the code does what
Analysis
it is supposed to (functionality,
performance, reliability, …) How it should be done
Project Management
Devise a plan, manage
resources, costs, time, …

Design
Coding
Create a software structure
Fill in the software (architecture) around which
structure with code code will be built


Software Processes

► A Software Process is
• A set of activities (e.g. requirements, analysis, design, coding, testing)
combined and sequenced in a particular fashion to produce software

► Recent trend: Agile Software Development
• Customer needs evolve with time
• Satisfying customers at delivery time (rather than at project initiation)
is more important than conforming to initial customer requirements


Example of Software Processes

Waterfall Iterative eXtreme Programming (XP)
Requirements

Requirements
Analysis

Testing
Coding
Design
Requirements Analysis

Design

Requirements
Analysis

Testing
Coding
Design
Coding

Analysis Testing

Requirements
Requirements

Analysis

Testing
Coding
Design
Time
Analysis
Design Design

Requirements
Analysis

Testing
Coding
Design
Coding
Testing

Requirements
Coding Requirements

Analysis

Testing
Coding
Design
Analysis

Design

Requirements
Analysis

Testing
Coding
Design
Testing Coding
Testing

Scope (customer needs)


Software Phases Related to this Course

Testing
performance, reliability, …)

Design
Coding


Software Dependability



Degree of user confidence
that the system will operate as expected
and it will not fail in normal use


The Blue Screen of Death (BSOD)


More BSOD Embarrassments


Does Software Dependability Matter?

► Certainly at the marketing level ☺
• No vendor would say its software is undependable
• No team would say it produces undependable software

► In practice there is plenty of software you cannot depend on

► Not all software needs to be dependable

► Useful but not very dependable software can be OK
• If this machine crashes while doing this presentation I will reboot
• If your word processor crashes while you write an important
document there is no harm if you save your document frequently


► Dependability = Usability
/
• E.g. word processor

Dimensions of
Dependability

Availability Reliability Safety Security

Ability of the system Ability of the system Ability of the system Ability of the system
to deliver service to deliver correct to operate without to protect itself
when requested results catastrophic failure against intrusions

Can be measured with defect rates Expressed in terms of integrity levels

Warning about Defect Rates

Is a defect rate of 99.9% acceptable? It depends…

► 1 document/year lost while word-processing
► 1 document/year lost while word-processing
•• Great ☺
Great ☺
► 2 accidents/month at the International Airport in London
► 2 accidents/month at the International Airport in London
••
► 22,000 checks/hour drawn from the wrong account in the US
► 22,000 checks/hour drawn from the wrong account in the US
••

Analyze software defect rates in the context of the application


Software Failures: Availability

► Denial-of-service attacks
• Example: attack against GRC.com
- Attacked by 195 Windows 2000 servers running insecure versions of
Microsoft's IIS web server. IIS was the apparent point of hacker entry
into the system.


Software Failures: Reliability
► January 15, 1990: 9 hour nation-wide telecom shutdown
• 1 month earlier ATT updated its software in 114 switching stations
• Cause: 1 misplaced “break” statement in a C program
► January 2001: 230,000 units new Internet-enabled mobile phone recalled
• Users reported that their phones were freezing after accessing certain Web sites,
and when they were powered back on, all stored information (addresses, e-mails,
bookmarks, memos) had been lost
► Matracom 6500 PABX (telephone switch)
• Random phone messages are garbled
• Long phone calls are cut
► Windows 95/98/ME/2000
• September 1997: propulsion system of the USS Yorktown ship failed
- Cause: Windows NT 4.0 crashed
• An amusing story: Installed an HP scanner on a SONY VAIO with Windows 2000.
Now machine cannot enter suspend mode and when it tries the screen disappears
until powered-off (with loss of work )

Software Failures: Safety

► 1986: Therac 25 radiation machine kills several patients
• Cause: poor testing of the software

► June 4, 1996: 1st flight of Ariane 5 aborted: Ariane 5 destroyed
• Cause: Code from Ariane 4 guidance system was reused in Ariane 5
but not tested.

► 2000: Deadly accident in French highway
• Cause: Software malfunction in car braking system. Car manufacturer
acknowledges responsibility.


Software Failures: Security

► November 2, 1988 Internet Worm
• A self-replicating program was released upon the Internet
• This program (a worm) invaded VAX and Sun computers running
versions of Berkeley UNIX, and used their resources to attack still
more computers.
• Within the space of hours this program had spread across the U.S.,
infecting thousands of computers and making many of them unusable
due to the burden of its activity.
• Cause: undetected buffer overflow in C routine gets()

► Many interesting virus stories especially on Windows


… And 30% of Software Projects
Don’t Even Get to That Stage

► US Internal Revenue Service Modernization
• $4 Billion, dropped in early 1997

► FBI Fingerprint system
• $500 million, dropped

► Bell Atlantic 411
• Nov 1996, outage, backed out of upgrade


Software & Safety Criticality

► Business-critical
• Software failure may result in the business
shutting down
• E.g. Bank trading system

► Mission-critical
• Software failure may result in mission failure
• E.g. Pathfinder on Mars

► Safety-critical
• Software failure may result in injury, loss of life or
major environmental damage
• E.g. Plane


Safety Critical Levels

Several standards

► RTCA/EUROCAE DO-178B
• The international avionics standard for safety critical software
► IEC 880
• Standard for software in nuclear power stations
► IEC61508 / DEF STAN 00-55/56
• European safety standards
► Development Guidelines for Vehicle Based Software
• Safety standard promoted by the Motor Industry Software Reliability
Association (MISRA)
►…

DO-178B Software Criticality Levels
Criticality Level Consequences of Software Failing
Catastrophic
(Level A products tell the cockpit crew where they are and
Level A
keep them from flying into the ground, e.g. flight control
systems, air data systems, some displays. )
Hazardous/Severe-Major
Level B
(Level B systems: traffic alert & collision avoidance)

Major
Level C
(Level C systems: communication & data link management)
Minor
Level D
(Level D system: pilot override of the entertainment system)
No Effect
Level E
(Level E system: entertainment system)

IEC61508
Safety-Complexity-Integrity Levels (SCIL)

SCIL Level Consequences of Software Failing
Death of one or more persons, significant financial loss
(Areas: flight-critical aerospace, life-critical medical
SCIL 4
systems, transport control systems, hazardous process
control systems, automotive breaking systems)
Serious injury or financial loss
SCIL 3
(Areas: automotive engine management)

Inconvenience or disappointment to the public
SCIL 2
(Areas: small consumer goods, point of sale equipmt.)

No inconvenience
SCIL 1
(Areas: student project, research)


MISRA Integrity Levels

Integrity Controllability by Acceptable
Examples of Software Failure
Level vehicle occupants Failure Rate

Extremely
4 Uncontrollable Loss of power assisted steering
improbable

3 Difficult to control Very remote Braking system failure

2 Debilitating Remote Windshield wiping system failure

1 Distracting Unlikely Electrical window system failure

Reasonably
0 Nuisance Only Radio/CD system failing
possible


Software Security Levels

► TCSEC (Orange Book)
• Trusted Computer Security Evaluation Criteria

► Common Criteria For Information Technology Security
Evaluation (ISO/IEC 15408-1)
• Evaluation criteria for IT security
• 7 security levels


Evaluation Assurance Levels (EALs)

EAL Constraints on the Software Developed
EAL7 Formally Verified Design & Tested

EAL6 Semi formally Verified Design & Tested

EAL5 Semi formally Designed & Tested

EAL4 Methodically Designed, Tested & Reviewed

EAL3 Methodically tested and checked

EAL2 Structurally tested

EAL1 Functionally tested


Software Evolution


Software Needs to Evolve

► Bug Fixes

► Port to new architectures
• Software lasts for a long time
- E.g. Y2K problem
• Most useful software outlives the hardware it was designed to run on
- E.g. VAX/VMS
• When new hardware becomes available it’s cheaper to port existing
applications than rewrite everything from scratch
- E.g. Intel IA-64

► Enhancements & new features
• E.g. Dos, Windows 3.1, Windows 95/98/ME, Windows NT/2000/XP


Software Investment Costs in 2001

► Typical software productivity is:
• Between 2 and 20 lines of working code (LOC) per programmer per day

► Average cost of a programmer per day (loaded with all costs):
• Between 150 and 500 USD/day

► Average cost to write a line of code (LOC)
• Between 10 and 50 USD

► Cost to develop a 100,000 LOC application
• Typically between 1 M USD to 5 M USD


Software Evolution is a Must
► You cannot just throw away software and redo it
• Cost is one thing
• But time-to-market is usually even more important

► Your software might not need to be very dependable, but…

► … it must be capable to evolve
• In a timely fashion
• At a reasonable cost

► Examples
• The GNU Ada/C/C++ compiler is approx 1 M LOC
• Emacs editor is approx 1.4 M LOC
• GNU/Linux is approx 4 M LOC


Software Trend

New software is increasingly developed
by extending and modifying existing systems


Summary

Depending on your application domain

► Some or all of the software dependability parameters are
probably important
• availability, reliability, safety, security

► … but in almost all cases

software evolution is fundamental


Programming Languages


The Construction Analogy*

Building Construction Software Construction
Class1

Architectural Analysis & design documents
drawings (e.g. UML diagrams) «uses»
Class2 Class3

•Programming languages
Materials •Libraries
•Reusable components
Development tools:
Tools •Editor, compiler, debugger
•Config. mgmt, testing tools,…

*Analogy from Tucker Taft invited talk at the Tools USA 99 conference
http://www.tools-conferences.com/usa_99/keynotes.html#taft


Software Phases Affected by the P.L.

Testing (Unit Testing)
performance, reliability, …)

Design
Coding


Importance of Tools’ & Materials’ Quality

Building Construction Software Construction

Imagine nailing wooden panels where Imagine programming with a language
nails bent if you do not hit them which accepts everything that you
perfectly in their axis type and tries to guess what to do

Imagine building a wall where 1 in ever
Imagine using a graphics library where
4 bricks breaks when you place it on
1 in 4 routines has a bug
the wall

Imagine working with a compiler that
Imagine using a hammer whose head
crashes every 3 compilations or that
flies off if you do not hit the nails
generates executables that run very
perfectly
slowly


The Programming Language Matters

► A “good” programming language helps you build software
that is:
• Reliable
• Safe
• Secure
• Evolvable

A good programming language will make your life easier.
It will NOT do the job for you.


► A “poor” programming language will make it harder to build
software that is:
• Reliable
• Safe
• Secure
• Evolvable

It is possible to write good software with a poor language.
It will require more experienced engineers.
In any event it will take longer and will be more COSTLY
than with a good language.


Facts of Life in Software Construction

Human Factors Properties of a Good
Affecting Programming Programming language

► Make it harder to write incorrect code
► Humans make mistakes

► Support abstraction
► People move on
• The code authors are not the ► Help write readable code
ones that will fix bugs, port or add
new features to the software
► Support modular software organization

► Software evolves constantly ► Portable


Why?
Requirement for a Good
Explanation
Programming Language
Make it harder to write Humans make mistakes. Especially programmers who are
incorrect code constantly submersed with work.
Humans make mistakes & People move on. Be able to write a
Support abstraction program at a conceptual level close to the application domain.
This makes the code easier to write & understand.
People move on. Especially programmers. To preserve your
Help write readable
software investment other people must be able to understand
code
the code quickly.
Software evolves constantly. You must deliver software to your
Support modular clients before it is actually finished (important to have
software organization feedback). Furthermore, once delivered you have to correct
bugs, and add new features.

Portable Software evolves constantly. You must port it to new hardware.


A Programming Example

► Can you tell in less than 20 seconds whether the following 3
routines in the following 3 programming languages do the
following correctly:

► Return the n-bit field of a 32 bit word from
• Bit position p
• To bit position p-n+1
► Bit position 0 is at the right end
n bits

Bit Bit Bit Bit
……… ………… ………
31 p p-n+1 0


Pentium Assembly Language
_getbits:
pushl %ebp
movl %esp,%ebp
pushl %ebx
movl 16(%ebp),%ebx
movl 12(%ebp),%eax
subl %ebx,%eax
incl %eax
movl 8(%ebp),%edx
movl %eax,%ecx
shrl %cl,%edx
movl $-1,%eax
movl %ebx,%ecx
sall %cl,%eax
movl -4(%ebp),%ebx
notl %eax
movl %ebp,%esp
andl %edx,%eax
popl %ebp
ret

C
unsigned get_bits (unsigned x, int p, int n) {
return (x >> (p-n+1)) & ~(~0 << n);
}


Ada 95
function Get_Bits (X : Bit_Array; P : Bit; N : Offset) return Bit_Array is
begin
return X (P – N + 1 .. P);
end Get_Bits;


History of Some Imperative Languages
1950 1960 1970 1980 1990 2000

PL/I(66) Eiffel (86)
Ada(95)

Ada(83)
Cobol(58)
ASSEMBLY

Pascal(70)
Java(96)
Algol(60)
C(72) C++(89)

Fortran(54)
Simula(67) Smalltalk(80)

imperative
Basic(66)


1970 1980 1990 2000 2005

Ada(0X)
Ada(95)

Ada(83)

Pascal(70)
Eiffel (86) ???
Java(96)

ISO C++(98)
C++(89)

C(72) ANSI C(88) ISO C(99)


Programming Language Design Goals

►C
• A portable, higher-level assembly language
• No reliability, safety, and security concerns

► C++
• An object-oriented language upwardly compatible with C
• No reliability, safety, and security concerns

► Java
• Fix C++ insecurity problems (i.e. cannot create a virus in Java)
• No reliability, and safety concerns


SECURE != RELIABLE
SECURE != SAFE

► Java is a secure language
• That is you cannot create viruses with Java programs

► Java (like C and C++) is NOT a reliable or safe language
• It is easy for a programmer to make mistakes in Java both during
regular development and during software evolution
- and create programs that behave incorrectly

► Sun Microsystems does not want Java to be used in safety-
critical contexts


Contents of the Windows 2000 License
NOTE ON JAVA SUPPORT

THE SOFTWARE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS
WRITTEN IN JAVA.

JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED,
MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ON-LINE CONTROL
EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE
PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT
NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE
SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA
TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR
SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE.

Sun Microsystems, Inc. has contractually obligated Microsoft to make this disclaimer.


Ada
► Industrial-strength version of Pascal designed to build:
1. Reliable, safe, and secure software
2. Software that needs to evolve
3. Systems where software matters (e.g. real-time systems)
4. Mixed-language software

► Language designed by an international team
• 1983: First version of the language
- Object- based language, not object oriented
• 1995: First standard revised (e.g. OO programming added)
- First object-oriented language to be an ISO standard

► Only language to have a formal compiler validation procedure
• Validation procedure is an ISO standard (> 4,000 compiler tests)

Ada: Use it for Safety-Related Systems

► Safety standards recommend the use of Ada for the highest
integrity levels

► Even the MISRA-C document recommends the use of Ada:
Guidelines for the Use of the C Language in Vehicle Based Software
• “… it should be recognized that there are other languages available
which are in general better suited to safety-related systems, having
(for example) fewer insecurities and better type checking. Examples
of Languages generally recognized to be more suitable than C are
Ada and Modula 2. If such languages could be available for a
proposed system then their use should be seriously considered in
preference to C.” page 3.


Ada-Inspired Programming Features

► C++
• Templates (Generics)
• Exceptions

► Java
• Array index checking
• Division by zero checks


Some Languages Derived from Ada

► SPARK
• Subset of Ada used to design the most safety-critical systems

► VHDL
• Used for chip design

► PL SQL
• New programming language designed to extend SQL and make it a
full programming language


Some Industrial Applications in Ada
► Business-critical
• Canal+ Technologies: Pay-per-view, access control
• BNP: Trading Language
• Philips: Semiconductor assembly equipment
• Helsinki radiotelescope

► Mission-critical
• Astree: European-wide railroad signaling
• Weirton Steel - process controller
• Mondex electronic money
• Scanning Electron microscope

► Safety-critical
• Airbus A340
• Boeing 777

Ada and Software Costs (1995 Study)

1800
1600
1000s of 1994 Dollars

Ada 270,000 LOC
1400
Other HOLs
1200 C 225,000 LOC

1000 135,000 LOC

800 150,000 LOC

600 112,500 LOC

400
75,000 LOC
200
0
350 700 1,050 1,400 1,750 2,100
Function Points

Source: MITRE (Avionics domain)

Ziegler’s Study: Comparing C & Ada
► 1995 study on the VADS compiler
• 60 engineers, from 1984 ..1994 with MS degrees in computer science
• All knew C at hire. All programmed in both C and Ada.
► VADS
• About 4.5 million lines of code, 22000 files, cost >$28m over 10 years
2500000

2000000

1500000
All Lines

1000000

500000

0
C Code Ada Code Make Scripts Miscellany

Costs Per Feature During Implementation

cost/feature:

$350

$300

$250

$200

$150

$100

$50

$0
C C, including Makefiles ADA


Post-Delivery (User-Reported) Defects

1200

1000

800

C
600
Ad a

400

200

0
Critic a l D e fe c ts S e ve re De fe c ts Mino r d e fe c ts T o ta l De fe c ts


Summary

► Developing software in Ada is 60% cheaper than in C
► Code developed in Ada has 9 times less bugs than in C

► Was Ada consistently better? *YES*
• Over different subsets of VADS
• For experienced AND inexperienced programmers
• For both C experts AND Ada experts
• For the highest AND lowest rated programmers
► Was Ada harder to learn? *No*
► Was Ada code more reliable? *YES*

See http://archive.adaic.com/docs/reports/cada/cada_art.html


Some Non-Reasons for Ada’s Advantage

► Not because of people:
• The same people used both languages
► Not because of process:
• The same process was used, for design, for testing, for debugging,
for source control, for management, and so forth
• C required ‘makefiles’, but had tighter coding standards
► Not because of Ada’s highest level constructs:
• VADS used few generics or tasks
► Not because of reuse:
• This study considers only unique code, factoring out reuse


Some Reasons for Ada’s Advantage

► Ada Enabled Better Error Locality
• Most errors caught at compile-time
• Runtime errors are easier to trace
► Ada Enabled Better Tool Support
• Ada’s richer semantic model allows computers to help more
• For example, builds are automated and guaranteed consistent
► Ada Reduced Effective Complexity
• Function of language complexity and application complexity
• Standard language complexity is easier to learn and use
► Ada Encouraged Better Program Organization
• Packages, with specifications and private parts


From an Education Perspective

► Ada is a good language to teach good software practice
• Reliability, safety, security

► Ada 95 allows to design functionality-oriented as well as
object-oriented software
• Ada allows the construction of software that can evolve

► Today there is a Free Software high-quality Ada 95 compiler
available to all
• GNAT (GNU Ada)
• Linux, Solaris, Windows, …


You Should Know Several Languages

► No single programming language is appropriate in every
circumstance

► Today most systems use a mixture of programming languages


Example: MULTOS CA

► Multiple application OS for smart cards

► 30%: SPARK (Ada subset)
• “Security kernel” of tamper- proof software
• Certified at the HIGHEST security level
► 30%: Ada 95 Infrastructure
• (concurrency, inter- task and inter- process communications,
database interfaces etc.), bindings to ODBC and Win32
► 30%: C++
• GUI (Microsoft Foundation Classes)
► 5%: C
• Device drivers, cryptographic algorithms
► 5%: SQL Database stored procedures

Developing Software That Matters I

Recommended

Recommended

More Related Content

Similar to Developing Software That Matters I

Similar to Developing Software That Matters I (20)

More from Gneuromante canalada.org

More from Gneuromante canalada.org (10)

Recently uploaded

Recently uploaded (20)

Developing Software That Matters I