EMOF and the abstract syntax of the Empathy Canvas (part 1)

To Osterwalder et al. (2014), taking customers’ goals, problems, and expectations to heart is a key to successful entrepreneurship. This conviction led them to create the Empathy Canvas (Osterwalder et al., 2014, pp. 10–25): a modelling language inviting us to deepen our understanding of customers, so that ideas about products and services they like come naturally to us.

We have tested this language and have found it so great that we have decided to make a software application out of it.

But before writing a single bit of code, the first step is to detail as explicitly as possible the concepts that the Empathy Canvas enables us to model, and that our program will have to depict symbolically on the computer screen. To do this, we are going to use a specialised language called EMOF (Object Management Group, 2016, pp. 25–34). For EMOF fosters precision, whereas English and other natural languages leave room for innuendoes and thereby complicate programming.

How to model with EMOF

Concepts are categories—classes, as they are referred to by computer scientists—into which we place things that share common properties but has each its own identity. The author of this article is an example—an instance (this is the technical term)—of the concept of Blogger because he matches the definition of a Blogger: he regularly posts new Content on a Blog, which is, in a way, his personal Communication Space on the internet.

When we capitalise a common noun or common noun phrase, such as Blogger, Content, Blog, or Communication Space, we stress that we are interested in the concept behind the words. In EMOF, this is made known by writing them inside a rectangle (Figure 1).

If a concept has a finite and reasonable number of instances, and if we know them all, we can list them below its name, provided that the indication «enumeration» precedes it (Figure 1). Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, and Sunday are, for example, the only instances of the concept of Day (Figure 1).

Just a moment ago, we have explained the concept of Blogger by associating it with those of Content and Blog by the relation “posts on”. And we have related likewise the concept of Blog to that of Communication Space by the relation “is”.

That is exactly how we express things in EMOF: we describe concepts in terms of other concepts, which we link again with other concepts, and so forth until there remain only concepts that we consider primitive, i.e. simple and basic enough to be understood by readers.

Graphically, the existence of a relation between two concepts is shown by connecting with a line the rectangles symbolising them. On this line, it is obligatory to specify next to each concept its role and its cardinality in the relation (Figure 2).

In Figure 2, we have introduced the concepts of Date, Person, and String. In computer science, Strings are pieces of raw text such as "rest", "a beautiful landscape", and "I like formal methods". They are customarily started and ended with a “"”—not to be confused with quotation marks (“…”).

Three relations can be seen (Figure 2):

1. A relation between Persons and Strings in which Strings play the role of surnames. The cardinality of Strings, 1, says that a Person has at least one and no more than one surname, while the cardinality of Persons, 0..*, says that a String is the surname of zero or several Persons. For instance, in the United Kingdom, there are a lot of "Smith"’s but no "Qwerty"’s.
2. A relation between Persons and Strings in which Strings play the role of forenames. The cardinality of Strings, 1..*{ordered}, says that a Person has at least one and possibly more than one ordered forenames—a first, a second, a third, etc., with the order being important—while the cardinality of Persons, 0..*, says that a String is one of the forenames of zero or several Persons.
3. A relation between Persons and Dates in which Dates play the role of birthdates. The cardinality of Dates, 1, says that a Person has at least one and no more than one birthdate, while the cardinality of Persons, 0..*, says that a Date is the birthdate of zero or several Persons. The “{readOnly}” appearing twice is not part of cardinalities. We will clarify its meaning shortly.

In general terms, in a relation between two concepts C and D, the cardinality of C is of the form n..pQ, where n and p are respectively the minimum and maximum numbers of instances of C with which an instance of D may be linked. It goes without saying that p must be greater than or equal to n. The notation n..* means that p is unlimited (but not infinite). EMOF allows us to shorten n..n to n and 0..* to *.

If needed, a cardinality can be complemented with an “ordered” or a “nonunique” between braces in the optional part Q. An “ordered” indicates that there is a first, a second, a third, etc., and that the ordinal number of an instance is an indispensable piece of information. We saw its usefulness in Figure 2. To understand when to use “nonunique”, one has to know that without it, by default, a relation does not connect two instances several times. The model in Figure 2 implicitly states that each of the forenames of a Person is different.

Not having the “nonunique” at our disposal would have limited our modelling capability. For example, in Figure 3, the Web Users of the model on the left never visit a Web Page twice, something nobody does in real life. To correct it, in the model on the right, we added an “ordered” and a “nonunique” to the cardinality of Web Pages. The “ordered” reminds that the visits of a Web User occur in a chronological order, and the “nonunique” models his freedom to return to a Web Page as many times as he wishes. We do not feel the need of an “ordered” in the cardinality of Web Users; we think that a “nonunique” is enough because for a Web Page, what matters is the total number of visits, not the order in which they take place (this is a debatable point of view).

