UML Facilitation Workshop Overview

UML Facilitation Workshop in Design Research Seminar
Media laitos, Aalto University School of Art and Design.


This workshop was planned to take place within the Design Research Seminar programme Syys/Autumn 2010, led by Prof. Lily Diaz.

It aims to assist students in creating an abstract model of their interaction design projects/systems, focusing on the Use Case model.


General Questions:

What and who are the group involved with?

What types of representations are being used?

For whom is each representation they for?

What is not described?

What is the benefit of making a model that others understand?

Our consideration in workshop:

Your Modelling Language (YouML) or Unified Modelling Language (UML)?


Which types of systems / environments are you aware of?

For example: Environments (Habitats)

Built environment, constructed surroundings that provide the setting for human activity, ranging from the large-scale civic surroundings to the personal places.

Environment (systems), the surroundings of a physical system that may interact with the system by exchanging mass, energy, or other properties

Knowledge environment, may be defined as social practices, technological and physical arrangements intended to facilitate collaborative knowledge building, decision making, inference or discovery, depending on the epistemological premises and goals.

Natural environment, all living and non-living things that occur naturally on Earth

Social environment, the culture that an individual lives in, and the people and institutions with whom they interact

1. Natural-Biological (includes natural capital, transfer and exchange)
2. Social-Human (social/human capital, transfer and exchange)
3. Cultural-Political (cultural/institutional capital, transfer and exchange)
4. Infrastructural-Built (material?/infrastructural? capital, transfer and exchange)
5. Informational-Media (knowledge capital, transfer and exchange)
6. Financial-Economical (financial capital, transfer and exchange)
7. Emotional (emotional capital, transfer and exchange)


What is UML? & Why?

In 1997: “the Object Management Group (OMG) released the Unified Modeling Language (UML).

One of the purposes of UML was to provide the development community with a stable and common design language that could be used to develop and build computer applications.

It is made up of notation (symbols, connectors, labels, notes, values) and diagrams (pictorial representations of system or process).

UML brought forth a unified standard modeling notation that IT professionals had been wanting for years.. And can be a blueprint for the following aspects:

  • activities
  • actors
  • business processes
  • database schemas
  • (logical) components
  • programming language statements
  • reusable software components

Using UML, IT professionals could now read and disseminate system structure and design plans — just as construction workers have been doing for years with blueprints of buildings.”

“One reason UML has become a standard modeling language is that it is programming-language independent.”

“the UML notation set is a language and not a methodology.” .. It is a language for specifying..

To define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in.

By using standard UML diagrams, “you make it easier for UML-proficient people to join your project and quickly become productive”.. and “increase the ease of understanding an application under development.”

It is also used for the modeling of non-software systems, and is extensively implemented in most industry sectors including finance, military and engineering.


UML as a representation for Interaction Design?

Panos Markopoulos & Peter Marijnissen:

“This paper examines how UML can help specify various representations employed in interaction design, the limitations of UML notations for this domain and where it is beneficial to combine UML with HCI purpose-specific notations outside their intended scope, weighing them against the use of purpose-specific representations.”

“Broad categories of representation used for interaction design:

Scenarios for envisioning systems at early stages of the design process
Task and domain models for a more thorough and complete representations of user requirements.
Detailed interaction models, describing the 'look and feel' and the dynamic aspects of interaction down to the level or interactive objects”


“Scenarios and use cases illustrate differences in form and content between their numerous varients”

“Domain models are a common modelling concern for software developers and interaction designers alike: they can be modelled as UML class diagrams”
Panos Markopoulos & Peter Marijnissen note:

“There is some confusion concerning the relationship between scenarios as understood in the field of HCI (interaction scenarios for short) and use cases, as defined within UML. Very diverse representations serving different modelling purposes are described by their proponents as scenarios or use cases.

While the dominance of UML makes use cases somewhat a less ambiguous concept, scenarios are not part of a singular family of notations, and scenario based design is not a single coherent design method.”

“UML defines a use case as a classifier, which describes a set of sequences of actions that a system performs to yield an observable result of value to an actor.

In UML parlance a scenario is a single such sequence of actions, which instantiates a use case.

UML cases are used throughout software development and individual use cases are instrumental to support traceablilty between these models.

We note the following major differences between use cases and interaction scenarios:

[1] Use cases describe the behaviour of the system under design, not the user using it.

For some.. an interaction scenario, captures primarily user rather than system behaviour.

Eg. a scenario identifies the person, their motivations, describes the actions and the reasons that these actions were taken and characterises their results in terms of the users' motivations and expectations.

Even if system behaviour only is described, an interaction scenario describes functionality from the viewpoint of a single user – who maybe one of many actors related to a use case.

[2] Use cases are performed by actors who, apart from human users, can also be systems”

