Nothing going on here, move along…

Posts tagged ‘UML’

Models and diagrams

RUP – Rational Unified Process


Analysis, design and implementation


Waterfall, semistructured, structured, RAD, BOEHMS spiral, incremental and iterative (this is a real model not a prototype.)

Phases for UML/RUP

Inceptions – Identity

Elaboration – Design

Construction – Build

Transaction – Roll out

Diagrams and their contents

Use case diagram – ID system boundry, fuctions and events, how the user sees the system,not behind the scenes

Activity diagram – Use case diagram details

Sequence diagram – Use case timing

Class diagram – Developed from the use case

State transition diagram – Models the behaviours of subsystems


These are users which affect the system eg. In a bank system there would be a ‘banker’ actor and a ‘customer’ actor.

In diagrams actorsare shown as stick figures

Primary elements are actors processes are use cases.

Titles are used but not names

Use cases

A use case diagram is a visual representation of a distinct business functionality

Each business fuction can be classified as a use case but some may be sub cases

A use case is represented by an oval

The system boundry is an oblong that surrounds the use cases but not the actors

Each use case has a limit defined by the boundry

Use cases share different kinds of relationships:

Association – communicates a relationship. Shown with a line __________

Include – Used to indicate a use case needs another use case to work. Shown with a broken line arrow and <<include>> sign on the line ———>. Goes from child to parent

Extend – The child case add to the functionality of the parent case the same as the include funtion, this functio is not always needed to complete a transaction, has <<extend>> sign instead of include

Genralizations – Inheritance of an object in UML, an enhancement of the parent case. Uses a closed arrowhead with an unbroken line     |>

Modelling types

Data flow diagrams (DFD)

O-O modelling

Uses UML (a case tool), attributes, methods, messages, classes and instances.

Each object needs a parent object

DFD has different levels as follows:

  • Context level diagram
  • Level 0 DFD
  • Level 1 DFD
  • Level 2 DFD

There should be no more than four levels, (the context level diagram counts as a level even though it doesn’t have a number)

Context level diagram contains:

  • The processes of a system
  • External entities
  • Data flow in and out of the system
  • The relationship between dataflows

Level 0 DFD contains:

  • Processes of the system
  • External entities
  • Data flows
  • Data stores
  • Sub processes

Level 1 DFD contains:

  • Subprocesses of the level 0 DFD

Level 2 ERD (Entity Relationship Diagram) contains:

  • Entities
  • Relationships
  • Cardinality – The closest option to the box
  • Optionality – May have this, option furtherest away from the box


0 – Zero

1 – One

<-   – Many (more like an E)


0 – Zero

1 – One

*ERD’s should have the cardinalities and optionalities written out for both directions

The context level provides each item/process, in level 0 these are numbered eg 1. 2. 3. etc

In level one each subprocess is numbered off of its original process eg. 1.1, 2.1, 3.2 etc

In level two these processes are broken down again eg 1.1.1, 2.1.3, 3.2.2


Unified modelling language used mostly for o-o

Contains a super class, a class and a subclass

Visual modelling is a UML

UML diagrams use:

  • A use case diagram
  • Activity diagrams
  • Sequence diagrams
  • Class diagrams
  • State transitional diagrams

Objects are held within the classes Eg.


| Object

| Object

| Object

| Object


The relationship is the information the objects need to know about each other, or how they relate.

Tag Cloud