CET203 SOFTWARE DEVELOPMENT Session 1B Modelling 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 read Martin Fowler, “UML Distilled” (3 rd 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 : Other MyClass Other value

Describing Associations We can show multiplicity at both ends of an association: MyClass Other 1 1..* Sometimes a verb phrase may be used to name an association: Throttle Motor Controls

Types of Association Class 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 B Bidirectional association

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 is an instance of class Student. More concisely, 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 Organism Animal Vertebrate Mammal Carnivore Cat Felix Felix Leo Fred

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 title author price copies SellCopy() OrderCopies() Magazine title price orderQty currIssue copies 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