| |
Time: 20 hours
Level: Intermediate
| |
|
| |
 Introduction Resource- This material introduces the first steps in modelling a software system. Software development is made up of phases, which are often organised into cycles. The first of these phases is requirements specification....
| |
|
| |
- 1.1 Conceptualising the system domain as classes Resource
- The first step in structuring the system is to model the system domain in terms of a collection of classes and the relationships between them. The system domain is the real-world context specific to the...
- 1.2 The aims of this unit Resource
- Starting with the requirements document for a hospital based system dealing with teams of doctors, patients and wards (see the 'View document' link at the foot of this page), the main aim of this unit...
- 1.3 Studying this unit Resource
- This unit contains a number of self-assessment questions and activities, which are designed to reinforce your understanding of the concepts presented. These form an important part of the teaching strategy...
| |
|
| | 2 Developing the conceptual model
- 2.1 Main activities in developing a conceptual model Resource
- In this section you will learn about:
- 2.2 The role of the conceptual model Resource
- At the very heart of object-oriented programming is the philosophy that software objects can usefully correspond to real-world entities. This is why we create a conceptual model that ‘looks’ object-oriented:...
- 2.3 The conceptual model in the context of the wider system Resource
- The broad real-world context in which the software under development is to operate is known as the business area. This encompasses all the entities and processes, systems and subsystems that contribute...
| |
|
| |
- 3.1 Terminology and notation Resource
- In this section, you will learn ways of using a requirements document as the basis for identifying the conceptual classes needed to represent entities from the system domain.
- 3.2 Identifying classes and attributes Resource
- The analysis process starts with the identification of a set of conceptual classes – the categories of things which are of significance in the system domain.
- 3.3 Identifying classes and attributes for the Hospital System Resource
- Now that you have been armed with a number of techniques for identifying appropriate classes for a conceptual model, you can apply them to the requirements document for the Hospital System.
- 3.4 Generalisation relationships Resource
- We have already discussed links between particular entities in the system domain, and briefly introduced the concept of an association between two classes – a relationship whereby the instances of those...
- 3.5 Abstract classes Resource
- Read the following extract from the requirements for the Hospital System:
- 3.6 Class or attribute? Resource
- In determining suitable classes and attributes for the Hospital System, this section has presented a number of guidelines and techniques as if applying these were a fairly straightforward process:
| |
|
| |
- 4.1 What is an association? Resource
- In the previous section you learnt how to identify conceptual classes and their attributes from a requirements document.
- 4.2 Identifying associations Resource
- In practice, the identification of associations often proceeds in parallel with the identification of classes. When you are considering a possible class, it is also natural to think about the connections...
- 4.3 Multiplicity Resource
- When discussing the associations for the DVD Library System, we noted that a requirements document frequently provides information about the number of links that are possible between objects of particular...
| |
|
| |
- 5.1 Criteria for modelling events Resource
- In the discussion of classes earlier in the unit, we gave events as one category of ‘thing’ that could be modelled by classes. You saw an example of this in the DVD Library System, where the loan of a...
- 5.2 Summary of criteria Resource
- We will end this section by summarising the criteria to be considered when deciding whether an event is best represented by a class or an association.
| |
|
| |
- 6.1 What is an invariant? Resource
- The aim in constructing a conceptual model is to capture all the relevant information about the system domain provided in the requirements document so that this model can form the basis for the structure...
- 6.2 Remaining invariants for the Hospital System Resource
- There are two of these corresponding to the constraints that the team code of each team is unique and that the ward name of each ward is unique.
| |
|
| | 7 Derived attributes and associations
- 7.1 Using invariants to derive attributes Resource
- In this section, you will learn:
- 7.2 Using invariants to derive associations Resource
- Just as there is a relationship between invariants involving attributes and derived attributes, so it is the case that invariants involving links of different associations may indicate that one of those...
| |
|
| |
- 8.1 Conceptual model for the Hospital System Resource
- We are now in a position to produce a conceptual model for the Hospital System.
- Class diagram Resource
- The attribute of any object has the same value as the type attribute of the linked object.
| |
|
| |
- 9 Summary Resource
- This unit has introduced you to the ideas and techniques involved in forming a conceptual model of a system domain and in particular a conceptual model for the Hospital System.
| |
|
| |
- Glossary Resource
- Abstract class –
A class which cannot be instantiated, i.e. one which has no instances of its own but only instances of its child classes. An abstract class defines properties which are common...
| |
|
| | References and Acknowledgements | |
|
Except for third party materials and otherwise stated, content on this site is made available
OPML Feed
