Monitoring software components and component-based software

Gao, Jerry; Zhu, Enguo; Shim, Simon; Chang, Lee

doi:10.1109/cmpsac.2000.884757

Cited by 22 publications

(14 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…If an output event o can be generated but not as a response for any input event (empty input, in an active component), we represent this as ξ → o. Figure 1 presents an example of an initial input and output event sequence (trace) for a component (1) and some, but not all, possible interpretations for the causalities between input and output events (2,3,4,5). In this example, in order to calculate the number of all possible different interpretations, we need to consider the possible input trigger events for each output event (based on the temporal sequence of the events):…”

Section: The Causality Relation (Cause and Effect)mentioning

confidence: 99%

“…With no source code available, it is hard to instrument the component and, consequently, to monitor its internal dynamic behavior [3]. For black-box components, the dynamic behavior can be reasoned only by its "externally visible" behavior through the interface usage, i.e.…”

Section: Motivationmentioning

confidence: 99%

“…Event-based COTS components bring more difficulty for the checking task [3]. With no source code available, it is hard to instrument the component and, consequently, to monitor its internal dynamic behavior [3].…”

Section: Motivationmentioning

confidence: 99%

See 2 more Smart Citations

Identifying cause and effect relations between events in concurrent event-based components

Dias¹,

Richardson²

2002

Proceedings 17th IEEE International Conference on Automated Software Engineering,

View full text Add to dashboard Cite

Concurrent event-based components present characteristics that impose difficulties in understanding their dynamic behavior, mainly for interpreting the cause & effect relations between input and output events in component interactions. In this paper, we propose a technique to help in the process of understanding the dynamic behavior of concurrent event-based components. It checks the event trace (generated by monitoring the component execution) against a specification of the component communication protocol (even with a possibly incomplete or incorrect specification). The technique identifies and presents the more probable cause & effect relations between the component events, providing also a measurement related to this probability.

show abstract

Section: The Causality Relation (Cause and Effect)mentioning

confidence: 99%

Section: Motivationmentioning

confidence: 99%

See 1 more Smart Citation

Identifying cause and effect relations between events in concurrent event-based components

Dias¹,

Richardson²

2002

Proceedings 17th IEEE International Conference on Automated Software Engineering,

View full text Add to dashboard Cite

show abstract

“…Aspects may be used to trace the program execution and identify points, in which aspects implementing new functionalities may be applied. Aspects oriented approach were used in program tracing [5,6,7,8] but the goal of tracing was different than in our approach. In [9] an example of adding new functionalities by aspects can be found.…”

Section: Introductionmentioning

confidence: 99%

Aspects in the Maintenance of Compiled Programs

Bluemke

Billewicz

2008

2008 Third International Conference on Dependability of Computer Systems DepCoS-RELCOMEX

View full text Add to dashboard Cite

We propose a new approach to the maintenance of programs with unavailable source code and documentation i.e. aspects oriented programming [2,3,4]. Aspects are used to trace the program execution and identify points, in which aspects implementing new functionalities may be applied. A special tool [1,10] for aspect oriented program tracing was designed and implemented. This tool is necessary to use the proposed approach. A modification of GIU interface of a compiled program without source code and documentation is presented. Advantages and disadvantages of described concepts are pointed out.

show abstract

“…Zum einen kann diese Schnittstelle von anderen Tools genutzt werden. So werden in[18,19] zwei Tools mit dem Namen test agent und tracking agent beschrieben, die zusammen eine Testumgebung für Testable-Beans bilden. Zum anderen besteht die Möglichkeit Testskripte in die Testable-Bean zu integrieren.…”

unclassified

STECC: Selbsttestende Software-Komponenten

Beydeda

2006

Informatik Forsch. Entw.

View full text Add to dashboard Cite

ZusammenfassungKomponentenbasierte Softwareentwicklung kann verschiedene Vorteile in der Entwicklung von größeren Softwaresystemen haben. Diesen Vorteilen stehen aber häufig Nachteile gegenüber, wie beispielsweise die erschwerte Testbarkeit einer Komponente durch ihren Nutzer, der die Komponenten als Teil in ein größeres System integrieren möchte. Die erschwerte Testbarkeit resultiert insbesondere aus der Tatsache, dass der Quelltext vor allem bei kommerziellen Komponenten im Allgemeinen nicht offen gelegt wird und somit keine programmbasierten Tests mög-lich sind. Dieser Beitrag stellt die Self-Testing COTS Components (STECC) Method vor, die genau an dieser Stelle ansetzt. Die zugrunde liegende Strategie der STECC-Methode ist die Erweiterung einer Komponente mit Funktionalität von Testwerkzeugen, so dass die Komponente selbsttestend wird. Der Quelltext und andere kritische Informationen können innerhalb der Komponente in einer eingekapselten Art und Weise für Testzwecke genutzt werden, ohne dass diese Informationen nach außen, also zum Komponentennutzer, sichtbar werden. Die STECC-Methode stellt technisch einen Rahmen zur Verfügung, in den bestehende Verfahren, insbesondere solche für das pfadorientierte Testen, eingebettet werden können.Schlüsselwörter Komponentenbasierte Softwareentwicklung · Selbsttestbarkeit · Kontrollflussgraphgenerierung · Pfadorientiertes Testen Abstract Component-based development can have various benefits in the development of large software systems. However, component-based development can also introduce problems, such as obstacles in testing of a component by its user who intends to integrate the component into a larger system. Such an obstacle is, for instance, a lack of source code in the case of commercial components, which hinders program-based tests as one implication in particular. This article introduces the Self-Testing COTS Components (STECC) Method for such circumstances. The underlying strategy of the STECC method is to augment the functionality of a component by functionality specific to testing tools, so that the component is capable of testing itself. Source code and other detailed technical information can be processed within the component in an encapsulated form, without being disclosed to the component user for testing purposes. The STECC method provides a framework in which techniques of, in particular, path-oriented testing can be embedded.

show abstract

Monitoring software components and component-based software

Cited by 22 publications

References 12 publications

Identifying cause and effect relations between events in concurrent event-based components

Identifying cause and effect relations between events in concurrent event-based components

Aspects in the Maintenance of Compiled Programs

STECC: Selbsttestende Software-Komponenten

Contact Info

Product

Resources

About