2. Bird’s View
Before you can start creating your MDG it is necessary to do some preparatory work. A MDG shall support development of your UML models and enhance communication with respect to the individual domain you are working in. To actually do that you need to know your domain. And the best way is to sketch a domain model. It’s as simple as drawing a class diagram – in theory. In practice it is one of the most difficult tasks since the domain knowledge is usually distributed and well hidden in papers piled in drawers of different staff. Or quite more often just in the brains of the latter.
To get a start with this create a new repository for the MDG design. The model/root node is best called after the domain itself. This can be the industry, company or branch name. I found it best to use Model Driven Architecture (MDA) from the beginning. So the Views beneath the model root shall be named CIM (computation-independent model), PIM (platform-independent model) and PSM2 (platform-specific model). A Sandbox view comes in handy for several purposes.
2.1 Stakeholders
The business itself is important. But even more are people doing that business. Only if you know who is involved it will be possible to create something that will be accepted. Your project can only succeed if you get all relevant people aboard. Else prepare for ship wrecking.
Inside the CIM create a folder Stakeholders with a use case diagram of the same name. Start by putting actors for the most obvious roles onto the diagram. Make sure you write a short description in the notes of each actor. If there is a job description (on paper) just reference that. It is not much work but will help understanding the domain. Not just for you but also for people coming after you that need to get started.
You can augment the diagram by relating the single actors as to the company hierarchy. Use simply dependency relations for that.
The list of stakeholders must not be complete from beginning on. Often you discover new ones in the course of the following process. Just don’t forget to add them to the diagram!
2.2 Requirements
Gathering requirements can bring you a hard time. Without the right requirements it is impossible to find the goals you want to reach with modeling. But most times people think that requirements are “obvious” and do not need any effort to be extracted. For the same reason you will not find a budget for this. So to overcome that dilemma you must discipline yourself to write down anything that resembles a requirement. Of course, the best place is this repository where you want to design the MDG.
Place a Requirements folder inside CIM and create a Requirements diagram inside. Eventually you will need some structure for functional and non-functional requirements later. But for now if you happen to find a requirement from any stakeholder just drag the actor as link onto the diagram (you might as well use instances and name the concrete person) create a Requirement from the toolbox and <<trace>> it to the actor.
2.3 The Domain Model
Once you got the basic set of stakeholders and hopefully a set of requirements you can start analyzing the business domain. Create a folder Domain Model with a class diagram of the same name inside the CIM view just below the Stakeholders package.
Now start with adding classes for all business objects that come to mind. I sort of mix object and class here. What you actually do is to find the real objects and create a class for it. Each business object shall finally be represented by a class in the domain model.
Of course each domain has very different business objects to deal with. A bank will have accounts and stocks, machine building companies will deal with all sorts of tech paraphernalia, a chemical plant will use chemical material and so on. In a first step just name the single objects and place them on the class diagram. This can well be done as a brain-storming on a white-board.
Eventually the number of domain objects can get large so you need to package them. Papers are a good example to build an own package. Often you can simply identify dependencies between papers and you should draw those directly between the single objects.
The next step is to identify the properties of the single business objects. This is one of the more tricky steps. Finding the properties themselves will often cause you to ask different people and moderate their contradicting answers.
At the same time you need to make up your mind as to what granularity your domain model will go. For example an address can be formalized quite much. But only if your business is limited to a certain geographical area. Once you have more than one area you will find that formalizing address descriptions can easily become a nightmare. It is often easier to start with simple string properties and attach notes to where a later refinement might be useful.
The above model would be some start for our example domain. Definitely it is not complete but from here you will get an easy start and an idea how to continue.
It is important to involve all stakeholders in completing each single business object. But rather than bringing all together in a single work shop (which is often challenging due to time constraints) go and visit one after the other and note what they say. Such big meetings often end up in fruitless discussions and are a simple waste of time. Once you got the different opinions try to unify the diverse ideas and moderate that in smaller workshops. Once you made a picture go ahead and present and discuss this to get a sign-off. Eventually you have to go that round-about once or twice but that should be it.