software systems design – 3 class diagrams (static structure) klaas sikkel software systemsdesign...

65
Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software Systems Design - 3 1

Upload: hollie-scott

Post on 19-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 1

Software Systems

Design – 3

Class Diagrams (static structure)

Klaas Sikkel

Software Systems

Page 2: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 2

Today’s topic

Software Systems

Class Diagram(static)

State MachineDiagram

datafunctionalitybehaviour

ActivityDiagram

interaction

RequirementsList

Use Case Diagram

CommunicationDiagram

SequenceDiagramClass Diagram

(dynamic)

System boundary

Page 3: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 3

Contents

1. What is object-orientation?2. (Static) class diagrams3. What does a class diagram represent?4. Extensions to class diagrams

4.1. Association classes4.2. Generalization

Software Systems

Page 4: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 4

1. What is object-orientation?

Software Systems

Page 5: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 5

What is object-orientation?

Philosophical perspective:• A way to understand how concepts are

structured in the world– Generalization / Specialization

• A tiger is a cat– Subspecies include Bengal, Sumatran and Siberian tiger

• A cat is a mammal• A mammal is a vertebrateAll cats have something in common that they do not share with other mammals

Software Systems

Page 6: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 6

What is object-orientation?

Philosophical perspective:• A way to understand how concepts are

structured in the world– The concept “cat” describes a set of individual

animals that share certain properties(Class vs. Object)

Software Systems

Page 7: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 7

What is object-orientation?

Programming / Software Engineering perspective:• A programming paradigm in which

functionalities are assigned to particular kinds of data– Supports polymorhism– Supports information hiding

Software Systems

Page 8: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 8

Example of a class

Software Systems

Hotel

nameaddressrooms

checkin()lookup()

Page 9: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 9

Pre-object-oriented programming

Oversimplification:• In the early days of programming, the focus

was mostly on programming logic. What happened to the data depended on the logic.

• In object-oriented programming the data are more central and the programming logic depends on the (type of) data.

Software Systems

Page 10: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 10

Polymorphism

Software Systems

Page 11: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 11

Information hiding

• One cannot directly access an object’s data; one can only access the data through a method

Consequence:• Makes software easier to scale up• Makes software easier to maintain

Software Systems

Page 12: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 12

2. (Static) class diagrams

Software Systems

Page 13: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 13

2. (Static) Class diagrams

• A class diagram is used to describe– What the objects are that should be stored in the

system– How these objects are structured– How these objects relate to each other

– (Not: what functionality these objects offer)

Software Systems

Page 14: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 14

Simple example

Software Systems

CD for (part of) a company’s administration

1

Employee

name: Stringinitials: StringSSN: Stringsalary scale: Integerhours/week: Integer

Department

name: Stringworks_in

**

Address

street: Stringnumber: Stringpostal code: Stringtown: String

*lives_at

Page 15: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 15

Class vs. Object

Class• Describes what we

want to know about an employee

Object• Stores data of one

particular employee

Employee

name: Stringinitials: StringSSN: Stringsalary scale: Integerhours/week: Integer

e23156: Employee

name: String = “Smith”initials: String = “JC”SSN: String = “113765775”salary scale: Integer = 9hours/week: 32

Software Systems

Page 16: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 16

Elements of a CD (1): ClassNotation: Example:

Class

attribute 1[: Datatype]attribute 2[: Datatype]...

Class

Employee

nameinitialsSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

N.B.: class name is a singular noun

Software Systems

Page 17: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 17

Elements of a CD (2): Attributes

• A class has zero or more attributes• For every attribute a standard data type can be

specified– Can be omitted if the data type is obvious and/or

not interesting in a given context• Standard data types include:

- Integer - Date- Real - Time- Boolean - Money- String

Software Systems

Page 18: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 18

Elements of a CD (3): Association(Notation will be elaborated on next slides)

multiplicities

(Elements betweenbrackets[ ] are optional) name

Direction of the association

role of Class 2in the association

Class 1 Class 2[<] association [>][ role ]

n..m k..l

[ role ]

Software Systems

Page 19: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 19

Examples

• An employee lives at an address• At any address zero or more employees

are living

Employee

name: StringInitials: StringSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

1*

lives_at

Address

