1. Notice: Surgery Sessions (Weeks 6-10)
Modelling with UML
CS223 Lecture 4
(see BD Ch. 2)
Ananda Amatya
Notice: Surgery Sessions (Weeks 6-10)
Mon in C1.01 & Fri in C1.04
Please attend any one session convenient to you
Hello every body!
This is the 4th lecture on CS223, the Introduction to Software Engineering module.
My name is Ananda Amatya.
I’ll start by teaching you how to model software using UML.
The source for this lecture is Bruegge and Dutoit book Chapter 2.
Please note that there will be 4 hourly surgery sessions on my lectures on Mondays at 2 pm & 3 pm, and on Fridays at 9 am & 10 am, starting from Week 6.
Hopefully, you will be able to attend the one of these sessions.

2. Overview: modelling with UML
What is modelling?
What is UML?
Use case diagrams
Class diagrams
Sequence diagrams (Collaboration diagrams)
Activity diagrams
StateChart diagrams
We’ll start by answering the questions “What’s modelling?” and “What’s UML?”.
We’ll then introduce the basic UML diagrams,
Use case diagrams,
Class diagrams,
Sequence and Collaboration diagrams,
Activity and Statechart diagrams.

3. What is modelling? Modelling building an abstraction of reality.
Abstractions
simplifications:
ignore irrelevant details
focus on matters of concern.
What is relevant and what is irrelevant?
depends on the purpose of the model.
So, what’s modelling? What does it involve?
The simplest answer is: Modelling involves building an abstraction of reality.
This begs the question: what’s abstraction, and what’s reality?
These are philosophical questions, but we all have some vague ideas of what they are.
Basically, Abstractions are simplifications: ignore irrelevant details and keep only the relevant ones.
Abstractions capture the essence of what ever bit of reality we are talking about.
This then raises the question what’s relevant and what’s irrelevant?
This depends on the purpose of the model, that is, what was to be achieved by the modelling activity, in the first place.

4. Example: street map that models access roads
Let us consider an example of a simple model.
This is a street plan of Warwick University Central Campus.
It shows the essential details of the locations of buildings and streets.
Its purpose is to guide us from one building to another in the university.

5. Why model software? More sophisticated software means more complexity:
Windows XP > 40 million lines of code;
Several coders must be involved.
One developer’s code must be understood by another developer.
Complex systems must be simplified:
Modelling is a way of achieving this.
In software engineering we model software.
The question is: why do we model software?
The answer goes as follows:
Software is getting increasingly more complex, most programs are very big, for example, Windows XP > 40 million lines of code.
A single programmer cannot manage this amount of code in its entirety.
Also Code is not easily understood by developers who did not write it
We need simpler ways of representing complex systems.
Modelling is a way of dealing with this complexity.
Models abstract from complex codes to simpler, more easily understood concepts.

6. Systems, Models and Views
System: an organised set of communicating parts.
Model: an abstraction describing a subset of a system.
View: a selected aspect of a model.
Notation: a set of graphical or textual rules for depicting views.
Views and models of a single system may overlap each other.
Examples:
System: Aircraft
Models: Flight simulator, scale model
Views: All blueprints, electrical wiring, fuel system
Let’s put models in the context of systems they represent, and look at depicting the different aspects of models as views.
What is a system? An organised set of communicating parts
How is a model related to a system? An abstraction describing a subset of a system
How are the different aspects of a model depicted? By selecting appropriate views
How are the models expressed? Using notation, a set of graphical or textual rules
Are the different views of the models of a system distinct? Not necessarily, they could overlap.
This is true also of models, they could overlap.
Examples: Aircraft
An aircraft is a system
Flight simulator and scale model are models of the aircraft system
Blueprints, electrical wiring and fuel system are views of such models

7. Systems, Models and Views
Blueprints
Aircraft
Flightsimulator
Fuel System
Scale Model
Electrical wiring and Fuel system views overlap as Fuel systems use electricity.
Blue print for cockpit overlaps with both Electric wiring and Fuel system views.
Scale and Flight simulator models both include wings though they represent their different aspects (e.g., expanse and aerodynamics).
Electrical
Wiring

