GOAL
The problem we are specifically trying to solve is to bridge the gap between system level design diagrams and implementation level design diagrams. We hope that by adding a physical scale created by walking between layers of abstraction we will succeed in filling this gap with an informative and concrete model for the user.
PROBLEM
You are an implementer, given a design or implementation document, and it is now your task to understand the system and begin work on an assigned module. Using a large, stereo display, an implementer can view high level architectures, and move into less abstract, lower-level diagrams easily by moving back and forth through a 3D space. This space will act as a scale between the different layers of abstraction, allowing the implementer to gain a thorough understanding of the structure of the system.
An implementer can then interact with a diagram, physically moving through layers of abstraction until they reach the module they will work on, gaining a grounded understanding of the module they are working on and how it relates to the project as a whole.
SCENARIOS
S1: Implementer Learns About a System
Background: Implementor Andy is working on a software system to handle a companys shopping records and customer accounts. Andy has been assigned to work on a module which keeps track of products within the system.
1. Andy views the highlevel architecture.
2. The product module is located relative to the other high-level modules.
3. The relationships between the product module and other modules are noted.
4. On the the relationships are noted, Andy walks forward.
5. Andy is presented with a lower level diagram.
6. More detailed information about the module is noted.
7. Andy learns the types relationships between modules, and sees abstractly which modules make requests to the Products module and which requests the Products module makes to other modules.
8. Andy walks forward and is presented with a lower-level diagram.
9. The specific attributes and methods of the Products module are noted,
10. Modules which use or contribute to Products attributes and methods are noted.
11. Andy walks forward and is presented with the implementation design for the Products module.
12. Andy learns about method internal to Product and its private data.
Conclusion: Andy has a thorough understanding of the Products modules because he physically walked through the views of the design starting with abstract architecture/system design and moved incrementally to the low-level implementation design.
PROJECT PLAN
Week 2
· Research. ( 3 Days)
· Write Project Proposal/Description. ( 2 Days )
Week 3
· Research. ( 2 Days)
· Begin designing diagrams. ( 3 Days )
Week 4
· Design information to be displayed. ( 2 Days )
· Generate all diagrams. ( 1 Day )
· Begin creating virtual model. ( 2 Days )
Week 5
· Create/Complete virtual model. ( 3-4 Days )
· Begin to Refine/ Debug Interface and Model ( 1-2 Days )
Week 6
· Complete Refining/Debugging of Interface and Model ( 3-5 Days )
· Begin Evaluation ( 0-2 Days )
Week 7
· Complete Evaluation ( 3 Days )
· Complete Paper ( 2 Days )