Engels G., Lewerentz C., Nagl M., Schfer W., Schrr A.: Building Integrated Software Development Environments Part I: Tool Specification, in: acm Transactions on Software Engineering and Methodology, vol. 1, no. 2, New York: acm Press  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of the process which requires more tight integration with development tools than what is currently available. Other relevant works in the field of software engineering and methodology describe techniques and approaches to integrate different tools more efficiently and effectively. Engels et al.[16] describe an approach to building integrated software development environments using attributed graphs to model and implement object structures such as software documents and their relationships. The resulting approach is suited for environments developed from scratch and not as well suited to ....

G.Engels,C.Lewerents,M.Nagl,W.Schafer, and A. Schurr. Building integrated software development environments part i: Tool specification. ACM Transactions on Software Engineering and Methodology, 1992.

....between version sets. 1: m and 1: n relationships are modeled through non functional features called roles [50] This extension will introduce and unify versioning concepts in graph structured applications such as computer aided design (CAD) 26] or graph based software development environments [13, 48]; first results are given in [63] Support of the SCM process. On the conceptual level, we must find out if and how SCM processes might be formalized using the version set model and whether SCM tool behaviour may be verified against the SCM process. We imagine organizing the SCM process entirely ....

Engels, G., Lewerentz, C., Nagl, M., Schfer, W., and Schrr, A. Building integrated software development environments---Part 1: Tool specification. ACM Transactions on Software Engineering and Methodology 1,2 (1992), 135--167.

....of goals, but also the re establishment of a dialog goal in case of a goal failure. Goal monitoring is performed actively, so that violations are detected immediately; however, this requires a consumption of resources that hand held devices cannot bear. Software development environments [9, 21, 7] have devised mechanisms for specifying consistency constraints between artifacts. They are able to detect static violations of these constraints and resolve them automatically, for example, by propagating changes to dependent documents. Inconsistencies are often found in requirements documents, ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments --- Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

....of an SDE is judged by its ability to enable incremental, intertwined, and syntax directed development of documents. Good SDEs also provide for maintenance of these documents, tracing back of errors through different documents, and change propagation through document boundaries to correct errors (Engels et al. 1992; Habermann and Notkin, 1986) These environments are also expected to provide multi user and often geographically distributed support. They should have flexible and adaptable mechanisms to facilitate controlled sharing of information by a number of users. These environments usually require the ....

Engels, G., C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. 1992. Building integrated software development environments. - Part 1: Tool specification. ACM Trans. Software Engineering and Methodology 1(2): 135-167.

....maintained by PSEEs, leading to a proliferation of types that must be transformed to the relational model. Consider storing a complex data object, such as an abstract syntax graphs (ASG) which is used as the common internal representation of a set of syntax directed tools in an existing PSEE [37, 36]. Like other graphs, an ASG is composed of a set of nodes and edges. Each node has an identity and a type that defines the attributes associated with the node. The attributes can be either flat (e.g. an integer) or structured (e.g. an error list) Edges can be one to one (from a single node to ....

Gregor Engels, Claus Lewerentz, Manfred Nagl, Wilhelm Schaefer, and Andy Schuerr. Building Integrated Software Development Environments. ACM Transactions on Software Engineering and Methodology, 1(2), 1992.

....for querying source code representations. In GUPRO modeling is enabled by the definition of graph classes. Graphs constitute a vivid formal mathematical model as well as an efficient data structure with time tested algorithms providing a seamless approach to modeling and implementation [18][19]. Classes of graphs are specified using extended entity relationship (EER) diagrams [6] that can be annotated by additional constraints in the Z like GRAL specification language [21] Such EER GRAL models are used to specify the underlying graph data structure. This consists of a rather general ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building integrated software development environments part I: Tool specification. ACM Transactions of Software Engineering and Methodology, 1(2):135--167, Apr. 1992.

....the two formalisms and their relative merits are discussed. 1 Introduction The mid and the late eighties saw a proliferation of different programming environment generators, some of the best known among them being the Synthesizer Generator [37] Centaur [9] Pan [7] Mentor [12] PSG [6] IPSEN [14], Pecan [36] Mjolner [32] Yggdrasil [10] GIPE [21] and ASDL [27] Very recently there has Mailing address: German National Research Center for Computer Science, GMD FIRST, Rudower Chaussee 5, D 12489 Berlin, Germany. email: ma first.gmd.de y Computer Engineering and Networks Laboratory, ETH ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building integrated software development environments Part I: Tool specification. ACM Transactions on Software Engineering and Methodology, 1(2):135 -- 167, April 1992.

....and to [35] as well as to [44] and to [58] the two Ph.D. thesises that present a formal definition of a PROGRES language kernel and the design of its programming environment, respectively. Further details concerning the evolution of an accompanying graph grammar engineering method may be found in [17,16,50]. 13.2. SPECIFICATION AND VHL PROGRAMMING LANGUAGES 491 13.2 Specification and VHL Programming Languages Writing a compact comparison of PROGRES with related work is a rather challenging job. There are too many aspects which have to be taken into account due to the fact that PROGRES is an ....

....for writing and developing specifications in a methodological way. As described in Chapter 5 graph (grammar) technology has been quite suc 542 CHAPTER 13. PROGRES: LANGUAGE AND ENVIRONMENT cessfully used for developing integrated project support environments within the IPSEN project. 17] and [16] document the growing knowledge on how to model internal data structures of software engineering environments as graphs and how to specify operations on them by means of graph rewrite rules. Compared to the former papers, the graph grammar engineering approach presented in [50] is no longer ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building integrated software development environments -- part 1: Tool specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

