P. Inverardi, A. Wolf, D. Yankelevich, Static checking of system behaviors using derived component assumptions, ACM Transactions on Software Engineering and Methodology 9 (3) (2000) 239--272.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....a component is in full control of its outputs. In addition, in our approach the substitutability of heterogeneous components can be checked with the aid of interface automata. There are some other approaches which also utilize the environmental assumptions of components for verification. In [5, 6], the assumptions and the actual behaviours of components are derived from component specifications. The deadlock freedom of a system is determined by pairwise matching between the assumptions of a component and the actual behaviour of another component. However, the proposed method is incomplete ....

P. Inverardi, A. Wolf, and D. Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Trans. on Software Engineering and Methodology, 9(3):239-- 272, 2000.

....and requires some special techniques in our methodology (as presented in this paper) Our compositions do not map inherently to abstraction refinements. Inverardi, Wolf, and Yankelevich extract graph based representations of software components for purposes of checking for deadlock freedom [26]. Their work, like ours, also represents components by graph based abstractions and traverses those graphs to check properties. Our work differs from theirs in two key ways: first, we are establishing an overall methodology for handling feature oriented design, which adds some technical challenges ....

....and or paths between states in the base machine. State machine models of software arise from one of two sources: either the software is written in terms of state machines, as is true for many embedded software applications, or abstraction techniques derive state machines from the source code [13, 14, 26]. As FSATSis of the former flavor, we assume that approach in this paper. Our work could adapt to the latter if the abstractions produce machines for which we could define meaningful interfaces between features; accordingly, we regard the work on state machine abstractions as orthogonal to this ....

P. Inverardi, A. Wolf, and D. Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239--272, July 2000.

.... using a few generic integration elements allows an integration architecture to be created [K99, KG98] Post Integration Assessment Once an integration architecture is in place, analysis can be performed to detect such problems as deadlock, liveness, reliability, evolvability and security [CIW99, DG02b, JG02, IWY00]. Thesis Terminology The most important terms used in this thesis are defined. 2.1 Properties Describing a Software Architecture The software architecture of a system is the blueprint of its computational elements, the means by which they interact, and the structural constraints on their ....

....assessment Post integration assessment looks at systems after the integration solution is already in place. The CHemical Abstract Machine (CHAM) formalism is one such assessment method. It identifies deadlock problems caused by mismatched behavioral assumptions at the architectural level [CIW99, IWY00]. These assessments offer additional insight into the prescribed integration architecture and can help in uncovering the impetus behind integration solutions. However, they are limited in how they assess interoperability a priori and how they direct the selection of an initial solution that is ....

[Article contains additional citation context not shown here]

Inverardi, P., Wolf, A., and Yankelevich, D. Static Checking of System Behaviors Using Derived Component Assumptions. ACM Transactions on Software Engineering and Methodologies (2000), 9(3): 239-272.

....of a control intensive communications protocol between personnel and data intensive decisions within the protocol. Third, our current methodology assumes that collaborations specify control flow via state machines. We would like to extend existing work on deriving state machines from source code [12, 13, 22] to extract collaboration oriented models. A related question asks whether our collaboration based organization is too restrictive; it may be possible to extract collaboration like behavior from code that is composed in parallel, perhaps by examining synchronization points. ....

P. Inverardi, A. Wolf, and D. Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239--272, July 2000.

....is that explicit description of connector types will allow designers the flexibility to choose the correct interaction schemes in an integrated system [GAR98, AG97] 8 . Post Integration assessment Research is being conducted currently to uncover the impetus behind interoperability conflict [IWY00]. Once an integration architecture is in place, analysis can be performed to detect problems. Thesis Terminology The most contentious terms in this thesis are defined. 2.1 Properties Describing a Software Architecture The software architecture of a system is a high level description of its ....

....between integration architectures and the middleware frameworks and 13 integration strategies they formulate [KG98] 2. 5 Post Integration assessment Research is being conducted currently to uncover the impetus behind integration solutions and how they resolve interoperability conflicts [IWY00]. These approaches are concerned with post integration assessment, and, thus, look at the system after an integration solution is in place. IWY00] employ a formalism called a chemical abstract machine (CHAM) to specify the participating components, including the integration architecture. The ....

[Article contains additional citation context not shown here]

Inverardi, P., Wolf, A., Yankelevich, D. Static Checking of System Behaviors Using Derived Component Assumptions. ACM TOSEM,9(3): 239-72, 2000.

