Swartout W, Balzer R (1982) The inevitable intertwining of specification and implementation. Comm ACM 25:438--440  Home/Search   Document Not in Database   Summary   Related Articles   Check

....this is being able to trace ones steps from inception to transition. If done comprehensively, tracing can outline every step along the way of how a problem is transformed into a solution, including intermediate results and findings. Software development needs traceability for that same reason [15]. It has been argued repeatedly that software developers need to capture traces [6,17] between requirements, design, and code. Most trace capture methods, however, require extensive manual intervention [7,9] e.g. via naming dictionaries or traceability matrices) only rare cases have (semi) ....

Swartout W. and Balzer R.: On the Inevitable Intertwining of Specification and Implementation. Communications of the ACM 25(7), 1982, 438-440.

....not How when giving the requirements specification for a CBS. Specifying only What allows the implementers the greatest freedom to choose an implementation, a How. However, several have noted that sometimes it is necessary to give some details of the How, usually what is now termed Architecture [36, 4, 30, 29]. One example described by Berry [4] is that of Knuth s exposure of the linebreaking algorithm for T E XinThe T E Xbook [26] which serves as both the requirements specification and the user s manual. Knuth described the algorithm in the specification and user s manual for two main reasons: 1. to ....

Swartout, W. and Balzer, R., "The Inevitable Intertwining of Specification and Implementation," Communications of the ACM 25(7), p.438--440 (July 1982).

....how designers can refine the presentation, application description, interactive manipulation and sequencing aspects of the interface in a rather independent manner. We believe that HUMANOID substantially enhances the iterative design process required for constructing good user interfaces [2, 22] by allowing designs to be put into action faster and earlier than current design tools allow, and by allowing designers to refine designs along multiple, relatively independent dimensions. ACKNOWLEDGEMENTS We wish to thank Peter Aberg, David Benjamin, and Brian Harp for helpful comments on ....

W. Swartout and R. Balzer. On the Inevitable Intertwining of Specification and Implementation. CACM 25, 7 (July 1982), pp. 438-440.

