A Formal Object-Oriented Analysis for Software Reliability: Design for Verification

1. A Formal Object-Oriented Analysis for SoftwareReliability: Design for Verification BY OKAY ASLAN 2006703558 CMPE 516 FAULT TOLERANT COMPUTING

2. INTRODUCTION • Problem • Software systems used for control of modern devices are typicallyboth complex and concurrent. • Object-Oriented (OO) development methods areincreasingly employed to cope with the complexity of these software systems. • OO developmentsystems still largely depend on conventional testing to validate correctnessof system behaviors. Not adequate to attain the needed reliability,for complex systems.

3. INTRODUCTION • Model checking • Formally verifies that a given system satisfies a desired behavioral property throughexhaustive search of ALL states reachable by the system • Widely and successfully applied to verification of hardware systems.

4. INTRODUCTION • Model checking on Software • Much less successful • Softwaresystems must be translated fromprogramming or specification languages to representations to which model checkingcan be applied • It must have a tractablestate space if model checking is to be successful. By conventional development processes, however, it is resulted invery large interconnected state spaces

5. INTRODUCTION • Target: Applying model checking on Software and increase system reliability • Developmentof OO software systems that when translated to representations to which modelchecking can be applied, yield manageable state spaces. • Design rules are thecritical initial step in the methodology for integration of formal verification by modelchecking into OO development processes

6. INTRODUCTION • 4 steps to obtain reliable system • Re-implement the control subsystem as an executable specification in the formof an Object-Oriented Analysis (OOA) model (in the Shlaer-Mellor(SM) methodology) • Validate this executable specification as thoroughly as possible by testing • Apply model checking to the OOA model to validate its behavior at all possiblestates of the system • Generate the control software by compilation of the validated and verified OOAmodel.

7. INTRODUCTION • OOA Models • Represents the program at a higher level of abstraction than a conventional programminglanguage • Partitions the system into well-defined classes to attempt to apply model checking to these apparently highly modular OOA models ledto intractably large state spaces

8. INTRODUCTION • Spatial Modularity • In hardware, the “calling” moduleand “called” module are separated spatially and communicate through a clean interfaceand a specified protocol. • Supports divide-and-conqueranalytical techniques, as each module can be analyzed in isolation • Essential forsuccessful model-checking because it resolves a fundamental problem of the state spaceexplosion

9. INTRODUCTION • Spatial Modularityfor software systems • It is the strong form of name spacemodularity where the name spaces modules are strictly disjoint and all interactionsamong modules are across specified interfaces and follow specified protocols • A set of design rules are introduced, which constrain the syntactic structureof OOA models to match “spatial modularity”

10. Integration of Model Checking with OO Development The OOA-based methodology for the spatial development of software systems

11. Integration of Model Checking with OO Development • Fulfills the requirements: • modeling, design analysis, formal verification, and automated code generation

12. Integration of Model Checking with OO Development • xUML Notation: • The action language (a standart language adopted by Object Management Group) and SM OOA semantics represented in UML notation define anexecutable subset of UML (xUML).

13. Integration of Model Checking with OO Development • Static structure diagrams: • capture conceptualentities as classes with semantics defined by attributes

14. Integration of Model Checking with OO Development • Object information diagrams(OID) • Describes the classes and relationships that hold between the classes. • Graphically represents a design architecture for an application domain

15. Integration of Model Checking with OO Development • Subsystem relationship diagrams • positions the application domain in relation to its scope, limits, relationships withother domains and main actors involved (scenarios)

16. Integration of Model Checking with OO Development • The collaboration diagram • For graphical representation of the signals sent from one class to another. • Provides a summary of asynchronous communication between state/event modelsin the system.

17. Integration of Model Checking with OO Development • The state transition diagram • graphically represents a state machine. • consists of nodes, representing statesand their associated actions to be performed, and event arcs, which represent transitionsbetween states.

18. Integration of Model Checking with OO Development • The execution of an action occurs after receiving the signal or event. • A transition table is a list of signals, and ”the next” states that are their result. • Signalshave an arbitrary identifier, a target class, and associated data elements

19. Integration of Model Checking with OO Development • COSPAN • An Automaton-based Model Checking Tool • Allowssymbolic analysis of the design model for user-defined behavioral properties. • Each suchtest of task performance constitutes a mathematical proof (or disproof), derived throughthe symbolic analysis (not through execution or simulation).

20. DESIGN FOR VERIFICATION • An xUML OOA is a natural representation to which to apply model-based verificationtechniques. • The complexity level of the executable OOA models is far less than theprocedural language programs to which they are translated. • OOA techniques provides finitestate representation

21. DESIGN FOR VERIFICATION • OOA Methodology Features: • Abstraction of implementation details • Relationships between objects at the OOAlevel are represented as associations and not as pointers. OOA constructs such as signalsin UML express state transitions without reference to the internal states of objects. • Separate specification of class models and behavior models separates specification ofdata from control.

22. DESIGN FOR VERIFICATION • OOA Methodology Features: • Hierarchical system representation • Supports modular designs andencourage software developers to decompose a system into subsystems, derive interfacesthat summarize the behavior of each system, and then perform analysis, validationand verification, using interfaces in place of the details of the subsystems.

