Introduction p4: CASSM models
CASSM describes two sorts of concepts, using the same language for each: concepts held by the user, and concepts built into the device.
Think about a mobile phone (cell phone) address list. The user has the concept of a person with a name and a phone number. The device has the concept of an address book entry, which corresponds to a person, and has two attributes, name and number. All of these are readily available at the interface.
But the device has a finite size, so there is a maximum number of entries. That is a fixed device limitation, represented in CASSM as a device-constraint relationship, which is not part of the user's original conceptual model. No great problem in this case, but if there are too many arbitrary device limitations, it will be hard to learn.
The user might also have the concept of a group of people, such as members of a band. The phone doesn't know about groups, so here is a misfit. Misfits make problems. To send a message to all band members, a message has to be sent to each member individually - an instance of 'repetition viscosity' that will be detected by CASSM.
To figure this out, the modeller has to have sufficient understanding of the user's concepts, and has to understand the device well enough.
Then the concepts and features need to be analysed and laid out more formally as a CASSM model. We have found it useful to represent them in a tabular form:
name |
... user? |
... interface ? |
... system? |
creatable? |
changeable? |
entry |
yes |
yes |
yes |
yes |
yes |
entry.name |
yes |
yes |
yes |
yes |
yes |
band |
yes |
NO |
NO |
NO |
NO |
To help organise and analyse such tables we have created an editor and analysis tool, Cassata (follow link to 'Support tools').

screenshot from Cassata version of the model
[ next page: CASSM in design]
This page last modified
26 February, 2010
by Ann Blandford
|