1 / 30

CET203 SOFTWARE DEVELOPMENT

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

anika
Download Presentation

CET203 SOFTWARE DEVELOPMENT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related