8. Models, Views and Systems (UML)* *
System
Model
View
Described by
Depicted by
Airplane: System
Scale Model: Model
Flight Simulator: Model
A system is described by 1 or more models, each model being depicted by 1 or more views.
A particular aeroplane system has a scale and a flight simulator models.
A scale model has a blueprints view, and a flight simulator model has a fuel system and an electrical wiring views
These are UML diagrams to show system, models and views.
Blueprints: View
Fuel System: View
Electrical Wiring: View

9. Concepts and Phenomena
Phenomenon:
An object in the world of a domain as you perceive it.
Examples: this lecture, that wall clock
Concept:
An abstraction that describes phenomena with common properties.
Examples: Lecture, Wall clock
Concept is a 3-tuple:
Name (to distinguish one concept from another)
Purpose (to determine if a phenomenon belongs to a concept)
Members (the set of phenomena that belong to the concept - instances)
In the real world we distinguish between phenomena and concepts.
A phenomenon is something we perceive, e.g., this lecture, the clock on the wall, the screen you are watching.
These are real world objects that we experience.
A concept is the grouping of all phenomena with the same properties, e.g., lecture, clock, screen
Concepts capture the essence, i.e., the properties of being a lecture (lecture-ness), a clock (clock-ness), and a screen (screen-ness).
A particular phenomenon is a manifestation of the corresponding concept.
A concept has name, properties (purpose) and members (a set of phenomena that are its possible manifestations).

10. Concepts and Phenomena (contd.)
Members
Name
Clock
Purpose
A device that
measures time.
Abstraction
Classification of phenomena into concepts
Modelling
Development of abstractions to answer specific questions about a set of phenomena while ignoring irrelevant details.
The concept Clock has name: clock, purpose: measuring time, members: Wall Clock, Alarm Clock, Sand Glass
Abstraction is the conceptualisation of phenomena into concepts.
Modelling is the development of such abstractions about sets of phenomena ignoring irrelevant issues, in order to answer specific questions.

11. Concepts in software: Type and Instance
An abstraction in the context of programming languages
Name: int,
Purpose: integral number,
Members: 0, -1, 1, 2, -2, . . .
Instance:
Member of a specific type
The type of a variable represents all of its possible instances
The following relationships (<–>) are similar:
“type” <–> “instance”
“concept” <–> “phenomenon”
Let’s now relate concepts and phenomena to software.
Concepts in software are the types of programming languages.
For example, int type is an abstraction of integer numbers; name: int, purpose: integer numbers, members: 0, -1, 1, …
Instances are particular members of a specific type.
The type of a variable represents all the possible values the variable can take.
At any instance the variable will have one of these values.
Type is to concept as instance is to phenomenon.

12. Abstract Data Types & Classes
Special type whose implementation is hidden from the rest of the system.
Class:
An abstraction in the context of object-oriented languages
Like an abstract data type, a class encapsulates both state (variables) and behaviour (methods)
Example Class: Watch
Unlike abstract data types, classes can be defined in terms of other classes using inheritance
Abstract data types are special types whose implementations are hidden from the rest of the system in which they are used.
Classes are abstractions in the context of Object-oriented programming languages.
Like an Abstract data type, a class encapsulates both its state (variables, attributes) and its behaviour (methods, operations)
Example class: Watch
Unlike an abstract data type, classes can be defined in terms of other classes using inheritance,
Example: Calculator Watch as a subclass of Watch class.

13. Application and Solution Domain
Application Domain (Requirements Analysis):
The environment in which the system is operating
Solution Domain (System Design, Object Design):
The available technologies to build the system
In Object-oriented software development it is important to distinguish between application domain objects and solution domain objects
Application domain objects are real world objects relevant for the application that appear in the analysis of the problem
Solution domain objects are objects that are used in the development (design) of a software solution for the problem

