https://wiki.kram.nz/index.php?action=history&feed=atom&title=SE450%3ASAMSE450:SAM - Revision history2026-04-06T19:06:55ZRevision history for this page on the wikiMediaWiki 1.45.3https://wiki.kram.nz/index.php?title=SE450:SAM&diff=48&oldid=prevMark: New page: == Members == Lauren, Jason, Eddie, Don, Craig, Calvin and Judy == Paper == SAM - An Animated 3D Programming Language. SAMVL98.pdf from [https://www.se.auckland.ac.nz/courses/SOFTENG45...2008-02-15T19:51:53Z<p>New page: == Members == Lauren, Jason, Eddie, Don, Craig, Calvin and Judy == Paper == SAM - An Animated 3D Programming Language. SAMVL98.pdf from [https://www.se.auckland.ac.nz/courses/SOFTENG45...</p>
<p><b>New page</b></p><div>== Members ==<br />
Lauren, Jason, Eddie, Don, Craig, Calvin and Judy<br />
<br />
<br />
<br />
== Paper ==<br />
SAM - An Animated 3D Programming Language. SAMVL98.pdf from [https://www.se.auckland.ac.nz/courses/SOFTENG450/resources/ here]<br />
<br />
== Deliverables ==<br />
* 4 slides presentation in less than 4 minutes on Tuesday 27th March. Need to email the presentation to John Hosking before 12 noon<br />
* One page summary paper in IEEE format done individually, due on 5pm Thursday 5th April<br />
<br />
== Type of End Users ==<br />
* Programmers - Abstract 3D presentation<br />
* Clients, someone preparing the requirements documentation who has little/no idea about programming - Concrete, solid 3D presentation<br />
<br />
== Metaphors Used ==<br />
When implementing the program, agent (entities) rules, ports, messages and agents are represented using system defined 3D objects. When executing the code, entities can be represented using arbitrary concrete 3D objects.<br />
<br />
== Evaluation of Effectiveness ==<br />
=== Abstraction Gradient ===<br />
* '''POOR'''<br />
* rules can't be nested, which limits encapsulation<br />
<br />
=== Closeness of mapping ===<br />
* On-screen entities do map to conceptual programming objects<br />
* symbols aren't easily recognisable<br />
* symbols don't appear to represent their models<br />
* difficult programming game<br />
<br />
=== Consistency ===<br />
* Only a few visual entities to learn, so consistency is okay.<br />
<br />
=== Diffuseness ===<br />
* sufficient symbols<br />
* as simple as possible, for a 3d environment<br />
* 3d environment makes it difficult to reduce diffuseness<br />
<br />
=== Error proneness ===<br />
* Good<br />
* Hard to induce mistakes in code<br />
* Forms for data entry; assumed form checking?<br />
<br />
=== Hard mental operations ===<br />
* '''POOR'''<br />
* need to remember where messages are going to (no obvious communication channels)<br />
* don't know output of actions until you watch the program run.<br />
<br />
=== Hidden dependencies ===<br />
* communications between objects are not obvious<br />
* can show code<br />
** code vaguely indicates dependencies<br />
** but no symbolic representation<br />
<br />
=== Premature commitment === <br />
* OK, since objects / rules/etc can be specified in any order with few design time dependencies<br />
<br />
=== Progressive evaluation ===<br />
* '''GOOD'''<br />
* Animation - can show the state of the object<br />
* Can switch between pretty animation and design-style animation at run-time.<br />
<br />
=== Role-expressiveness ===<br />
* poor at design time, only good during animation.<br />
<br />
=== Secondary notation ===<br />
* Can use layout and object sizes to group stuff and convey meaning<br />
* colours?<br />
* comments?<br />
* Average, could be improved.<br />
<br />
=== Viscosity ===<br />
* High viscosity<br />
* simple model<br />
* form-based interaction, hard to copy/paste/change data in bulk<br />
<br />
=== Visibility ===<br />
* '''POOR'''<br />
* Can't read all code at once<br />
* No start point when looking at text code<br />
* Code is dispersed spatially<br />
<br />
= Presentation =<br />
[https://www.se.auckland.ac.nz/wiki/images/c/c0/450_visual_language%28final_version%29.pdf Download]</div>Mark