SE450:G5

Cognitive Dimensions

Abstraction gradient

What are the minimum and maximum levels of abstraction? Can fragments be encapsulated?

• There is only one level of abstraction; nothing is encapsulated in this VL. However one level of abstraction is enough due to the nature of the domain.

Closeness of mapping

What ‘programming games’ need to be learned?

• Architects helped to develop it (it uses their system of representation) so it is fairly close.

Because the VL is used to generate actual house designs and no further alterations are necessarily required (invalid designs are filtered out), mapping is very close.

Consistency

When some of the language has been learnt, how much of the rest can be inferred?

• Language is relatively simple and consistent. For those who know relevant architectural theory it could be intuitive.

Diffuseness

How many symbols or graphic entities are required to express a meaning?

• Individual "trays" do not require many symbols to be expressed; however, there need to be quite a lot of rules to constrain generated designs.

Error-proneness

Does the design of the notation induce ‘careless mistakes?

• All information is easy to see for trays; very hard to make mistakes. For generation, it is conceivably quite easy to miss some constraints, but errors or omissions should become apparent in generated designs.

Hard mental operations

Are there places where the user needs to resort to fingers or penciled annotation to keep track of what’s happening?

• Not really; the VL does not have complex constructs (except maybe for quite sophisticated constraints).

Hidden dependencies

Is every dependency overtly indicated in both directions? Is the indication perceptual or only symbolic?

• The language is relatively small so there are few dependencies; they only exist for the rules/constraints, which are very explicit.

Premature commitment

Do programmers have to make decisions before they have the information they need?

• No; again there are few dependencies of this nature and there is no reason to (for instance) create constraints before their trays have been specified. The language is too simple to have major issues with complexity.

Progressive evaluation

Can a partially-complete program be executed to obtain feedback on “How am I doing�??

• To some extent - there need to be some trays and constraints to generate designs, but in fact progressive evaluation is probably a very good way of developing schemas (or rule sets, whichever).

Role-expressiveness

Can the reader see how each component of a program relates to the whole?

• Very expressive language because it is simple and does not require much work at each stage.

Secondary notation

Can programmers use layout, color, or other cues to convey extra meaning, above and beyond the ‘official’ semantics of the language?

• No secondary notation - extra vocabulary could conceivably be added but the language does not support semantic extension.

Viscosity

How much effort is required to perform a single change?

• Not very easy to judge without being able to use the language, but it doesn't look too difficult to change; no complex interdependencies - rule sets are built from simple relationships. Because we can't use the system, it is unclear if changing one dimension (of the tray) will affect all others that relate to it.

Visibility

Is every part of the code simultaneously visible (assuming a large enough display), or is it at least possible to compare any two parts side-by-side at will? If the code is dispersed, is it at least possible to know in what order to read it?

• Because this VL is a rule-based language, and many rules will be required, it probably isn't possible to see all of the model/diagram simultaneously, but it is very easy to compare them. Additionally, there is no inherent order to the VL so it does not particularly matter how models are read.