Hello? It’s me! I was wondering if after all this time you’d like to have a good guide to UML? Yes, you want that, and that’s exactly what I’m presenting to you here. This guide will provide a one-stop resource for software modelling in the Academy of Computer Science and Software Engineering (ACSSE). All important diagrams that are used from first year through to third year are discussed and explained in detail.
I wrote it in a conversational style that deviates from the normal tone textbooks have about them. I hope that it makes this guide more fun to read and easier to understand. If not, at least I had fun writing it.
Everything in this guide has its origin from a recognised standard. Trust me, I didn’t make all of this up! Well, some of it… The origins of the documents comes from the Unified Modelling Language for the majority of the document and then Crow’s Foot for databases.
The Unified Modelling Language (or UML) is a modelling specification maintained by the Object Management Group (or OMG) for the field of software engineering. UML’s aim is to provide a standardised means of visualising the modelling and design of a software based system.
The newest version of the UML specification is available from the OMG UML Resources website at http://www.uml.org. Be forewarned, though, the most up to date specification, at the time of writing, is over 600 pages long.
For Entity Relation Diagrams (or ERD), this guide will make use of the Crow’s Foot notation. Crow’s Foot notation was developed by Gordon Everest. Originally Everest used the term “inverted arrow” for his notation. The name “crow’s foot” comes from the cardinality of a relationship that looks like a crow’s foot.
In this guide I will make reference to a case study to further elaborate a point. The case study will be based on a mark management system for a university department (cough EVE cough). This system will be named SPAMS (Student Performance, Assessment, and Marks Systems).
Since this chapter is already too long for my taste, I will not be elaborating on the SPAMS system right now. Instead, I will give a relevant piece of information in the relevant section. Everything to do with SPAMS will clearly be indicated.
As you continue through the guide, you will note that UML is very flexible and there can be multiple ways to describe the same scenario. This means that you can easily have discrepancies in your diagrams where you use different methods to describe the same type of event. This will lead to a document that is ambiguous and confusing for those who read it. In order to avoid this, make sure your entire development team decides on a standard or a specific way of drawing a certain thing. Not only will this lead to a neater and more consistent document, but all those who read it (that is, your marker, who gives you marks) won’t have any problems understanding your system.
I will make use of the following three boxes to draw your attention. If you don’t read anything else, read at least this!
Very important! Mostly relating to the ideas and concepts behind the diagram, do take note of these important announcements.
When drawing your diagram, take note that there are some pitfalls that you might step into. These tips will help you produce fantastic (and professional) diagrams and avoid mistakes that have happened in the past. Trust me, I know!
These boxouts will contain diagrams relating to the running case study of SPAMS.
Since the UML specification is over 600 pages long (and I cannot expect any student to read it just for funsies) and there are also too many tutorials online, each with a differing opinion on how a certain diagram should be drawn, that it has become difficult for my students to produce a software specification that made sense. As such, I have decided to compile a guide of general Software Modelling practises used by the Academy of Computer Science and Software Engineering (or ACSSE) at the University of Johannesburg.
Way back when, ACSSE used to prescribe a good textbook, Shaum’s Outline of UML, but this book has since gone out of print. I also cannot find any book that is comparable in terms of ease of use (even though this book was also quite thick). Many sections in this guide have been inspired by this book.
There are a variety of tools that you can use to draw your diagrams. Each of these has its own set of pros and cons. Here are some of the tools that are available for you to draw stunning, professional-looking diagrams. With each tool, I also give my impression.
Diagrams.net is an online diagram application and makes it easy to start drawing your diagrams. Diagrams.net runs on any device with a modern browser.
Blauw’s Impressions: At first it took me a while to get used to an online tool. However, once I got used to it, I really liked it. It has all the basic diagramming tools that are required for a good deliverable. In addition to saving documents in multiple formats, you can directly commit your diagram to GitHub as an “Editable Vector Image”. These diagrams can be inserted into your document and still be edited by the application.
Diagrams.net is available from https://app.diagrams.net/
UMLet is a free, open-source UML tool with a simple user interface. You can draw UML diagrams fast, build sequence and activity diagrams from plain text, export diagrams, share diagrams using Eclipse, and create new, custom UML elements. UMLet runs stand-alone or as an Eclipse plug-in on Windows, OS X and Linux.
Blauw’s Impressions: UMLet is an old favourite of ACSSE. Diagrams are easily assembled using a quick drag-and-drop interface. However, customisation of the graphics require a bit of pseudo-programming. Activity diagrams and Interaction sequence diagrams are also easily “programmed” and looks neat and tidy; although this does compromise customisability. Two issues, though: there are no inherent stencils for crow’s foot ERDs; and the export quality of the diagrams is often not very crisp.
UMLet is available from http://www.umlet.com/
Visual Paradigm Community Edition provides an easy-to-use and intuitive visual modelling environment with a rich set of export and import capabilities such as XMI, XML, PDF, JPG & much more! Visual Paradigm runs on Windows, Linux and Mac OS X.
Blauw’s Impressions: A free tool with loads of features. Once the template is set up, it is very easy to draw professional-looking diagrams. My biggest gripe is that all exported images have a very pesky and overly large watermark!
Visual Paradigm Community Edition is available from http://www.visual-paradigm.com/editions/community.jsp
Dia is roughly inspired by the commercial Windows program ‘Visio,’ though more geared towards informal diagrams for casual use. It currently has special objects to help draw entity relationship diagrams, UML diagrams, flowcharts, network diagrams, and many other diagrams. Dia runs on Windows, Linux and Mac OS X.
Blauw’s Impressions: Another favourite of the ACSSE. Although this tool is a bit outdated, it still produces solid diagrams.
Dia is available from http://dia-installer.de/
Visio makes diagramming simple. Whether you want to quickly capture a flowchart that you brainstormed on a whiteboard, map an IT network, build an organizational chart, document a business process, or draw a floor plan, Visio helps you work visually. Microsoft Visio runs exclusively on Microsoft Windows.
Blauw’s Impressions: I couldn’t get the newest version to install. It moaned something about its installer not being compatible with Microsoft Office’s installer. I didn’t try much harder…
Microsoft Visio is available from the ACSSE DreamSpark store. See EVE for more details.
The diagrams and models in this guide have evolved from years of use in the software engineering courses at the Academy of Computer Science and Software Engineering at the University of Johannesburg. Although these diagrams follow the standardised UML and ERD modelling techniques, they have been adapted to allow for ease of teaching to the students and ease of marking by project leaders.
Also, opinions expressed in this guide are purely those of the author!