14. Object-oriented modelling
Application Domain
Solution Domain
UML Package
TrafficControl
SummaryDisplay
MapDisplay
TrafficController
Aircraft
FlightPlanDatabase
In developing an aircraft TrafficControl system, the application domain objects are Aircraft, FlightPlan, TrafficController, Airport
The solution domain objects for the TrafficControl system are: SummaryDisplay, MapDisplay, FlightPlanDatabase, and the solutions domain versions of the application domain objects Aircraft, FlightPlan, TrafficController, Airport.
Airport
TrafficControl
FlightPlan
System Model
Application Domain Model

15. What is UML? UML (Unified modelling Language)
A standard for modelling object-oriented software.
Resulted from the convergence of notations from:
OMT (James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)
Reference: OMG (Object Management Group)
Supported by several CASE tools
Rational ROSE (IBM)
Poseidon (ArgoUML)
TogetherJ (Borland)
Rhapsody (ILogix)
Eclipse (IBM) …
Now that we know what models are in the context of Object-oriented software development, let’s introduce UML.
UML stands for Unified Modelling Language
UML is an emerging standard for modelling object-oriented software.
UML resulted from the convergence of notations from three leading object-oriented methods: OMT (James Rumbaugh), OOSE (Ivar Jacobson), and Booch (Grady Booch)
The main reference for UML is: “The Unified modelling Language User Guide”, Addison Wesley, 1999.
UML is supported by several CASE tools: Rational ROSE, Borland TogetherJ, ILogix Rhapsody, ArgoUML, Umbrello, …
I’ll talk a bit more about these next week, as part of the Project Lecture.

16. UML: First Pass
You can model 80% of most problems by using about 20% UML
We teach you those 20%
UML is a BIG modelling language.
You can model 80% of most problems by using about 20% UML
So we’ll concentrate on those 20%

17. UML First Pass Use case Diagrams
describe a system’s functional behaviour as seen by its user.
Class diagrams
describe a system’s static structure: Classes, Associations
Sequence diagrams
describe a system’s dynamic behaviour: actors, objects, messages
Statechart diagrams
describe the dynamic behaviour of individual objects of the system: states, events, transitions
Activity Diagrams
model a system’s dynamic behaviour: activities, workflows (flowcharts)
Let’s first look at the basic parts of UML.
Use case Diagrams describe the functional behaviour of the system as seen by the user.
Class diagrams describe the static structure of the system: Objects, Attributes, Associations
Sequence diagrams describe the dynamic behaviour between actors and the system and between objects of the system
Statechart diagrams describe the dynamic behaviour of an individual object (a finite state automaton)
Activity Diagrams model the dynamic behaviour of a system, in particular its workflows (a flowchart)

18. UML first pass: Use case diagrams
Package
Watch
Actor
ReadTime
WatchUser
WatchRepairPerson
SetTime
ChangeBattery
A Use case diagram visualises the functionality of a system from its users’ points of view:
It uses actors, use cases, system boundary and communicating association between actors and use cases.
A use case diagram does not mean much unless it is supported by its specification documents, especially, the event flow sequences for the use cases involved.
Use case diagrams represent the system’s functionality
from user’s point of view

19. UML first pass: Class diagrams
Association
Class
Multiplicity
Watch 1
blinkIdx
blinkSeconds()
blinkMinutes()
blinkHours()
stopBlinking()
referesh()
LCDDisplay 1
Battery
load 1 2 1
Time
now 2
PushButton
state
push() release()
A Class diagram for a system visualises the system’s structure showing its classes (with attributes and operations) and the associations between them (with multiplicities at the association ends).
Attribute
Operations
Class diagrams represent the structure of the system