[3] Use cases specify system functionality.

At a semantic level they can serve as a specification of interactions, but they normally abstract away from user interface specifics.

An interaction scenario aims precisely to envision and specify user interface design ideas or decisions.”

“These points above are independent of the representational style; they concern the essence of use cases and interaction scenarios.

Both use cases and interaction scenarios can be represented in many forms: narrative structured text or they can be associated with storyboards, notations such as state machines, pre- and post- conditions associated with interactions etc.

We can think of use cases and interaction scenarios as different classes of design representations distinguished by content, viewpoint and intended use in design.”

Markopoulos, P., Marijnissen, P., (2000), UML as a representation for Interaction Design, In proceedings OZCHI2000


UML 2.*

The most useful, standard UML diagrams are: use case diagram, class diagram, sequence diagram, statechart diagram, activity diagram, component diagram, and deployment diagram.”


UML 2.0 diagrams

Structural diagrams

  • Class
  • Component
  • Composite structure
  • Deployment
  • Object
  • Package

Behavioural diagrams

  • Activity
  • State
  • Use-case

Interaction diagrams

  • Communication
  • Interaction overview
  • Sequence
  • Timing


Making a UML Model of your project

1.Object Orientation

Identify the classes (types) and objects (actualities) present

Object is something that exists in the context of a system
An Object is an instance of a Class
A Class is a category into which an object can be organised
A Class is a template from which objects can be created
Classes and Objects have attributes: properties such as size, colour
Classes and Objects have operations: functionality

Consider the relationships between objects

Inheritance of attributes from Class to subClasses

Identify the generalisations (in hierarchy)

Identify the associations (in information/data sharing)(in collaboration)(that acts upon other)

Identify the aggregations (relationship between whole & part)(a part in a composition relationship it cant be part of any other whole)

Consider Multiplicity shows the number of objects that can participate in a relationship

Consider Polymorphism (ability to take on more than one form) as it applies to objects and operations


4+1 Systems architecture model

Philippe Kruchten in 1995 developed the 4+1 model (


Break down whole into parts to understand how UML is modelling different diagrams

1: Logical View [UML Class, State, Object, Sequence, Communication diagrams]
functionality of the system, parts of system as abstractions, emphasising classes & objects

2: Process View [UML Activity diagrams]
dynamic aspects of the system, the processes, and how they communicate between.
good for simultaneous processes

3: Physical View [UML Deployment diagrams]
engineers perspective of the system, execution environment, software+hardware
ie whats needed

4: Development View [UML Component, Package diagrams]
modules & components, building-blocks, layers, how it will be implemented & managed

+1: Use Case View/ Scenarios: system & environmental [UML Use Case diagram]
sequences of interactions between objects & between processes from view of 'outside world', user goals & scenarios, functionality. Helpful to define other diagrams.


Static vs Dynamic models

Static: structural characteristics, emphasises parts, & class names, attributes, methods, packages
[UML Class, Object, Use Case diagrams]

subset of Static: Implementation: elements required for making system, organisation of physical software, resources, connection paths,
[UML Component, Deployment diagrams]

Static models are good for detailed information, 'back-bone of model'

Dynamic: behavioural characteristics, response to external events, identify objects needed and how they work together, interactions
[UML Sequence, Communication, State, Activity diagrams]

Dynamic models help define objects and how they interact

Agile development models advocate developing these models in parallel


Violet UML Modeller

"Whilst UML 2.0 specifies fourteen diagrams, in reality a number of these diagrams are more commonly used than others. Violet UML supports the production of use-case, class, sequence, state, activity and object diagrams."

Structural diagrams

  • Class
  • Component
  • Composite structure
  • Deployment
  • Object
  • Package

Behavioural diagrams

  • Activity
  • State
  • Use-case

Interaction diagrams

  • Communication
  • Interaction overview
  • Sequence
  • Timing


Exercise: Making a Use Case Diagram

Support videos:



References & Resources

OMG: UML Specifications

Matthew Karlsen: COMM005 - Information Systems Development - Violet UML Tutorial

rmb1905: Virtual Training Company: 1.01_Welcome to the UML [1-13 sections/92 clips in total]

Sparx Systems: UML Tutorials

IBM: UML Basics: An introduction to Unified Modelling Language

Wikipedia entries on UML

UML Jokes


UML Software

Violet UML (Win/Mac OSX/Linux: FLOSS)
[Whilst UML 2.0 specifies fourteen diagrams, in reality a number of these diagrams are more commonly used than others. Violet UML supports the production of use-case, class, sequence, state, activity and object diagrams]

Visual Paradigm for UML (Cross-platform: Java: Proprietary, Non-commercial version)

Michael W. Godfrey's My Little UML (Tools) Page

Wikipedia's entry on UML Tools

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License