Software Engineering – Domain Modelling

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.

http://en.wikipedia.org/wiki/Domain_model

 

 

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:

1. Courses
2. Reading Material
3. Books
4. Chapters, and
5. 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