User:BenMcDonald

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m
Line 13: Line 13:
 
* The performance on the skills needs to be evaluated and for additional activities to be recommended to the athlete.
 
* The performance on the skills needs to be evaluated and for additional activities to be recommended to the athlete.
 
* An athlete’s evaluation history, progress and general details to be recorded and recoverable.
 
* An athlete’s evaluation history, progress and general details to be recorded and recoverable.
 +
* Measurements from the augmented reality marker need to update the position of the athlete's head.
 +
* WiiMote gestures need to be detected and reacted to.
  
 
My design is below. Any comments or suggestions are very welcome.  
 
My design is below. Any comments or suggestions are very welcome.  
  
 
== Iteration Three ==
 
== Iteration Three ==
 +
=== Style===
 +
{|
 +
|-
 +
| '''Standard'''|| '''Code''' || '''UML'''
 +
|-
 +
| Immutable attributes accessors are named after the attributes as is the C++ standard || ''Object foo_; virtual const Object& foo() const;'' || foo, foo()
 +
|-
 +
| Object queries end with the keyword 'const' || ''virtual const std::string& name() const; ''|| name():String const
 +
|-
 +
| Method inputs begin with the keyword 'const' || ''virtual void foo(const string &in, string *out); ''|| foo(const String in):String
 +
|-
 +
|}
 +
 
