1 / 1

Włodzimierz Funika, Marcin Białek, Piotr Pęgiel, Marcin Smętek

JINEXT. EVENTS: Stop Line Debugger Error List Watches. EVENTS : Set Break Point Begin Debugging Continue Step Source Changed. ACTIONS u pon : Debugger Error Source Changed List Watches. ACTIONS: Upon Begin Debugging Upon Set Break Point Upon Continue Upon Step. Editor window

sarah
Download Presentation

Włodzimierz Funika, Marcin Białek, Piotr Pęgiel, Marcin Smętek

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JINEXT EVENTS: • Stop Line • Debugger Error • List Watches EVENTS: • Set Break Point • Begin Debugging • Continue • Step • Source Changed ACTIONS upon: • Debugger Error • Source Changed • List Watches ACTIONS: • Upon Begin Debugging • Upon Set Break Point • Upon Continue • Upon Step Editor window with application source code Registering the debugger in the J-OCM/JINEXT References: Advantages that come from using interoperable software: • Possibility of concurrency aware software development process. • New possibilities of team work (program can be simultaneously debugged by many distant users), and immediately exchange ideas. • Allows for faster development of scalable applications • Arkadiusz Janik, Kraków 2004: Interoperabilność narzędzi wspierających rozwijanie aplikacji w języku Java • Roland Wismüller: Interoperable Laufzeit-Werkzeuge für parallele und verteilteSysteme, Habilitationsschrift, Universität Munchen, 2001 • Marcin Smetek: OMIS-based Monitoring System for Distributed Java Applications. Master of Science Thesis. Kraków June 2003 Cooperation between Debugger and Editor A Case Study of Interoperability in a Distributed Tools Environment Włodzimierz Funika, Marcin Białek, Piotr Pęgiel, Marcin Smętek Institute of Computer Science AGH, Mickiewicza 30, 30-059 Kraków, Poland <funika@agh.edu.pl, bialekmarcin@poczta.fm, barca@wp.pl, smetek@agh.edu.pl> Situation before interoperability: What is interoperability? Let’s imagine that an editor and a debugger operate on the same application. Programs are being run on separate machines and all communication between team members goes by separate channel (e.g. icq). This approach demands special time effort needed for communication, and leads to further mistakes and misunderstandings. • the ability of two or more systems or components to exchange information and to use this information • the ability of two or more software components to share andprocess common information • the ability of two or more software components to cooperate with each other • the property of the independently developed software components of interaction between each other INTERNET INTRANET User 2 User 1 Goals of research: Communication • Introducing JINEXT interoperability monitoringfeatures • Showing cooperation between commonly known software tool types • Introducing new way to monitorcooperative work of programming teams in distributedcommunication model Editor 1 Editor 2 Debugger 1 Debugger 2 Application Computer 1 The new approach – asystem with interoperability support Editor description: • Features of a commonly used editor software such as:- code/text files operations- saving/editing multiple files • Allows to control debugger (setting break points, starting debugger instance,setting watches) • Allows the visualization of debugger current state (current line, variables state) • Allows multi-user synchronization (detects changes in source code done by other users) • Written in C++ with use of Qt and gtk+ To cope with the problem we have introduced a layered architecture. Software layer: commonly known software tools Debugger 1 Editor 1 Tool layer: Tool layer represents theproxy patternfor software tools. It's responsible for: • Interacting with JINEXT mediator – sending events and registering for specific actions. • Cooperation with our software tools (currently editor and gdb debugger) Editor tool type Debbuger tool type Mediator layer:JINEXT allows each cooperating application to retain transparency of its implementation. As a result the applications do not need to know anything about each other and they are still able to work together. Debugger description: As the debbuger we used gdb runinng in the full text mode (outputs everything), our proxy template (debugger tool type proxy) allowed it to expose main debugger features for the editor. J-OCM Monitoring system layer: J-OCM is an implementation of the J-OMIS specification. J-OCM consists of a set of distributed components providing tools with interactive access to the Java application and runtime environment. Application Features of new interoperability tools:

More Related