CET203 SOFTWARE DEVELOPMENT Session 1B Modelling and the Theory of Inheritance

CET203SOFTWARE DEVELOPMENT

Session 1BModelling and the Theory of

Inheritance

Objectives

• Recognise the different elements and attributes that form a UML class diagram

• Identify and represent relationships on class diagrams

• Produce models which exhibit inheritance and know how to represent them on a class diagram

UML Class Diagrams

• Graphical representation of main concepts (except method implementation)

• Static representation of the members of, and relationships between, classes

• Can be used to– sketch outline of design– communicate design ideas– formally document design

UML Class diagrams

• UML class diagrams provide a precise visual representation of class design which can take us forward towards implementation.

• You may sometimes hear people speak erroneously about the ‘UML method’ or ‘methodology’

• UML is simply a set of standardized notations which can be used with or without a formal methodology

• A methodology defines the process which the system developers go through, not simply the form in which the design is documented

Uses of Class Diagrams

• We have concentrated on UML models ‘one step away’ from concrete C# implementations

• We have thought of members in terms of their programming implementations (instance variables and methods)

• Class diagrams may also be used much earlier in the life cycle when analysing the requirements

• In such contexts the meaning will be more abstract and not necessarily map closely onto programming language constructs

Terminology• Strictly UML talks about ‘properties’ and ‘operations’ rather than

‘instance variables’ and ‘methods’• Properties comprise ‘attributes’ and ‘associations’• Beware: In this context ‘properties’ are not equivalent to the C#

properties discussed in the last lecture!

ClassName

attribute

operation()

ClassName

attribute

operation()

association

Suppression• UML allows us to show as much or as little detail as we wish on any

particular diagram.• This is convenient because we can tailor the diagram to focus on

the things we are particularly interested in conveying.• It can also be confusing, since we can never infer the absence of

something in the design from its omission in a diagram – it might simply have been ‘suppressed’!

• The details which follow do not cover every aspect of the UML 2.0 class diagram notation but allow enough detail to be recorded to create a fairly rich model

• For more information readMartin Fowler, “UML Distilled” (3rd Edn.), Addison Wesley, 2004.

Summary of Class Diagram Elements

• Classes• Members

– attributes– operations– visibility

• Relationships– navigability– multiplicity– dependency

– aggregation – composition

• Generalization / specialization– inheritance– interfaces

• Keywords• Notes and Comments

Attributes

• Syntax:visibility name : type multiplicity

• Visibility– ‘+’ public– ‘-’ private– ‘#’ protected– ‘~’ internal

• Multiplicity– ‘n’ exactly n– ‘*’ zero or more– ‘m..‘n’ between m and n

Don’t worry about these for now

Exercise 1

Operations• Syntax:

visibility name (par1 : type1, par2 : type2): type • Visibility

– ‘+’ public– ‘-’ private– ‘#’ protected– ‘~’ internal

• Example+ AddName (newName : String) : boolean

Exercise 2

Associations• Primitive types (int, boolean etc.) can only be attributes• Associations are similar to attributes of Object types and

use some of the same notation• We use an association when we want to give two

related classes, and their relationship, prominence on a diagram

• The following are equivalent:

MyClass

value : OtherMyClass Other

value

Describing Associations

• We can show multiplicity at both ends of an association:

MyClass Other1 1..*

• Sometimes a verb phrase may be used to name an association:

Throttle Motor

Controls

Types of AssociationClass A Class B Dependency

Class A Class B

Simple association(navigable from A to B)

Class A Class B Aggregation

Class A Class B Composition

Class A Class BBidirectionalassociation

Dependency

• Most unspecific relationship between classes (not strictly an ‘association’)

• Class A in some way uses facilities defined by Class B

• Changes to Class B may affect Class A

Class A Class B

Simple Association

• Class A ‘uses’ objects of Class B• Typically Class A has an attribute of Class B• Navigability A to B:

– A Class A object can access the Class B object(s) with which it is associated

– The reverse is not true – the Class B object doesn’t ‘know about’ the Class A object

Class A Class B

Bidirectional Association

• Classes A and B have a two-way association• Each refers to the other class• Navigability A to B and B to A:

– A Class A object can access the Class B object(s) with which it is associated

– Also, a Class B object can access the Class A object(s) with which it is associated

Class A Class B

Aggregation

• Object(s) of Class B ‘belong to’ Class A• Implies reference from A to B• Aggregation is rather controversial

– In general objects of Class B retain an existence independent of Class A

– Some designers believe there is no real distinction between aggregation and simple association

Class A Class B

Composition

• Object(s) of Class B are ‘part of’ a Class A object• Again implies reference from A to B• Much ‘stronger’ than aggregation

– Class B objects are an integral part of Class A– In general objects of Class B never exist other than as

part of Class A, i.e. they have the same ‘lifetime’

Class A Class B

Notes• We can add notes to comment on a diagram

element:

Publication

Includes all items with an ISBN or

an ISSN

Generalization

• Classes are a generalized form from which objects with differing details can be created.

• The objects are ‘instances’ of their class.• Student no. 091234567 is an instance of class

Student.• More concisely, 091234567 is a Student.• Classes themselves can often be organised by

a similar kind of relationship.

Example: Biological classification

• Kingdom (e.g. animals)• Phylum (e.g. vertebrates)• Class (e.g. mammal)• Order (e.g. carnivore)• Family (e.g. cat)• Genus (e.g. felix)• Species (e.g. felix leo)• Fred the lion is a…

Hierarchy

Fred is a…

• Fred is a felix leo is a felix is a cat is a carnivore• Carnivores eat meat• So Fred has the characteristic ‘eats meat’.• Fred is a felix leo is a felix is a cat is a carnivore

is a mammal is a vertebrate• Vertebrates have a backbone• So Fred has the characteristic ‘has a

backbone’.

Inheritance

• Specifying general characteristics high up in the hierarchy and more specific characteristics lower down.

• Important principle in OO – we call this generalization and specialization.

• All the characteristics from classes above a class/object in the hierarchy are automatically featured in it – we call this inheritance.

Publications

Book

titleauthorpricecopies

SellCopy()OrderCopies()

Magazine

titlepriceorderQtycurrIssuecopies

SellCopy()AdjustQty()RecvNewIssue()

Exercise 3a

Inheritance in UML

• Aside from associations, the other main modelling relationship is inheritance:

• Class A ‘inherits’ both the interface and implementation of Class B, though it may override implementation details and supplement both

Class A Class B

Exercise 3b