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

Nurhak Karakaya 2007702532 CMPE 516

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

5. Questions

Thank you for listening