Sunday, February 17, 2008 

Cognitive Dimensions of Notations

I constantly hear that the blogsphere is highly self-referential, so what's better than starting a post by quoting yourself? Here is an excerpt from Listen to Your Tools and Materials:
Our material is knowledge, or information. We acquire, understand, filter, and structure information; and we encode it in a variety of formats: text, diagrams, code, and so on.[...]the diagram isn't a material, just a representation. We use a tool to represent the material, which is intangible knowledge. [...] What's peculiar with software is that, in many cases, the tools and the materials have the same nature.

Note that I'm using "tool" in a very broad sense there. UML is not our material, is a tool we use to encode our material (and yeah, we may also use a software tool to draw the UML). Source code is not our material, is a tool we use to encode our material.
The fact that we often confuse tools and materials, and that we can get along with that just fine, empirically proves that they are somehow similar in nature.

Now, If our tools and materials have similar nature, then perhaps by understanding better the properties of our tools we can also understand better the properties of our materials, and ultimately of our creations. Assuming, of course, that we can somehow define and classify some interesting properties of our tools (that is, notations).

Turns out that people have been doing so for quite a while now. There is an interesting body of knowledge about the so-called Cognitive Dimensions of notations. I'll quote some portions from a short paper (Cognitive Dimensions of Notations: Design Tools for Cognitive Technology), but if you're interested, I recommend you dig deeper by reading Cognitive Dimensions of Information Artefacts: a tutorial.

When we use a notation, we are both limited and enabled by its own peculiarities. Our own style further emphasizes some of those attributes. For instance, a class diagram is relatively easy to change: you can quickly reshape your design into a very different one. In the Cognitive Dimensions vocabulary, we would say that its viscosity is low. However, if you have also modeled some scenarios on that class diagram (using for instance a sequence diagram) you have to work much harder to make changes. Sequence diagram have high viscosity.

Now, I really like the choice of viscosity as an attribute. I have to confess: I like it because it's not nerdy. When we're dealing with intangible information, it's easy to find ourselves lacking the necessary words. In software development, there is then a wide tendency to adopt some weird, geeky term.
Perhaps that's why I've immediately appreciated the Cognitive Dimensions framework. They put some considerable effort in creating the vocabulary itself. Here is a quote from the aforementioned paper: We believe that this problem is best addressed by providing a vocabulary for discussing the design problems that might arise – a vocabulary informed by research in cognitive psychology, but oriented toward the understanding of a system developer. The Cognitive Dimensions of Notations are such a vocabulary. Bingo! :-)

If you spend some time familiarizing with the vocabulary, you'll see how useful it can be to settle down some long-standing debates, like code Vs. diagrams or even static typing Vs. dynamic typing. Consider, for instance:
Premature commitment: constraints on the order of doing things.
Hidden dependencies: important links between entities are not visible.
Error-proneness: the notation invites mistakes and the system gives little protection.

and so on. They provide a sound reference against which the pros and cons of different notations can be evaluated.

The real boon (for me) is: some of those concepts can be extended from the tool to the material! Actual code may or may not have Hidden Dependencies. Actual code may have different degrees of Viscosity. Actual code may or may not have Closeness of Mapping. And so on. Of course, the notation itself is providing a bottom line on some properties. But ultimately, the form you give to your material may move quite far from the bottom line.
Indeed, I believe the form itself will be heavily influenced by the process and notation you used when you conceived the form. If you conceive your form using diagrammatic reasoning, it will keep some of the inherent properties of that notation even when it's translated into another notation (like source code). If you start with source code, your form will be more heavily influenced by the properties of source code.

I also like some of the candidate dimensions. For instance, I'm especially fond of Creative Ambiguity. This, I would say, it's one of the properties that code is lacking most. It's also something academics are trying hard to remove :-) from UML. And in a sense, it's what makes some practices like TDD so limited.
Code doesn't afford much creative ambiguity, yet what we call "modeling" should probably be called "incubation". Shaping a great form ain't easy. We need low viscosity, a good degree of creative ambiguity, high provisionality, and so on. Code alone just won't cut it.
Of course, we might not be after great form, just run-of-the-mill form. Then anything sensible is gonna work: see also my recent post on old-fashioned architectures "designed" for mass adoption.