20. UML first pass: Sequence diagram
Actor
Object
:WatchUser
:Watch
:LCDDisplay
:Time
pressButton1()
blinkHours()
pressButton1()
blinkMinutes()
Message
pressButton2()
incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
A Sequence diagram visualises the interactions between objects (class instances) for a particular functionality of an actor as messages are passed between the objects as time flows.
Activations show the durations in which messages are completed , and lifelines show whether the objects are there to receive and send such messages.
Activation
Lifeline
Sequence diagrams represent the behaviour as interactions

21. Statecharts represent behaviour as states and transitions
UML first pass: Statechart (diagrams) for objects with interesting dynamic behaviour
State
Event
Initial state
[button2Pressed]
[button1&2Pressed]
BlinkHours
IncrementHrs
Transition
[button1Pressed]
[button2Pressed]
[button1&2Pressed]
BlinkMinutes
IncrementMin.
[button1Pressed]
[button1&2Pressed]
[button2Pressed]
A Statechart shows the transition of an object from one state to another as it receives a message due to an event occurring.
An object enters its state chart at the initial state when it starts the interaction, and exits at its final state when it leaves the interaction.
BlinkSeconds
IncrementSec.
Final state
StopBlinking
Statecharts represent behaviour as states and transitions

22. Other UML Notations UML provide other notations
Implementation diagrams
Component diagrams (BD Chapter 7)
Deployment diagrams (BD Chapter 7)
UML includes OCL (Object constraint language)
Used in Design (BD Chapter 9)
And then … there is UML 2 (a major revision of UML)
For a good introduction see
IBM Webcast Recorded Event Feb15 Intro.itm in
Other UML notation relevant later in this course are implementation diagrams (Component and Deployment diagrams) and OCL (Object Constraint Language).
UML2 is a major revision of UML

23. UML Core Conventions Rectangles are classes or instances
Ovals are functions or use cases
Instances are denoted with underlined names
Examples: myWatch:SimpleWatch, Joe:Firefighter
Types are denoted with non-underlined names
Examples: SimpleWatch, Firefighter
Diagrams are graphs
Nodes are entities
Arcs are relationships between entities
Some UML conventions:
Classes and objects are shown by rectangles
Use cases by ellipses
States by Rounded boxes
Activities by Capsules (Rounded boxes in UML2)
Instances have underlined names
Class names start with Capital letter
Diagram nodes are entities (classes, objects, states, …)
Arcs joining the nodes are relationships (associations)

24. Use Case Diagrams
Used during requirements elicitation to capture a system’s external behaviour
An Actor represents a user’s role, that is, the type of a user of the system
A Use case represents a sequence of interactions for a type of functionality
A use case model is the set of all the use cases for a system and its environment, i.e., a complete description of all the functionalities of the system and its environment
Passenger
PurchaseTicket
Use case diagrams represent functional requirements
An Actor represents a role of the users of the system
A Use case represents a sequence of interactions for a functionality of the system
A use case model describes all the functionality of the system and its environment in terms of use cases

25. Actors
An actor models an external entity which communicates with the system:
User
External system
Physical environment
An actor has a unique name and an optional description.
Examples:
Passenger: A person using a train
GPS satellite: A Provider of GPS coordinates to the system
Passenger
An actor models an external entity which communicates with the system, e.g., User, External system, Physical environment
An actor has a unique name and an optional description.
Examples: Passenger: A person using the train, GPS satellite: Provides the system with GPS coordinates

26. Use Case
A use case represents a class of functionality provided by the system as an event flow.
A use case consists of:
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
PurchaseTicket
A use case represents a class of functionality provided by the system.
A use case description consists of: Unique name, Participating actors, Entry conditions, Flow of events, Exit conditions, Special requirements
Special requirements are not related to functionality, they are to do with constraints: system performance (response time), implementation restrictions, hardware platforms

