PERRY, D. E. 1989. The Inscape environment. In Proceedings of the 11th International Conference on Software Engineering. 2--12.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....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.

....changes and extreme proliferation of program versions. On the other hand, on line replacement deals with the problem of installing new software version after the development is complete. There are systems that allow flexible interconnection of software components to form the complete system [3, 4, 5]. Though such systems allow flexible interconnection of components, they frequently require interconnections to be specified before execution and do not usually permit changes to modules while the software is executing. Some systems allow the configuration of a distributed program to be changed ....

D. Perry. "The Inscape environment". In Proc. 11th Int. Conf. on Software Engg., pages 2--12, 1989. 19

.... type replacement system [1] the DAS operating system [2] DYMOS [3] PODUS [4] 5] and the authors system [6] A survey of many different implementations can be found in [7] There are also systems that allow flexible interconnection of software components to form the complete system [8] [9], 10] However such systems frequently require interconnections to be specified before execution of the software and do not permit changes to modules during execution. Currently with Indian Institute of Technology, Guwahati Some other systems allow the configuration of a distributed program to ....

D. Perry, "The Inscape environment", in Proc. 11th Int. Conf. on Software Engg., 1989, pp. 2--12.

....broadcast, or point to point communication are implicit and unavoidable. From the perspective of Module Interconnection Languages, informal or semi formal languages have been used to describe software architectures [22] In those cases, it is more di#cult to prove properties of the systems. Perry [18] presents a 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. However, since it was aimed at modules and assembly of modules, the dynamics of the system ....

D.E. Perry. The Inscape Environment. In Proceedings of the 11th International Conference on Software Engineering, pages 2--11. IEEE Computer Society, May 1989. 22

....of programs over a library of so called schemes, i.e. program fragments which are enriched by assertions about their combination and instantiation possibilites. The construction process then generated proof tasks which were solved by the Boyer Moore theorem prover. The Inscape system [Per87] aimed at the development of large software systems based on specifications; it also offered some retrieval support. However, both systems worked with severely restricted logics and inference mechanisms and never left the prototype stage. Lowry et al. LP 94] utilized a formally specified ....

D. E. Perry. "The Inscape Environment". In Proc. 11th ICSE, pp. 2--12. IEEE Computer Society Press, May 1987.

....are informal because they rely only on the meaning conveyed by words. This work is supported by the DFG within the Schwerpunkt Deduktion , grant Sn11 2 3. As a more exact alternative, the application of formal specification methods to software libraries has been investigated, starting with [10, 23, 25]. The general idea is quite simple. Each component is indexed with a formal specification which captures its relevant behavior. Any desired relation between two components (e.g. refinement or matching) is expressed by a logical formula composed from the indices. An automated theorem prover is ....

D. E. Perry. The Inscape environment. In Proc. 11th Intl. Conf. Software Engineering, pages 2--12. IEEE Comp. Soc. Press, May 1987.

....mentioned in Section 2. The advantage of such implicit frame axioms is that if we apply them to procedure specifications after inheritance, conjunction, etc. have been expanded, then we get the desired effect of things not changing unless otherwise stated . Several systems, such as INSCAPE [Perry89], make the meta assertion that variables are not changed unless explicitly said so, and then implement it operationally in the sense that the specific reasoning done by the system take this into account. In the case of INSCAPE, the system concerns itself mostly with propagating necessary or ....

D. Perry, "The Inscape Environment", Proc. 11th Int. Conf. on Software Engineering, Pittsburgh, May 1989.

....wrote them from the code. The specifications were written in a rigorous format as a list of preconditions (that describe allowable inputs to the program) and postconditions (each of which describes a particular result and the conditions under which it occurs) The format is partially derived from [Perry89]; an example is given in Appendix A. 2.2. The Test Procedure The programs were tested in five stages. Each stage produced a new test suite that addressed the shortcomings of its predecessors. 2.2.1. Applying a Variant Black Box Technique The first two test suites were developed using a variant ....

Dewayne E. Perry. "The Inscape Environment". Proceedings of the 11th International Conference on Software Engineering, pp. 2-12, IEEE Press, 1989.

