Software evolution in componentware using requirements/assurances contracts
Proceedings of the 22nd international conference on Software engineering
A Grey-Box Approach to Component Composition
GCSE '99 Proceedings of the First International Symposium on Generative and Component-Based Software Engineering
Introducing Connections Into Classes With Static Meta-Programming
COORDINATION '99 Proceedings of the Third International Conference on Coordination Languages and Models
Developing Components in the Presence of Re-entrance
FM '99 Proceedings of the Wold Congress on Formal Methods in the Development of Computing Systems-Volume II
Verified Software: Theories, Tools, Experiments
Dynamic weaving of components in a distributed environment
Proceedings of the ACM/IFIP/USENIX Middleware '08 Conference Companion
AOCI: Weaving Components in a Distributed Environment
OTM '08 Proceedings of the OTM 2008 Confederated International Conferences, CoopIS, DOA, GADA, IS, and ODBASE 2008. Part I on On the Move to Meaningful Internet Systems:
AOCI: ontology-based pointcuts
Proceedings of the 8th workshop on Aspects, components, and patterns for infrastructure software
Providing context-aware adaptations based on a semantic model
Proceedings of the 11th IFIP WG 6.1 international conference on Distributed applications and interoperable systems
| Hi-index | 0.00 |
Interface Description Languages (IDLs) describe the syntactic part of a component''s interface, but they do not help to specify semantics. Additional informal descriptions or pre- and postconditions of operations are often not precise enough. For instance, they cannot properly describe call-back scenarios, that is, the states, at which external calls are made, and the sequence of calls. Revealing the full implementation, that is, the source code, on the other hand, overspecifies the component and, thus, prohibits alternative implementations and future enhancements. What is needed is a language that allows to reveal as much of an implementation as is required to use a component, but not more. Such a language can be found in the theory of program refinement, but this is rarely used with commercial software because of the human factor: the notation is very symbolic instead of resembling a known implementation language. The lack of tool support for simulating specifications and for automatic refinement proofs also limits the enticement of writing specifications.