27. Use Case Diagram: Example
Name: Purchase ticket
Participating actor: Passenger
Entry condition:
Passenger standing in front of ticket distributor.
Passenger has sufficient money to purchase ticket.
Exit condition:
Passenger has ticket.
Event flow:
1. Passenger selects the number of zones to be travelled.
2. Distributor displays the amount due.
3. Passenger inserts money, of at least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
Example: Purchase Train Ticket Use Case
Name: Purchase ticket
Participating actor: Passenger
Entry condition:
Passenger has sufficient money, and is ready to buy a ticket from ticket distributor.
Exit condition:
Passenger has ticket.
Event flow:
1. Passenger selects the zone number to be travelled.
2. Distributor displays the amount due.
3. Passenger inserts money, of at least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
Alternative paths and exceptional cases, if simple, should be given in the same use case flow of events.
Alternatively, they should be given as separate (extension) use cases when they are complicated.
Anything missing?
Exceptional cases!

28. The <<extends>> Relationship
<<extend>> relationships represent exceptional or seldom invoked cases.
The exceptional event flows are separated from the main event flow for clarity.
A use case representing exceptional event flows may extend one or more use cases.
The direction of a <<extend>> relationship is to the extended use case
Passenger
PurchaseTicket
OutOfOrder
<<extend>>
Cancel
<<extend>>
TimeOut
<<extend>>
NoChange
<<extend>>
Extend Relationship is used to handle alternative cases.
<<extend>> relationships represent exceptional or seldom invoked cases.
The exceptional event flows are factored out of the main event flow, and form the extending use case.
A Use case representing some exceptional event flow can extend more than one use case.
The direction of an <<extend>> relationship is to the extended use case

29. The <<includes>> Relationship
<<include>> relationship represents behaviour that is factored out of the use case.
<<include>> behaviour is factored out for reuse, not because it is an exception.
The direction of a <<include>> relationship is to the using use case (unlike <<extend>> relationships).
Passenger
PurchaseMultiCard
PurchaseSingleTicket
<<include>>
CollectMoney
<<include>>
<<include>> relationship is used to factor out common steps in the event flows of several use cases. Removes redundancy in updates.
<<include>> relationship represents behaviour that is factored out of the use case.
<<include>> behaviour is factored out for reuse, not because it is an exception or an option.
The direction of a <<include>> relationship is to the using use case (contrast <<extend>>).
A use case that requires an <<include>> use case is incomplete without the included use case
<<extend>> use case adds optional/alternative behaviour while <<include>> use case completes a use case by including required behaviour
NoChange
<<extend>>
Cancel
<<extend>>

30. Use Case Diagrams: Summary
Use case diagrams represent external behavior
Use case diagrams are useful as an index into the use cases
Use case descriptions (flow of events) provide meat of model, not the use case diagrams.
All use cases need to be described (flow of events) for the model to be useful.
Summary of Use case diagrams:
A use case diagram models a system’s external behavior (system’s behaviour to its actors).
The diagram acts as an index (reference/pointer) to the use case invoked by its actors.
The use case descriptions (specifications) form the essence of the model, use case diagrams themselves being just the pointers to these descriptions.
For a use case model to be useful all its use cases need to be described.

31. Class Diagrams
TarifSchedule
Trip
zone:Zone
Price: Price
Enumeration getZones()
Price getPrice(Zone) * *
Class diagrams represent the structure of the system.
Used
during requirements analysis to model problem domain concepts
during system design to model subsystems and interfaces
during object design to model classes.
A Class diagram represents the structure of a system.
It is used during
requirements analysis to model problem domain concepts
system design to model subsystems and interfaces
object design to model classes.