Labels: , ,

Comments:
About your viscosity remarks...

Your comparison isn't quite correct I think.

If you only have a class diagram, you probably don't have much of a design at all. If you add a sequence diagram, the design becomes harder to change but that is simply because you now have more artifacts (and information) to maintain and keep consistent.

Sequence diagrams are not intrinsically harder to change than class diagrams. It really depends on the software tool(s) you have available to you.

Sequence diagrams do have a * lot * more layout constraints than class diagrams but that also presents an opportunity for automating the layout.

As it happens, I've created just such a tool : Trace Modeler is an easy to use and smart editor for UML sequence diagrams.

Basically, it adapts the layout of your sequence diagrams instantly and automatically to any changes you make, freeing you to focus on the content.

If you're in a hurry, here's a 30 sec demo of Trace Modeler in action.

If you use Trace Modeler for your sequence diagrams, you might find that the viscosity comparison you made, is reversed ;o)

If you give it a try, let me know what you think of it. I'm always happy to get feedback!

Best regards,
Yanic
 
Yanic: just when I thought I'd found a way to easily settle some debates :-)).

I've taken a look at Trace Modeler (I might have seen it before, but I'm not sure). It's really a nice tool, and I surely appreciate the effort you spent to make editing a sequence diagram more natural. This is, however, one of those rare cases where we should not confuse the tool with the notation.

Consider code: code (I guess we might agree on this :-) has high viscosity. Code tend to resist changes more than diagrams, for various reasons (among which the strictly sequential nature, the large number of details, and so on). However, modern refactoring tools go to a great length to help the programmer change the code. This is the equivalent of adding a solvent to a fluid, or raising its temperature, in an attempt to lower viscosity. It works, to a certain extent.

You raised some interesting observation though, and I'd like to elaborate a little:

If you only have a class diagram, you probably don't have much of a design at all.
I don't want to get you wrong here. If I read your statement literally, I strongly disagree.
Maybe it depends on what we mean by design. If you mean an excruciatingly precise specification, which could be transferred to some code monkey who could then implement the exact thing without even speaking to you, then yes, a class diagram is definitely not enough.
If you consider design as an exploration of the solution space, together with a reasonable encoding of the chosen solution, usually carried out by a few people, who will then implement the real thing, then in many cases a class diagram (or a set of class diagrams) is more than enough.
People familiar with OOD have little problem with the dynamics of their own system, once the design is clean, uses clear names, adopt common interaction patterns, and maybe other visual aids to suggest the dynamics. In some cases, a few pseudocode snippets add the missing link, and that's it.
Sure, sometimes we do need other diagrams (like a state diagram, or an activity diagram, or a timing diagram, and so on). But not all the time. (Famous) case in point: if you look at the initial samples in the GoF book, they manage to explain a reasonable design for an editor, using 10 small class diagrams, 9 code snippets, 11 other pictures (most of them would be object diagram) and just 1 trivial sequence diagram.

If you add a sequence diagram, the design becomes harder to change but that is simply because you now have more artifacts (and information) to maintain and keep consistent.
It's not just that. If I add another class diagram, for instance, I can manage to keep the two highly decoupled: here a “good shape” in the diagram subsumes a good shape in the underlying form (information). Viscosity would increase a little, but not much. Tools can help to a large extent and keep the views synchronized.
If I add a state diagram, that's usually confined to describe the (logical or physical) behavior of a single class. I can later split the class using the State pattern, but I won't change the state diagram, because that's the logical behavior I want to model. Viscosity, therefore, wouldn't increase much by adding a state diagram.
Now, if I add a sequence diagram, I have a constant maintenance to perform, whenever I change the allocation of responsibilities (for instance, replacing inheritance with delegation, adopting a strategy pattern), or the granularity of responsibilities, or the ordering of responsibilities. The sequence diagram is very close to [pseudo]code, and as such, its viscosity is very close to that of [pseudo]code. Without a tool like yours, it's actually much higher.