....combine the text of many different nodes and attributes to form the text to be handed to a specific application. Where we have taken the approach that the node granularity is to be kept at a certain level (guided by a set of principles, such as those in figure 2) the IPSEN project described in [3] is based on directed attributed graphs. Attributes are attached to nodes only, and are related through directed edges. Both nodes and edges have types. When going to such fine grained structure, there is no longer a need for anchors, at the cost that all structure must be represented at the same ....

G. Engels, C. Lewerenz, M. Nagl, W. Schafer, and A. Schurr. Building integrated software development environments part I: Tool specification. ACM Transaction on Software Engineering and Methodology, 1(2):135--167, April 1992.

No context found.

Engels G., Lewerentz C., Nagl M., Schafer W., Schurr A.: Building Integrated Software Development Environments Part I: Tool Specification, in: acm Transactions on Software Engineering and Methodology, vol. 1, no. 2, New York: acm Press (1992), 135-167

.... types or graph manipulating tools (cf. 8, 13, 14, 15] Early attempts to define graph manipulation languages may be found in [38, 32] Currently, the multi paradigm language PROGRES is the latest and most expressive descendent of a whole family of application oriented graph rewriting languages [11, 12, 47]. It is a partly diagrammatic, partly text oriented language that has already been used for . specifying tools and data structures of integrated software engineering environments [12, 34] its main application area) describing tools for process modeling, version control, and configuration ....

....latest and most expressive descendent of a whole family of application oriented graph rewriting languages [11, 12, 47] It is a partly diagrammatic, partly text oriented language that has already been used for . specifying tools and data structures of integrated software engineering environments [12, 34] (its main application area) describing tools for process modeling, version control, and configuration management in CIM environments [50] defining the semantics of a visual database query language [1] and finally as the underlying fundament of a new approach to diagram parsing [43] ....

[Article contains additional citation context not shown here]

Engels G., Lewerentz C., Nagl M., Schfer W., Schrr A.: Building Integrated Software Development Environments Part I: Tool Specification, in: acm Transactions on Software Engineering and Methodology, vol. 1, no. 2, New York: acm Press (1992), 135-167

....commonly considered to be one of the first attempts at two dimensional query languages, Work supported by COMPUGRAPH II, ESPRIT BRWG 7183. 1 The term hybrid was inspired by hybrid syntax directed editors, where the user can freely choose between a syntax directed and a free style of editing [16]. 1 already offers facilities along this line. Indeed, while join conditions and selections are entered graphically (that is, in table skeletons) complex conditions involving e.g. aggregate functions, should be entered in plain text in a so called condition box . Similar facilities are ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments, Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, Apr. 1992.

....and to [8] as well as to [9] and to [10] the two Ph.D. thesises that present a formal definition of a PROGRES language kernel and the design of its programming environment, respectively. Further details concerning the evolution of an accompanying graph grammar engineering method may be found in [11,12,13]. 4 1.2 Specification and VHL Programming Languages Writing a compact comparison of PROGRES with related work is a rather challenging job. There are too many aspects which have to be taken into account due to the fact that PROGRES is an object oriented data modeling language, a kind of formal ....

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building integrated software development environments -- part 1: Tool specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

No context found.

Engels G., Lewerentz C., Nagl M., Schfer W., Schrr A.: Building Integrated Software Development Environments Part I: Tool Specification, in: acm Transactions on Software Engineering and Methodology, vol. 1, no. 2, New York: acm Press

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, A. Schrr, "Building Integrated Software Development Environments Part 1: Tool Specification," ACM Trans. Software Engineering and Methodology, Vol. 1, No. 2, Apr. 1992, pp. 135-167.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr, "Building Integrated Software Development Environments --- Part 1: Tool Specification," ACM Trans. on Software Engineering and Methodology, vol. 1, no. 2, pp. 135--167, 1992.

No context found.

G.Engels et al., Building Integrated Software Development Environments part I: Tool Specification, ACM Trans. on Soft. Engin. and Method., 1.2 , (

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments --- Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr, "Building Integrated Software Development Environments --- Part 1: Tool Specification, " ACM Trans. on Software Engineering and Methodology, vol. 1, no. 2, pp. 135--167, 1992.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments --- Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992. 16

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Sch#afer, and A. Sch#urr. Building Integrated Software DevelopmentEnvironments --- Part 1: Tool Speci#cation. ACM Transactions on Software Engineering and Methodology, 1#2#:135#167, 1992.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Sch#afer, and A. Sch#urr. Building Integrated Software DevelopmentEnvironments. ACM Transactions on Software Engineering and Methods, 1, 1992. To appear, also Technical Report 60, Universityof Dortmund, Dept. of Computer Science, Chair for Software Technology.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Sch#afer, and A. Sch#urr. Building Integrated Software DevelopmentEnvironments --- Part 1: Tool Speci#cation. ACM Transactions on Software Engineering and Methodology, 1#2#:135#167, 1992.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments --- Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

No context found.

G. Engels, C. Lewerentz, M. Nagl, W. Schafer, and A. Schurr. Building Integrated Software Development Environments --- Part 1: Tool Specification. ACM Transactions on Software Engineering and Methodology, 1(2):135--167, 1992.

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