SE450:SAM

Members

Lauren, Jason, Eddie, Don, Craig, Calvin and Judy

Paper

SAM - An Animated 3D Programming Language. SAMVL98.pdf from here

Deliverables

• 4 slides presentation in less than 4 minutes on Tuesday 27th March. Need to email the presentation to John Hosking before 12 noon
• One page summary paper in IEEE format done individually, due on 5pm Thursday 5th April

Type of End Users

• Programmers - Abstract 3D presentation
• Clients, someone preparing the requirements documentation who has little/no idea about programming - Concrete, solid 3D presentation

Metaphors Used

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.

Evaluation of Effectiveness

Abstraction Gradient

• POOR
• rules can't be nested, which limits encapsulation

Closeness of mapping

• On-screen entities do map to conceptual programming objects
• symbols aren't easily recognisable
• symbols don't appear to represent their models
• difficult programming game

Consistency

• Only a few visual entities to learn, so consistency is okay.

Diffuseness

• sufficient symbols
• as simple as possible, for a 3d environment
• 3d environment makes it difficult to reduce diffuseness

Error proneness

• Good
• Hard to induce mistakes in code
• Forms for data entry; assumed form checking?

Hard mental operations

• POOR
• need to remember where messages are going to (no obvious communication channels)
• don't know output of actions until you watch the program run.

Hidden dependencies

• communications between objects are not obvious
• can show code
  • code vaguely indicates dependencies
  • but no symbolic representation

Premature commitment

• OK, since objects / rules/etc can be specified in any order with few design time dependencies

Progressive evaluation

• GOOD
• Animation - can show the state of the object
• Can switch between pretty animation and design-style animation at run-time.

Role-expressiveness

• poor at design time, only good during animation.

Secondary notation

• Can use layout and object sizes to group stuff and convey meaning
• colours?
• comments?
• Average, could be improved.

Viscosity

• High viscosity
• simple model
• form-based interaction, hard to copy/paste/change data in bulk

Visibility

• POOR
• Can't read all code at once
• No start point when looking at text code
• Code is dispersed spatially

Presentation

Download