Our paper, a prototype, gives us a nice picture of the interaction, and our outline captures a lot of information about how the program should behave in various cases.
It also captures details on the naming side of things from a business perspective.
All in all, this gives us a lot of good insight, but there is still a part missing. This makes the information out of our paper prototype durable enough, so we can more easily reference it as we move along. The prototype we drew earlier is missing some information that is important to the implementation. We need to capture more of the
This is the point where Unified Modelling Language (UML) comes into play, yes this scary piece of waterfall-infused practice that most of us never thought of as being useful. When talking about UML is it often referenced as the idea to encode all modeling information in a diagram; so ultimately code could be generated and filled out by basically everybody with some amount of coding skills. Of course, this does not work, but UML still has some interesting properties that make it useful. What we are setting out to do is leveraging one property of UML, and this is the ability to capture interactions in a concise form. UML defines multiple categories of diagrams:
• Structure diagrams
• Behavior diagrams
• Interaction diagrams
A structure diagram focuses mostly on the actors in the system and their
relationships. In our case, it would express the relationship of the keeper toward the dungeon and other orcs for example. This can be helpful when many actors are involved, but is not necessarily the most important information to start out with.
1 1
1 Dungeon
Structure Diagram
Keeper oversees Orc
*
A use case diagram gives a slightly more detailed picture of the actors in the system, and their interaction with each other. A use case diagram is part of the behavior diagram family and therefore focuses on the behaviors of the actors. This is not only useful information for our system, but also too coarse grained at the moment to express the flow of information and actions.
Behavior/
Use Case Diagram Dungeon
Manages Collects
Money Guards
Keeper Orc
As our feature does involve interaction between the defined actors of our system, a useful thing to explore is the sequence of events as they happen in our system.
For this, we can use a sequence diagram, which is a type of interaction diagram in UML. This kind of diagram focuses on the sequence of events that need to happen to achieve a certain goal. Some of this may be asynchronous, some needs to await a response; all this is captured in a single diagram:
Transparent
Keeper Orc Dungeon Prisoner
notify release from
cell
assign Prisoner
assign orc
Sent off Check available More
Prisoner
With this kind of illustration, it is easy to distinguish between synchronous and asynchronous messaging, so we can be sure to model the methods accordingly. Also, naming things is known as one of the hardest problems of computer science, so be sure to show this to your domain experts to draw from their language to name the now exposed messages and methods.
So far, the idea of every part has been to have the tools to explore the problem from different view perspectives, but don't drink too much of the Kool-Aid! We don't try to create a complete description of the whole system, but rather explore one part just deeply enough so that we can get a sense of what its core functionality is going to be and how it makes sense to implement it. We can then remove the uncertainties, by asking the right questions as we know the domain well enough so that we are able to explore the business domain together with the experts.
Involving the experts
As we explore the domain from every angle, it is important to talk to the people who know as much as one can about it. One of the core ideas of domain-driven design is to create a language around the domain that can be spoken by each party involved.
When talking about the tools, we set out to create them in such a way developers as well as domain experts can take part on an equal footing, so each can draw from the other's knowledge to approach a problem.
The spoken language is a problem in itself, so for developers it needs to be as unambiguous as possible, because very concrete and specific ideas need to be expressed. There should be no room for misinterpretation. For business people, on the other hand, it needs to be understandable for such a non-technical audience.
Now comes the important part, where we actually are going to see whether we have achieved this goal so far, and how we are able to communicate the ideas of the domain back and forth.
When involving the experts of a domain, we should first have a clear idea of what we are trying to achieve, such as gaining knowledge about the system we are currently developing. It is a natural tendency for developers to make their system shine in the best light, but our goal is to expose misunderstandings and uncertainties in our design and understanding so far. We actually want to get caught off-guard, so to speak. For the current stage of the project, this should be considered an achievement. Right now, change is as cheap as it is going to get, so if we expose a certain gap in our knowledge, we make our lives easier down the road. Getting a misunderstanding exposed right now also means that we were able to ask all the right questions such that we were able to communicate this abstract idea of a software system successfully; thus, the business side was able to dive into our system and correct the flaws. If we get to this point, non-developers are actually involved in the development and we can move forward developing a very well-suited system.
So, how do we get there?