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
In software development
- They can be used for modelling the domain. This means that the classes in the diagram have domain objects in them, not software objects. This is for when the diagram will be used as a communication tool between engineers and customers
- They might be used to model the specification and design of the system, so that the object in this case are software objects. In this case, diagrams are only used between software engineers so it's not vital to put loads of information on them, as the customer won't see it anyway
- They could also be used to document the actual code. You show all detail in it, normally reverse engineered from the code. Javadoc might be a better idea though.
What is domain modelling?
- This is when we are representing the context the software needs to operate in
- Normally class diagrams although maybe interaction diagrams (these appear in semester 2)
- Remember to KISS: Keep It Simple, Stupid. You aren't modelling the software to be built
Basics of domain modelling
A helpful step by step guide
- Go through the data sources available, this is things like the use cases, glossary, original info. Identify things you might be able to use as domain classes. Nouns are good for this. A noun is a person, place or a thing.
- Work out the basic relationships between the different classes
- Now add the key attributes and shake well
- Make sure you get the relationships right
- Iterate
- Update your original resources, don't forget the glossary
Example
(Adapted from Software Engineering Notes 2009; John Sargeant)
No comments:
Post a Comment