CET203 SOFTWARE DEVELOPMENT Session 1B Modelling and the Theory of Inheritance.
-
Upload
chester-russell -
Category
Documents
-
view
217 -
download
0
Transcript of 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