An “ordered” or a “nonunique” has to be taken into consideration only if the cardinality is of the form n..* or n..p with p ≥ 2.

Relations usually evolve over time. A marriage may, for example, alter the surname of a Person. He might also decide on his own to change it in order to integrate himself more thoroughly into a community or for other personal reasons. Relations where every link between instances is immutable once established are marked with “{readOnly}”. In Figure 2, the two “{readOnly}” model the fact that a Person’s birthdate will always be the same.

Nothing prohibits us to duplicate a concept at different places of our diagram or to associate it with itself. The two relations in Figure 4 below are absolutely all right and express exactly the same thing: a Person has two parents and zero or several children.

If, at the instance level, all the connexions formed by a relation are deducible from one or more other relations already modelled, then it is derived. The age of a Person and the Day he was born are two examples of relations—the first between Persons and Integers, and the second between Persons and Days (Figure 5)—computable or retrievable from his birthdate. On a model, derived relations are easily recognisable because the roles of the concepts they join are prefixed by “/”.

Dates are often written as triplets of Integers where one of the three Integers stands for the year, another between 1 and 12 for the month of the year, and another between 1 and 28, 29, 30, or 31 for the day of the month. For example, depending on the country, an all-numeric writing of the 14th of May 2019 is 14/05/2019, 05/14/2019, or 2019/05/14. This is what is modelled in Figure 5 by the three relations between Dates and Integers.

Let us return now to our Blogger. We said at the beginning of this section that what makes someone a Blogger is his regular postings of new Content on a Blog. In this description, the act of posting is a relation that involves three concepts: Bloggers, Contents, and Blogs. But in EMOF, concepts must be linked two by two. So, how are we going to model this?

The solution is to add a connective concept (Figure 6).

In Figure 6, the connective concept of Post embodies the connexion existing between Bloggers, Contents, and Blogs because no Post is realisable without a Blogger, some Content, and a Blog. Its addition even enables us to model without difficulty the Instant at which a Blogger posts Content on his Blog (Figure 6). An Instant is specified by indicating the Date, the hour, the minute, and the second (Figure 6).

The same content cannot be posted by the same Blogger on two different Blogs at the exact same Instant. It is impossible. Moreover, if a Blog becomes inaccessible, for example because of its deletion, then so will be all its Posts. These two properties of the relation between Posts and Blogs tell us that it is a so-called composition. On a model, the compositional nature of a relation is shown by a small black diamond adjacent to the concept that results from the composition (Figure 7).

The precise definition of composition is the following. A relation between two concepts C and D (in the previous example, C was the concept of Blog and D that of Post) is a composition if and only if:

1. as long as an instance of C is linked with an instance d of D, no other instance of C can be linked with this d (the cardinality of C is consequently 0..1 or 1);
2. whenever an instance c of C is lost or inaccessible, so are all the instances of D linked with c.

For a Blogger, a Blog is a personal Communication Space on the internet. To say that a Blog is a Communication Space is to say that every instance of the concept of Blog is also an instance of that of Communication Space. In EMOF terminology, the concept of Blog is a specialisation of that of Communication Space, and the concept of Communication Space is a generalisation of that of Blog. EMOF symbolises this kind of relation by a line with a triangular hollow arrowhead (Figure 8) pointing to the generalisation (Communication Spaces). It is the only type of relation without roles and cardinalities (Figure 8).

A specialisation inherits all the relations of the concept it specialises. For example, because a Blogger is a Person (Figure 8), he has, like any Person, a surname, one or more forenames, and a birthdate.

OK, after this overview of EMOF, we are now ready to tackle the abstract syntax of the Empathy Canvas. Even though we have not discussed all the modelling facilities of this metalanguage—we do not want this post to be long and boring—what we have learned is enough to start. A little practice will do us great good. We will complete our review as we write new articles.

An abstract syntax for the Empathy Canvas

As a reminder, a modelling language is a set of rules followed by its users to represent and convey their ideas regarding a particular theme. The Empathy Canvas (Figure 9) is, for instance, a modelling language whose theme is the understanding of what customers are looking for.

The abstract syntax of a modelling language is the inventory of the concepts about which its users can speak, and the list of the relations between these concepts that, through it, they are able to express. Below, in Figure 10, we used EMOF to present the abstract syntax of the Empathy Canvas.