you might find that the viscosity comparison you made, is reversed ;o)
As I said, I certainly appreciate your results, and I would be glad to see the same level of usability in a full-blown UML tool. However, given that sequence diagram is hardly the focal point of reasoning when we design, it's hard to reverse the equation. We tend to reason most often on the class diagram because (I'll add more on a future post) within the OO paradigm the concept of form is more closely (although incompletely) modeled by the static structure. Unfortunately, even minor changes to the static structure tend to unravel in a stream of tiny changes to the sequence diagrams. Even more so if we model distinct scenarios using different sequence diagrams (which makes them more understandable, but adds to viscosity).

That said, I still hope you get the reward you deserve for your tool. By the way, have you considered working also on some other UML 2 diagram, like the timing diagram which is so poorly supported by several case tools?
 
Perhaps a more straightforward analogy (or is that a simile?) for the influence of refactoring tools on code viscosity would be the acceleration of time?

if you only have a class diagram...
Ok, so were talking about the viewpoint that that a class diagram suffices and only serves as a memory aid, and there's a much larger design in your and your team members' heads. I'd say such an ephemeral and distributed medium makes for a highly viscuous situation, no?

the initial samples in the GoF book
True about the diagrams, but those diagrams are located in about 44 pages of accompanying explanatory text. Plus, you wouldn't be able to produce a working editor with just that information, the devil tends to be in the details. For example, their discussion of undo/redo is just too simple for a real graphical editor. Consider moving a figure by dragging it, you wouldn't want 300 tiny move commands in your history right? So you need something more sophisticated, and that is a non-trivial design change if your move command has any kind of domain logic in it (apart from updating x&y). So those 44 pages don't represent a coherent design to me, just a bunch of independent possible design ideas. Note that I do not claim that 'a documented design' must list every little detail.

People familiar with OOD have little problem with the dynamics of their own system
I think that people familiar with OOD have *a lot* of problems with the dynamics of their own system. I always look at it this way : the dynamics are what you're trying to work out and get right, the static description is just a consolidation/summary/projection of whatever you decided on for the dynamics. I.e. the dynamics are the essence and the structure is just a consequence.

sequence diagram is hardly the focal point of reasoning when we design
I think we have different views on OOD. I consider sequence diagrams to be very important. Not because of the diagrams themselves, another notation would work too, but because of what they depict : interaction, dynamics. I believe responsibility driven design is the way to go and that approach doesn't work by focusing on structure.

Considering OOD as mostly a matter of structure and class diagrams, is in my opinion a masked form of data modeling. Fortunately that practice works adequately for many developers because they work in business contexts, which are transactional and data-driven anyway.

I've always found it strange that books on OOD begin with & focus on class diagrams. And what's even stranger is that those diagrams almost always contain very little methods (apart from the implied getters & setters).

any plans for..
No, timing diagrams aren't on my list, I've never used them to be honest so I couldn't judge what current tools are lacking in their support. Class diagrams might happen in the future, but not at the moment. I'm actually working on something really cool right now that would reduce the viscosity of certain uses of sequence diagrams to practically zero. But it only works with a java code base and I see from your site you're not using java?

Best regards,
Yanic
 
