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.
Here are some of the artifacts we should consider producing for this
project. We can consider our summer objective as roughly producing
these artifacts as deliverable documentation.
- Project description: A brief description of the context of the
project, describing what it is used for and briefly giving some
historical context for the system and a suggestion of its future
evolutionary requirements. This should also provide
pointers/references to any existing documentation (a
requirements document, for example) for the system
as well as pointers to the implementation.
- Requirements structuring: Use Colin and Annie's GBRAT tool to
produce a structured representation of the goals a user has in
interacting with the system.
- Scenario elicitation/structuring: Come up with a list of
scenarios that represent normal and intended use of the system.
These will represent the current mission statements for the
system and the intended evolved mission requirements.
- Architectural description: A document describing the
architectural composition of the current system. This will
contain both static and dynamic information about the system.
It would be much preferred if this description were done in some
accepted architecture description language. Even better would
be to do it in Ashok's SBF notation.
- Architecture verification document: Through some reverse engineering
techniques, demonstrate the correspondence between the
architectural description and the actual system artifact. This
can be done by means of static analysis tests, dynamic
visualization tools, or other means. The purpose of this
document is to provide eveidence that the architectural
description above is a correct one with respect to the actual system.
- Impact analysis: A SAAM analysis of some subset of scenarios
that represent behavior that the evolved system should have.
This analysis should provide some indication of the level of
expected effort to evolve the system.
- Reuse document: Indicate what parts of the system can be reused
from one version to the next.
- Evolutionary design journal: An attempt at producing some
documentation on the evolution of the system. This may be as
simple as just placing some of the above documents in a
particular order, or it may involve other work.
Dependencies
Given the above list of dependencies, here is an attempt to describe
some of the dependencies, to assist in coming up with a plan.
- Project description: does not depend on anything
- Requirements structuring: depends on having either
documentation of the system (requirements?) or access to the
working system and/or access to people who have used the system
in order to determine what goals it is implemented to fulfill.
- Scenario elicitation/structuring: similar dependencies to
requirements structuring. Also needs some indication of change
in mission requirements, which should be provided in project
description.
- Architectural description: Requires either a system expert
(person who built the current system) or a domain expert (person
familiar with the way systems like the one under consideration
are constructed.
- Architecture verification document: Requires an architectural
description of a system and access to the source code and
running system.
- Impact analysis: Requires scenarios (prioritized) and
architectural description.
- Reuse document: Requires either the impact analysis or evidence
from two versions of a system.
- Evolutionary design journal: ???
Plan
Given the above list of deliverables and dependencies and our rough
goal of having completed this case study by October 1, here is a
suggested plan for the summer.
Activity Dates Deliverable
Project description June 19 - July 12 project desc; reference
(Abowd|Potts|Rugaber)
Reqts. structuring July 3 - Aug 2 GBRAT document
(Potts)
Scenario elicitation July 3 - Aug 16 Scenario document, prioritization
(Potts, Abowd, Rugaber)
Arch. desc July 3 - Aug 16 Architecture document
(Abowd, Goel)
Arch. verification July 22 - Aug 30 Revised architecture document
(Rugaber, Wills)
Impact analysis Aug 5 - Aug 30 SAAM analysis
(Abowd)
Reuse determination Aug 26 - Sept 13 Reuse identification
(Wills, Moore, Rugaber)
Evol. Design Journal July 3 -- Oct 1 EDJ
(Wills, McCracken)
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. If a system is
all in one language, then size is probably more of a concern. If the
system is heterogeneous with respect to language, then the size is
probably not all that important as the heterogeneity will cause enough
confusion about the big picture.
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 to consider. This list has been pared
down from a longer list.
For each suggested project, we provide
- a brief description of the project
- a description of how the system is to be evolved
- a collection of pointers to obtain further information
- a discussion of the advantages and disadvantages of this
project as a summer case study
Description
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).
Evolution
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.
Pointers
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. There are plenty of other projects that have worked on
suggestions for additions.
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
Description/evolution
Colin might be able to improve on this
The problem of group calendars and meeting scheduling is a very old
one. Lots of people have worked on it, and nobody has really been
that successful. Single person calendar managers are fairly good, and
the usual path for evolution has been to take a single person system
and evolve it into a group product. There are plenty of avenues of
evolution for all of these systems beyond moving from single user to
multi-user. 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.
Pointers
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.
It would also be worthwhile to look at some commercial
calendar/scheduling systems, such as Now
Up-to-Date, which currently provides Web and PDA integration
products.
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?
Citation
Description
Spencer may be able to improve on this
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.
Evolution
The emphasis for evolution has been in two areas; number of
bibliographic formats accepted/produced and platform of availability.
Pointers
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.
Gregory Abowd <abowd@cc.gatech.edu>
Last modified: Tue Jul 2 14:48:00 EDT 1996