The AR Workbench: A Complete Co-located Reach-in Mirror-Based ...
The AR Workbench: A Complete Co-located Reach-in Mirror-Based ...
The AR Workbench: A Complete Co-located Reach-in Mirror-Based ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
5.2 <strong>Co</strong>nceptual Design<br />
Marlon Richert, Master’s <strong>The</strong>sis, Friday, 23 February, 2007<br />
<strong>The</strong> user’s mental model of the system is very similar to the analysis object model<br />
(see section 4.2), but with some simplifications. Figure 6 lays out the objects of the<br />
user’s mental model and their properties, relations between each other and<br />
operations on them. All objects <strong>in</strong> the model represent th<strong>in</strong>gs that the user will<br />
actually perceive.<br />
<strong>The</strong> names of the objects <strong>in</strong> the figure refer to nouns <strong>in</strong> the scenarios presented <strong>in</strong><br />
chapter 1. <strong>The</strong> Patient class represents, of course, all patients that will use the<br />
system. A patient us<strong>in</strong>g the system will control a real handle, which is a real object.<br />
Attached to this handle is a virtual tool, which is a virtual object. Mov<strong>in</strong>g the handle<br />
will move the tool with it. With the use of the virtual tool, the patient can <strong>in</strong>teract<br />
with other objects present <strong>in</strong> the workspace. F<strong>in</strong>ally, all objects <strong>in</strong> the workspace,<br />
both real and virtual, are three-dimensional objects, with a position and orientation<br />
<strong>in</strong> space.<br />
Figure 6 <strong>Co</strong>nceptual design of the user’s mental model of the proposed<br />
system (class diagram).<br />
5.3 Semantic Design<br />
<strong>The</strong> virtual part of the conceptual design needs to be realized as a software library.<br />
Given the requirements, this will be a module <strong>in</strong> Python. Figure 7 details the static<br />
structure of this module, called roles. <strong>The</strong> design of the roles module tries to<br />
solve the problem of generality: we not only want the design to be able to<br />
implement the situations sketched <strong>in</strong> chapter 4 and the section 5.2 above, we want<br />
it to be generic enough to be easily adapted to be applied to other, unforeseen<br />
applications of the <strong>AR</strong> system. Further, the design tries to be extendable and<br />
modular, so that developers may easily add functionality or change the underly<strong>in</strong>g<br />
implementation without break<strong>in</strong>g exist<strong>in</strong>g code or violat<strong>in</strong>g <strong>in</strong>terface contracts.<br />
Some elaboration on the contents of the figure is <strong>in</strong> order. First, please note that<br />
the Actor class <strong>in</strong> the figure is not the same as the Actor class <strong>in</strong> the conceptual<br />
design or the analysis object model. <strong>The</strong> Actor here rather represents any object<br />
21