KIT206 Tutorial 2 – Introduction to class diagrams
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
1/3
Tutorial 2: Your first class diagram
Purpose: To gain experience modelling the entities involved in an (informally-described) business case
and learn the basics of a particular computer-assisted software engineering (CASE) tool.
Outline
A system model is comprised of both static and dynamic elements. Class diagrams capture the static
structure of the system in different classes of objects, their attributes (i.e., data) and operations, and
their relationships to each other. Sequence diagrams (which we’ll start on in two weeks) capture the
dynamic behaviour by showing the order in which objects of difference classes call the methods
(operations) of other objects.
Entity classes are those that represent the data that a system will manage, and typically correspond
to the real-world objects that the system describes. This makes them a good place to start, because
it’s only as you gain experience that you’ll recognise the other classes of objects that are entirely
internal to the system you are designing. In today’s exercises you’ll do two things: create (possibly
your first) class diagram to represent the entities involved in an informally-described business case
and, importantly, gain experience using a particular computer-assisted software engineering (CASE)
tool to do that.
If you have time left over you can continue working on structured scenarios. You may prefer to work
on the Assignment Case Study rather than the Sample Case Study in preparation for creating a class
diagram for part of that system in next week’s tutorial.
0 Preparation
If you haven’t already, form a group of three for Assignment 1 (each member must come from your
tutorial class and enrol in the same group on MyLO). Although you won’t be working directly on the
assignment today you may find it useful to work on the tasks in your assignment groups.
1 Preparing to use StarUML for the first time
Before you begin, note that every modelling tool has both good and bad features, and that models
can become very complex very easily. The following suggested workflow should manage the
complexity and allow you to focus on the subset of StarUML’s features that you need to use in this
unit. You will need to practice with StarUML to learn how all the necessary features work. Outside of
tutorial time you may also want to view the videos on using StarUML 2 in Module 2 on MyLO.
Start StarUML and familiarise yourself with the four key regions of the window, highlighted in the
screen capture on the next page.
• Left: the Toolbox, which is a palette of diagram shapes and connections (the contents will
change depending on what kind of diagram you are working on)
• Centre: the diagram editing area
• Top-right: the Model Explorer, where you can create new models and the diagrams within
them, and move model elements between different packages
• Bottom-right: the properties editor, which you will use occasionally to change properties of
model elements that you cannot modify easily through the model editor
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
2/3
The Model Explorer presents your project as a tree, rooted at the project, beneath which you can have
any number of models, indicated by the icon. In today’s exercise, and in your assignment, you’ll
have a single model. Each model can contain any number of diagrams, including class diagrams (today
and next week), package diagrams (next week) and sequence diagrams (two weeks from now).
The new, untitled project already contains a single class diagram, titled Main. You can rename this, or
any other model element, by selecting it in the Model Explorer and entering a new name in Properties
list at the bottom right. Before moving on, save the untitled project as TSO.
2 Modelling the classes in an orchestra
You have been speaking with the Tasmanian Symphony Orchestra (TSO) and have collected a set of
rather unstructured notes (next page). Key words, which may indicate entities, their attributes or their
operations, have been italicised.
Task: Create a class diagram to represent the information in the notes. Consider the following as you
build your model:
• Each class name should be singular.
• Extract the obvious (named) classes first. Then add their attributes, taking your best guess as
to their data type. Are any operations, including attributes that must be calculated, indicated
by the notes? Attribute names can be briefer than they idea they express. If an attribute name
consists of multiple words, join them using CamelCase, asInThisExample.
• Consider how the classes are related to each other. Will objects of one class be related to one
or more objects of another? This may indicate an aggregation relationship.
• Consider if some classes are generalisations of other ones. If so, connect them via a
Generalization association, with the open arrow ending on the more general class.
o Consider if a more general type is implied, but not explicitly stated. Do some notionally
different classes actually share a lot of common attributes or operations?
https://en.wikipedia.org/wiki/CamelCase
KIT206 Software Design & Development KIT506 Software Application Design & Implementation
3/3
Your notes about the Tasmanian Symphony Orchestra (TSO):
• The TSO performs a number of concerts each year. Each concert has a date, start time, duration,
and may or may not have an intermission, and list of musicians. Each concert comprises a
number of works, each of which has a title, composer, publication date and length in minutes.
It should be possible to calculate the duration based on its works, the average gap in minutes
between each (for applause) and adding 20 minutes for any intermission.
• Works are labelled as being one of Medieval, Renaissance, Baroque, Classical or Soundtrack.
• The TSO employs a large number of musicians, and needs to maintain the following information
about each: their family and given names, their annual salary, the kind of instruments (1 or
more) they can play, and their star rating (an integer between 1 and 5). The TSO would also like
to know each musician’s value, which is their salary divided by their star rating.
• Each musician belongs to a different (single) section of the orchestra based on the kind of
instruments they play. The sections are string, brass, woodwind, and percussion.
o String players have a preferred string brand of string wax.
o Brass players have a maximum volume, expressed in decibels.
o Woodwind players may prefer to be playing jazz.
o Percussionists each have a maximum amount of force they are capable of imparting to a
large drum, which is expressed in Newtons, and whether or not they play the triangle.
• Some musicians are known as principal artists, meaning they are the most important player
among those playing the same instrument. It is sufficient to record whether or not a particular
musician is principal, since it really represents whether they can take on that role as needed.
2.1 Advice for modelling classes with StarUML
• Play with StarUML to discover how you can add, modify and move class attributes. Mostly
you’ll double click a class icon to edit its attributes and operations, but the Properties window
also gives you the ability to edit these once created.
• An attribute’s data type can be given by editing its entry within the diagram to match the form
‘name : data-type’, but also in the Properties window.
• Some entity attributes can hold one of a fixed number of alternative values. Rather than
modelling these attributes as strings (text), you can define a new data type, called an
enumeration, that specifies the set of possible values. Then in the relevant class you can assign
this enumeration data type to those attributes. You can find the Enumeration model element
in the Classes (Advanced) section of the Toolbox.
• When you identify an aggregation association between two classes (in which each object of
class A knows about/has a collection of many objects of class B) then select the Aggregation
association from the Toolbox and drag from class B towards class A.
• You can modify the properties of each association’s ends separately by double-clicking the
end you want to change. Consider multiplicities (how many objects on one side of the
relationship versus the other) and indicate it where known.
o If one side of the association will know about the other, but not the reverse (e.g., a
container knows the objects it contains, but those objects may not know the
container they’re in) then indicate this by changing the navigability of the association.
3 Optional, if time: create more structured scenarios
Add to the work you began last week on a structured scenario for the RAP Sample Case Study use case
8, User_views_ResearchersList, by creating draft structured scenarios for some of the other use cases.
Remember to sketch the UI for each of the views you imagine the user interacting with.
Outline
0 Preparation
1 Preparing to use StarUML for the first time
2 Modelling the classes in an orchestra
2.1 Advice for modelling classes with StarUML
3 Optional, if time: create more structured scenarios