Simon Lucas
Department of Computer Science
Essex University
These notes provide a very quick overview of a simple subset of the Unified Modelling Language (UML).
We include only the aspects of UML that are most relevant to modelling E-commerce applications.
Realisation
The Use-Case diagram is very simple.
We have a rectangle that represents the system under consideration.
Outside the system, we have the named actors who can interact with it.
Inside, in ellipses, we have the named modes of usage.
Lines link the actors to their intended modes of use.
The following example describes possible use cases for a FAQ (Frequently Asked Questions) list - perhaps for a customer product support system. Here we see that:
a casual user is only allowed to Search and Browse the FAQs (different modes of read only access to the system).
a registered user inherits these modes of operation from the Casual User (i.e. is also allowed to search and browse) and is also allowed to post new questions and post new answers to existing questions.
an editor is allowed to answer, edit and publish a FAQ.
we could alternatively have modelled the editor as an extension of a registered user - the separation is used to indicate a fundamentally different mode of behaviour. In some cases, for example, the editor might be assumed to have server-side privileges (and hence not be limited to web-based operations on the data).
It is worth stressing that the most important part of UseCases are not the diagrams, but the Use-Cases themselves. For example, the Use Case for the Search FAQs usage mode might read as follows:
"A user visits the main FAQ search page. He enters a search string (or regular expression) and hits <enter> or the <search> button. He is then presented with the total number of matches (e.g. 33), the 10 closest matching FAQs, and a link to the next best 10."
These diagrams indicate how the key agents in a task interact or collaborate. Each agent/actor is named at the top of a vertical dashed line, that shows (loosely speaking) how its thread of control unfolds in time in relation to the operations of other agents.
This sequence diagram has a dual view as a collaboration diagram, which highlights the interactions of the various agents rather than their behaviour through time. These are also called the flow of control by time and the flow of control by organisation.
Classes are shown in boxes, with the name at the top. Consider the following diagram:
This was derived (reverse engineered) from the following code for a simple 'Hello World' type of Servlet. Click <here> to test it.
package servlet.test;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/plain");
PrintWriter out = response.getWriter();
out.println("Hello World");
}
}
The diagram gives us very quick view of where an object or class fits in with the rest of the system.
Note that with the UML it is up to the modeller to choose which aspects of the system to show in a particular diagram. In the above case, we simply show that the HelloServlet is a subclass of HTTPServlet and that it depends on the definition of the PrintWriter class in some way. However, we omitted the superclass of HTTPServlet, and also omitted HTTPServletRequest and HTTPServletResponse. An object of the HTTPServletClass was explicitly used by the method, and should probably have been included on the diagram.
We've already seen some kinds of relationship. For clarity, we repeat examples of Dependency and Generalisation here in isolation.
The following link indicates that:
HelloServlet depends in some way on the definition of PrintWriter
but the converse is not true
(i.e. PrintWriter in no way depends on the definition of HelloServlet).
Relating this example to the above code, if the name of the println method of PrintWriter was changed, then HelloServlet code for HelloServlet which uses it would have to be changed accordingly.
Again, this shows that HelloServlet is a subclass of HttpServlet.
In UML terms, this is called generalisation. This can be confusing (at least for me!!!). Let me share this confusion with you, then try to clear it up.
The diagram indicates that HttpServlet is a generalisation of HelloServlet
Or alternatively, that HelloServlet is a specialisation of HttpServlet.
In Java terms, HelloServlet extends HttpServlet.
Subclasses can inherit methods from the superclass, and can also add their own.
Therefore, the set of subclass methods is a superset (not necessarily proper) of the set of superclass methods.
However, all subclass objects can be used in place of superclass objects, but the converse is not true.
The following diagram may help. Person is the more general classification of an individual, while Male and Female are more specialised categories. We could ask anyone of type Person to enter a building, but we should determine their gender before instructing them on the way to the restroom.
Draw a class hierarchy for the following geometric terms: Triangle, Circle, Shape, Polygon, Square.
The realisation relationship is used to indicate that a class implements an interface. This is drawn just like generalisation, except that a dashed line is used instead of a solid line. Suppose that we had the following Java code for an interface called HelloInterface, and a new version of our hello servlet:
package servlet.test; import java.io.PrintWriter;
public interface HelloInterface {
public void sayHello(PrintWriter out);
}
package servlet.test;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloServlet extends HttpServlet
implements HelloInterface
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/plain");
sayHello(response.getWriter());
}
public void sayHello(PrintWriter out) {
out.println("Hello World");
}
}
Please note that I'm not suggesting for a moment that this is a sensible piece of code! It is intended as a minimal extension of the previous example that introduces the realisation relationship, which leads on to the following diagram. Note that some UML drawings show interfaces as circles - the tool I used (MagicDraw) uses a rectangle but places a circle inside the rectangle to indicate that it is an interface.
Consider the following diagram - this is an approximate model of the relationships between a department, its lecturing staff, its students and the courses that it runs at a typical University. This was adapted (simplified and modified) from The Unified Modelling User Guide, Booch, Rumbaugh and Jacobson, page 112.
Plain lines indicate a peer-based association.
Diamond ends are used to indicate membership.
For example, the Takes association between student and course is seen as peer-based - a student takes a course, and a course is taken by students.
A department has a set of students and a set of lecturing staff. Think of the diamond as indicating this.
The numbers or asterisks are used to indicate the cardinality or multiplicity of the associations.
Building Web Applications with UML, Jim Conallen. Nice introduction to the area with some good example UML diagrams. Shame about the ASP stuff!
Java Server & Servlets: building portable web applications. Peter Rossbach and Hendrik Schrieber. This book is excellent: there are many examples that relate non-trivial server-side Java to UML Class and Sequence diagrams. Parts of the book are a bit advanced for this course, however.
Thanks go to Norbert Voelker for many helpful comments on this guide.
The diagrams were drawn with MagicDraw.