CET203 SOFTWARE DEVELOPMENT

1. CET203SOFTWARE DEVELOPMENT Session 1B Modelling and the Theory of Inheritance

2. 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

3. 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

4. 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

5. 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

6. 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 ClassName association attribute attribute operation() operation()

7. 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” (3rdEdn.), Addison Wesley, 2004.

8. Classes Members attributes operations visibility Relationships navigability multiplicity dependency aggregation composition Generalization / specialization inheritance interfaces Keywords Notes and Comments Summary of Class Diagram Elements

9. 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

10. Exercise 1

11. Operations • Syntax: visibility name (par1 : type1, par2 : type2): type • Visibility • ‘+’ public • ‘-’ private • ‘#’ protected • ‘~’ internal • Example + AddName(newName : String) : boolean

12. Exercise 2

13. 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: value MyClass MyClass Other value : Other

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

15. Types of Association Class A Class B Dependency Simple association (navigable from A to B) Class A Class B Bidirectional association Class A Class B Class A Class B Aggregation Class A Class B Composition

16. Dependency Class A Class B • 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

17. Simple Association Class A Class B • 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

18. Bidirectional Association Class A Class B • 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

19. Aggregation Class A Class B • 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

20. Composition Class A Class B • 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’

21. Notes • We can add notes to comment on a diagram element: Publication Includes all items with an ISBN or an ISSN

22. 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.

23. 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…

24. Hierarchy

25. 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’.

26. 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.

27. Publications Book Magazine title price orderQty currIssue copies title author price copies SellCopy() AdjustQty() RecvNewIssue() SellCopy() OrderCopies()

28. Exercise 3a

29. 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

30. Exercise 3b