32. Classes Name Signature Attributes Operations
Table zone2price
Enumeration getZones()
Price getPrice(Zone)
TarifSchedule
Name
zone2price
getZones()
getPrice()
TarifSchedule
Attributes
Signature
Operations
TarifSchedule
A class represent a concept
A class encapsulates state (attributes) and behaviour (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
A class represents a concept
It encapsulates state (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information

33. tarif_2004:TarifSchedule
Instances
tarif_2004:TarifSchedule
zone2price = {
{‘1’, .20}, {‘2’, .40},
{‘3’, .60}}
An instance represents a phenomenon.
Instance name is underlined and can show its class.
The attributes are shown with their values.
No operation is shown as it is the same as for its class.
An instance represents a phenomenon.
The name of an instance is underlined and can show its class.
The attributes are shown with their values.
No operation is shown as it is the same for all instances and is the same as for its class.

34. Actor vs Instances Difference between actor, class and instance:
external to the system
interacts with the system
E.g., “Passenger”
Class:
models an entity in the problem domain
modelled inside the system
E.g., “TariffSchedule”
Instance:
A specific instance of a class
E.g., “tarif_2004, the specific TariffSchedule being used by the passenger for purchasing a ticket from the ticket distributor”
What is the difference between an actor , a class and an instance?
Actor: an entity outside the system being modelled, it interacts with the system (“Passenger”)
Class: an abstraction modelling an entity in the problem domain, must be inside the system (“TariffSchedule”)
Instance: a specific object of a class (“tarif_2004, the specific TariffSchedule being used by the passenger for purchasing a ticket from the ticket distributor”).

35. Associations * * Associations denote relationships between classes.
TarifSchedule
TripLeg
Enumeration getZones()
Price getPrice(Zone)
Price Zone * *
Associations denote relationships between classes.
The multiplicity at an association end denotes how many objects the source object can legitimately reference.
Associations denote relationships between classes.
The multiplicity at an association end denotes how many objects of the class at that end can be legitimately referenced by the source object at the other end of the association.

36. 1-to-1 and 1-to-many Associations
Has-capital
CapitalCity
Country
name:String
name:String
One-to-one association
Point
Has-vertex *
Polygon
x: Integer
Default multiplicity 1
* Means many (0 or more, n)
1-1
1-many
y: Integer
draw()
One-to-many association

37. Many-to-Many Associations
Lists
Company * *
StockExchange
tickerSymbol *
Lists 1
Company
StockExchange
Many-many, Many-1
A stock exchange lists many companies each with its own unique ticker symbol (attribute).
A company can be listed on more than one stock exchange, using the same ticker symbol.
Example: Mercedes Benz is a company listed on more than one stock exchange, Frankfurt and NYSE.
Does it have two different Ticker symbols? Or is the same Ticker symbol used at Frankfurt and NYSE?
Something not clear here: What happens if the company cannot have the same ticker symbol on two different stock exchanges?
Clearly in that case the company must carry the stock exchange specific ticker symbol lists, or each stock exchange must have ticker symbol conversion tables for that company.
By having qualifiers at both ends of the association the many-to-many association is converted into 1-to-1 qualified association, i.e., each StockExchange uses a ticker symbol to associate uniquely with a unique StockExchange ID of a company.
tickerSymbol

38. From Problem Statement To Object Model
A stock exchange lists many companies. Each
company is uniquely identified by a ticker symbol
Class Diagram: * *
Company
StockExchange
Problem statement
Class Diagram: classes, attributes, multiplicities
Lists
tickerSymbol

39. From Problem Statement to Code
A stock exchange lists many companies.
Each company is identified by a ticker symbol
Class Diagram: * *
StockExchange
Company
Lists
tickerSymbol
Java Code:
public class StockExchange {
private Vector m_Company = new Vector(); };
public class Company
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
Use Vector in java for multiplicity, many

40. Aggregation
An aggregation is a special case of association denoting a “consists of” hierarchy.
The aggregate is the parent class, the components are the children class.
A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate.
Exhaust system
Muffler
diameter
Tailpipe 1
0..2
Exhaust system 1
0..2
Muffler
Tailpipe
diameter
diameter
Composition has life-time dependency, i.e., ZoneButton will not exist without a TicketMachine.
On the other hand Muffler and Tailpipe components will exist without an Exhaust system.
TicketMachine 3
ZoneButton

41. Without qualification
Qualifiers
Directory
File
filename
Without qualification 1 *
With qualification
Directory
File
0…1 1
filename
Qualifiers can be used to reduce the multiplicity of an association.
Directory uses filename to make the association 1:1
A Directory is associated with many files.
A Directory uses a filename to associate uniquely with a File.

42. Inheritance
Button
ZoneButton
CancelButton
The children classes inherit the attributes and operations of the parent class.
Inheritance simplifies the model by eliminating redundancy.
Inheritance eliminates redundancy.
Children classes inherit attributes and operations of the parent class.

43. Object modelling in Practice: Class Identification
Foo
Quantity
CustomerId
Deposit()
Withdraw()
GetBalance()
Class Identification: Name of Class, Attributes and Methods
Names should be chosen carefully.

44. Object modelling in Practice: Encourage Brainstorming
Foo
Quantity
CustomerId
Deposit()
Withdraw()
GetBalance()
Account
Quantity
CustomerId
Account with attributes accountId and amount is better than Foo with CustomerID and Quantity, or even, Account with attributes CustomerID and Quantity.
Deposit()
Naming is important!
Is Foo the right name?
Withdraw()
GetBalance()

45. Object modelling in Practice contd.
Account
Quantity
Deposit()
Withdraw()
GetBalance()
Customer
Name
Bank
Name
CustomerId
AccountId
CustomerId
1) Find New Objects
Iterate to find new objects, and appropriate names, attributes and operations
2) Iterate on Names, Attributes and Methods

