MORALE
Mission ORiented Architectural Legacy Evolution
Summer 1996 plan
Gregory Abowd
Introduction
This document is intended to outline the summer 1996 plans for the
MORALE project. We will discuss the objectives of the summer project,
some requirements on the project and then present a series of project
ideas.
We should quickly (by end of June), determine the project topic so
that we can begin working on the case study. We are aiming to have a
documented case study by October 1.
Objectives
The purpose for this project is to help us focus on how our individual
work efforts can be integrated and to help us figure out what tools we
have now and could most easily develop to include in the Morale
suite.
Our focus should be on a documented relatively small case
study that shows how we would maintain an evolutionary design journal.
We'll want to document existing requirements and changing requirements
in whatever form/structure that Colin desires/dictates. We'll want to
produce an architectural description of the existing system and
perform a SAAM analysis to provide an impact analysis of the new
requirements on that architecture. Finally, we will want to use some
reverse engineering techniques to increase our confidence of the
correspondence between architecture and artifact.
Project requirements
The project needs to be one that we can become familiar with
relatively quickly. For those reasons, it should be a relatively
small project. One suggestion for increasing familiarity is to make
the system one that at least one of the MORALE team has worked with
closely.
We need to have a system which is large enough to require some
architectural representation to portray the big picture that is not
entirely clear from looking at the source code itself.
I believe that the visualization/understanding tools we have only work
on a limited number of languages, so we should take that into
consideration.
Project suggestions
The following list of projects contains pointers to any further
project info, a brief description of the project and a discussion of
the advantages and disadvantages of this as a summer case study for MORALE.
Classroom 2000 is a project within the Future Computing Environments
Group. It has been running since September 1995. One of the main
artifacts of the project is an experimental note-taking and review
system. The existing system is divided into three distinct parts. The
first part is a pre-production facility that allows for an instructor
to produce electronic slides and consists of a simple Perl script that
bursts a PostScript file into a series of GIF/BMP images. The second
part is the in-class note-taking environment that runs on a variety of
pen-based computers running Visual Basic. The system allows students
and teacher to annotate the prepared slides and logs various user
activities and saves annotated slides. The live portion of the class
also consists of digital audio recording and currently analogue video
capture. The third part of the system is the post-production/review
facilities. The note-taking logs and annotated slides are processed
to produce a frame-based series of Web pages for review purposes.
Each lecture is available with streaming, indexed audio links attached
to each annotated slide. In addition, students are able to search
across a set of lectures for slides that pertain to certain keywords
(as determined by an automatically generated keyword index based on
the ASCII text of the prepared material).
There are a number of changes to the Classroom 2000 system that have
been suggested and will be implemented. Some of those are to convert
over to a Java-based note-taking environment so that the capture and
review systems can be identical. This will allow for updating of the
notes after a class. We also want to provide support for both
pen-based and keyboard editing of notes. We want to provide a means
to share notes during a lecture (students can plug into the
instructors notes or into each others notes under their control). We
want to improve the searching capabilities to include searches of the
students annotations or the digital audio. We want to support
cross-platform streaming, indexed audio using commercially available
services such as RealAudio. We want to provide support for streaming
indexed video services that are becoming commercially available within
the next year.
Some of the changes to Classroom 2000 are because of enhanced
capabilities of the environment. A special purpose classroom is being
constructed that will provide Ethernet capability to each student
seat. The room will also have enhanced audio and video capture
capabilities and presentation capabilities.
Advantages
This is a good-sized system with a history of use and a clear
evolutionary path. Abowd has already conducted a somewhat extensive
SAAM evaluation of the initial system that would serve as a good
starting point.
The problem of ubiquitous capture to support review is an important
one for future computing environments. It is not that much of a
stretch to imagine building a similar system to support collaborative
design. How to take an existing application and make it
"capture/review"-enabled would be a good contribution that could be
sold to DARPA on the grounds that it will apply to a lot of DoD
software development.
Disadvantages
Don't know what the reverse engineering people would be able to do
with this system. Various parts are in Perl and Visual Basic and the
intention is to move most of it to Java using an SQL-like database for
persistent storage of notes.
Calendar/meeting scheduler
There are a number of calendar projects being developed on campus.
There is the DISCS project in the Real World Lab.
This project is building a complete Web-based calendar system for the
campus (sponsored by OIT) using Oracle as a back-end persistent
storage mechanism with interesting group viewing functions. There is another OIT-sponsored calendar project,
Web Cal that
integrates the Sun Calendar Manager with a Web version to browse and
edit, good for a single user's meetings. Finally,
there is a two-part project (Part
1 and Part
2) on a Java-based calendar manager that
integrates with the the Xplan calendar system on unix. This last
project was done as part of Abowd's 3302 Introduction to Software
Engineering class. Part 2 further integrates the calendar with a Java
contact manager.
There are plenty of avenues of evolution for all of these systems.
One major one is to integrate the Web-based solutions with a PDA
solution. The basic idea is to be able to use any of a number of
calendar system interfaces all operating on the same individual and
group calendar information, leading to a more ubiquitous calendar
service. The single-user calendar services can be expanded to provide
valuable group services, as suggested by the DISCS project and the
Java calendar, neither of which is fully functional.
Advantages
Colin has a lot of experience with this domain, though it is not clear
that the scenario modeling for the new requirements listed above have
yet been considered. Abowd has interest in this if it moves to
integrating mobile platforms.
Web Cal is not all that complicated and appears to be the only really
functional and used system, though DISCS is ready for deployment.
We could leverage off of the RWL class this summer and the obvious
interest of OIT in this domain.
Disadvantages
Lots of CGI magic in DISCS and Web Cal projects. Not clear how we
would analyze these from reverse engineering perspective. Variety of
COTS and hardware options makes the problem very realistic, but is
there too much variety?
Carrying on from the calendar projects, the Future Computing
Environments group has a project that consists of building a number of
independent personal productivity tools in Java and then building a
mechanism to present all of these tools in an environment that
replaces the traditional stationary desktop with a more functional
active browser interface. The new interface would automatically
suggest integrating strategies to the user, so that a person listed in
a meeting scheduler could be automatically linked to a record of that
person in a contact manager. And this integration is done without
having to program the interaction in the individual applets
beforehand.
There are currently a number of productivity tools (to-do list,
contact manager, calendar tool, financial planner, mail tool. A few
of them have been integrated, either through explicit re-programming,
or by an experimental integration framework. The evolution of this
system is to bring all tools into a common browser desktop. It is
also planned to integrate the Web tools with some mobile tools, either
through PDA browsers running Java or through other data integration
mechanisms.
Advantages
Abowd has interest and has an architectural description (fairly
informal) of an integration mechanism. Two graduate students have
been in close contact with this project for a few months and one will
be very closely involved up until the end of September. This project
has a close tie with the calendar project described earlier and can in
fact be viewed as a requirement that caused an evolution of the
calendar tool.
This is all done in one language, though there is discussion about
integrating non-Java tools in the future.
Disadvantages
Don't know the level of interest of rest of MORALE on this topic. Not
a very robust system at this point.
A ubiquitous messaging service that combines messages from all input
modalities (e-mail, voice, snail-mail, fax, newsgroups, etc.) and
provides them along all output modalities depending on user location
and preferences. This project is part of the Future Computing
Environments efforts and has been going on since January 1996. The
current system has a fairly well-defined architectural scheme and has
been demonstrated to provide e-mail input to pager/voice/Web
output.
The evolution of this project is to experiment with more input
modalities and to extend the prioritization mechanisms and
user-awareness portions of the system.
Advantages
Most of the system has been done in C with reasonable configuration
management and architectural design. There are very clear
evolutionary paths, many of which are directly affected by previous
architectural choices. This project will most likely be the topic of
one or more senior design projects starting as early as this summer.
Deals with a variety of hardware options and works mainly because of
the architectural solution holding various pieces together through
standardized interfaces.
Disadvantages
Not a very robust system.
This project has a lot of history with Spencer. It is a system to
provide conversion between any of a number of citation formats. The
system has already been through several iterations of design and
implementation, having first been developed in C++ and currently being
transitioned over to Java.
Advantages
Spencer and Kurt have a lot of familiarity with this system. One of
Spencer's students did a SAAM-like evaluation of the system under some
expected changes. Gregory and Kurt attempted a reflexion model
evaluation of the system without much luck. The C++ system might work
well with Dean's visualization system and the Java version wouldn't be
that much of a stretch.
Disadvantages
Not a terribly complicated system, but that might not matter at this point.
Cyberguide is a mobile, context-aware tour guide, used for both indoor
and outdoor location-dependent guidance. The whole project has
evolved as each quarter of the RWL since Summer 1995 has taken the
existing system and built further functionality or ported to a
different platform. There are now several versions of the system with
different communications and positioning systems. The high-level
architecture of the system was intended to provide maximal separation
between positioning, map services, information services and
communication. It has been built on Newtons and palmtop PCs and has
used indoor cellular IR and outdoor GPS for positioning.
The currently planned evolution of the system is to provide a complete
wireless IR communications system for indoor use. This will provide
some two-way services (finding out where other Cyberguide tourists are
located, fetching information on a project that is not stored locally,
receiving broadcast announcements) that were previously unavailable.
Advantages
System has undergone a lot of evolution already. Fairly robust system
that will be worked on by at least two RWL students this summer. One
graduate student will be working on a radically different model of
Cyberguide that is more like an augmented reality tour guide starting
in the Fall.
Disadvantages
Has always had an architectural vision, but that has not really been
documented all that well. System has undergone a lot of evolution
already.
System is done in Newton Toolkit language (NewtonScript) and in Delphi
(Object Pascal). Indoor positioning is provided by a C program
running on an alternate processor. The communications system will be
split between the mobile unit and the CoC network. The CoC network
side will be done in C.
CyberFridge is the first in a series of projects by the FCE and BTC
groups concentrating on future environments and applications for the
home. CyberFridge aims to support a lot of the messaging services of
a domestic refrigerator door, only supercharged to sit on the
Internet. The project is also aiming to use vision to be able to
support capture functionality and history services (determine how much
milk is in the refrigerator based on who has been using it).
The current system provides a general message board and photo gallery
system that uses the metaphor of the fridge door as a
Internet-addressable Web browser. The first evolution of the system
is to integrate the message board so that they work together in a
reasonable manner. The next stages of the project will integrate
vision services (face recognition) to be able to provide more
personalized services. The historical services are more long-term
plans.
Advantages
Interest from FCE and BTC on project (potential corporate sponsorship).
Clear evolutionary path.
Disadvantages
Might be more revolutionary than evolutionary, though it is quite
possible to view the current project as a message board and put it on
an office door instead of a refrigerator. Each piece uses many
different languages (Perl, Java, JavaScript). There was not enough
concentration on an overall architectural scheme for all of
CyberFridge, hence the two pieces do not integrate well as of now.
Conclusions
We have lots of projects to choose from. I don't think we should
spend too much time on the decision, but we might want to think a bit
more clearly about the requirements for a project from the reverse
engineering perspective.
Gregory Abowd <abowd@cc.gatech.edu>
Last modified: Wed Jun 19 00:36:40 EDT 1996