Perhaps a more straightforward analogy (or is that a simile?) for the influence of refactoring tools on code viscosity would be the acceleration of time?
--
Well, no, not really. They choose the idea of viscosity because moving in a viscous fluid is not only difficult, it takes a lot of energy. If you want to reduce the [mechanical] energy, you have to apply some external force, like dropping in some solvent.
The nice part about the “refactoring tool as solvent” concept is that the solvent is a fluid, exactly like the viscous fluid. Like the refactoring tool is software, exactly like the software you apply it to (albeit in binary vs. source code form). This reinforces the idea that our tools have the same nature of our materials.
Actually, what I like about the “raising the temperature” alternative is that reinforces another concept (which is less self-evident in the solvent metaphor). If you take away the source of heat, the viscous fluid gets back to its viscous state. Sometimes, it gets even worse. This reinforces the idea that viscosity can be mitigated through the use of tools, but not eliminated. For instance, when the initial architecture is sought, teams usually work on a whiteboard, not on a PC screen (for reasons I guess I don't have to explain). Having to rely on a tool to make a notation less viscous doesn't help when you can't use a tool. There is a parallel issue with RAD, library design, code generators and so on but would take too much to explore it here.
“Acceleration of time”, depending on what it's actually meant by that (moving faster, like keeping the same space and accelerating time to get higher speed?), would not have a positive impact on energy saving. It's true, however, that if we add a solvent or raise the temperature, we can move faster without spending more mechanical energy. (Ok, enough physics, let's talk software :-)

Ok, so were talking about the viewpoint that that a class diagram suffices and only serves as a memory aid, and there's a much larger design in your and your team members' heads.
--
You seem to discount the idea of collaborative design way too much. Design is mainly a process of devising a good solution. In many cases (co-located teams, and so on), it's much more efficient to discuss many details, but put only reminders of those details in diagrams, not the full details. As I said before, it's highly contextual. Forcing people to work with the “design as a precise specification of the implementation” model is exactly what lead many software developers to abandon the concept of design altogether, and rely only on emergent design (through refactoring). As I said, things may be different if you plan to have a distributed (or offshore) development, but that's not always the case.

I'd say such an ephemeral and distributed medium makes for a highly viscuous situation, no?
--
Well, no, exactly the opposite. Actually here we're comparing apples to oranges (viscosity of a notation vs. viscosity of a process/situation). But the viscosity of a process is exactly a function of how much bureaucracy you add, how much redundancy you build in your artefact chain, how many tiny details you want to work out before going to the meat. It's not an accident that the agile guys tend to be against diagrams (more or less). It's because the “design as specification” use of diagrams will put you in a highly viscous situation.

True about the diagrams, but those diagrams are located in about 44 pages of accompanying explanatory text
--
Exactly! That text, in a book, is the direct replacement for all the talking that would take place in a real-world design situation. Sure, in most cases, we would draw an overall diagram and not many snippets (again, that's the limit of printed stuff, you've to deal with limited space). In some cases we would go deeper in details, in some we wouldn't. The idea that we have to store in the design medium all the knowledge we accumulate through the design process is theoretically appealing, but in practice, it doesn't work. The economics just don't work in your favor.

Consider moving a figure by dragging it, you wouldn't want 300 tiny move commands in your history right? So you need something more sophisticated, and that is a non-trivial design change if your move command has any kind of domain
--
On the other hand, if you want a coalescence property on commands (which you most likely want), that would be a very visible method on the command class. Apart from that, it's unlikely that a sequence diagram will help much in devising a sound coalescence strategy...

I think that people familiar with OOD have *a lot* of problems with the dynamics of their own system.
--
Sounds like a self-fulfilling prophecy :-))).

I always look at it this way : the dynamics are what you're trying to work out and get right, the static description is just a consolidation/summary/projection of whatever you decided on for the dynamics.
--
Let me clear this out: when we design the structure (form), we obviously do that to support the desired behavior. Of course we go one step further: we want to support even other behaviors, making the design flexible. We're also looking for conceptual integrity, low coupling, high cohesion. It's quite hard to evaluate (for instance) cohesion from a bunch of sequence diagrams. Most of the properties of “good design” are more easily evaluated on the structural diagrams.
That said, it is a misconception that the structural diagrams don't talk about the dynamics. It would be a long story for a comment, but I can provide an interesting reference from Peter Coad: he talks about the implicit vs. explicit dynamic in Archetypes,Color, and the
Domain-Neutral Component
(from page 15). Peter presents his ideas on the Domain Neutral Component, but they're obviously not limited to that. Also, clear names for classes and methods, the adoption of well-established patterns (which have an implicit dynamic), colors, and so on all enhance our ability to communicate and encode some of the dynamic on the class diagram.
In other cases, as I said, we do use diagrams (like state charts and activity diagrams, which are much less viscous than sequence diagrams).