street: Stringnumber: Stringpostal code: Stringtown: String

Software Systems

Page 20: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 20

Examples

Employee

name: StringInitials: StringSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

11..*

lives_at

Address

street: Stringnumber: Stringpostal code: Stringtown: String

• An employee lives at an address• At any address one or more employees

are livingSoftware Systems

Page 21: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 21

Examples

• Multiple associations between two classes

Employee

name: Stringinitials: StringSSN: Stringsalary scale: Integerhours/week: Real

Department

name: String

works_in

1*

**works_on_projects_for

Software Systems

Page 22: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 22

1

Melding incident

volgnummer: Integersoort_incident: Stringdatum: Datetijd: Timeplaats: String

Verslag indicent

datum: Datetijd: Timeverslag: String

Medew. meldkamer

naam: Stringdienstnummer: Stringfunctie: String

*

registreert_melding

0..1

< aanvulling_bij

Agent

naam: Stringdienstnummer: Stringfunctie: String

doet_verslag

1

*

0..1

Examples

Software Systems

Page 23: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 23

MultiplicitiesClass

Class

Class

Class

Class

1

*

0..1

1..*

1..4,7

exactly one

one or more

zero or more

zero or one

(other combinations possible)

Class0..*

alternativenotations forzero or more

Class

Software Systems

Page 24: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 24

Roles in an association

• Consider the following CD

Software Systems

1Behandeling

*Arts

Patiënt

ondergaat

*

1

is_verantwoordelijk_voor

Page 25: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 25

Roles in an association

• We can use a role name, rather than association name, if a class has a specific role in the association

Software Systems

1Behandeling

*Arts

Patiënt

ondergaat

*

1

verantwoordelijkarts

Page 26: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 26

Direction of an association• An association has a