23. DESIGN FOR VERIFICATION • OOA Methodology Features: • Structural design rules • A set of design rules was developed to conform to “spatial modularity”.

24. DESIGN FOR VERIFICATION • Structural design rules 1-Write access to attributes of one class by another class must bemade through the event mechanism. • The attributes of a class should be local to the class. Change of values of a class instanceshould be performed only through the event mechanism. This prevents couplingof internal states of classes.

25. DESIGN FOR VERIFICATION • Structural design rules 2-Attribute values which are shared by multiple classes should bedefined in separate class and accessed only through the event mechanism. • This design rule also avoids coupling of internal states of classes.

26. DESIGN FOR VERIFICATION • Structural design rules 3-Declaration and definition of functional entities must be performedwithin the same component • A component may have dependencies on other components. To prevent the situationwhen functionality of one component can be changed by other components any logicalconstruct that a component declares should be defined entirely within that component

27. DESIGN FOR VERIFICATION • Structural design rules 4-Declaration and definition of functional entities must be performedwithin the same component Inheritance must be confined to extensions of supertypes. • Modificationof the behavior of supertypes (overriding of supertype methods) is prohibited

28. vEEF THE ROBOT CONTROLLER STUDY • Re-engineering the control subsystem for a NASArobotics software system. • The goal of the project was to increase the subsystem’s reliability. • This goal was achieved, as serious logical design errors were discovered, throughthe application of model-checking

29. THE ROBOT CONTROLLER STUDY • A robotic software used for control of redundant robots is examined • An essential feature for a redundant robot is that an infinite number ofrobot’s joints displacements can lead to a definite wrist (end-effector) position

30. THE ROBOT CONTROLLER STUDY • Domain Analysis and Modeling • Classes • In addition to tangible objects (Arm, Joint, EndEffector, PerformanceCriterion),incident objects (TrialConfiguration, SearchSpace, SimpleSearchSpace, FactorialSearchSpace),specification objects (Fused Criterion), and role objects (DecisionTree, OSCAR Interface, Checker) were derived

31. THE ROBOT CONTROLLER STUDY • Domain Analysis and Modeling • Attributes • Example attributes: EE ID is a key attribute whose value uniquely distinguishes each instance of an EEobject. Current position and Limit are descriptive attributes that provide facts intrinsicto the EE object

32. THE ROBOT CONTROLLER STUDY • Domain Analysis and Modeling • Associations • binary (those in which objects of two different types participate) and higher-order(Arm-Joint relationship) • supertype-subtype (those when several objects have certain attributes in common whichare placed in the supertype object)(PerformanceCriterion-ConstraintCriterion)

33. THE ROBOT CONTROLLER STUDY • Domain Analysis and Modeling • Robotic Decision-Support Domain Architecture • computational subsystems :includes kinematics algorithms and interfaces to thecomputational libraries of the OSCAR system • optimization subsystems: implements the decision-making strategy by applyingdecision-making techniques

34. THE ROBOT CONTROLLER STUDY • Compliance to the design rules 1-Write access to attributes of one class by another class must bemade through the event mechanism. • All updates of the attribute values were donethrough the event mechanism

35. THE ROBOT CONTROLLER STUDY • Compliance to the design rules 2-Attribute values which are shared by multiple classes should bedefined in separate class and accessed only through the event mechanism • After the design system was completed and validated by simulation, a separateobject Global that contained all the global variables as its attributes was createdand used during verification and code generation.

36. THE ROBOT CONTROLLER STUDY • Compliance to the design rules 3-Declaration and definition of functional entities must be performedwithin the same component • Designis restricted to insure that all functional components are fullyself-contained.

37. THE ROBOT CONTROLLER STUDY • Compliance to the design rules 4-Declaration and definition of functional entities must be performedwithin the same component Inheritance must be confined to extensions of supertypes • inheritance is restricted to a purely syntactic role: code reuse and sharing,and module importation

38. THE ROBOT CONTROLLER STUDY • OOA Model Validation and Formal Verification • The OOA model was validated by simulation. • Several serious error or defects in theoriginal design and in the original versions of the OOA model were identified and corrected.

39. THE ROBOT CONTROLLER STUDY • OOA Model Validation and Formal Verification • One failure indicates in some cases the system does not terminate its executionas specified • One failure indicates that an error in the fault resolution algorithmrecomputes the joint angles of other jointswhile not resolving the fault situation. • One failure indicates that there is a problemof coordination between the Arm and Checker processes.

40. CONCLUSION • Feasibility demonstration for the application of verification by modelchecking • Verification of significant behavioral properties of the robot controlsubsystem were carried out. • Design rules leading to xUML OOA models to whichverification by model checking can be practically applied have been proposed and applied.

41. REFERENCES • A Formal Object-Oriented Analysis for SoftwareReliability: Design for Verification- Natasha Sharygina , James C. Browne , and Robert P. Kurshan - ISBN:3-540-41863-6 (2001)

42. THANK YOU FOR LISTENING