46. Object modelling in Practice: A Banking System
Account
Quantity
Deposit()
Withdraw()
GetBalance()
Customer
Name
CustomerId
Bank *
Has
CustomerId
AccountId
1) Find New Objects
2) Iterate on Names, Attributes and Methods
Find associations, roles and multiplicities
3) Find Associations between Objects
4) Label the associations
5) Determine the multiplicity of the associations

47. Practice Object modelling: Iterate, Categorize!
Account
Amount
Deposit()
Withdraw()
GetBalance()
Bank
Name
Customer
Name
CustomerId * *
Has
AccountId
CustomerId()
Savings
Account
Withdraw()
Checking
Account
Withdraw()
Mortgage
Account
Withdraw()
CustomerID() should be a method which will access the private attribute CustomerID
Use Inheritance to abstract away common attributes and methods.
The parent class method Withdraw() in Account is overridden by appropriate operations in the child classes SavingsAccount, ChequeAccount and MortgageAccount.

48. Packages
A package is a UML mechanism for organizing elements into groups (usually not an application domain concept)
Packages are the basic grouping constructs with which you may organise UML models to increase their readability.
A complex system can be decomposed into subsystems, where each subsystem is modelled as a package
DispatcherInterface
Notification
IncidentManagement
Packages are used to group system elements into subsystems.
Packages are solution domain concepts.
Packages simplify the solution
Dependency between subsystems is given by the package interfaces.

49. Class Diagrams: Summary
Class diagrams: system structure
Class: name, attributes (types), operations (signatures)
Instances: underlined names, attribute values
Associations between classes, multiplicities
Qualified Associations: from many:many to 1:1
Aggregation, composition
Inheritance
Iterate udring class identification, naming, attributes and methods, associations
Packages
Summary of Class diagrams:

50. UML sequence diagrams Used during requirements analysis
selectZone()
pickupChange()
pickUpTicket()
insertCoins()
Passenger
TicketMachine
Used during requirements analysis
To refine use case descriptions
to find additional objects (“participating objects”)
Used during system design
to refine subsystem interfaces
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines
Dynamic modelling of system behaviour at analysis stage.
Used during analysis: To refine use case descriptions, to find additional objects (“participating objects”)
Used during system design: to refine subsystem interfaces
Classes are represented by column headers
Messages are represented by labelled arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines

51. Nested messages Dataflow
Passenger
TarifSchedule
Display
ZoneButton
selectZone()
lookupPrice(selection)
price
Dataflow
displayPrice(price)
…to be continued...
The source of an arrow indicates the activation which sent the message
An activation is as long as all nested activations
Horizontal dashed arrows indicate data flow
Vertical dashed lines indicate lifelines
Data flows between interacting objects shown by dashed lines.
The source of an arrow indicates the activation which sent the message
An activation is as long as all nested activations
Horizontal dashed arrows indicate data flow
Vertical dashed lines indicate lifelines

