12.08.2013 Views

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 ...

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!