R. Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Trans. Software Eng. SE 11 (Nov., 1985), . 31  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Outputs of the process are the target implementation, goal graphs, and a prediction of performance [36] calculated in terms of a performance model. It is interesting to contrast the treatment offered in this section with other research based on the transformational approach, such as the TI system [2]. TI, like its transformation based peers, focuses on correctness requirements, i.e. making sure that the generated implementation is consistent with the original specification. Performance, if treated at all, is treated as a selection criterion among alternative transformations. Kant s early ....

R. Balzer, "A 15 Year Perspective on Automatic Programming" IEEE Trans. Software Eng., vol. SE--11, no. 11, Nov. 1985, pp. 1257--1268.

....and complexity of input specifications. They require only modest understanding of the details of library procedures for successful reuse. Our techniques allow restructuring of data to meet new requirements or to improve efficiency. Traditional languages reflect the data implementation in the code [3], making changes costly. Our system derives code from the data definitions; design decisions are stated in a single place and distributed by compilation rather than by hand coding. The ability to produce code in different languages decouples the choice of programming tools from the choice of ....

R. Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Trans. Software Engineering, vol. 11, no. 11 pp. 1257-1267, Nov. 1985.

....in this area is automation: it is widely accepted that development of software will become easier and cheaper if more of it can be formalised and automated. In effect, this has meant that the boundary of automation has crept steadily upstream, to the earlier stages of the development process [Balzer 1985]. Complimenting this trend is the introduction of formal methods which ensure that each step in the development process is formally justified, allowing the products of the process to be formally verified. Precise definition is vital for the requirements specification. There is always a degree of ....

Balzer, R., 1985, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on Software Engineering, Vol SE-11, No 11.

....o o o o o o o Application UI Application Conceptual Model Generation step Figure 2. Generating UIs in TACTICS. While transformations in software engineering have been used for generating functional code for a target program from a high level specification and for performing optimizations [Balzer 85, Darlington 81, Partsch 83] UIDE was the first to apply the transformation approach to UI design. TACTICS improves on UIDE in two aspects. The first improvement is a separate UI representation capturing UI specifics at finer level of details than in UIDE. While UIDE keeps UI details together ....

Balzer, Robert, "A 15 Year Perspective on Automatic Programming," IEEE TSE, Vol. SE-11, No.11, November 1985, pp. 1257-1268.

.... place emphasis on automated software construction, specifically identifying the important role of formal specifications as the key to validation of user requirements and the important role of formal specifications as the key to validation of user requirements and generation of the system itself [1]. It is suggested that maintenance is not conducted directly on generation of the system itself [1] It is suggested that maintenance is not conducted directly on the system itself, but rather on the specification, with new versions of the system automatically the system itself, but rather on ....

.... formal specifications as the key to validation of user requirements and the important role of formal specifications as the key to validation of user requirements and generation of the system itself [1] It is suggested that maintenance is not conducted directly on generation of the system itself [1]. It is suggested that maintenance is not conducted directly on the system itself, but rather on the specification, with new versions of the system automatically the system itself, but rather on the specification, with new versions of the system automatically re generated from that new ....

[Article contains additional citation context not shown here]

R. Balzer, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on R. Balzer, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on Software Engineering, SE-11 (11), Nov. 1985

....defined to be equivalent if they have the same semantics. In the model based approach, all the required proofs are captured in a library of general purpose transformations, but if the model is weak a plethora of low level transformations is applicable at each step (as has been reported by Balzer [6]) In contrast, experience to date with transformations defined using denotational semantics, and proved using weakest preconditions expressed in infinitary logic, suggests that the method is sufficiently powerful to form the basis of a practical transformation system. The basis for our formal ....

R. Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Trans. Software Eng. SE 11 (Nov., 1985), .

.... emphasised automated software construction, specifically identifying the important role of formal specifications as the key to validation of user requirements and generation of the system itself specifications as the key to validation of user requirements and generation of the system itself [Balzer 85] It is suggested that maintenance is not conducted directly on the system itself, but [Balzer 85] It is suggested that maintenance is not conducted directly on the system itself, but rather on the specification, with new versions of the system automatically re generated from rather on the ....

.... specifications as the key to validation of user requirements and generation of the system itself specifications as the key to validation of user requirements and generation of the system itself [Balzer 85] It is suggested that maintenance is not conducted directly on the system itself, but [Balzer 85] It is suggested that maintenance is not conducted directly on the system itself, but rather on the specification, with new versions of the system automatically re generated from rather on the specification, with new versions of the system automatically re generated from that new ....

R. Balzer, "A 15 Year Perspective on Automatic Programming", IEEE R. Balzer, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on Software Engineering, SE-11 (11), Nov. 1985

.... part or parameters of the abstraction [15] The abstraction realizations represent the different instances of the abstraction however it is convenient to represent them [15] Much of the AI work on automatic programming is based on instantiating or specializing reusable program templates [1] (sometimes called frames[2] or cliches [28] which may also be considered as program families of sorts. There are a number of factors to consider when designing a program family. By and large, program families Intrator Mili Page 3 have the potential of: 1) Saving on development and ....

Robert Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Transactions on Software Engineering, vol. SE-11, no. 11, pp. 1257-1268, November 1985.

....generator that generates executable code from the specification (Prywes 1979) Further examples are Gist and SETL. Gist models objects as sets, operations as functions, and can be compiled into another language and executed. It also provides a library of transforms to refine the specification (Balzer 1985). SETL is an executable, procedural, but very high level language developed at New York University (Smith 1985) and it has general finite sets, maps relations, and tuples as its basic data types. 2.4.3 Transformational Systems The objective of transformation systems is to allow the system ....

Balzer, R. (1985), "A 15 year Perspective on Automatic Programming", IEEE Trans on Software Engineering, September.