....Previous Work The authors are certainly not the first ones to raise concerns about the restrictiveness of refinement, and a number of extant works are related to the ideas in this paper. For instance, an early mention of the de facto reverse engineering of abstract levels from concrete ones is [Swartout and Balzer (1982)] while our distinguishing the world above the contracted model form the one below is related to the open closed principle of [Meyer (1988) The use of additional predicates during the refinement process appears in the rely guarantee method of [Jones (1983) and its successors. This also ....

Swartout W., Balzer R. (1982); On the Inevitable Intertwining of Specification and Implementation. Comm. ACM 25, 438-440.

....interface construction tools and provide little transition from design conceptualization to refinement and implementation. Research has shown that the top down design approach is inadequate for illstructured design problem domains and that the lack of transition discourages opportunistic design [11, 12, 14, 33]. Tools that facilitate low level design and implementation and that support paradigms of intertwined design and implementation [6, 33] do not provide an adequate balance between providing high level design automation and giving designers extensive control over interface design. Interface ....

.... that the top down design approach is inadequate for illstructured design problem domains and that the lack of transition discourages opportunistic design [11, 12, 14, 33] Tools that facilitate low level design and implementation and that support paradigms of intertwined design and implementation [6, 33] do not provide an adequate balance between providing high level design automation and giving designers extensive control over interface design. Interface builders (e.g. 24, 25] and automatic interface generation systems (e.g. 2, 10, 13, 26, 30] represent tools of this kind. Interface ....

W. Swartout and R. Balzer. On the inevitable intertwining of specification and implementation. CACM 25, 7 (July 1982), pp. 438-440.

....by R transformations. The proof is simply the last part of the proof of proposition 5.7. 6. Discussion of the framework One may argue that an implementation process where the specification phase and the implementation phase are clearly separated is overly naive and does not match reality [27], specification and implementation being respectively the already fixed and the yet to be done portions of a multi step system development. In our framework, each stage of the implementation process should be a valid realization of the specification. By valid we mean that behaviours specified by ....

W. Swartout, R. Balzer, On the Inevitable Intertwining of Specification and Implementation, Communications of the ACM, Vol. 25, No. 7, July 1982, 438-440.

.... specification and development of part of the Light Control System, a significant case study involving both functional and timing requirements [Problem Description, 2000] 2 Previous and Related Work The need to allow requirements specifications to evolve has been recognised for some time [Swartout and Balzer, 1982]. One reason for wanting this capability is that the practical limitations of implementation languages and hardware cannot usually be anticipated when the initial requirements document is written. This is particularly true of embedded real time systems. Such systems interact with their environment ....

Swartout, W. and Balzer, R. On the inevitable intertwining of specification and implementation. Communications of the ACM, 25(7):438-- 440.

....problem domain (as opposed to the solution domain) To make sure some solution solves a problem correctly, one must first state that problem correctly. This dichotomy is however simplistic; a solution to a problem may in general be given as a set of subproblems to be specified and solved in turn [Swa82]. A specification must thus in general satisfy some higher level specification and be satisfied by some lower level specifications. Formal is often confused with precise (the former entails the latter but the reverse is of course not true) A specification is formal if it is expressed in a ....

W. Swartout and R. Balzer, "On the Inevitable Intertwining of Specification and Implementation", Communications of the ACM, Vol. 25 No. 7, July 1982, 438-440.

....as he gains expertise (Jeffries, Turner, Polson, Atwood, 1981) Thus, in addition to knowledge about software architectures, algorithms, data structures, programming languages creating software design requires domain specific knowledge. Because requirements are ambiguous and incomplete (Swartout Balzer, 1982; Parnas Clements, 1986) and because both the requirements and the environment in which the software operates are in a constant state of flux, there is a need for problem structuring during software design (Guindon, 1990) Problem structuring is the process of discovering missing information ....

Swartout, W. & Balzer, R.:1982, On the Inevitable Intertwining of Specification and Implementation. Communications of the ACM, 25(7), 438-440.

.... the modeling methodological work to date has been the recognition of Dijkstra s principle of the separation of concerns which argues for the separateness of specification and implementation [4] In many cases, this philosophy has been tempered by the pragmatic observations of Swartout and Balzer [17], who observe that separation is a worthy goal but not achievable in totality since any specification, S, may be viewed as an implementation of some higher order specification, S # . Another argument in favor of the intertwining of specification and implementation is that technological ....

Swartout W.; and R. Balzer. 1982. "On the Inevitable Intertwining of Specification and Implementation. " Communications of the ACM, 25, no. 7(July):438-440.

....are non operational abstractions to be satisfied through components, requirements themselves seldom directly interact. Rathe r, requirements interact indirectly through the components that can satisfy them. Computer science terms this the intertwining between specification and design[258]. Decision science terms this the means ends interdependency[286] Similarl y, AI planning distinguishes between goals and plans[276] Actual requirement interactions are always conditional. Consider two requirements, each a logical negation of the other: R x X and R y X. While the two ....

Swartout,W., Balzer, R., On the inevitable intertwining of specification and implementation, CACM V ol. 25 (1982) 438-440.

....work which has objectives similar to ours is the data model (DODM) in the DAMOKLES project [6] The presented model considers the specification for each component of a product as being closely linked to its implementation. The need for such an integration has been felt before. Swartout and Balzer [14] argue that even though software process models view specification and implementation as successive steps, in reality they influence one another. In other words, as software evolves both specifications and implementations undergo change. In fact, systems that integrate specifications in the design ....

W. Swartout and R. Balzer. On the inevitable intertwining of specification and implementation. Communications of the ACM, 25(7):438--440, July 1982.

.... software development emphasize the need for maintaining fidelity in an efficient manner [2] For example, not only must the code implement behaviors as specified by a model during development, but a model itself may need to change based on discovered limitations of the implementation environment [3]. Maintaining fidelity between the code and models is important as the software evolves because any divergence sacrifices the benefits of formal analysis on the model and may lead to future problems including design errors, inconsistent documentation, and expensive rework. Typically, a model ....

Swartout, W. and R. Balzer, On the Inevitable Intertwining of Specification and Implementation. j-CACM, 1982. 25(??): p. 438-440.

....allow for a degree of feedback and revision. The causes are well known: no one has perfect foresight to predict what they will want in the future; clients are not even certain about what they want now, nor what is possible; and the consequences of particular requirements cannot be foreseen (Swartout Balzer, 1982). Furthermore, the introduction of a new system itself generates new requirements. All these problems suggest that some form of exploration is desirable. For the later stages of software engineering, exploratory programming has been proposed. The specification process, on the other hand is ....

....describes exactly what is required. One symptom of this uncertainty is that the specification gets altered once implementation is underway. The fact that the process of designing a specification cannot be fully separated from the implementation has already been noted. Swartout Balzer (Swartout Balzer, 1982) identify two main reasons for alterations to the specification once the implementation is underway. The first of these involves physical limitations arising from implementation decisions. The second reason is the most interesting, and is put down to lack of foresight in the specification. ....

Swartout, W., & Balzer, R. (1982). On the Inevitable Intertwining of Specification and Implementation. Communications of the ACM, 25(7), 438-440.

....[3] flow diagrams, process algebras [4] petri nets, and many other formal and informal notations. During development, the code must not only implement behaviors as specified by a model, but a model itself may need to change based on discovered limitations of the implementation environment [5]. Maintaining fidelity between the code and models is important as the software evolves because any divergence may lead to future problems including design errors, inconsistent documentation, and expensive rework. While it is possible in some cases to generate code directly from a model, most ....

Swartout, W. and R. Balzer, On the Inevitable Intertwining of Specification and Implementation. j-CACM, 1982. 25(??): p. 438-440.

No context found.

Swartout W, Balzer R (1982) The inevitable intertwining of specification and implementation. Comm ACM 25:438--440

No context found.

Swartout, W. and Balzer, R. On the inevitable intertwining of specification and implementation. Communications of the ACM, 25(7):438-- 440.

No context found.

W. Swartout and R. Balzer, "On the Inevitable Intertwining of Specification and Implementation", Communications of the ACM, 25(7):438-440, ACM Press, July 1982.

No context found.

W. Swartout, R. Balzer, On the inevitable intertwining of specification and implementa- tion. Commun. ACM, 25 (1982), 7, 438-440.

No context found.

W. Swartout and R. Balzer, "On the Inevitable Intertwining of Specification and Implementation", Communications of the ACM, Vol. 25 No. 7, July 1982, 438-440.

No context found.

W. Swartout and R. Balzer (1982), "On the Inevitable Intertwining of Specification and Implementation", Communications of the ACM, 25(7): 438-440.

No context found.

Swartout, W., R. Balzer, "On the Inevitable Intertwining of Specification and Implementation," Communications of the ACM, Vol. 25, No. 7, July 1982.

No context found.

Swartout, W., Balzer, R., On the inevitable intertwining of specification and implementation, CACM Vol. 25 (1982) 438-440.

No context found.

Swartout 82 W. Swartout and R. Balzer. The Inevitable Intertwining of Specification and Implementation. Communications of the ACM 25(7):438-440, July, 1982.

No context found.

AI Magazine, 6, (4). Swartout, W.R., & Balzer, R. (1982). On the Inevitable Intertwining of Specification and Implementation. Communications of the ACM, 25 (7), 438-439.

First 50 documents

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