Supporting Component and Architecture Re-usage by Detection of Integration Faults

1. Supporting Component and Architecture Re-usage by Detection of Integration Faults Nurhak Karakaya 2007702532 CMPE 516

2. Abstract The usage of pre-developed components in a new application simplifes your job. But using these components may couse erros in the new application. Integrating those application to your system may couse local and global inconsistencies at run time. The articale will try to develop a machanism to support the avoidance, the automatic detection and tolerance of erros that can be occur when you integrate pre-developed classes to your system.

3. 1.Introduction The integration of a software system to a new system has some benefits: • The clarify of resulting architecture by building block abstraction • The reliability of resulting system by re-usage of proven components. • The reduction of development costs by re-usage of predeveloped components. But the re-usage may cause serious problems: • The integration process may involve critical faults which may cause inconsistencies. • One of the reason for these faults: the existing components does not reflect new application due to insufficient information. • A detailed information about the existing component must be available for avoidance of faults.

4. 1.Introduction Cnt. Descriptions: • Component: a software unit providing given services at its interface • The request of a such a service assumes a certain number of input parameters and maybe an output parameter. Context Sensitive Failures: • The economic attractiveness of reusing predeveloped components led to designing new applications. • But even the integration of proven-in-use components may cause serious errors. • If a component is re-used under wrong assumptions differing from the application context, the component might not provide some needed properties.

5. 1.Introduction Cnt. In the paper: • Some inconsistencies occurred during component integration are presented and classified. • For each identified class, the inconsistency is illustrated by real world examples. • The inconsistency class is analyzed for the purpose of effective problem handling by an appropriate fault detection or tolerance strategy.

6. 2. Inconsistency Classes Integration of inconsistencies may be classified with respect to: • Syntax at component interface level • Semantic at component interface level • Application-specific properties at system level • Pragmatic properties of system environment • The first one, syntactical inconsistencies: mistakes between data imported and data exported can be overcome by use of an interface language. • The other inconsistencies will be described.

7. 2. Inconsistency Classes Cnt. Semantic Inconsistincies • Semantic inconsistencies may occur, if data with different semantic is exchanged between components. • In other words, syntatically correct data may be interprated in different ways. • This class can be futher subdivided with regard to interpration: • Linguistic inconsistincy: the logical meaning of a symbol in a given lenguage • Numerical inconsistincy: the numerical meaning of a symbol • Referance system inconsistincy: the physical meaning of a symbol Lenguage Inconsistincy occur if syntatically correct lenguage contructs allow different semantic interprations. For example, old FORTRAN allowing the space in variable names. “DO 100 I=1.1” interprates as variable.

8. 2. Inconsistency Classes Cnt. Numerical Inconsistencies • Occur whenever different representations are used by usage of dots and commas for decimal number representation systems. • Usage of identical prefixes to denote different numerical meaning in decimal and data storage matrix system. Example, “Mega” meaning: 1.000.000 or 1.048.578 Physical Inconsistencies • Occur whenever the value of a parameter is taken by different components to refer to different physical referenences with respect to physical units, country codes, time zones. • For example, a data is impoted in Britsh force unit (pound force) but a different componet imported same data inNewton unit.

9. 2. Inconsistency Classes Cnt. Application Based Inconsistencies: • Pre-developed components may be re-used such that their local functionalities do not reflect the new global application context. • This occur if the global application constraints are not fulfilled by component for the reasons: • Violation of state/input relations. • This occur whenever mandatory relations between component parameters and component internal states are not fulfilled. • Example, Dutch Chemical Planet explodes duo to typing error, usage of values indicating chemicals whose mixture reacted in an undesired fusion. • Data range inconsistencies. • This occur whenever value range required by the application are not fulfilled the data that is given by the component. • Example, Ariane 4 exploded because horizontal speed 16 bit data. If 64 bits are used the explosion would not occur.

10. 2. Inconsistency Classes Cnt. Pragmatic Inconsistencies: • Concerns • Concurrny constraints • Access policies to external resorces • Timing requirements dictated by hardware and user interface constraints • Global pragmatic constraints may occur: • Violation of absolute time constraints • Occurs whenever absolute timing restrictions on requests to a component are not fulfilled. • Such restrictions may concern the execution time of the operation or the time between two succesive request. • Example, Patriot Missile system fauilure

11. 2. Inconsistency Classes Cnt. • Violation of concurrency constraints • Occurs whenever relative timing restrictions on component execution are not fulfilled. • Example, race conditions and transactional failures in database systems. • Violation of architectural constraints • Occurs whenever components were developed to operate in different architectural environments. • Example, a component may be designed for message-driven system , while other is designed for client-server environment.

12. 3. Integration Fault Tolerance • For each inconsistency class, fault-handling offers varying degrees of fault handling. • A first differentiation concerns detectibility. Some inconsistencies are detected statically at integration time. But others are only detectadle at runtime. • A second discriminator is the degree of tolerance allowed. Static Detectable Inconsistencies • Abortion of the integration process • Architectural requirements are not met by some components. • Parameter values exceed the range a component can process • Extended description language allows detection of inconsistency at integration time • The integration process may be interrupted

13. 3. Integration Fault Tolerance Cnt. Dynamic fault handling by conversion Mechanism • Deviating interpations of data shared between components are staticly detectable by comparing type attributes at integration • In the case of mismatch of type attributes, appropriate conversion routines arre added to the component. • For inconsistences that are not detectable during integation, detection may be occur at run time Dynamic fault handling by delaying mechanism • Violations of concurrency constraints may not be statically detectable and therefore require dynamic runtime. • To do this: • Each call to a service is checked in terms of current message sequences forbiding its processing

14. 3. Integration Fault Tolerance Cnt. • To do this cnt: • If required, the forbidden call is temporally stored and forwarded to the component when allowed by the application context. • In case of too short service execution time, the return of a result may be appropriately delayed. Dynamic Error Logging • Violation of absolute timing requirements also may not be detectable statically, but requires execution time measurements at runtime • In case upper limit time or time between subsequent call exceeds the situation must be reported. • The same must be applied when relation between service parameters and component states are not fulfilled.

15. 4. Re-usable Componenets The approach suggested in this article supports re-usability in two levels • At local component level, • by allowing to detect and to tolerate local inconsistencies • Depending of the application, a suitable subset of components can be selected and subjected to purpose specific adaptation • At global architectural level, • By allowing to handle separately the application-specific constraints • The seperation of appliction-specific constraints from component structure allows siligtly different application senarios. For example, similar application differs in terms of safety requirements.

16. 5. Conclusion • The notation and safeguarding of application-specific consistency constraints enable the re-usage of components. • When using a pre-developed component in an architecture, typical inconsistencies may occur but there are detection and tolerance approaches for that inconsistencies.

17. 5. Questions Thank you for listening