| PERRY, D. E. 1989. The Inscape environment. In Proceedings of the 11th International Conference on Software Engineering. 2--12. |
....program components it is often necessary to specify the pre and post conditions of the code required. These conditions can be used to search code in a data base of candidate reuse components. The pre and post condition search approach to reuse was first suggested by Katz et al. 34] Perry [45] and Rollins and Wing [46] A survey of the approach is presented by Mili [38] Systems which automate the search for such components typically use theorem proving to find possible matches [39, 44] Unfortunately, in some cases there may be no exact match, but there may be several components ....
PERRY, D. E. The Inscape Environment. In Proceedings: 11th International Conference on Software Engineering (1989), IEEE Computer Society Press / ACM Press, pp. 2--11.
....specification, checking and enforcement of interaction protocols. That is, there is no requirement that all interaction constraints must be specified. In a sense, it advocates the line of specifying as much as you require or see fit , and follows the spirit of light weight semantics in Inscape [13, 14]. Therefore it is more practical to use than always requiring a full specification. Constructs for constraint specification. In specifying the interaction constraints, we introduce a number of constructs to express the relationships between interface elements. The first construct has the ....
....constraint specification is simple and incremental. Our use of constraints for light weight semantic specification has its roots in our earlier work on specifying and managing the structural properties and consistency of software documents [7] and is further inspired by Perry s work on Inscape [13, 14]. 5 Conclusions Rich interface specification for software components represents a major challenge in advancing the current state of the practice of component based software engineering. This paper takes a step towards meeting this challenge by introducing a temporal logic based approach to the ....
D. Perry. The Inscape environment. In Proceedings of the 11th International Conference on Software Engineering, pages 2--12, Pittsburgh, USA, May 1989.
....external exception is propagated. Some systems provide an automatic support which guarantees the all or nothing semantics: if an exception is propagated outside, all modifications made inside the context are cancelled. Another possibility (which originates in the Inscape development environment [P89]) is to allow the context to be left in several states: an initial state (an abort exception is propagated) successfully committed state (if no exception is propagated outside) and several partial committed states, when the requested result cannot be achieved but partial (or degraded, ....
D.E. Perry. The Inscape Environment, in the 11th Int. Conf. On Software Engineering. Pennsylvania (1989) 2-11
....Combined, all revisions and variants create a version tree, which is the central entity through which users interact with a first generation CM system. In order to support tracking of compound changes to groups of source files and advanced workspace management, research into system models [9,14,27,37] sparked the inception of the second generation of CM systems. System models and their associated modeling languages provide a way to capture the structure of the software being managed via configurations sets of specific versions of specific source files. To capture the potential evolution of ....
....level, and meaningful, because the system model relates changes to each other. Existing CM system models (e.g. ShapeTools [14] and PROTEUS [37] are limited in this regard: with the exception of Adele (through interfaces [9] and Inscape (through obligations and pre and post conditions [27]) these system models do not provide mechanisms beyond grouping, versioning, and selection. The central role of architectural concepts in our system model changes that fact. Specifically, it allows us to leverage explicit architectural styles, subtyping relations among components, and behavior ....
[Article contains additional citation context not shown here]
Perry D.E., The Inscape Environment, in Proceedings of the Eleventh International Conference on Software Engineering, pp. 2-11, 1989.
....still a subject of current research to determine whether this is possible on an Internet scale. However, integration of WREN with ArchStudio is planned. While tool integration in WREN is currently implemented on an ad hoc basis, the principled approach of ArchStudio is clearly preferable. Inscape [27] is an integrated development environment that uses formal module specifications to ensure component compatibility. In a similar way to our approach, it does not perform a complete semantic analysis, but instead leverages a well designed namespace. However, rather than employing name equivalence ....
Perry, D. E. The Inscape Environment. In Proc. 11th International Conference on Software Engineering. IEEE, Washington, 1989, 2-12.
....as design by contract [11] preconditions of operations are the responsibility of callers while postconditions are the obligations of implementers, and implementers may thus assume that the preconditions hold at the time of invocation. Others have proposed different allocations of responsibilities [10, 14]. One key difference in the approach advocated here is that responsibility for checking whether or not obligations are met should be separated from both client and implementer. In addition to decoupling checking code from both the client and the component, this also opens up the opportunity of ....
Perry DE. The Inscape environment. In Proc. 11th Intl. Conf. On Software Eng. IEEE CS Press: Los Alamitos, CA, 1989, pp. 2-12.
....are driven by and how they drive their connectors. While each of these components may in its own right be a complex subsystem defined by its own (sub)architecture, that complexity has been abstracted away by the architectural view which models it simply as a component in the larger architecture[Perry89, Shaw95, Luckham93, Luckham95]. INSTRUMENTING ARCHITECTURES Our thesis is simply that the power of the architectural view arises from its focus on the exchange of data and control between components and that for us to effectively design and develop systems at this level, we need tools that provide access to this ....
Dewayne E. Perry, The Inscape Environment", Proceedings of the 11 th International Conference on Software Engineering, Pittsburgh PA, May 1989, pp 212
....specification of the exception handling models that are supported by the architectural elements. Although such a feature is not put forward by existing ADLs, base solutions may be found in the literature, e.g. see the Inscape environment that is a precursor of ADL based development environments [20]. Nonetheless, rigorous specification of exception handling models and of exception propagation at the architectural level remains an issue for future work. In this paper, we concentrate more specifically on the handling of configuration exceptions. Configuration exception handling requires ....
D. E. Perry. The Inscape environment. In Proceedings of the Eleventh International Conference on Software Engineering, pages 2--12, 1989.
....on two research efforts on this topic: systematic component retrieval, and software reuse for customizing execution environment. To our knowledge, systematic component retrieval based on a specification of components using first order logic has firstly been experimented in the Inscape environment (Perry 1989). This environment belongs to the family of development environments that can be seen as ancestors of the ones based on ADL, i.e. applications are described using a module interconnection language which is roughly an ADL without the connector notion. The Inscape environment demonstrated that it ....
Perry D. E. (1989) The Inscape Environment. Proceedings of the 11th International Conference on Software Engineering, pages 2-12.
....broadcast, or point to point communication are implicit and unavoidable. From the perspective of module interconnection, informal or semiformal languages have been used to describe software architectures [Wolf et al. 1989] In those cases, it is more difficult to prove properties of the systems. Perry [1989] presents an improved model in which the semantics of connections is taken into account to check when modules match. The semantic information in the modules, given as predicates, is used to verify some properties. One kind of predicate that can be associated with a module is a so called ....
PERRY, D. 1989. The Inscape Environment. In Proceedings of the 11th International Conference on Software Engineering (May 1989), pp. 2--11. IEEE Computer Society.
....it. Such memory leaks typically have no effect on the output, so they re not visible during a test. You only see them when the program runs out of memory after running for many hours. This is an example of a fault difficult to detect with testing. These are typically failures to honor what [Perry89] calls obligations . That is, one part of a program uses the result of another part of the program. As a result, it incurs an obligation to perform some action later. The bug is that it fails to fulfill the obligation it fails to free the memory, or it fails to close the opened file. For the ....
Dewayne E. Perry. "The Inscape Environment". Proceedings of the 11th International Conference on Software Engineering, pp. 2-12, IEEE Press, 1989.
....of equational reasoning to determine that they match. The VCR retrieval system [5] uses plug in match with VDM as the specification language. The focus of this work is on efficiency of proving match; the tool performs a series of filtering steps before doing all out match. Perry s Inscape system [22] is a specification based software development environment. Its Inquire tool provides predicate based retrieval in Inscape. Match is either exact pre post or a form of generalized match. The prototype system has a simplified and hence fairly limited inference mechanism. Also, since specifications ....
Perry, D. E. The Inscape environment. In Proc. of the 11 th ICSE (1989), pp. 2--12.
....[PA95] use theorem proving to translate automatically specifications into domain specific feature sets (sets of attribute value pairs) which they then use to do a more efficient retrieval. Such an approach depends on formulating the feature sets for each domain, however. Perry s Inscape system [Per89] is a specification based software development environment. Its Inquire tool [PP93] provides predicate based retrieval in Inscape. Match can be either exact pre post or a form of generalized match. The prototype system has a simplified and hence fairly limited inference mechanism. In Inscape, the ....
Dewayne E. Perry. The Inscape environment. In Proc. of the 11 th ICSE, pages 2--12, 1989.
....retrieval (Maarek et al. 1991; Prieto D iaz, 1991) but these methods are informal because they rely only on the meaning conveyed by words. As a more exact alternative, the application of formal specification methods to software libraries has been investigated, starting with (Katz et al. 1987; Perry, 1989; Rollins and Wing, 1991) The general idea is quite simple. Each component is associated with a formal specification which captures its relevant behavior. Any desired relation between two c fl 1999 Kluwer Academic Publishers. Printed in the Netherlands. fischer.tex; 9 08 1999; 17:16; p.1 2 Bernd ....
Perry, D. E.: 1989, `The Inscape Environment'. In: Proc. 11th Intl. Conf. Software Engineering. Pittsburg, PA, pp. 2--12.
....broadcast, or point to point communication are implicit and unavoidable. From the perspective of module interconnection, informal or semi formal languages have been used to describe software architectures [27] In those cases, it is more dicult to prove properties of the systems. Perry [22] presents an improved model in which the semantics of connections are taken into account to check when modules match. The semantic information in the modules, given as predicates, is used to verify some properties. One kind of predicate that can be associated with a module is a so called ....
D.E. Perry. The Inscape Environment. In Proceedings of the 11th International Conference on Software Engineering, pages 2-11. IEEE Computer Society, May 1989.
....with partially characterized services; any increment over the current IDL description provides a corresponding benefit This suggests formalisms that are expressively limited, with decidable reasoning problems. Some languages investigated in the formal methods literature (e.g. Wright [2] Inscape [22], etc. fall in this category. However, a third desirable feature of service specification languages is that their basic ontology should match the objectoriented nature of current IDLs, and they should be well suited to describe application domains in the natural world. The aforementioned ....
D. Perry, "The inscape environment" Proceedings, ICSE 1989.
....homogeneity) instead of dealing with heterogeneity. Fortunately, differences between domains have been considered in previous research, and mechanisms have been developed to help overcome the barriers imposed by heterogeneity. Many previous systems provided some form of interconnection capability [BDW89, HaMS88, HaNo86, JoRT85, LiSh88, MaKS89, NoBL88, Perr89, Snod89, WLRT91]. However, their focii were on the interconnection mechanisms themselves (such as data coercion operations or communication protocols) and not on the software engineering environment in which the mechanisms would be employed to solve large scale problems. There are some fundamental engineering ....
D. Perry. The Inscape Environment. Proceedings of 11th International Conference on Software Engineering, (1989), pp. 2-12.
.... are usually introduced at later stages of the software lifecycle, such as architectural design or programming, where the boundary between the software and its environment has been decided and cannot be reconsidered, and where the requirements specifications are postulated correct and complete [And81, Bor85, Per89, Cri91, Ros92, Jal94, Cri95, Aro98, Gar99]. In contrast, we perform systematic obstacle analysis at the much earlier stage of requirements engineering, from goal formulations, so that more freedom is left on adequate ways of handling obstacles to goals like, e.g. considering alternative requirements or alternative agent assignments ....
D.E. Perry, "The Inscape Environment", Proc. ICSE-11, 11th Intl. Conf. on Software Engineering, 1989, pp. 2-12.
....other static analysis systems. To simplify the verification of properties of programs, these systems restrict the forms of their formal specification notations or create abstract models from programs that could be analyzed with state exploration rather than theorem proving techniques. In Inscape [56, 57, 58], complex logical formulas are abstracted to simple predicates which may be primitive or defined in terms of other predicates (like our environmental assumptions) Predicates form pre and postconditions used to specify implementations. A programmer constructs an implementation with an editor that ....
Dewayne E. Perry. "The Inscape Environment.". In Proceedings of the 11th International Conference on Software Engineering, pages 2--12, Pittsburgh PA, May 1989.
....well defined logical relation, e.g. if the component has a weaker precondition and a stronger postcondition than the search key. From this matching relation a proof task is constructed and an ATP is used to establish (or disprove) the match. This approach has been proposed before (e.g. KRT87, Per87, RW91, MM91, MMM94, MW95] but without convincing success because essential user requirements have been neglected. In this NORA is no real acronym, HAMMR is a highly adaptive multi method retrieval tool. y This work is supported by the DFG within the Schwerpunkt Deduktion (grant Sn11 2 3) ....
D. E. Perry. "The Inscape Environment". In Proc. 11th Intl. Conf. Software Engineering, pp. 2--12. IEEE Computer Society Press, May 1987.
No context found.
PERRY, D. E. 1989. The Inscape environment. In Proceedings of the 11th International Conference on Software Engineering. 2--12.
No context found.
D. E. Perry. The Inscape environment. In Proc. 11th Intl. Conf. Software Engineering, pages 2--12. IEEE Comp. Soc. Press, May 1987.
No context found.
Perry D.E., The Inscape Environment, in Proceedings of the Eleventh International Conference on Software Engineering, pp. 2-11, 1989. 42
No context found.
D. Perry, `The Inscape environment', Proc. 11th Int. Conf. on Software Eng., 1989, pp. 2--12.
No context found.
D. E. Perry, "The Inscape Environment", International Conference on Software Engineering 1989.
First 50 documents Next 50
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