Maximizing Software Reliability: The Importance of Programming Languages

1. Ada Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Way, Box U-255 Storrs, CT 06269-3255 Steven.Demurjian@uconn.edu http://www.engr.uconn.edu/~steve (860) 486–4818 (Office) (860) 486-3719 (CSE Office)

2. Ada Compilers • Ada IDE • http://adagide.martincarlisle.com/ • https://sourceforge.net/projects/adagide/ • Other Links • http://sandbox.mc.edu/~bennet/ada/examples/ • http://cs.fit.edu/~ryan/ada/programs/ • https://rosettacode.org/wiki/Category:Ada

3. Multiple Presentations • An Introduction to Ada – • http://www.engr.uconn.edu/~steve/Cse4102/cse4102Ada.pdf • Contains: https://cs.nyu.edu/courses/fall02/G22.2110-001/adaintro.ppt • Ada– Overview and rationale – Part 1 • http://www.slideshare.net/AdaCore/ada-2012 • An Introduction to Ada • https://cs.nyu.edu/courses/fall02/G22.2110-001/adaintro.ppt • Ada 2012 – Part 2 • http://www.slideshare.net/AdaCore/ada-2012 • Ada Programming Language • http://ece.ut.ac.ir/Classpages/F86/ECE460/slides/Maclennan-chap7-Ada.ppt

4. Quentin Ochem Technical Account Manager Ada and Ada 2012 – Overview and rationale http://www.slideshare.net/AdaCore/ada-2012

5. Why Programming Languages Matter?

6. Presentation Scope • In High-Reliable Software, the choice is usually being made between • C • C++ • Java • Ada • What are the criteria for this choice? • What are the implications of this choice?

7. Human Resources Criteria • There are more people that know C++ than Ada • There are more people that know C than C++ • There are more people trained in Java than C or C++ • So from a HR point of view, the choice is obviously…

8. Human Resources Criteria Visual Basic

9. Is Programmers’ Language Skill an Issue? • Main software paradigms are key • Object orientation • Pointers • Stack • Exceptions • … • Applying these skills to any programming language should be easy for any developer

10. Show-Stopper Criteria • Is the language supported by the industry? • Does the language have perspectives for long term development? • Is the language properly supported by tools? • Does the language generate efficient code? • Is the language supported on the target architectures? • Can the language support generic programming paradigms? All four languages, C, C++, Java and Ada fulfill these requirements

11. Other Criteria of Interest • What direction does the evolution of the language take? • What are the primary markets using this language? • Is the language defined by a public or private entity? • Can the language support the full development cycle (specification/code/verification)? • Can the language help in the writing more reliable code? • Can the language help in the writing more maintainable code?

12. Goal: Reducing Costs (Finding Errors and Inconsistencies Earlier)

13. Goal: Finding Errors and Inconsistencies Earlier

14. Easing the Reaching Higher Levels of Reliability Developer Responsibility ToolResponsibility Language Responsibility

15. How do we get there?

16. The One-Line-Of-Code Hell • Is “tab” null? • Is “tab” an array? • Is i within the boundaries of “tab”? • Has “tab” been initialized? • Is “tab” expecting floats or integers? • If it’s float, is this a float or a integer division? Can’t tell. Can’t tell. Can’t tell. Can’t tell. Can’t tell. Can’t tell.

17. The One-Line-Of-Code Hell • Is “tab” null? • Is “tab” an array? • Is i within the boundaries of “tab”? • Has “tab” been initialized? • Is “tab” expecting floats or integers? • If it’s float, is this a float or a integer division? No, tab is an array. Yes, otherwise can’t access the indices. Checked at run-time. Can’t tell. If float, compiler runtime. If needed, explicit conversion.

18. Driving Design Principles • Be explicit as much as possible • Put as much (formal) information as possible in the code • Put as much (formal) information as possible in the specification • Avoid pointers as much as possible • Avoid shortcuts • Avoid ambiguous constructs as much as possible • Make dubious constructs possible but visible

19. Driving Rationale • Ada eases manual and automatic analysis at various levels: • Developer review • Peer review • Compiler errors and warnings • Static analysis tools • Proof tools • Maintenance • Simplify code and readability when dealing with high-level programming concepts

20. StrongTyping • A type is a semantic entity, independent from its implementation • Strong typing forbids implicit conversions • Values are checked at run-time (can be deactivated)

21. Strong typing (continued) • Enumerations have a dedicated semantic

22. Arrays • Arrayscanbeindexed by anydiscrete types (integers, enumeration) • First and Last index can be specified at declaration time • Buffer overflows are checkedatrun-time • There is an arrayliteral (aggregate)

23. Array Copy, Slicing and Sliding • Arrays provide a high-level copy sematic • Arrays provide a high level slicing/sliding sematic

24. Parameter Modes • Threeparameter modes : in (input), out (output) and in-out (input/output) • The correct parameter usage isdoneat compile-time • The compiler decides if it has to bepassed by reference or copy • This is a case of explicit pointer avoidance

25. Pre, Post Conditions and Invariants • Generalized contracts are available through pre- and post-conditions • New type invariants will ensure properties of an object • Subtypepredicates