....characterized services; any increment over the current IDL description provides a corresponding benefit This suggests the use of formalisms that are expressively limited, but have decidable reasoning problems. Some languages investigated in the formal methods literature (e.g. Wright [2] Inscape [23], etc. fall in this category. However, a third desirable feature of service specification languages is that their basic ontology should match the object oriented 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.

....specifications of execution properties Formal speci cation of functional properties amounts to specifying the behavior of the operations required and provided by the architectural elements. the behavior of operations is speci ed in terms of pre and post conditions using Hoare s logic (e.g. [17, 23]) In addition to the straightforward bene t of formally specifying functional properties for verifying the correctness of component interconnection, it further favors software reuse and evolution. A component may be retrieved from a component database using the component speci cation. The ....

....can be checked with respect to the speci cations of involved components. The aforementioned veri cations lie in the de nition of relations over speci cations. These relations de ne, in terms of speci cation matching, correctness conditions for software interconnection, re use, and substitution [17, 13, 23]. A non functional property characterizes a resource management policy that is implemented by the underlying execution platform. Similar to functional properties, non functional ones are speci ed in terms of rst order logic (e.g. 9] These speci cations refer to operations that are not ....

D. E. Perry. The Inscape Environment. In Proceedings of the 11th International Conference on Software Engineering, pages 2-12, May 1989.

....are procedures, variables, types, and so on. However, the Software Landscape MIL [13, 5, 9] uses more coarsely grained resources, such as modules and classes, as the currency of exchange between subsystems. The emergence of formal methods for programming has resulted in MILs, like Inscape [14] and NuMIL [11] that also feature pre and post conditions as resources. The dependencies among the components in a MIL specification are not arbitrary; they must conform to a set of scoping rules that is specific to the MIL. The Software Landscape is a visual MIL that has adopted several ideas ....

Perry, D. E. The Inscape Environment. In Proceedings of the 11th IEEE International Conference on Software Engineering (Pittsburgh, Pennsylvania, 1989), pp. 2--12.

....function being redefined are immediately discarded. While this Spartan approach guarantees soundness and consistency, it does not offer much flexibility to the user, nor does it attempt to preserve previous work which depends on unmodified parts of a redefined function. The INSCAPE Environment [Perry 89] uses semantic interconnection information to track dependencies among program modules, with a goal of supporting formal modularization of large scale systems. The environment tracks pre and post condition dependence, caller obligations, and preclusion and handling of runtime exceptions. ....

Dewayne E. Perry. The Inscape Environment. Technical Report, AT&T Bell Laboratories, February, 1989. publication pending.

....declared in the components interfaces, that is to say, the operations that are required and provided by the components. Thus, an approach to component formal specification consists in specifying operations behaviors in terms of pre and post conditions using the Hoare logic [8] as proposed in [23, 30]. For illustration purpose, let us consider the create operation of a file system. A specification for this operation may be: create (F: FileName) P: FilePtr) pre: not exist(F) post: exist(F) and open(F) and valid(P) where the meanings of exist, open and valid are straightforward from the ....

....within a configuration can be checked with respect to the specifications of involved components. The aforementioned verifications lie in the definition of relations over specifications. These relations set conditions upon which software interconnection, re use, and substitution are correct [23, 17, 30]; and they are defined in terms of specification matching. Examples of such relations, which are taken from [30] are given hereafter. Specification matching. A component specification is the set of specifications of the component s (required and provided) operations. Thus, specification matching ....

[Article contains additional citation context not shown here]

D. E. Perry. The Inscape environment. In Proceedings of the Eleventh International Conference on Software Engineering, pages 2--12, 1989.

....proposed in [18] for example) and different mechanisms for the generation of new capabilities. 6 Related Work This work is clearly related to the concept of module interconnection languages, introduced by DeRemer and Kron [7] and further developed, among others, by Wolf et al. 36] by Perry [30], and, in the context of distributed system, by Kramer and Magee [14] More recently, this gave rise to the concept of software architecture (SA) introduced by Perry and Wolf in 1992 [31] and continued by Garlan and Shaw [10, 33] and by many others. This body of works seeks to define an explicit ....

D.E. Perry. The inscape environment. In Proceedings of the 11th International Conference on Software Engineering, May 1989.

