Binah: Vision

 

Version: Inception [05 Mar 2003]

An object-oriented program's run-time structure often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program's run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa."

Gamma, et al., Design Patterns


"Escaping this flatland is the essential task of envisioning information-- for all the interesting worlds (physical, biological, imaginary, human) that we seek to understand are inevitably and happily multivariate in nature. Not flatlands."

Edward R. Tufte, Envisioning Information

Project Vision and Business Case

This document gives the vision and business case for the Binah project. This page is divided into the following sections:

  1. Introduction
  2. Positioning
  3. Stakeholder Descriptions
  4. Product Overview
  5. Summary of System Features

Introduction

We envision a tool that allows the visualization of the execution of multi-threaded Java programs to provide assistance with identifying and debugging concurrency problems. By analogy, the Binah is to traditional debuggers as an UML diagramming tool is to a source-code editor-- both are needed, but they are useful at different levels of abstraction.

Return to top

Positioning

Although threads have become a de facto tool for exploiting parallelism in Java applications, there remains little debugging support for the concurrency problems that arise from their use. Unfortunately, Java debugging tools are generally insufficient to illuminate the run-time behavior of these multi-threaded applications. Often, developers and maintainers of such systems are forced to turn to massive trace logs of events or other custom instrumentation to record and understand the behavior of the application.

We see this as an oppurtunity to provide a useful and needed tool to high-end system integrators and their clients, especially those using application servers that provide little or no run-time analysis tools.

Return to top

Stakeholder Descriptions

Stakeholder (Non-User) Summary

The primary non-user stakeholders of this system are the class participants, both students and instructors, of CS 362 at Iowa State.

A secondary set of non-user stakeholders are the businesses that provide tools for, and thus rely on, the development of complex server applications, such as BEA Systems, the owner of the Weblogic application server, and IBM, the owner of WebSphere.

Another secondary set of stakeholders are the companies that rely on large, complex server applications using Java as a primary aspect of their business. For example, Charles Schwab, a financial services company that uses a J2EE application to handle about 35,000 queries and transactions per hour.

User Summary

The user of the system is a Java developer or system maintainer who is responsible for the correct and efficient operation of a large, complex Java-based application. This person may or may not already be familiar with the general operation of the system, but they should be reasonably fluent with Object-Oriented techniques, Java programming and traditional debugging methods.

Key High-level Goals and Problems of the Stakeholders

  • The students require a project of sufficient flexibility to practice software design skills, while still being a fun, non-trivial project with potential real-world application. In addition, students wish to explore the in-depth the workings of a Java Virtual Machine and gain experience designing effective visualization techniques using 3D graphics.
  • The Instructors of CS 362 require a project of sufficent scope and originality to guage the design and implementation performance of the students involved in the development of the project.
  • The businesses providing tools for the development of complex applications in Java want cheaper and faster development of more reliable and robust applications, as that will increase the value of their offerings at no additional cost to them.
  • The businesses that rely on such complex applications have an obvious interest in ensuring those applications are stable and robust, and if problems do arise, that they are solved quickly. In addition, they are interested in reducing the cost of training new developers on the workings of the application.

Key High-level User Goals

The users need a system to fulfill these goals:

  • Decrease the time required to understand a complex Java application through visualization of its operation.
  • Understand the object-level behavior of a system over time to assist in finding the source of incorrect or problematic behavior.
  • Be able to view, comprehend and debug threading-interaction problems, such as deadlocks.
  • Easily view the allocation and clean-up of objects in the JVM during execution with a comprehension of the relative sizes of objects in memory.
  • Or, in summary, to improve their understanding of the execution-time behavior (both aberrant and correct) of a multi-threaded, Java-based application beyond that gained using traditional debuggers.

Return to top

Product Overview

Binah provides a visulaization of the execution of a Java application. It uses the Java Debug Interface along with optional Java code instrumentation in the application to display the state of the running application and JVM in a scale-variable, three-dimensional manner using the Java 3D API.

Return to top

Summary of System Features

The system provides:

  • A three-dimensional view of the objects, threads and interactions of the running application.
  • A representation of the threads of execution and their held locks, ideally in such a way as to illuminate potential concurrency issues.
  • A plug-in to the Eclipse editor to allow source-level debugging and stepping control while viewing and interacting with the 3-D visualization.
  • Support for running the application on separate JVMs and/or separate physical computers.

Return to top

Last modified Monday April 28, 2003.

Copyright 2003.