|
Software Research Lab |
|||||
Current
Projects
|
|
Rubin (Andriy Hnativ, Christopher Dutchyn) Rubin is an extension to the Ruby interpreter (JRuby), and its purpose is to make irb better support interactive program development. The purpose of the Ruby interpreter, irb, is to develop and test code fragments that will eventually form a complete program. Programming with irb is an interactive process, expected to provide immediate feedback from the Ruby interpreter, typically warnings and error messages that show inconsistencies or programming mistakes, when code is executed. However, a program fragment can be executed only when all dependent fragments are also written. |
|
 |
|
|
This may introduce a potentially substantial delay between programming and validation, filled with distractions from writing the needed dependent code. Another possible problem arises with the use of control-flow statements, as Ruby (unlike Java or C) allows programmers to produce different results in different branches. This may lead to unexpected results much later in the code. |
|
 |
|
|
As a result, error messages are emitted later than necessary, and may appear in other blocks of code than where the error originates. Essentially, irb lacks a type checker: a system to infer types and check their consistency before code is executed. This is not surprising, given the obstacles that irb’s interactive code development raises for type checking. As one develops a program, code fragments are written and re-written; each are difficult to validate in isolation, and complex to merge and re-check collectively. We have implemented a system, Rubin, that reports type errors for incomplete irb programs, by verifying code blocks as they are developed, and checking that they mesh correctly with other code blocks as the developer changes and replaces them. By using principal typings inference, our tool adds lightweight type checking to the Ruby language without changing the syntax. As a result, coders will be able to reduce development time by more precisely locating errors at a better time in the development process. We are planning a usage and utility study of Rubin. If you are interested in learning more about this study, please contact Andriy or Chris and more details will be provided. Updates and more information about Rubin will be here in a couple of days! |
|
|
SoftSphere: Dynamic Visualization of Coupling in Java Programs |
|
Bluewall The purpose of the BlueWall is to evaluate the benefits of large and interactive display spaces with respect to software development, collaboration, and management. Reasonably sized software projects require interaction amongst management, developers, potential users and customers. Projects involving the BlueWall will look at ways to enhance this interaction using vast screen real estate, and automation of common tasks. The BlueWall consists of eight 30" Apple Cinema Displays, a Sony VPL-VW100 1920 x 1080p projector, one 45" display, and a 21" Wacom Cintiq 21UX LCD tablet. Two PowerMac G5 Quad Cores are used to drive the displays and provide a user-friendly system for interaction. Support for portable devices such as PDAs and laptops is also something the BlueWall looks to support. |
|
3D Software Visualization To better understand what issues arise when visualizing software and software artifacts in three dimensions, we have created two technical reports. The first was a preliminary survey on previous work in 3D software visualization. A number of issues were identified, and possible technical solutions were offered. The second report describes a prototype -- SoftSphere -- that was created to see how coupling between Java classes can be visualized. This graph-based visualization used three-dimensions, clustering algorithms and animation to show how the coupling between classes can change between versions. |
|
 |
 |
|
SoftSphere: Dynamic Visualization of Coupling in Java Programs |
|
|
Treemap Visualizations We are currently looking at using Treemap layouts to represent the hierarchical structure of software. We have constructed a prototype that explores how source code can be arranged in a treemap-like fashion. The goal is to be able to better support software engineering tasks by utilizing spatial memory. The prototype arranges code files according to their place in the software hierarchy. At the moment we are investigating other arrangements based on other types of software relationships. |
|
 |
 |
Eclipse Eclipse is IBM's IDE and is being worked on by top computer science research departments in U.S. and Canada. Our lab in collaboration with the deparmtent's Human Computer Interaction Lab is developing a plug-in for Eclipse to perfor source code analysis, transformations, and visualizations. |
|
|
2004 CMPT 856 Class Projects CMPT 856 is an advanced Software Engineering graduate course that is concerned with tools, methods, methodologies, and standards in the software engineering of conventional information systems, hypermedia and multimedia systems, and knowledge-based systems. Topics are to be selected from the following: requirements specification methodologies, object oriented modeling and design methodologies; process modeling; formal specifications; transformations; integrated CASE environments; software testing, validation and verification; software metrics; quality assurance; software estimation; knowledge-based tools and techniques in CASE; interactive-graphic human interfaces; reverse engineering; and CASE standards. |
|