.... simple architecture styles in [32] and the limitation of evaluation assessment to only nonfunctional requirements in [16] Postintegration analysis can offer additional insight into the prescribed integration architecture, as with the chemical abstract machine (CHAM) formalism discussed in [14] and with ADLs such as Wright [3] While these approaches aid in the assessment of integration solutions, they do not provide a means to assess interoperability a priori and to direct the selection of an initial solution that is appropriate. 3. SOFTWARE ARCHITECTURE CHARACTERISTICS In this ....

....with our example. We employ the characteristics from Table 1 and the notation described in Section 4. 6 5. 1 The Compressing Proxy The Compressing Proxy is an HTTP server that dynamically compresses and uncompresses data sent across a network, with the goal of improving web browser performance [6,14]. The Compressing Proxy is constructed by integrating gzip into the W3C HTTP daemon (CERN server) The CERN server is a generic, full featured hypertext server, which can be used as a regular HTTP server. According to the HTML documents distributed with the source code, the CERN server processes ....

[Article contains additional citation context not shown here]

Inverardi, P., Wolf, A., Yankelevich, D. Static Checking of System Behaviors Using Derived 10 Component Assumptions. ACM TOSEM (2000), 9(3): 239-72.

....To date, research in the area has focused primarily on the use of architecture description languages (ADLs) as a substrate for analysis algorithms. The analysis algorithms that have been developed for these languages have, in general, focused on correctness properties, such as liveness and safety [2,10,14,16]. However, other types of analysis are also appropriate for use at the architecture level and are currently the focus of research projects. Examples include system understanding [13,21,27] performance analysis [3,20] and architecture based testing [4,24] One still unresolved challenge for ....

P. Inverardi, A.L. Wolf, and D. Yankelevich, Static Checking of System Behaviors Using Derived Compo- nent Assumptions, ACM Transaction on Software Engineering and Methodology, Vol. 9, No. 3, July. 2000, pp. 238-272.

.... final product by permitting analyses to be performed early in the life cycle [5, 13, 23] Consequently, much e#ort has been devoted to researching, experimenting with, and categorizing the kinds of analyses that can be performed and the product quality attributes that can be improved through them [1, 3, 4, 7, 8, 9, 14, 15, 17, 18, 19, 21, 22]. Despite the significant amount of research in architectural specification, there has been little attempt to formally relate it to higher levels of specification, such as the system requirements [24] Only recently has interest begun to emerge in this regard [16, 20] In this paper we present our ....

....11] This is a well known branching logic for which model checkers are available. To specify software architectures, we use the CHAM (CHemical Abstract Machine) formalism [6] This formalism has been used extensively by us and others in previous work on architectural specification and analysis [9, 14, 15, 25]. Note, however, that the general approach we describe in this paper is not tied to the CHAM formalism. For those unfamiliar with CHAM or its use in specifying software architectures, Appendix A provides a brief review. Appendix A also provides a brief review of CTL. In the next section of the ....

P. Inverardi, A.L. Wolf, and D. Yankelevich. Static Checking of System Behaviors Using Derived Component Assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239--272, July 2000. 28

No context found.

P. Inverardi, A.L. Wolf, and D. Yankelevich, "Static Checking of System Behaviors Using Derived Component Assumptions," ACM Transactions on Software Engineering and Methodology, 9(3):239--272 (July 2000).

....description languages (ADLs) allow one to reason about properties of software systems at correspondingly high levels of abstraction. The analysis techniques that have been developed for these languages have, in general, focused primarily on correctness properties, such as liveness and safety [2, 17, 22, 25]. But there are many other kinds of questions in addition to correctness that one might want to ask at an architectural level for purposes as varied as localizing faults, determining the impact of changes, minimizing regression tests, reengineering a system, reusing components, and managing a ....

P. Inverardi, A.L. Wolf, and D. Yankelevich. Static Checking of System Behaviors Using Derived Component Assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239-272, July 2000.

No context found.

P. Inverardi, A. Wolf, D. Yankelevich, Static checking of system behaviors using derived component assumptions, ACM Transactions on Software Engineering and Methodology 9 (3) (2000) 239--272.

No context found.

Paola Inverardi, Alexander L. Wolf, and Daniel Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239--272, July 2000.

No context found.

P. Inverardi, A. Wolf, and D. Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Transactions on Software Engineering Methods, 9(3):239--272, July 2000.

No context found.

P. Inverardi, A. Wolf, and D. Yankelevich. Static checking of system behaviors using derived component assumptions. ACM Transactions on Software Engineering and Methodology, 9(3):239--272, July 2000.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC