University of Toronto

Department of Computer Science

Lectures 2 & 3: Introduction to Modeling & UML

Why Build Models? What types of Models to build Intro to UML Class Diagrams Relationship between UML and program code Uses of UML

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Getting started

Youve just joined an ongoing project

Where do you start? (oh, BTW, the project doesnt really have any documentation)

Reverse Engineering:
Recover design information from the code Create higher level views to improve understanding

E.g. Structure of the code

Code Dependencies Components and couplings

E.g. Behaviour of the code

Execution traces State machines models of complex objects

E.g. Function of the code

What functions does it provide to the user?
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Sometimes you dont need a map

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Why build models?

Modelling can guide your exploration:

It can help you gure out what questions to ask It can help to reveal key design decisions It can help you to uncover problems
e.g. conicting or infeasible requirements, confusion over terminology, scope, etc

Modelling can help us check our understanding

Reason about the model to understand its consequences
Does it have the properties we expect?

Animate the model to help us visualize/validate the requirements

Modelling can help us communicate

Provides useful abstracts that focus on the point you want to make without overwhelming people with detail

Throw-away modelling?
The exercise of modelling is more important than the model itself Time spent perfecting the models might be time wasted
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Maps as Abstractions

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Dealing with problem complexity

Abstraction
Ignore detail to see the big picture Treat objects as the same by ignoring certain differences (beware: every abstraction involves choice over what is important)

Decomposition
Partition a problem into independent pieces, to study separately (beware: the parts are rarely independent really)

Projection
Separate different concerns (views) and describe them separately Different from decomposition as it does not partition the problem space (beware: different views will be inconsistent most of the time)

Modularization
Choose structures that are stable over time, to localize change (beware: any structure will make some changes easier and others harder)
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

the Unied Modelling Language (UML)

Third generation OO method

Booch, Rumbaugh & Jacobson are principal authors
Still evolving (currently version 2.0) Attempt to standardize the proliferation of OO variants

Is purely a notation
No modelling method associated with it! Was intended as a design notation

Has become an industry standard

But is primarily promoted by IBM/Rational (who sell lots of UML tools, services)

Has a standardized meta-model

Use case diagrams Class diagrams Message sequence charts Activity diagrams State Diagrams Module Diagrams Platform diagrams
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Modeling Notations
UML Class Diagrams
information structure relationships between data items modular structure for the system

Use Cases
users view Lists functions visual overview of the main requirements

UML Package Diagrams

Overall architecture Dependencies between components

(UML) Statecharts
responses to events dynamic behavior event ordering, reachability, deadlock, etc

UML Sequence Diagrams

individual scenario interactions between users and system Sequence of messages

Activity diagrams
business processes; concurrency and synchronization; dependencies between tasks; 9

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto
Source: Adapted from Davis, 1990, p67-68

Department of Computer Science

Intro: Object Classes in UML

Generalization (an abstraction hierarchy)
:patient
Name Date of Birth physician history

Aggregation (a partitioning hierarchy)

:patient
Name Date of Birth physician history

0..1 0..1 0..1

1 :in-patient
Room Bed Treatments food prefs

1..2 :kidney
Natural/artif. Orig/implant number

0..2 :eyes
Natural/artif. Vision colour

:out-patient
Last visit next visit prescriptions

:heart
Natural/artif. Orig/implant normal bpm

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

10

University of Toronto
Class name

Department of Computer Science :eye

aggregation multiplicities
0..1 0..1 0..1 :heart 1..2 :kidney
Operational?

Colour 0..2 Diameter Correction

attributes

:patient
Name Date of Birth Height Weight

services

generalization

Normal bpm Blood type

:In-patient
Room Bed Physician

:Out-patient
Last visit next visit physician

:organ
Natural/artif. Orig/implant donor

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

11

University of Toronto

Department of Computer Science

What are classes?

A class describes a group of objects with

similar properties (attributes), common behaviour (operations), common relationships to other objects, and common meaning (semantics).

Examples
employee: has a name, employee# and department; an employee is hired, and red; an employee works in one or more projects

Attributes (optional)

:employee name employee# department hire() re() assignproject()

Name (mandatory)

Operations (optional)
12

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

The full notation

Attribute type Attribute name
Student

Name of the class Other Properties

Visibility: +, -, #,

+ name: string [1] = Anon {readOnly} + registeredIn: Course [*]

Default value
+ register (c: Course) + isRegistered (c: Course) : Boolean

Multiplicity

Operation name

Parameters

Return value

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

13

University of Toronto

Department of Computer Science

Objects vs. Classes

The instances of a class are called objects.

Objects are represented as:

Fred_Bloggs:Employee name: Fred Bloggs Employee #: 234609234 Department: Marketing

