The aim is to produce an overview of the analysis and design stages of a UML project. So we will introduce the main UML concepts,
Class diagrams.
Sequence diagrams.
Communication diagrams.
State diagrams.
This is not a detailed treatment but only an overview to show how these diagrams relate to each other.
We start with a set of requirements, use case diagrams and detailed software requirements. So we have the first draft of a functional specification for our software product. But what do we have to do now?
Well, we have to start developing the software by identifying its components. Since we are determined to use a modern approach, these will be objects. We also need to decide how the objects will interact with each other so we need to identify their properties and behaviour. The properties will be expressed as attributes (represented by variables) and their behaviour will be expressed as methods. Then we can start to implement the application in Java or C# or whatever.
To get the objects, and their attributes and methods, we need to specify the classes we will use - so that is our first task.
For our first attempt at a list of classes we read through the problem statement and note all the nouns. Our list of classes will come from these nouns. Other nouns may represent attributes of these classes while the verbs may help to identify class methods. If it were a perfect statement it would contain references to all the classes and their attributes and methods – but nothing is perfect, at least, in this first iteration.
To illustrate the process we can look at a brief problem statement for a very simple software application to manage an online course. Read the statement and see how many nouns you can identify. Try to list the ones that will turn out to be implemented as classes and those that might be attributes or just descriptive padding. Then try to spot the main use cases which will lead to the identification of class methods.
A university department wishes to update its course management system by committing its operations to a new software application. The application will be developed initially for trial on a new course. The title of the course is “Android App Development for Beginners”. It will allow the course manager to appoint existing teaching staff to the course and to enrol students on the course. It will also enable the manager to assign groups of students to appointed tutors. These will be known as tutor groups.
The system will record the course details and the names and other personal information of students enrolled on it as well as the names of their tutors. For tutors it will record academic specialisations, employment information and the names of students assigned to their tutor group.
So it is quite a simple problem.
I make it about 12 different nouns. Maybe 4 would be classes, including the Department, Student, Tutor and Course. These are the entities about which structured information has to be stored.
Many of the other nouns are just used to describe the problem. These include system, function, application and, probably, groups.
Other nouns such as title, details, names, personal information, academic specialisations, and employment information are relatively simple data best represented as variables and probably will be attributes of some of the classes.
The class diagram should have identified some potential classes. But to explore their relationships further we need to model the processes that take place and the methods required to implement them. One way to do this is to model some use cases using objects of our classes with tentative attributes and methods. In fact, since we are using objects rather than classes these are really use case scenarios.
To do this we will draw an interaction diagram for each use case. There are two equivalent types of interaction diagram – sequence diagrams and communication diagrams. We will start with the first.
So to do this, from the problem statement, what do you think the main use cases might be?
My suggestions –
Appoint a tutor
Enrol a student
Assign students to tutor groups
There is only one user actor – the course manager. Another might be the system representing existing departmental facilities but this is not actually specified in the statement so we should not invent anything. The students and the tutor will not be using the system.
A sequence diagram is a representation of the sequence of processes that will take place in our system. Each diagram depicts a particular use case scenario in which messages are sent from the user interface to a succession of objects. Sometimes the user interface is omitted. The sequence takes place from left to right across the diagram with each message displaced downwards to represent the passage of time. Normally there would be a subsequent set of return messages at the end of the diagram but these are not usually shown.
A message is usually a call to one of the receiver’s methods with one or more of its attributes as the argument. So a message to a department object, d9 for example, to appoint a tutor to a course might be d9.appointTutor(t1,c3) where d9, t1 and c3 are instance variables held by the sending object referring to the department, the tutor to be appointed and the course to which the appointment is to be made.
Here is a sequence diagram for the use case to appoint a tutor. Have a look at it and try to suggest a way of relating it to the class diagram.
The alternative approach to modelling processes is to use a communication diagram which is more directly related to the class diagram. Like the sequence diagram is shows a scenario rather than a use case so it is based on actual objects. But it does not show the sequence of events as the sequence diagram does from top to bottom.
We can draw an object diagram with the four objects shown in the sequence diagram. Then we can show the methods as transitions between the objects. We would use exactly the same attribute and method names.
The only problem would be modelling the sequence of these messages. We would have to introduce a numbering system to show the order in which the methods are executed.
There is one other type of UML diagram that is used to model the behaviour of a software system. It is sometimes called a statechart diagram or it may be described as a state machine diagram.
In either case, it simply describes the various states in which an object can exist and the transitions between these states. It is used to confirm that the previous diagrams are mutually consistent and nothing has been missed out. It is also a means of identifying the states in which class instance variables can exist and, therefore, the methods required to cause transitions to take place between these states.
For example, the Department class holds instances of the Tutor class. Can you suggest states in which these objects might exist?
A tutor may be employed by the department but not appointed to the course. We might call this state Available. Then he/she might become Appointed to the course and eventually Assigned to a group of students. There is another possible state where the tutor is not yet part of the department staff but in this case he/she would not normally need to be part of the system. So there are 3 states and 4 transitions between them -
appoint to the course
withdraw from the course
assign a student group
remove tutor group
And the state machine diagram looks like this -
So the appoint() method must check to see if the tutor, t1, is available. If so it uses setCourse() to check the tutor is not already assigned to the course and if not, it sets the state of the tutor to assigned and assigns the tutor to course, c3, with addTutor().
We have started to find a set of classes with which to build our software. We have also started to identify some of the methods and attributes that will be associated with these classes.
We may have to iterate the procedure a few times to get the best solution but eventually we should be able to get all the required classes and their attributes and methods.
Then we can go back to the detailed software specifications, design a user interface that accesses all the use cases and write the code.