Considering OOD as mostly a matter of structure and class diagrams, is in my opinion a masked form of data modeling
--
That's really a misconception. Along the same line of reasoning, we could easily argue that focusing on sequence diagrams leads to traditional functional decomposition. It doesn't have to be so, in both cases.
I understand it's not obvious or immediate to reason about the dynamics while observing the static view. In my experience, however, it's something most experienced designers gradually learn to do.
It is also important to understand that we design the static structure exactly to make the dynamics simple. Many good design concepts (among which the Law of Demeter) lead us to shun deep, complex interactions that have to be understood in their entirety (diagrams are useless if the interaction is simple, and sub-interactions well encapsulated).
We can simplify interactions by providing the right structure: again, I understand it's not an immediate concept; more will follow as I get back to the Concept of Form theme. However, if one starts with the idea that interactions will so complex as to benefit from diagrammatic reasoning, that's a hell of a self-fulfilling prophecy :-).
Having a static structure emerging from a bunch of sequence diagrams is also likely to create a fragile static structure (exactly like having a static structure emerging from writing code), as the dynamics tend to be volatile. That's why we insist so much on creating a flexible, robust static structure that can accommodate several different dynamics.

And what's even stranger is that those diagrams almost always contain very little methods
--
I guess we read different books :-)))


Winding down: of course, I didn't write the above to change your mind (I know people seldom do without experiencing things first hand). But I thought it could be interesting for other readers as well. So, thank you for the stimulating conversation: I'm sure a few point will become clearer when I'll get back to the Concept of Form.
 
Carlo, the CD framework is a very interesting tool. Its aim is a necessary meta-reasoning about our way to solve problems (or to shape form?): << (the CD framework has been created) to assist the designers of notational systems and information artifacts to evaluate their designs with respect to the impact that they will have on the users of those designs.>>

This reasoning impacts process effectiveness (of a single or a group of designers) and product quality.

In my opinion, software ergonomics have two side: user side and designer side. Many work focus the user side but the designer side is important too (the designer is a person as well as the user!). Moreover I think the two side are related. GUI task and concepts reflect the designer's comprehension of the domain/problem and this comprehension is embodied in the software model (the internal organization of information). The cognitive dimensions of the sw model (the material or the notation) perhaps have repercussions on the cognitive dimensions of the user's space of interaction (CD authors ensure they have repercussions on how designer handle the design).

The first paper in your post is 7-years old. I didn't find more recent papers about the framework or is evolution. In particular I am interesting in the exploratory understanding profile that allow me to do a simple (test) evaluation: I usually write the document that explains design decision in the form (notation) of word processor outline. My question is: is this the best form? Or a mental-map (see Mindmanager for a tool) is a better form? (This idea came to me reading the paper) Did you know where I can find this profile?
 
The cognitive dimensions of the sw model (the material or the notation) perhaps have repercussions on the cognitive dimensions of the user's space of interaction
Yeap, I think so too. That's was basically what I meant by "Indeed, I believe the form itself will be heavily influenced by the process and notation you used when you conceived the form". It's also something that's routinely ignored in the "code vs. models" endless debate, while it could shed some much-needed light on a difficult topic.

Unfortunately, I don't have a specific reference on the exploratory understanding profile. However, your question is more specific, as it's about recording design rationale.
If you look at the cognitive dimensions bibliography you'll see several references to design rationale capturing, which closely address your question. Most of those papers are from Simon Buckingham Shum.
Funny thing is, I started this post speaking of an highly self-referential community. Back in December 2007 I quoted a paper by Simon, describing a free tool to capture design rationale (among other things). The post was titled "More synchronicity" which kinda closes the circle :-).

On a sidetrack, I tried mind mapping tools years ago, but for one reason or another, they never really "clicked" for me. Thanks for reminding me, I'll add something more as soon as I get around my long-due post on form, forces, and the forcefield.
 
Post a Comment

<< Home