Projects

• Dynamic System Adaptation
• Function Migration Decision-Making
• Protocol Monitoring Gauge
• Acme to UML Translator
• Acme to UML
• Jini Technology
• Problem Solving in Software Design

The work falls under the Adaptation area of the Rainbow project; please see the Rainbow page for background information.

More detail is forthcoming.

As the course project for the Advanced Operation Systems course, three of us formed a team to investigate the decision-making schemes for function migration. Function migration is a technique used in a distributed computing environment that relocates functions to processes of relatively higher resource availability in order to minimize execution time (or balance load, etc., depending on purpose).

Given a large number of objectrs (functions) executing in the system, there must exist an optimal placement of all the functions such the desired system property (e.g. aggregate execution time) is minimized. Intuitively, this can be achieved by a centralized placement decision maker. Unfortunately, centralized mechanisms do not scale well in a distributed environment, and the alternative is to use decentralized mechanisms. The degree of decentralization can vary, can the number of decision schemes available reflects the many ways one can mix centralized and decentralized approaches. Generally, the problem with decentralized mechanisms is that they're likely to fall into local maxima because they lack the global picture.

Our project seeks to determine to what degree a centralized function migration decision making scheme is useful, and to what degree a decentralized scheme is useful (a specific scheme, believed to be fairly representative of decentralized schemes, was chosen). A test system will be built on which to run experiments, and the data will be used to devise a hybrid scheme to combine the best of both types of approaches.

The work falls under the Detection/Resolution areas of the Rainbow project; please see the Rainbow page for background information. A gauge is a monitoring device attached to a system model that "gauges" a certain property of the system and relays any changes to the system model.

The aim of this work was to develop a high-level gauge capable of accepting a protocol specification (written in a light-weight, CSP-like language used by LTSA) from, say, a connector property of the system model, and internally keeping track of the protocol as a state machine. The gauge then observes the system for protocol interactions across the connector and validates the interaction against its internal protocol state machine. Any protocol violation is relayed to the system model and possibly to a human observer and a visualization tool that can show, for example, how the violation occurred on the state machine.

Work on this and other gauges is now in the hands of the one and only George (Elvis) Fairbanks.

This project is based on the paper, "Reconciling the Needs of Architecture Description with Object-Modeling Notations", by David Garlan, Andrew Kompanek and Pedro Pinto (Unpublished Manuscript).

Acme is a general purpose architectural description language (ADL) designed by the ABLE group at CMU. It provides a formal method to describe software architectures, and enables reasoning about the functional and non-functional properties of the system. An accompanying tool, AcmeStudio, provides a GUI that allows visualization and drag-and-drop creation of architectural designs. It is still in development, but a working version can be downloaded from here.

Because the Unified Modeling Language (UML) is a widely used object-oriented design standard, enabling the translation of Acme descriptions to models in UML becomes important for object-oriented designers who also wish to benefit from the strengths of Acme. The ultimate goal of this project is to develop a tool to automate this translation. Facilitating the translation of architectural designs to object-oriented models would encourage the use of architectural designs and benefit the software design community.

The current focus is to identify and resolve the feasibilities and ambiguities in syntactic and semantic mappings between Acme and UML.

Status, as of date:

• December 2000, a basic mapping has been established for the basic Acme elements of component, connector, port, and role.
• January 2001, a report has been drafted and is undergoing revision for publication.
• March 2001, a paper was completed and submitted to the Distributed Software Architecture session of the 2001 International Conference on Parallel Distributed Processing Techniques and Applications.
• April 2001, the paper was accepted as a "Regular research paper".
• June 27, 2001, the paper was presented at the PDPTA conference, Las Vegas, NV.

