University Homepage School Homepage School Contacts School Search

Paleo? Notes on Week 2 in-class discussion

We spent the last part of the Tuesday session and most of the Friday session on the Paleo flowchart shown at the end of the Modelling slides. Some of the following questions you answered in small groups; some we discussed or I answered. Sessions like this one are at least as important as the lectures. I hope these notes will be useful for revision; they may also be useful if you had to miss the session, but it's not possible to write notes good enough to replace being there. As usual, ask on Piazza if anything's unclear.

Is it a model? What's good/bad about it?

Referring back to the definition of a model, the controversial part is whether it's a representation of an aspect of a system. One could argue that either way, depending largely on how broad an interpretation of "system" we take. To get a definitively positive answer (so that it made sense to go on!) I asked you to imagine that you were designing a tool that would help users build diagrams like this, say to incorporate them into apps that people could use to check whether a food was acceptable or not.

As is often the case with graphical representations, this one is quite accessible to humans - we could see how to use it - but wouldn't be much good as a representation of the same information for use by a computer. It has some usability issues; for example, it's not made very clear visually where to start. It has one frank bug: where should we go if we answer No to "Did it have a face?"?

What are the elements of the model? What are the rules about how to combine them?

Here's a pre-cleanup picture of what you collectively came up with:

Some of the things we discussed were:

• How many of these things are different? E.g. are positive ("it's paleo") and negative ("that'll kill you") results the same kind of thing, or different kinds of thing? We could have gone either way, but because they have more in common than not, I opted to regard them both as Results.
• What about arrows? Are they elements of the diagram? In writing up the rules, I referred to "yes-arrows" and "no-arrows", combining the idea of a yes/no answer with the idea of an arrow; this seemed a useful thing to do because of the fact that all arrows occur along with either a yes or a no label, and because it made the rules easy to express.
• How far do we want to go with the rules? The first few rules we identifed are pretty straightforward structural things that can be checked by looking at a specific local place on the diagram. Then someone came up with "no cycles", ruling out diagrams like this:

  

  which we agreed was a good rule because diagrams with cycles are undesirable as they fail to fulfil the apparent purpose of letting someone answer the question about whether a food is paleo or not. We noted that the example isn't a tree, though it's arguable that it would be better to insist that these diagrams were trees; currently reusing results or not seems to be driven by graphical considerations.

  That led on to what else we might want to forbid. We discussed properties like "from every question, it should be possible to give a sequence of answers that leads to a positive result, and a sequence of answers that leads to a negative result". That's potentially useful because, if this doesn't hold, there's no point in asking the question: we already know the result. Similarly, if the yes and no branches from a question led to isomorphic subgraphs, asking the question is useless. It wasn't obvious that there might not be more cases of this issue, which we could sum up as saying that each question should be useful:

  

How can we represent our conclusions in UML?

For example, if we were building that tool to help users build apps implementing these diagrams, and we wanted each element of the diagram to correspond to an object in our tool, e.g. so that we could let users move the elements around on the screen and help them not build nonsensical diagrams, then what would the classes of these objects be, and how would they be related?

Looking at the elements board, I first put up classes Question and Result. The questions in the diagram should correspond to instances of Question, and I decided to put a boolean attribute isInitial to represent whether a question was a starting point or not. I also gave Result a boolean attribute paleo to record whether a given result element was positive or negative.

Then we ran into a problem: how to show the yes-arrows and no-arrows? Since there's no data associated with those - every yes-arrow is nothing more than an arrow, labelled yes, from one question to another question or to a result - it seemed reasonable to represent these as associations coming from Question. But to where? If we had an association yes-arrow to Question, and another to Result, we'd have no easy way to show that you shouldn't have two yes-arrows, one to a Question and one to a Result, from the same Question. Someone solved this by suggesting a common generalization of Question and Result, which I called Node. Then we could add an association called yes-arrow from Question to Node, with a 1 multiplicity at the Node end, indicating that any Question leads by a yes-arrow to one Node, which could be a Question or could be a Result. Similarly, we can have another association called no-arrow between the same places. We end up with:

Now, some of our rules are encoded directly in the diagram. Others, notably "no cycles" and "every question should be useful", aren't and can't be. We can leave those in English, or we can use a formal language such as the Object Constraint Language which forms part of UML, to record those. We'll meet OCL later in the course.

So what have we done?

You have just defined a domain specific modelling language, for the domain of defining diagrams like the one we started with. The UML diagram we came up with is its metamodel, and the rules we have to keep because they aren't encoded in the diagram are its constraints. We'll come back to this idea, but for now, note that this is a convenient way to explain what is and isn't a sensible diagram (but it doesn't explain what a sensible diagram means, that is, it doesn't give semantics to diagrams). The UML class diagrams you've seen show models of collections of objects in a system; e.g., when you write a class diagram with classes Customer and Account, you may be saying that in the running system, there will be objects of classes Customer and Account. Here we're at a more abstract level, if you like: since we agreed to treat the original paleo diagram as a model, our UML diagram here is a model that describes possible models! That's why it's called a metamodel: it's a model that describes models. You can also have metametamodels... (The metametamodel for our metamodel might have classes in it like Class, Association, Multiplicity, and rules like "an association connects two classes"...) More later!

Other answers are possible! If you don't like one of the decisions we made, try making it differently, and see if you can take that through to a metamodel and set of constraints.

---

This page is maintained by Perdita Stevens (perdita@inf.ed.ac.uk)