What is Domain Modelling?
Domain Modelling is a way of representing the context in which the software must operate – to understand the software better. However, one must remember that you’re not modelling the software to be built!
A better description would be:
A Domain Model in Software Engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relations.
Domain Modelling 101
- Go through the available data sources; such as the original description; Use Cases; Glossary etc etc. With this, you must then identify possible Domain Classes (noun phrases)
- Identify basic relationships between the domain classes.
- Add addition key attributes
- Pay attention to the relationships, like names and multiplicities – it is very important that these are correct!
Domain Modelling Example
Now for the moment you’ve all been waiting for, an example! :D Sadly a Domain Model doesn’t have any stick people in it, so there’ll be no awesome stick people of awesomeness :(
Lets say we have the following information for a basic Student Library System:
Courses may have recommended items of Reading Material, which may be either complete Books or individual Chapters. Items of Reading Material may also allows a user or floppy for every NFA there is i for for have Reviews associated with them.
Now with this we need to identify 5 classes, can you see what they are?
Hint: i cheated a little, they’re in italics…. :P
So, yeah… we have the 5 classes of:
- Courses
- Reading Material
- Books
- Chapters, and
- Reviews
And with this, this is what the Domain Model looks like:
Before I start to explain what this shows, lets explain the arrows and numbers:
-
This is the first thing. This – obviously – is a line. When we see a line connecting 2 classes together this shows us that these 2 classes are related. The text that lays on the line, ie “provides”, says that Course is related to Reading Material as a “Course provides Reading Material”.
An arrow implies a relation of inheritance. So for the diagram above, its should be obvious that a Book will inherit some methods from Reading Material. A more better example of this could be if we thought of this in a Java/C++ sense. For example, we create a Person Class and then create a Student Class, a Student will inherit methods (etc) from Person, such as getAge() and getHeight() , as well as name and age etc etc.
This is a line with a funny looking diamond thing on the end. What this states is that class ‘A’ contains class ‘B’. For example, above we say that a Book contains Chapters – which is obviously true, else it would really be a book…
Another example would be if we had the classes Wallet and Money. So we could have Wallet => contains => Money.- The final one is the numbers; so (0, 1, *, 0..* and 1..* and many more). What these state is a relation such as one-to-one, or one-to-many. In the example above we have these numbers on the contains relation for Books and Chapters. So we say that a one (1) Book contains one or more (1..*) Chapters.
Alternatively we can also say that one (1) Course provides zero or more (0..*) Reading Material.
As a note, remember that we can only use these numbers on plain relation lines and contains relations. we do NOT use them on inheritance relations! :)
And i think that’s it for Domain Models :D , sorry for doing this one a little late, i had some issues with the diagram above. However, many thanks to James Bedford, Daniel Lyon :D