[[Image:BenM's UMLI3.png|border|1000px]]
 
[[Image:BenM's UMLI3.png|border|1000px]]
  
 
Maxims that have been useful:
 
Maxims that have been useful:
−
* [[Command query separation]] / [[Avoid side effects]] - The interface would be tidier if the getFeedback() method in the Trainer object also cleared the feedback but doing this would violate CQS. By have two methods, getFeedback() and clearFeedback(), there are no side effects and the status of the object can be queried without invocking any commands. Additionally, I could add a getAndClearFeedback() method for convenience. One plus of C++ is that you can mark queries, and enforce them, with the const keyword.
+
* [[Command query separation]] / [[Avoid side effects]] - The interface would be tidier if the getFeedback() method in the Trainer object also cleared the feedback but doing this would violate CQS. By have two methods, getFeedback() and clearFeedback(), there are no side effects and the status of the object can be queried without invoking any commands. Additionally, I could add a getAndClearFeedback() method for convenience. One plus of C++ is that you can mark queries, and enforce them, with the const keyword.
 
* [[Design by contract]] - Using assert's to enforce conditions at the moment
 
* [[Design by contract]] - Using assert's to enforce conditions at the moment
 
* [[Don't expose mutable attributes]] - In C++, objects returned from another object's method can be marked as const to make them immutable.
 
* [[Don't expose mutable attributes]] - In C++, objects returned from another object's method can be marked as const to make them immutable.
−
* [[Object Encapsulation]] - Variables are ether 'protected' or 'public' and all methods are marked 'virtual'. Object encapsulation is more intuitive and I did not find any appropriate place for private variables.
+
* [[Object Encapsulation]] - Variables are ether 'protected' or 'public' and all methods are marked 'virtual'. Object encapsulation is more intuitive and I did not find any appropriate place for private variables. Class encapsulation does not allow for effective unit testing through inheritance.
 +
 
 +
====Some C++ Language semantics avoided in this project design====
 +
* [[Object Encapsulation|Public and private attributes]]
 +
* [[Don't expose mutable attributes|Exposing mutable attributes]]
 +
* [[Object Encapsulation|Non virtual methods]]
 +
* Calling methods in constructors - init() methods used instead
 +
** Hard to account for errors
 +
** Constructors cannot fail
 +
** Overloaded methods may be called
  
 
=== Patterns ===
 
=== Patterns ===
 
[[Intelligent children pattern]]
 
[[Intelligent children pattern]]
−
* BoxerPose hierarchy
+
{|
−
* Boxer hierarchy
+
|-
 +
| Hierarchy One|| ''BoxerPose ''
 +
|-
 +
| Hierarchy  Two || ''Boxer ''
 +
|-
 +
|}
  
−
[[State|State Pattern]]:
+
[[State|State Pattern]]
 
{|
 
{|
 
|-
 
|-
Line 44: Line 73:
  
 
[[Visitor|Visitor Pattern]]
 
[[Visitor|Visitor Pattern]]
−
* ConcreteElement - Trainer, Boxer
+
{|
−
* Element - Boxer
+
|-
−
* Visitor - Exporter
+
| ConcreteElement || Trainer, Boxer
 +
|-
 +
| Element || Boxer
 +
|-
 +
| Visitor || Exporter
 +
|-
 +
|}
  
−
[[Observer|Observer Pattern]]:
+
[[Observer|Observer Pattern]]
 
{|
 
{|
 
|-
 
|-
Line 62: Line 97:
 
A trainer can be made to observe a UserBoxerPose. The trainer will record the pose history and generate evaluations from that history, generate feedback from its observations and react to the pose's actions.
 
A trainer can be made to observe a UserBoxerPose. The trainer will record the pose history and generate evaluations from that history, generate feedback from its observations and react to the pose's actions.
  
−
[[Observer|Observer Pattern]]:
+
[[Observer|Observer Pattern]]
 
{|
 
{|
 
|-
 
|-

Revision as of 10:59, 24 September 2009

Contents

Ben McDoanld's page

I am doing my design study for my COSC426:Augmented Reality project. I need a design for a boxing skills trainer. No code has been written so far. I have made a sketch of the requirements for the design of the software. The project is in C++ using the libraries open scene graph (osg), augmented reality tool-kit open scene graph (ARTosg) and the Wii controller library for windows

Requirements:

  • A score needs to be generated from a set of tested skills:
    • Consistent guard
    • Eyes forward and on opponent
    • Bobbing and weaving
    • Timing of punches
  • Each skill needs to be modeled and the evaluation method for each skill also needs to be modeled.
  • The performance on the skills needs to be evaluated and for additional activities to be recommended to the athlete.
  • An athlete’s evaluation history, progress and general details to be recorded and recoverable.
  • Measurements from the augmented reality marker need to update the position of the athlete's head.
  • WiiMote gestures need to be detected and reacted to.

My design is below. Any comments or suggestions are very welcome.

Iteration Three

Style

Standard Code UML
Immutable attributes accessors are named after the attributes as is the C++ standard Object foo_; virtual const Object& foo() const; foo, foo()
Object queries end with the keyword 'const' virtual const std::string& name() const; name():String const
Method inputs begin with the keyword 'const' virtual void foo(const string &in, string *out); foo(const String in):String

BenM's UMLI3.png

Maxims that have been useful:

  • Command query separation / Avoid side effects - The interface would be tidier if the getFeedback() method in the Trainer object also cleared the feedback but doing this would violate CQS. By have two methods, getFeedback() and clearFeedback(), there are no side effects and the status of the object can be queried without invoking any commands. Additionally, I could add a getAndClearFeedback() method for convenience. One plus of C++ is that you can mark queries, and enforce them, with the const keyword.
  • Design by contract - Using assert's to enforce conditions at the moment
  • Don't expose mutable attributes - In C++, objects returned from another object's method can be marked as const to make them immutable.
  • Object Encapsulation - Variables are ether 'protected' or 'public' and all methods are marked 'virtual'. Object encapsulation is more intuitive and I did not find any appropriate place for private variables. Class encapsulation does not allow for effective unit testing through inheritance.

Some C++ Language semantics avoided in this project design

Patterns

Intelligent children pattern

Hierarchy One BoxerPose
Hierarchy Two Boxer

State Pattern

Context Trainer
Abstract State TrainingActivity
Concrete State1 PunchingDrill
Concrete State2 BobbingAndWeaving

Visitor Pattern

ConcreteElement Trainer, Boxer
Element Boxer
Visitor Exporter

Observer Pattern

Subject BoxerPose
ConcreteSubject UserBoxerPose
Observer Observer
ConcreteObserver Trainer

A trainer can be made to observe a UserBoxerPose. The trainer will record the pose history and generate evaluations from that history, generate feedback from its observations and react to the pose's actions.

Observer Pattern

Subject BoxerPose
ConcreteSubject TrainerPose
Observer Observer
ConcreteObserver TrainerAnimation

I wanted the Trainer to know about the timings of the animations and was tempted to couple the Trainer class to the TrainerAnimations class and vice versa. I instead decided to remove the Trainer's knowledge of its animations and required the animations to conform to the timings of the Trainer's movements. The TrainerAnimations class is likely to change and coupling the Trainer class to it would increase maintenance of the Trainer class.

Iteration Two

BenM's UMLI2.png

Design:

State Pattern:

  • Context - Trainer
  • State - TrainingState
  • ConcreteStates - PunchingDrill, BobbingAndWeaving

Observer Pattern:

  • Subject - Observable
  • ConcreteSubject - UserBoxer
  • Observer - Observer
  • ConcreteObserver - Trainer

Observer Pattern:

  • Subject - Observable
  • ConcreteSubject - Trainer
  • Observer - Observer
  • ConcreteObserver - TrainerAnimation


Iteration One

BenM's UMLI1.png

Design:

Observer Pattern:

  • Subject - Observable
  • ConcreteSubject - Athlete
  • Observer - Observer
  • ConcreteObserver - Trainer
Retrieved from "https://oowisdom.csse.canterbury.ac.nz/index.php?title=User:BenMcDonald&oldid=4854"
Personal tools