We arrived at this abstract syntax after carrying out the following analysis:

1. The circle in the background (Figure 9) symbolises a Customer Segment—in the present case, readers of software engineering courses. So, Customer Segments are concepts of the abstract syntax (Figure 10).
2. The right, bottom, and top areas of this circle (Figure 9) are respectively reserved for the writing of Goals, Problems, and Expectations. So, Goals, Problems, and Expectations are concepts of the abstract syntax too (Figure 10).
3. Every Goal, Problem, or Expectation of a Customer Segment is for it a Concern (Figure 10). In Figure 10, “Concern” is written in italics, which means in EMOF that it is an abstract concept, in the sense that, contrary to Goals, Problems, and Expectations, its existence is not noticeable directly on the Empathy Canvas (Figure 9); it exists only indirectly through the instances of its specialisations, which are, precisely, Goals, Problems, and Expectations (Figure 10).
4. Each Concern—Goal, Problem, or Expectation—is given as a descriptive text (Figure 9) which is a String (Figure 10).
5. The darkerlighter the background colour of a Concern—a Goal, Problem, or Expectation—is (Figure 9), the greater its importance in the eyes of the Customer Segment. For us, these shades of color are actually figurations of Real Numbers between 0 and 100 (Figure 10). In mathematics, Real Numbers—we will call them Reals for brevity (Figure 10)—are the numbers with which we measure things of the real world.
6. The background colour of a Concern—a Goal, Problem, or Expectation—(Figure 9) can be thought of as a Boolean (Figure 10), i.e. a piece of information that is either true or false. Indeed, if it is not grey (Figure 9), then the existence of the Concern has been validated by an experiment (Figure 10), but if it is grey (Figure 9), then no experiment has succeeded to demonstrate the existence of the Concern yet (Figure 10).
7. The border colour of a Concern—a Goal, Problem, or Expectation—(Figure 9) can be thought of as a Boolean too (Figure 10) because if it is not grey (Figure 9), then the level of importance of the Concern has been validated by an experiment (Figure 10), but if it is grey (Figure 9), then no experiment has succeeded to demonstrate the level of importance of the Concern yet (Figure 10).
8. The experiments that have been run to assess the reality and the level of importance of a Concern—a Goal, Problem, or Expectation—are documented in a Test Card (Figure 11). The abstract syntax of this Test Card is easy to find (Figure 12). In Figure 10, the relation between the concept of Concern and the concept of Test reflects the connexion between Concerns and experiments.
9. Customers have Problems that prevent them from achieving their Goals, but they will favour only solutions that meet their Expectations. That is why we linked Goals with Problems (Problems prevent customers from achieving their Goals) and Problems with Expectations (customers have specific Expectations that determine the solutions they consider acceptable for their Problems).
10. Last but not least, one Goal, Problem, or Expectation can hide another. The whys and wherefores of a Goal, Problem, or Expectation are often other Goals, other Problems, or other Expectations. For instance, in Figure 9, the wish to be trained in software engineering may spring from the desire to retrain professionally in order to, perhaps, find a job with a future. In the abstract syntax (Figure 10), we took account of the possibility of such causal links by adding relations connecting Goals with other Goals, Problems with other Problems, and Expectations with other Expectations.

As we can see, in EMOF we describe concepts in terms of other concepts, which we link again with other concepts, and so forth until there remain only primitive concepts that are simple and basic enough to be understood by readers. We must indicate with a «primitive» the concepts that we consider primitive. Here, we have opted for Booleans, Integers, Reals, and Strings (Figures 10 and 12).

This selection is appropriate for models intended to be read by people because everybody can get an idea of ​​what Booleans, Integers, Reals, and Strings are after some brief explanation.

The problem is that our models are designed for computers. They are the ones in need of a detailed account of the concepts found in the Empathy Canvas—Customer Segments, Goals, Problems, Expectations, etc.—in order to depict them symbolically on the screen. Someone may have already told you that a computer knows nothing but the digits 0 and 1—a.k.a. the binary digits or bits for short. How then can they comprehend what Booleans, Integers, Reals, and Strings are? Let us keep the answer to this question for the next post.

Questions

Each of the symbols that compose a String is called a character. The r, e, s, and t of "rest" are instances of the concept of Character. Characters are thus more primitive than Strings:

What reasons do you see for choosing nonetheless as primitive the concept of String over or along with that of Character?

Bibliography

Photographic credits