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