52. …continued from previous slide...
Iteration & condition
Passenger
…continued from previous slide...
CoinIdentifier
Display
CoinDrop
ChangeProcessor *
insertChange(coin)
lookupCoin(coin)
price
Iteration
displayPrice(owedAmount)
Condition
[owedAmount<0] returnChange(-owedAmount)
…to be continued...
Iteration is denoted by a * preceding the message name
Condition is denoted by boolean expression in [ ] before the message name
Iteration is denoted by a * preceding the message name
Condition is denoted by boolean expression in [ ] before the message name

53. Creation and destruction
Passenger
…continued from previous slide...
ChangeProcessor
Creation
Ticket
createTicket(selection)
print()
Destruction
free()
Creation is denoted by a message arrow pointing to the object.
Destruction is denoted by an X mark at the end of the destruction activation.
In garbage collection environments, destruction can be used to denote the end of the useful life of an object.
Creation is denoted by a message arrow pointing to the object.
Destruction is denoted by an X mark at the end of the destruction activation.
In garbage collection environments, destruction can be used to denote the end of the useful life of an object.

54. Sequence Diagram Summary
UML sequence diagram represent behaviour in terms of interactions.
Useful to find missing objects.
Time consuming to build but worth the investment.
Complements the class diagrams (which represent structure).
Sequence Diagram Summary:
UML sequence diagram represent behaviour in terms of interactions.
Useful to find missing objects.
Time consuming to build but worth the investment.
Complements the class diagrams (which represent structure).

55. Represent behaviour as states and transitions
State Chart Diagrams
State
Event
Initial state
[button2Pressed]
[button1&2Pressed]
BlinkHours
IncrementHrs
Transition
[button1Pressed]
[button2Pressed]
[button1&2Pressed]
BlinkMinutes
IncrementMin.
[button1Pressed]
[button1&2Pressed]
[button2Pressed]
Statecharts represent an object behaviour as states and transitions under events.
BlinkSeconds
IncrementSec.
Final state
StopBlinking
Represent behaviour as states and transitions

56. Activity Diagrams
An activity diagram shows flow control within a system
An activity diagram is a special case of a state chart diagram in which states are activities (“functions”)
Two types of states:
Action state:
Cannot be decomposed any further
Happens “instantaneously” with respect to the level of abstraction used in the model
Activity state:
Can be decomposed further
The activity is modelled by another activity diagram
Note: UML 2 uses rounded rectangles for action and activity nodes.
Activity diagram shows flow control within a system.
The nodes are activity states or action states.
Action states happen instantaneously.
Activities may take time and may be modelled by another nested activity diagram.

57. Statechart Diagram vs. Activity Diagram
Statechart Diagram for Incident (similar to Mealy Automaton)
(State: Attribute or Collection of Attributes of object of type Incident)
Event causes
State transition
Active
Closed
Inactive
Archived
Incident-
Documented
Incident-
Handled
Incident-
Archived
Activity Diagram for Incident (similar to Moore)
(State: Operation or Collection of Operations)
State transitions need triggers which are the events that trigger the transitions.
Activity transitions do not require trigger. Completion of one activity starts another activity.
Triggerless
Transition
Completion of activity
causes state transition

58. Activity Diagram: modelling Decisions
Activity transitions may be controlled by guard conditions, which decide on which of the several possible paths the transition may take.

59. Activity Diagrams: modelling Concurrency
Synchronisation of multiple activities
Splitting the flow of control into multiple threads
Splitting
Synchronisation
Concurrency is handled by fork and join; following fork concurrent activities take place in different threads. Wait for the completion of all the activities in the concurrent threads and then join, and then follow as a single thread of activity.
Now Read BD Chapter 2