direction(by default:

– from left to right– from top to bottom

• We can explicitly indicate direction with < , > , ^ , v

Employee

name: StringInitials: StringSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

1

*

^ lives_at

Address

street: Stringnumber: Stringpostal code: Stringtown: String

Software Systems

Page 27: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 27

Direction of an association

Employee

name: Stringinitials: StringSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

0..1

*

< has_manager

boss

Employee

name: Stringinitials: StringSSN: Stringsalary scale: Integerhours/week: Realmarried: Boolean

0..1

*

is_manager_of >

boss

Software Systems

Page 28: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 28

Conventions for associations

• In principle, every association has a name.If a role is indicated, the association name can be discarded

• By default an association is read from left to right or top to bottomA direction can be stated explicitly by ‘<‘, ‘>’, ‘^’, ‘v’

• All multiplicities are explicitly given

Software Systems

Page 29: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 29

3. What does a class diagram represent?

Software Systems

Page 30: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 30

CD as a model of the physical world[Lecture 1]: A model is a simplified representation of part of the world, from a particular view

For Class Diagrams specifically:• View: Focus on data (not functions/behaviour)• Part of the world: The subject we’re modelling• Simplified: Only those data that should be

represented in the system

Software Systems

Page 31: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 31

CD as a model of the physical world

John Smith Representation of John Smith in the system

e23156: Employee

name: String = “Smith”initials: String = “JC”SSN: String = “113765775”salary scale: Integer = 9hours/week: 32

Software Systems

Page 32: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 32

Is the model an adequate representation?• Possibly reality is not correctly represented in the

system– John Smith moved to a new address but no-one told the

system • This does not invalidate the class diagram

• There are models in which reality cannot be represented– “Every employee works at one particular department”:

• What to do if someone has two part-time jobs at different departments?

Software Systems

Page 33: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 33

Which is the right model of an address?

Address

Street: StringNumber: IntegerPostal code: PostcodeTown: String

Address

Street: StringNumber: IntegerPostal code: StringTown: StringCountry: String

Address

Address line 1: StringAddress line 2: StringCountry: String

Software Systems

Page 34: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 34

Class and identity• Two different objects can have

the same values for all attributes• Internally they are distinguished

by a different key

h1792: Huisdier

diersoort: String = “Hond”naam: String = “Fikkie”ras: String = “gemengd”

h2365: Huisdier

diersoort: String = “Hond”naam: String = “Fikkie”ras: String = “gemengd”

• Such keys are not represented in the class diagram – unless these keys have spilled over into reality and now exist outside the system (student number, social security number, etc., …

Software Systems

Page 35: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 35

Snapshot vs. historic information• Do we model the world as it exists now, or do we

include data from the past?• This is a conscious choice.

Usually snapshot, sometimes historic information(in exercises it is always clear what was meant)

• Example of a snapshot: Employee has one adres, one manager

• Example of historic information:Incidents in the police information system.They will remain to be recorded after the incident has been dealt with.

Software Systems

Page 36: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 36

Class or attribute? Rule of the thumb:• An entity is an attribute if it is only used as a

particular data item of a class• An entity is a class

– If it can have multiple values– If it has attributes by itself– If it has associations with other classes

Software Systems

Page 37: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 37

Pitfalls

• Synonyms(different words for the same concept)

• Homonyms(one word for different concepts)

Software Systems

Page 38: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 38

Different levels of abstractionSpecial case of homonym• We use one word for a concept on different

levels of abstraction– The book ‘Bonita Avenue’– One copy of the book ‘Bonita Avenue’

– The Alfa Romeo 159 (type of car) has certain properties

– The Alfa Romeo 159 (particular car) which is parked in front of this building

Software Systems

Page 39: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 39

Different levels of abstraction

This distinction is important!And it remains to be difficult!

*

Car type

brand nametype namenr_of_doorsnr_of_seats

1

< has_type Car

license_plate_nrcolour

Software Systems

Page 40: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 40

Yet another example

*

Book

author: Stringtitle: StringISBN: Stringsignature: Stringdamaged: Boolean

Member

name: Stringnumber: Integer

*

0..1

has_reserved

*

has_borrowed

Member wants to reserve a book.The system says that it has beenborrowed by someone and will Be returned in two weeks.However, there are two copiesstill in the library.

Reservations and loans in a library

Inappropriate model:Impossible to indicatemultiple copies of theSame book

Software Systems

Page 41: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 41

Compare‘Car’ and ‘Car type’

*

Book title

author: Stringtitle: StringISBN: Stringsignature: String

Member

name: Stringnumber: Integer

*

0..1

has_reserved

*

has_borrowed

Book copy

inventory_nr: Stringdamaged: Boolean

1..*

1^ is_copy_of

Yet another exampleReservations and loans in a library

Software Systems

Page 42: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 42

4.1 Association classes

Software Systems

Page 43: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 43

Problem

How can we assigna grade to the test?

*

Exam

date: Dateresponsible_lecturer

Student

name: Stringstudent_nr: String

*

Course

name: Stringcode: StringEC: Integer

2..*

1tests

participates_in

Software Systems

Page 44: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 44

Association class: Example

*

Participation

grade: Integer

Exam

date: Dateresponsible_lecturer

Student

name: Stringstudent_nr: String

*

Course

name: Stringcode: StringEC: Integer

2..*

1tests

Software Systems

Page 45: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 45

Identity of an association class• The identity of an object of an association class is

defined as combination of the identity of the associated objects.

• That means: – One ‘participation’ is identified by the

combination of one student and one exam

Software Systems

Page 46: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 46

Elements of a CD (4): Association class

Class 1m..n

Class 2

Association class

attribute 1[: Datatype]attribute 2[: Datatype]...

k..l

Software Systems

Page 47: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 47

Associatieclass vs. class

Are these models equivalent?

*

Contract

start_date: Datesalary scale: Integerpermanent: Boolean

Company

name: Stringregistration_nr

Employee

name: Stringinitials: StringSSN: String

*

* 1

Company

name: Stringregistration_nr

Employee

name: Stringinitials: StringSSN: String

Contract

start_date: Datesalary scale: Integer: permanent: Boolean

*1

em-ployee

em-ployer

(b)

(a)

Software Systems

Page 48: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 48

Identity of an association classIdentity is combination of the identities of the associated classes• That implies, for (a):

– A contract is defined by a unique combination of employee and company

– Differently stated: For a combination of one person and one company there can only be a single contract

• But in case (b):– A person and a company can have multiple

contracts

Software Systems

Page 49: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 49

*

Participation

grade: Integer

Exam

date: Dateresponsible_lecturer

Student

name: Stringstudent_nr: String

*

Course

name: Stringcode: Stringnr_EC: Integer

2..*

1tests

For a student who participates in an exam there isexactly one grade

Software Systems

Page 50: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 50

A last exampleMarriage: snapshot view Marriage: historical view

Person

namebirth_date

0..1

Marriage

date: Date

0..1

Person

namebirth_date

*

*

Marriage

begin: Dateend: Date

Software Systems

Page 51: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Special case: Liz Taylor &Richard Burton

Married: 15 March 1964 — Divorced 26 June 1974

Married: 10 October 1975 — Divorced: 29 July 1976

Design - 3

Page 52: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 52

Liz Taylor & Richard BurtonPerson

namebirth_date

*

*

Marriage

begin: Dateend: Date

Person

namebirth_date

*

2

Marriage

begin: Dateend: Date

married

Inadequate model Adequate modelSoftware Systems

Page 53: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 53

4.2 Generalization

Software Systems

Page 54: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 54

Generalization example

Software Systems

Employeesalary scale: IntegerSSN: String

Student

student-nr: String

Person

name: Stringinitials: Stringkind_of_person

kind_of_person<<dynamic>>

Page 55: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Elements of a CD (5): generalization

Class 3attribuut3: Datatype...

discriminator<<static>> / <<dynamic>>

Class 2attribuut2: Datatype...

Class 1

attribuut1: Datatype...discriminator: Datatype

[d][c]

Elements:discriminatorstatic/dynamicdc / d / c / _

Class 1 is thesuperclass ofClasses 2 and 3

Class 3 is a subclass of Class 1

Design - 3

Page 56: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 56

Elements of generalizations (1)• Discriminator

– discriminator is one of the attributes of the super class

• <<static>>/<<dynamic>> – Static: an object cannot chance subclass

Example: a bicycle never becomes a car

– Dynamic: an object could belong to different subclasses at different moments in time Example: student graduates and becomes employee

Software Systems

Page 57: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 57

Elements of generalizations (2)• Disjoint generalization: an object can belong

to at most one subclass Not disjoint: anobject can belong to different subclasses at the same time (student assistant is both student and employee)

• Covering generalization: every object of the superclass belongs to (at least) one subclassNot covering: there can be objects that don’t belong to any subclass(external staff; is in the database but not an employee)

Software Systems

Page 58: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 58

Employeesalary scale: IntegerSSN: String

Student

student-nr: String

Person

name: Stringinitials: Stringkind_of_person

kind_of_person<<dynamic>>

Disjoint and coveringdc

d

c

?

Software Systems

Page 59: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 59

Use of generalization

We use a generalization if …• …subclasses can be distinguised that have

different attributes• … subclasses can be distinguished that have

different associations

Software Systems

Page 60: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 60

Use of GeneralizationDifferent attributes for ‘Student’ and ‘Teacher’

Software Systems

c

Teachersalary scale: IntegerSSN: String

Student

student-nr: String

Person

name: Stringinitials: Stringkind_of_person

kind_of_person<<dynamic>>

Page 61: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 61

Use of GeneralizationDifferent assocations for ‘Student’ and ‘Teacher’

Software Systems

cStudent

Person

name: Stringinitials: Stringkind_of_person

kind_of_person<<dynamic>>

Study programname: Stringabbreviation: Stringmaster: Boolean

*

1..*studies

Teacher

Page 62: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 62

Use of GeneralizationContains the same information as the previous slide

(Subclass without attributes can be deleted)

Software Systems

Student

Person

name: Stringinitials: Stringkind_of_person

kind_of_person<<dynamic>>

Study programname: Stringabbreviation: Stringmaster: Boolean

*

1..*studies

Page 63: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Generalization: more examples

Design - 3

Car Bicycle

Means of transport

Private car

d

cd Company car

Car leased by company

Car owned by company

cd

Page 64: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Generalization: more examples

Design - 3

Hospital staff Patient

Person

Medical staff

d

Support staffParamedical

staff

Page 65: Software Systems Design – 3 Class Diagrams (static structure) Klaas Sikkel Software SystemsDesign - 31

Design - 3 65

Self-study and Laboratory exercise

Please note:• The self-study prepares for the lab exercise• There is good reason for that:

Wednesday’s lab exercise is quite challenging• So do your homework and be prepared!

Software Systems