Ph.D. students in the Models course are required to complete a specification project. Taking my advisor's suggestion, I chose to specify Sun Microsystem's Jini technology. If you are interested, you can download the specification report here ([Postscript | http://mosquito.homeip.net/projects/JiniSpec-20001214.ps] | [PDF | http://mosquito.homeip.net/projects/JiniSpec-20001214.pdf]). I also gave a presentation on this topic, the slides of which you can view here.

In contrast, formal modeling provides a mathematical framework that allows designers to specify their design unambiguously, to catch inconsistencies, and, most importantly of all, to reason confidently about their design. This project applies knowledge from a software system models course to the formal specification of Jini. Two formal modeling techniques are used-Zed (Z) and CSP. The former uses schemas to describe the states of a system, while the latter supports parallelism and focuses on events, or transitions, of a system. Two fairly distinct aspects of a system can be described using these two types of models.

For system developers who wish to implement the Jini technology in their system, for application developers who wish to provide services for a Jini system, and for programmers who implement specific service functions, this project aims to provide a high-level model of the Jini system that serves as a starting point from which to refine and extend functionality.

First, we provide an overview of the aspects of Jini necessary to understand the formal specification. In part 1, we show the Z specification of the major aspects of Jini and prove two facts of Jini using the Z-Eves tool for Z. The aspects that are not modeled using Z are explained throughout part 1. In part 2, we give the CSP specification and demonstrate that no deadlock exists using the FDR checker for CSP. Similarly, the aspects that are not modeled using CSP are indicated throughout part 2. Finally, in part 3, we compare the experiences, advantages, and disadvantages of using these two modeling techniques.

The report can be downloaded from here ([Postscript | http://mosquito.homeip.net/projects/HPS-SwDesign-20001219.ps] | [PDF | http://mosquito.homeip.net/projects/HPS-SwDesign-20001219.pdf]). I also gave a presentation on this topic, the slides of which you can view here.

However, the more interesting question is, how far can we push the automation? What issues of design do we need to address and resolve to achieve software design automation? Toward this end, this research aims to attempt progress from a problem solving perspective. By looking at the problems solving skills that software designers use, in the context of presently available techniques, perhaps we can gain insight into the automation-related issues. We can ask, given a requirement statement, how do software designers produce software designs? What tools do they need, and what questions do they ask? Since software design is very much domain-specific, which in turn makes it technique dependent, it is also interesting to ask how designers using different techniques differ in this creative process?

More specifically, this research aims to explore the steps that software designers take to produce and analyze designs from statements of requirements, constrained by domain and the techniques that they use. Acquiring verbal protocols will be the primary weapon in this exploratory research. However, there are still several approaches to exploring this problem using this method; I will list three of them, and then select one. Before proceeding with any of these approaches, I need to come up with a relatively simple software problem-henceforth referred to as the "instruction"-that can elicit a fairly extensive design, so as to produce useful protocols. The instruction can be either complete or incomplete. The complete version allows the designer to work from beginning to end with no interaction from the researcher and, assuming that the designer is able to verbalize all his or her decisions, produce a fairly complete protocol. The incomplete version will require the designer to ask questions to clarify what exactly is needed, and is hence useful in probing, from the questions asked, what problem solving techniques the designer uses in producing the design. Since an actual software design process usually follows the second scenario, I will proceed in second style.

With the problem instruction, the first approach is to present it to two software designers who use relatively similar techniques to allow comparison and contrast. The second approach probes for similarity and differences in design paradigms based on the underlying programming language, and can be achieved by presenting the instruction to a designer who uses the popular object-oriented design approach, and to another who uses a functional design approach. The third approach seeks to examine the differences in design paradigms that are relatively less contrained by the programming language used for implementation, and can be achieved by presenting the instruction to an object-oriented-based designer and an architecture-based designer.

All three research approaches have their merits, but the third one has the prospect of offering insights into two fairly dissimilar perspectives of software design approach, without too much dependence on the programming language in which the software would be implemented. Therefore, this research will focus on the third approach. As a guideline for this research, we will operate on the hypothesis that the object-oriented and the architecture-based design paradigms result in distinct design approaches, and that each has advantages from which lessons of design can be learned.

As an exploratory research constrained to one semester, this effort is but one small step to gain insights into the human problem solving aspects that are relevant to the more difficult problem of automating the software design process. In a larger context, the software design activity, like all design problems, is a difficult one to resolve because it requires human intelligence and creativity. A "silver bullet" for this werewolf of a design problem would be an automatic tool that could generate complete designs from statements of requirement, with a few points and clicks from the software designer. However, this tool is difficult, if not impossible, to realize. As a future goal, once we have a good approximating theory of how software designers approach a design problem, we can hope to simulate this process with a computer program, and be one step closer to arriving at the "silver bullet."