Two different objects may have identical attribute values (like two people with identical name and address)

Objects have associations with other objects

E.g. Fred_Bloggs:employee is associated with the KillerApp:project object But we will capture these relationships at the class level (why?) Note: Make sure attributes are associated with the right class
E.g. you dont want both managerName and manager# as attributes of Project! (Why??)
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

14

University of Toronto

Department of Computer Science

Generalization

Notes:
Subclasses inherit attributes, associations, & operations from the superclass A subclass may override an inherited aspect
e.g. AdminStaff & CreativeStaff have different methods for calculating bonuses

Superclasses may be declared {abstract}, meaning they have no instances

Implies that the subclasses cover all possibilities e.g. there are no other staff than AdminStaff and CreativeStaff
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

15

University of Toronto

Department of Computer Science

Aggregation and Composition

Aggregation
This is the Has-a or Whole/part relationship

Composition
Strong form of aggregation that implies ownership:
if the whole is removed from the model, so is the part. the whole is responsible for the disposition of its parts

:Engine :Locomotive

composition

1..* 0..1

:Car

:Train

0..1

:Person
driver 1

0..*

0..1 passengers 16

aggregation

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

University of Toronto

Department of Computer Science

Aggregation / Composition (Refresher)

aggregation

Club
* *

Member

What does this mean??

composition

Polygon

{ordered} 3..*

Point

centre 1

Circle

Note: No sharing - any instance of point can be part of a polygon or a circle, but not both
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

17

University of Toronto

Department of Computer Science

Associations

Objects do not exist in isolation from one another

A relationship represents a connection among things. In UML, there are different types of relationships:
Association Aggregation and Composition Generalization Dependency Realization

Class diagrams show classes and their relationships

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

18

University of Toronto

Department of Computer Science

Association Multiplicity

Ask questions about the associations:

Can a campaign exist without a member of staff to manage it?
If yes, then the association is optional at the Staff end - zero or more (0..*) If no, then it is not optional - one or more (1..*) If it must be managed by one and only one member of staff - exactly one (1)

What about the other end of the association?

Does every member of staff have to manage exactly one campaign? No. So the correct multiplicity is zero or more.

Some examples of specifying multiplicity:

Optional (0 or 1) Exactly one Zero or more One or more A range of values 0..1 1 0..* 1..* 2..6 = 1..1 =*

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

19

University of Toronto

Department of Computer Science

Class associations
Multiplicity A client has exactly one staffmember as a contact person Name of the association Multiplicity A staff member has zero or more clients on His/her clientList

:StaffMember
staffName staff# staffStartDate

:Client
companyAddress 0..* companyEmail companyFax ClientList companyName companyTelephone

1
contact person

liaises with

Role The staffmembers role in this association is as a contact person

Direction The liaises with association should be read in this direction Role The clients role in this association is as a clientList
20

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

10

University of Toronto

Department of Computer Science

More Examples

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

21

University of Toronto

Department of Computer Science

Navigability / Visibility
Order + dateReceived: Date [0..1] + isPrepaid: Boolean [1] + lineItems: OrderLine [*] {ordered}

0..1 Date +dateReceived

* Order 1

1 +isPrepaid Boolean

+lineItems {ordered}

OrderLine
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

22

11

University of Toronto

Department of Computer Science

Bidirectional Associations
Person 0..1 * Car

Person + carsOwned: Car [*]

Car + Owner: Person [0..1]

Hard to implement correctly!

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

23

University of Toronto

Department of Computer Science

Dependencies
Model View ViewController

Layout

Example Dependency types:

<<call>> <<use>> <<create>> <<derive>> <<instantiate>> <<permit>> <<realize>> <<refine>> <<substitute>> <<parameter>> 24

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

12

University of Toronto

Department of Computer Science

Interfaces
<<interface>> Collection equals add

Order LineItems [*]

<<requires>>

<<interface>> List get

<<implements>>

ArrayList get add

Collection

Order LineItems [*]

List ArrayList

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

25

University of Toronto

Department of Computer Science

Annotations

Comments
-- can be used to add comments within a class description

Notes
{length = start - end}

Date Range Start: Date End: Date /length: integer

Constraint Rules
Any further constraints {in curly braces} e.g. {time limit: length must not be more than three months}

2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

26

13

University of Toronto

Department of Computer Science

What UML class diagrams can show

Division of Responsibility
Operations that objects are responsible for providing

Subclassing
Inheritance, generalization

Navigability / Visibility
When objects need to know about other objects to call their operations

Aggregation / Composition
When objects are part of other objects

Dependencies
When changing the design of a class will affect other classes

Interfaces
Used to reduce coupling between objects
2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license.

27

14