Software Engineering – Summary

I didn’t make these, but Nida has kindly made a summary for software engineering and asked me to publish it, so here it is! Read more of this post


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.



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! 😀 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…. 😛

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:

  •  DMline  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”.
  • DMarrow 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.
  • DMcontain 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 😀 , sorry for doing this one a little late, i had some issues with the diagram above. However, many thanks to James Bedford, Daniel Lyon 😀

Software Engineering – Software Testing Concepts

Software testing concepts

The fundamental rule of testing is that ‘a successful test is one that causes the software to fail.

You can have a testing team who didn’t write the software do this.

An agile solution would be to write the tests before the code. This helps to clarify requirements too. Read more of this post

Software Engineering – Design Class Diagrams

Design / Object Classes

A Design Class diagram is a way of modelling the domain to a level of detail much more than that of a domain model. Inside a design class diagram, the classes become objects – Object Classes:

Read more of this post

Software Engineering – Software Design Intro

Intro to software design

Embury’s law

Remember this?

The software has bugs in it, we just don’t know what they are yet.

This applies to all non trivial software systems. It’s fine to assume that some parts of software might be bug free though, for example something that has been translated from another language, as we can check it fully for errors/bugs Read more of this post

Software Engineering – Domain Modelling

Domain modelling

Class diagrams

  • Class diagrams show the different classes and the relationships between them
  • Make sure you don’t show too much detail on them Read more of this post

Software Engineering – Use Case Diagrams / Descriptions

UML & Use Cases

UML stands for Unified Modelling Language. They are diagrams to help aid the creation, visualisation and documentation of various aspects of the software engineering process.

Read more of this post

Software Engineering – Requirements


Gathering requirements is very important, as they are a way of finding out what the new system should do, as well as make sure that your application supports the appropriate activities.
You are in constant communication with the customer, the users and developers, so that your system will match the users needs.

Read more of this post

Software Engineering – Methodologies

Fail to Prepare – Prepare to Fail

Software projects are HUGE, if you just sat down at your computer and started to hack away at code then you’re screwed from the moment you start. For projects of this scale we need a well defined process or ‘methodology’ to follow.

Read more of this post