Swartout W, Balzer R (1982) The inevitable intertwining of specification and implementation. Comm ACM 25:438--440  @ NUS  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.

....if designed, should be consistent, adequate, valid, and reliable (which are, once again, qualitative properties) 2. 3 Isolation from Application This is one of the main motivations behind the design of all the User Interface Management Systems (see section 4) An interface should be isolated [9] from the application for which it is built. By isolation, we mean that the abstractions (objects in object oriented languages) of the applications should be distinct from those of the interface. There can be communication between these abstract objects, but each of them should not be dependent ....

W.Swartout and R.Blazer, "The Inevitable Intertwining of Specification and Implementation," Commun. ACM, Vol.25, No.7, Jul.1982, pp.438-440.

.... of software development than the phases of the standard life cycle that originated from the idea of mile stones [Zave Yeh 81] Of course, the activities of the phases of the standard life cycle remain, but they are spread over the two phases of our method, and can no longer be uniquely located [Swartout Balzer 82] 6 Current and Future Research The second prototype of our software development method comprises executable specifications and transformational implementation, and thus covers a substantial part of software development. Nevertheless, many of our requirements remain insufficiently fulfilled, ....

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

....to create. Developing virtual reality applications is an even harder challenge, since it involves the creation of a software system with strict quality and timing constraints dictated by the needs of sensory simulation and direct 3D interaction. A number of authors have analyzed these problems [87, 38, 77, 66, 80, 31, 92, 37, 88, 60, 41]. Their findings are summarized here. 4.1.1 Man machine communication Interactive programs have to establish a bidirectional communication with humans. Not only they have to let humans modify information, but they have to present it in a way to make it simple to understand, to indicate what types ....

SWARTOUT, W., AND BALZER, R. On the inevitable intertwining of specification and implementation. Communications of the ACM 25, 7 (July 1982), 438--440.

....by the specware approach, to seek ways of integrating the two approaches. Design Code: During development, the code must not only implement behaviors as specified by the design model, but models themselves may need to change based on discovered limitations of an implementation environment [8]. Managing the consistency between code and design models is important as the software evolves because any divergence may lead to serious flaws later in the lifecycle. Our work with formal testing has led us to an approach based on the generation of representative test cases from a formal model, ....

W. Swartout and R. Balzer, "On the Inevitable Intertwining of Specification and Implementation," Communications of the ACM, vol. 25, pp. 438-440, 1982.

....unnecessary. It is clearly not the first cut at stating the problem, rather, it is the result of careful forethought. Swartout and Balzer observed this, and went on to make the more general point that specifying what you want is inevitably intertwined with knowledge of how it is to be implemented [Swartout Balzer 1982]. The implication for specification exemplars is that one should expect to be involved in an ongoing cycle of specification and re specification, not simply the one time specification of a perfectly crafted problem statement. We never carried implementation through to anything other than a ....

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

....much more than mathematics and logic. This is the motive for almost all human sciences based software design methods. 41 A criticism voiced by many software designers and researchers points out that normative models are inflexible in the face of changing requirements and constraints [144] [202] [76] 57] 225] These critics note that constantly changing requirements is an attribute of almost every software design project. Normative models rarely acknowledge that software design involves highly iterative, interleaved, loosely ordered tasks [87] Software design work is not always ....

Swartout, W. and Balzer, R., "On the Inevitable Intertwining of Specification and Implementation," Communications of the ACM, vol. 25, no. 7, 438-440, Jul. 1982.

....is that a product specification gets divorced from the final product itself. In this report, we present a model in which the specification of each component of a product is closely linked to its implementation. The need for such an integration has been felt before. For example, Swartout and Balzer [SB82] 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 1 . Certain philosohical principles have been used to guide ....

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

....in the middle ground supports the mapping from conceptual design into functioning interfaces. The system described in this paper bridges that gap by mapping designers intentions into executable interface specification. Thus it supports an intertwined design and implementation working environment [17], a previously neglected need. CURRENT STATUS AND FUTURE WORK The HUMANOID model based design and execution environment is implemented in Garnet [9] and CommonLisp. We have used it within our group to implement the interfaces for two large applications, a logistics analysis system (DRAMA) and a ....

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

....in context of the DAMOKLES system, the data model is closely tied to its implementation. 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.

....It is clearly not the first cut at stating the problem, rather, it is the result of careful forethought. Swartout and Balzer observed this, and went on to make the more general point that specifying what you want is inevitably intertwined with knowledge of how it is to be implemented [Swartout Balzer 1982]. The implication for the use of specification exemplars is that one should expect to be involved in an ongoing cycle of specification and respecification, not simply the one time specification of a perfectly crafted problem statement. We never carried implementation through to anything other than ....

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

....and decomposition implies that interaction refinement and system decomposition are orthogonal. This is visualized in figure 2, called the magic square by Harel and Pnueli [24] Orthogonality means that decisions about interactions can be intertwined with decisions about decompositions in any way [50]. To explain this further, we return briefly to the process dimension. It is useful to distinguish logical design tasks from the way these tasks are ordered in time. Very generally, for any design task, the logical tasks are analysis of problem situation, Postmodern Software Design with NYAM ....

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

....[21] we put our emphasis upon the derivation of a specification as an incremental process of formalisation and validation involving complex interactive and iterative design. Such a view of the specification process is particularly well represented in the work of Balzer, Goldman and Sartout [4,20], which emphasises the essentially dynamic nature of the correspondence between program and application , and the need for a style of programming that supports both the clear articulation of the program, and of the salient aspects of its derivation. In this context, we have no distinction ....

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

....graph for the factorial application on resources defined by other components. The structure of an application includes a description of each component and the dependencies between them. One major problem is how to specify a component in a manner that is independent of any implementation [5] [6] [7] Often, it is impossible to completely separate specification and implementation from a system perspective. We present an approach to describing software structures, called structure graphs, that can be used to describe many levels of design: from gross structures to statement level ....

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

....design, as discussed above. This means that the conventional software engineering waterfall approach to software design, where the user interface is fully specified, then implemented, and later tested, is inadequate. Instead, the specification, implementation, and testing must be intertwined [Swartout 82] This makes it very difficult to schedule and manage user interface development. Why are User Interfaces Difficult to Design and Implement 9 4.2 Reactive Programming Once the implementation begins, there are a number of properties of user interface software that make it more complex than ....

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

....some best meeting date location to the intended participants that fit their constraints, or notifying them that no solution can be found with those constraints. Goal reduction and specification refinement are thus much intertwinned, as already pointed out at a lower level of development [Swa82]; the way a goal is reduced often impacts on its informal definition and vice versa. Our experience revealed that the diversity of conceivable decompositions for some goals can be a problem. Sometimes we felt uncomfortable in deciding which goal decomposition would be the most adequate. It is only ....

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.

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.

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

CiteSeer.IST at NUS - Copyright Penn State and NEC. Hosted by the School of Computing, National University of Singapore.