26. Package Architecture • All entities are subject to encapsulation • Not only OOP constructions • Specification and Implementation details are separated from the package, addresses any kind of semantic entity

27. Privacy • A package contains well identified public and private parts • The user can concentrate on only one part of the file

28. Private Types • A private type canbeimplemented by any data structure • User code does not rely on the actualrepresentation

29. Data Representation • Allows to optimizememory usage • Allows to preciselymap data

30. Genericity • Instanciation has to be explicit

31. Object Orientation • Ada implements full OOP principles • Encapsulation • Inheritance • Dispatching • Safe OOP paradigm is implemented • A unique concrete inheritance tree • Multiple interface inheritance • “Overriding” methods can be checked • OOP can be comfortably used without (explicit) pointers

32. Object Orientation Example

33. If pointers are needed… • Pointers are typed, associated with accessibility checks • Objects that can be pointed are explicitly identified • In the absence of de-allocation, pointers are guaranteed to never dangle • Pointers’ constraints can be specified • Is null value expected? • Is the pointer constant? • Is the object pointed by the pointer constant? Tmp := Local_Int’Unchecked_Access;

34. Concurrent Programing • Threads and semaphore are first class citizens

35. Why is all of this of any use? • For readability • Specification contains formally expressed properties on the code • For testability • Constraints on subprograms & code can lead to dynamic checks enabled during testing • For static analysis • The compiler checks the consistency of the properties • Static analysis tools (CodePeer) uses these properties as part of its analysis • For formal proof • Formal proof technologies can formally prove certain properties of the code (High-Lite project)

36. Yes But… • It is possible to reach similar levels of safety with othertechnologies (MISRA-C, RT-Java) • … but safety features have to be re-invented • Requires additional guidelines • Requires additional tools • Limited by the original language features • Examples of “circle fits in a square” features • Types management in MISRA-C • Stack emulation in RT-Java • When long term reliability is a goal, using the correct paradigm to start with will reach higher levels at lower cost

37. An Introduction to Ada Programming Languages Fall 2002 https://cs.nyu.edu/courses/fall02/G22.2110-001/adaintro.ppt

38. Basic Structure of a Program • A program is a collection of units • Packages • Functions • Procedures • Bound together to form a program • Typically a unit is stored in a file • Units reference other units

39. Procedure • procedure H (M : Integer) isdeclarationsbeginstatementsreturn;end H; • Typical use is procedure Main is … which defines the main program

40. Function • function Max (A : Integer; B : Integer)return Integeris Result : Integer;beginif A > B then Result := A;else Result := B;end if;return Result;end Max;

41. Packages • Packages define a related collection of types, and subprograms (procedure and functions) • A package provides a set of services to a client • A package may be a client of another package

42. Integer Type Declarations • Type Integer is built in • But you don’t want to use it • Because its range is implementation defined • Because it is defined to match the machine not your problem • Because it does not take advantage of strong typing to prevent errors

43. Defining Integer Types • Define type according to use • type Day_In_Year is range 1 .. 366;type Age is range 0 .. 130;type Temperature is range -20 .. +180; • Now we can define variables of the type • Today_Day : Day_In_Year;Employee_Age : Age;Machine_Room_Temp : Temperature;

44. Why Define Integer Types • No dependence on implementation • Unlike type int in C • Range of types matches problem • Get an error or warning at compile time • Age := 200; • Or an exception at runtime • Age := Age + 1000;

45. Strong Typing • Cannot mix integer types: • Current_Temp : Temperature;Current_Pressure : Pressure; • Current_Temp := Current_Pressure + 1; • Error, cannot assign pressure to temperature • Current_Temp := Current_Temp + Current_Pressure • Error, cannot add temperature to pressure

46. Integer Subtypes • A subtype creates a limited range • But is still the same type • subtype OK_Operating_Range is Temperature range 70 .. 80;Room_Temp : Temperature;Machine_Room_Temp : OK_Operating_Range…Machine_Room_Temp := Room_Temp; • Raises exception if Room_Temp out of range

47. Catching Exceptions • You can catch an exception at run time • begin … Machine_Room_Temp := Room_Temp …exceptionwhen Constraint_Error =>recovery stuffend;

48. Unsigned (Modular) Types • Modular types have wrap around: • type M is mod 7; -- values are 0,1,2,3,4,5,6q : m := 6; -- initialization…q := q + 2; -- result is 1 • Most common use, conventional unsigned • type Uns_32 is mod 2 ** 32; • Remember that twos complement arithmetic is equivalent to arithmetic mod 2**wordsize

49. Real Types • Float types (control relative accuracy) • type My_Float isdigits 7;type Xfloat is digits 7 range 1.0 .. 10.0;subtype F1 is My_Float range 1.0 .. 5.0; • Digits is decimal digits of relative precision • There is a formal model for fpt in Ada • Target independent (parametrized) • Guarantees minimal accuracy • Operations defined in terms of model numbers • Results fall in defined model interval

50. Fixed-Point Types • Fixed-point types are real types where you control the absolute accuracy. • Typically implemented as scaled integers • type Velocity is delta 0.125 range 0.0 .. 10.0; • Decimal fixed-point types • Decimal small • Typical use in financial programming • type Money is digits 10delta 0.01 range 0.00 .. 999_999_999.00;