.... in OO systems (shared data is objects, toolies are methods) 6, 13] spreadsheets (shared data is cells, toolies are formulae) 4] structureoriented editors (data is abstract syntax trees, toolies are attribute equations) 17] and rule based systems (data is shared data pool, toolies are rules) [2]. We now describe an environment for general purpose TA based design, and also elaborate on the KWIC design, TA notation and how toolies and ADSs interact. 3. Event propagation views ViTABaL event propagation views describe the interconnections between toolies and ADSs. These interconnections ....

....construct TA based systems by interacting directly with toolies and event flows, rather than working with textual equations or grammars. Other languages supporting TA construct these connections via dependency analysis (attribute grammars, 17] patterns and rule resolution (production systems, [2]) or active data rules (Smalltalk MVC, 13] These are much more difficult to visualise, both statically and dynamically, than are ViTABaL event propagation and execution views. ViTABaL also supports easier definition of complex systems via multiple views (both hierarchical and multiple ....

Balzer, R., "A 15 Year Perspective on Automatic Programming," IEEE Transactions on Software Engineering, vol. 11, no. 11, 1257-1268, November 1985.

.... from pb[ 1 mod M) 1] pb[ 1 mod M) 1] from pb[1] link pa[1] to pb[1] pb[1] to pa[1] pa[ 1 mod N) 1] to pb[ 1 mod M) 1] pb[ 1 mod M) 1] to pa[ 1 mod N) 1] The corresponding change transaction is: MERGE TRANSACTION: Evolving Philosophers page 21 August 19, passivate pa[N] pa[1] pa[2],pa[3] pb[M] pb[1] pb[2] pb[3] unlink pa[1] from pa[2] pa[2] from pa[1] pb[1] from pb[2] pb[2] from pb[1] link pa[1] to pb[1] pb[1] to pa[1, pa[2] to pb[2] pb[2] to pb[2] activate pa[N] pa[1] pa[2] pa[3] pb[M] pb[1] pb[2] pb[3] To justify that this change maintains an acyclic precedence ....

.... pb[ 1 mod M) 1] from pb[1] link pa[1] to pb[1] pb[1] to pa[1] pa[ 1 mod N) 1] to pb[ 1 mod M) 1] pb[ 1 mod M) 1] to pa[ 1 mod N) 1] The corresponding change transaction is: MERGE TRANSACTION: Evolving Philosophers page 21 August 19, passivate pa[N] pa[1] pa[2] pa[3] pb[M] pb[1] pb[2],pb[3] unlink pa[1] from pa[2] pa[2] from pa[1] pb[1] from pb[2] pb[2] from pb[1] link pa[1] to pb[1] pb[1] to pa[1, pa[2] to pb[2] pb[2] to pb[2] activate pa[N] pa[1] pa[2] pa[3] pb[M] pb[1] pb[2] pb[3] To justify that this change maintains an acyclic precedence graph we need only be To ....

[Article contains additional citation context not shown here]

BALZER, R. "A 15 Year Perspective on Automatic Programming", BALZER, R. "A 15 Year Perspective on Automatic Programming", IEEE Transactions on IEEE Transactions on Software Engineering, SE-11 (11), Nov. 1985.

....of 4th IEEE Workshop on Future Trends of Distributed Computing Systems, Lisbon, Sept. 1993. The System Architect s Assistant for Design and Construction of Distributed Systems Jeff Kramer, Jeff Magee, Keng Ng and Morris Sloman Department of Computing, Imperial College, London SW7 2BZ. Abstract Distributed systems are conveniently described, constructed and managed in terms of their software structure or architecture. However few current platforms exploit the architectural view. This paper outlines current work on the provision of an architectural methodology and graphical ....

....to evolution as changes to a system configuration. In contrast to the specification driven approach, our approach to distributed systems design is constructive . The specification driven approach attempts to formalise the decomposition process based only on the system specification [2] We believe that this process of component identification remains informal as it requires design information not usually included in the system specification. Decomposition is best dealt with through 1 In the paper, we use the neutral term component to mean a software entity which encapsulates ....

[Article contains additional citation context not shown here]

R.Balzer, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on Software Engineering, SE-11 (11), Nov. 1985

No context found.

R. Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Trans. Software Eng. SE 11 (Nov., 1985), . 31

No context found.

R. Balzer, "A 15 Year Perspective on Automatic Programming ", IEEE Trans. Software Engineering 11, Nov. 1985, pp. 1257-1268.

No context found.

R. Balzer, `A 15 year perspective on automatic programming' IEEE Trans. Software Engineering, SE11, (11), pp. 1257--1268 (1985).

No context found.

Balzer, Robert, "A 15 Year Perspective on Automatic Programming", IEEE Transactions on Software Engineering, Volume SE-11, Number 11, November 1985, pp. 12571277.

No context found.

Balzer R. (1985). A 15 year perspective on automatic programming. Pages 1257-1268 in IEEE Transactions on Software Engineering 11(11), November 1985.

No context found.

Robert Balzer, "A 15 Year Perspective on Automatic Programming," IEEE Transactions on Software Engineering, Vol. SE-11, No. 11, November 1985, pp. 1257-1268.

No context found.

B. Balzer, "A 15 year perspective on automatic programming", IEEE Trans. on Software engineering Vol. 11 No. 11, 1985, pp. 1257-1267.

No context found.

R. Balzer. "A 15 Years Perspective on Automatic Programming", IEEE Transactions on Software Engineering, Vol. SE-11, NO.11, pp. 1257-1268, Nov. 1985

No context found.

B. Balzer, "A 15 year perspective on automatic programming," IEEE Trans. on Software engineering SE11 (11) 1985, pp. 1257-1267.

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