Software Engineering Lesson #1: NEVER assume domain knowledge

This is a lesson for me as a teacher more than for students. Although I hope I will be able to transfer it to students too.

I have been issuing exam exercises for years now, spanning diverse topics and domains very remotely connected between each other, i.e., food, healthcare, transportation, banking, tourism, art, chemistry, and so on.

From time to time, depending on the domain of the exercise, I get questions from people asking things like:

  • is an atom bigger or smaller than a molecule?crossword-letter-tiles-hi
  • what’s the relation between a planet and a star?
  • OR EVEN: what is a cross-word? How do you play?

Usually, after a moment reflecting my disbelief, I kindly respond explaining things from relativity theory to gaming. But then, any use of this? Obviously yes! The main, first and core lesson any software engineer should always keep in mind:

#1: NEVER assume domain knowledge in your stakeholders.

If you do, you will quickly end up deluded (and you risk big in your projects, because you may start working based on statements from people that probably are not really knowledgeable of what’s really going to be needed).

Those omniscient users

Despite repeating it in my courses every year, I end up getting this error from at least 10 – 20% of the students at each exam session.

When drawing the class diagram of a software application, they invariably add a User class (call it the role you want: customer, admin, professor, director, clerk and so on) and then they add the list of actions that the user can perform in that class, instead of putting them in the classes they pertain to.

So, for instance if you want a method for paying a ticket of a flight, the payTicket() method ends up in the user class!

If you have any doubt that this is correct just think that then:

  • you should put all the method triggered by user choices, in user classes
  • to invoke that action from a caller method you should do it through the user class. Something like:  JohnDoe.buyTicket()
    While the right approach should be: myTicket.buy()

Attribution of actions / objectives to users is something you do at requirement specification level (e.g., when defining goal diagrams, use cases or scenarios), not at design level.

Model Driven Enterprise Engineering (TM)

Model Driven Enterprise Engineering (MDEE) is a concept proposed by Know Gravity, a company based in Zurich, Switzerland, that has been active in modeling and requirement engineering since 2000.

They propose a pragmatic approach to integration of OMG and non-OMG modeling specification, so as to cover all the modeling needs of the enterprise (and not only for software).
They come up with a quadrant of 4 + 1 modeling settings, as shown in this slide:

The Model Driven Enterprise Engineering framework and the mapping to the  OMG modeling languages.

The 5 scenarios are named as:

  • Strategy Model (business – what?)
  • Operational Model (business – how?)
  • IT Support Model (IT – what?)
  • Technology Model (business – how?)
  • Management Model

The focus of the approach is mainly in the first stages of design, and especially on requirement, simulation and early prototyping.
The approach is based on integrating and relating together multiple and diverse models, through the definition of a vocabulary (SBVR-based) and integrated metamodel.
It covers project management, enterprise and system document generation, functional requirements, business rules, and many more aspects.
The idea starts from the fact that using single OMG specification doesn’t make much sense, because actually many OMG business and IT specs are complementary and sometimes overlapping. Therefore there is need of alignment on meta entity level and of designing cross-model and/or cross-profile associations.
The current way they do this is to have a profile-based comprehensive modeling tool, that lets you model the various aspects and related them to each other.
In my opinion, this is not that different to the megamodeling approaches.
The good news is that they also plan to fully support IFML (the new OMG standard called Interaction Flow Modeling Language, see also my previous post on standardization here) in the framework by 2014.

Two peculiar initiatives I deem interesting are:

  • they trademarked the concept of Model Driven Enterprise Engineering!
  • they plan to write and publish a book on the topic which will be completely automatically generated out of the models, and will be produced following software engineering processes, starting from use cases, requirements, and so on!

You can find more on this at the company Web site: Know Gravity.

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Need to ask your analysts what they want?

Then you have a problem!
The problem is not that they are not able to collect from customers what they wanted. Sometimes they know very well, even too much. Sometimes they deliberately (and wisely) decide not to consider some requests. The price could be to live with the complaints of customers. All this is addressed very well in a recent post by Anthony Finkelstein on not asking users what they want (and I actually mimicked his title here). But this is another issue.

The problem with your analysts is they are not able to put into proper technical “words” (meaning models and specifications) what the customers informally ask for.
To cope with this, we try to teach people appropriate modeling languages, methods, formalisms, modeling tools and analysis tools. But these are all mere attempts to reduce the misunderstandings, implicitness, incoherency, and ambiguity in human-to-human communication.
And yet, addressing these problem is paramount in any large software project. From my point of view, it also opens up interesting research issues.
IEEEThat’s why, together with Irene Vanderfeesten and Dirk Fahland, from Eindhoven University of Technology, we decided to organize a new workshop this year, the:

1st IEEE International Workshop on Communicating Business Process and Software Models. Quality, Understandability, and Maintainability
Eindhoven, the Netherlands, 23 September 2013.


The workshop will focus on model understandability, complexity of modeling languages, actual usage of language features, cognitive aspects in modeling languages, human perception and subjective perspectives on models, impact of professional roles and of cultural background on model understanding, and related issues. The workshop will be a multi-disciplinary forum for discussing about impact of models on understanding and communication between people.

Its uniqueness stands in the attempt of bringing together the business process management (BPM) and software engineering and modeling communities
This will bring great value, as most of the misunderstanding and misalignments are between requirements and design, between business and IT, between CIM and PIM modeling levels. 
If you are interesting in knowing more about the 1st IEEE International Workshop onCommunicating Business Process and Software Models – Quality, Understandability, and Maintainability, you can visit the official Web site. You are obviously welcome to join the workshop and/or submit a contribution. The deadline for submitting is set to June 21st, 2013.

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

My invited post on Modeling Social Web Apps (on www.modeling-languages.com)

It’s with great pleasure that I announce my invited post on the modeling-languages.com blog, curated by Jordi Cabot.
First, I’m glad he invited me. Second, I’m happy that he asked for a post on Social-enabled Web application modeling.
I mean, we all see how social technologies are transforming our life. And yet, the modeling community and the software engineering community at large are paying very limited attention to this phenomenon.
That’s why I decided to address the problem by proposing a model-driven approach that is specifically focused on the development of Web applications that exploit social features, and my invited post is exactly focusing on this.
Basically, the proposal is to go from requirement specification down to static and dynamic design and to code generation of social applications with a pattern-based approach, which exploits goal-based requirement specification, UML modeling, and WebML models (enriched with social-specific primitives) for describing the user interaction. This image intuitively summarizes the idea:

You can find more details in the invited post on Social web application modeling on Jordi’s blog, and also check out the video that summarizes the approach:

 To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).