.... explicit structural (configuration) description is essential for all phases in the software development process, from system specification as a essential for all phases in the software development process, from system specification as a configuration of component specifications (eg.as in Inscape [37], GRID [36] and PAISLEY configuration of component specifications (eg.as in Inscape [37] GRID [36] and PAISLEY [44] to evolution as changes to a system configuration [18,23] In contrast to the [44] to evolution as changes to a system configuration [18,23] In contrast to the specification ....

.... development process, from system specification as a essential for all phases in the software development process, from system specification as a configuration of component specifications (eg.as in Inscape [37] GRID [36] and PAISLEY configuration of component specifications (eg.as in Inscape [37], GRID [36] and PAISLEY [44] to evolution as changes to a system configuration [18,23] In contrast to the [44] to evolution as changes to a system configuration [18,23] In contrast to the specification driven approach, our model is constructive . The specification driven specification ....

D.E.Perry, "The Inscape Environment", Proc. of 11th IEEE Int. Conf. on Software D.E.Perry, "The Inscape Environment", Proc. of 11th IEEE Int. Conf. on Software Engineering, Pittsburgh, May 1989.

....predicates, and DRC operators) must still be coded from scratch. We believe that a domain independent tool can be created that eliminates the burden of DRC software development. Generalizing attributes types, predicates, and DRC operators without sacrificing automatic DRC is the key issue [Per89b]. Fourth, it may be possible to be more aggressive in repairing composition errors. For example, it seems likely that some errors can be repaired automatically (e.g. inserting inbetween into an equation) Also, it may be possible to identify the specific list of components (e.g. Z in Figure 8b) ....

D. E. Perry, "The Inscape Environment", Proc. ICSE 1989, 2-12.

....and, in this way, software components that do not interface directly can interoperate efficiently. This is the particular communication system we have chosen to generate stubs for within Polygen, since Polylith simplifies many of the data coercion and relocation requirements. The Inscape project [11] is an alternate MIL approach, which primarily focuses on the semantics of module composition processes. Also, the Conic [10] and Durra [2] projects have recently addressed the same problems as Polylith with a similar toolkit approach, but without the aid of composition abstractions like the ....

D. Perry. The Inscape Environment. Proceedings of the IEEE 11th International Conference on Software Engineering, (May 1989), pp. 2-12.

....analysis systems. To simplify the verification of properties of implementations, these systems restrict the forms of their formal specification notations or create abstract models from implementations that could be analyzed with state exploration rather than theorem proving techniques. In Inscape[28, 29, 30], complex logical formulas are abstracted to simple predicates which may be primitive or defined in terms of other predicates (like our relationships) Predicates form pre and postconditions used to specify implementations. A programmer constructs an implementation with an editor that analyzes ....

Dewayne E. Perry. "The Inscape Environment.". In Proceedings of the 11th International Conference on Software Engineering, pages 60--68, Pittsburgh PA, May 1989.

....or with misleading ones) the version control paper from ICSE9 [16] the extended abstract for SCM3 [19] and the shared dependency paper from SCM6 [20] all of which have been published only in conference or workshop versions. There may be parts of the other Inscape papers (ICSE9 [15] ICSE11 [17], and TAV3 [18] included as well all of which have been published only in conference versions. 2 1. Introduction In his paper Tolerating Inconsistency [2] Balzer stated that Instead of treating inconsistency informally (i.e. outside the system) or as hard constraints, formalisms are ....

Dewayne E. Perry. "The Inscape Environment". The Proceedings of the Eleventh International Conference on Software Engineering, May 1989, Pittsburgh, PA. - 20 -

....within A in the manner prescribed by the static semantics (i.e. context sensitive syntax) of the programming language. Each use of an identifier defined externally (i.e. not defined in A) must be consistent with all other uses of the same identifier within A. In the case of semantic consistency [19], every identifier must be used correctly with respect to the semantic specification mechanism employed. For simplicity, we assume syntactic consistency analysis throughout the rest of this paper. Once module A is statically consistent, the programmer builds a test harness. The harness consists of ....

.... for software process activities [21] Extending Infuse to a distributed implementation by merging Infuse with Mercury [12] a generation system for multiple user, distributed language based environments (using incremental evaluation of attribute grammars) Integrating Infuse with Inscape [19] to support a semantic consistency model (i.e. preconditions, postconditions and obligations with respect to each program unit) in addition to the current syntactic model. Acknowledgements Yoelle Maarek developed the hierarchical clustering algorithm used by Infuse. Ben Fried, Barry Goldberg, ....

Dewayne E. Perry, "The Inscape Environment", 11th International Conference on Software Engineering , Pittsburgh PA, May, 1989, pp 2-12.

....Test Harness Apply Regression Tests Apply Integration Tests Deposit Integrated Component into Parent Each activity is defined by a set of preconditions and a set of results each of which consists of a set of postconditions and obligations. This is the model I use in the Inscape Environment [4] to define the behavior of operations. There is, however, an important difference: the preconditions, postconditions and obligations are policies that are required to be satisfied, are guaranteed to have been satisfied, or are entailed to be satisfied eventually, respectively. In the II Model, ....

Dewayne E. Perry. "The Inscape Environment" The Proceedings of the Eleventh International Conference on Software Engineering, May 1989, Pittsburgh, PA.

....have identical syntactic interfaces but entirely different semantics. It is for this reason that we must also consider fine grained semantic consistency issues. One example of this type of approach is found in the interface specifications and static analysis supported by the Inscape Environment [7]. Formally defined predicates provide the fine grained semantic dependencies and interconnections with which we can formally define semantic relationships and reason about them in both constructing compositions and in substituting one component for another in a composition. Perry s Version ....

Dewayne E. Perry. "The Inscape Environment". The Proceedings of the Eleventh International Conference on Software Engineering, May 1989, Pittsburgh, PA.

....off is derived from various disasters where the failure occurred with the systems on. We learn as much from how we do things when they turn out to be wrong as when they turn out to be right. Some of our methods are the result of theoretical concerns. For example, on the Inscape Environment [Perry89], the underlying principle is that once you have constructed the interface of a code fragment, you need not worry about the internal structure of that fragment. The interfaces have the property of referential transparency that is, you only need to know what is reported at the interface ....

Dewayne E. Perry. "The Inscape Environment". The Proceedings of the Eleventh International Conference on Software Engineering, May 1989, Pittsburgh, PA.

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.

No context found.

D.E. Perry. The Inscape environment. Proceedings, 11th International Conference on Software Engineering, pp 2-12. IEEE Computer Society Press, 1989.

No context found.

D. E. Perry, "The Inscape Environment", Proc. ICSE 1989.

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