1 / 31

Object orientation

Object orientation. What benefits does OO give?. Primarily Encapsulation (Associates data & operations) Types & specialisation Software re-use. “Manage the seams”. Define major interfaces between components And design so that there aren’t too many major interfaces. Thinking about objects.

jenna-mckay
Download Presentation

Object orientation

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. Object orientation

  2. What benefits does OO give? • Primarily • Encapsulation (Associates data & operations) • Types & specialisation • Software re-use

  3. “Manage the seams” • Define major interfaces between components • And design so that there aren’t too many major interfaces

  4. Thinking about objects • How to discover classes? • What kinds of relationships? • How to design for reuse? • How to capture design? • How to correct the design when you realise it’s wrong? (!)

  5. Analysis & Design • OO Analysis. A method of analysis in which requirements are examined from the perspective of the classes and objects found in the vocabulary of the problem domain. • OO Design. A method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design; specifically, the notation includes class diagrams, object diagrams, module diagrams and process diagrams. (BOOCH)

  6. 2 perspectives on OOA & OOD • OO Analysis is a kind of design • traceability of objects from analysis to design (Jacobsen) • Design features tend to creep into analysis • and this is bad (Embley et al)

  7. Discovering classes (Quatrani) • Entity • Information + behaviour that is generally long-lived. Look for nouns and noun-phrases describing responsibility • Boundary • Communication between system surroundings & inside of system, e.g. interface to user or to another system • Control • Behaviour specific to one or more use cases (scenarios). ‘Runs’ that particular use case

  8. Identifying relationships • ‘Kind-of’ (subclassing) different from ‘Part-of’ (collaboration — or, more precisely, aggregation) • So don’t make SteeringWheel subclass of Car just so it can access all the car information!

  9. OO modelling for biology • So should Vicia faba be modelled as a subclass of Vicia? • Or as a part of Vicia? • NEITHER – at the design phase we’re modelling programming objects • So a suitable class might be Taxon (debatable whether we should have a hierarchy – depends on intended use)

  10. Two kinds of ‘standard’ reuse • Reuse by inheritance • Reuse by composition

  11. What is inheritance for? • A means of indicating relationships • A means of programming-by-difference

  12. Refactoring • Your first design is probably wrong! • So look for ways of refactoring • Particularly expensive to refactor major objects, so try to get that bit right early • The ‘innards’ can be refactored much more readily (e.g. could change wrapper architecture without altering the way clients interface with wrappers)

  13. Modelling

  14. Introduction The UML was devised with the aims: • To be a standard (now adopted by the OMG) • To model aspects generally regarded as important: • static • dynamic • functional • To be extensible

  15. Background • Designed by 3 major players in OOA/OOD (Booch, Rumbaugh & Jacobsen) • Intended to provide a universal means of communicating design • A design has a relevance outside the particular process by which it was created

  16. Kinds of diagram Nine kinds of diagram (some related): • Class and Object diagrams • Use Case diagrams • Sequence diagrams • Collaboration diagrams • Statechart diagrams • Activity diagrams • Component and Deployment diagrams • CRC cards are also often used for informal modelling (brainstorming)

  17. Use Cases: Motivation • Capturing scenarios in which a system is to be used • Describing the details of how a particular scenario will be acted out

  18. Benefits Help us both in: • determining what kinds of classes are appropriate, and • determining the processes that the code to be written will implement

  19. What comprises a Use Case? • The Use Case itself (names a particular scenario) • The actors and their associations with each Use Case • Documentation

  20. Example Reserve book Refuse Loan <<extend>> Borrow copy of book Check for Reservation <<includes>> Return copy of book Borrower Librarian <<includes>> Update Catalogue Extend Loan

  21. Name: Reserve Book Description: Allow a borrower to reserve a book Preconditions: Member of library, no loans overdue, ... Postconditions: The borrower will be placed on the waiting list for the book

  22. Basic Course of Action 1. Borrower wants to reserve a book 2. Borrower submits details of book to be reserved 3. System determines whether borrower is eligible to reserve 4. Reservation stored 5. Confirmation of reservation given to borrower 6. Use Case Ends Alternative Course A: borrower ineligible A.3 Inform borrower (s)he’s ineligible A.4 Use Case ends

  23. We can start suggesting classes ... • Borrower • LibrarySystem • Book • Reservation • ...

  24. Class & Object Diagrams • Central to any genuinely object-oriented design is the relationship of objects — and of their classes — to each other

  25. Static models - class diagrams

  26. Static models - class diagrams

  27. 0..1 * Employment * 1 * 1 Person Company period: dateRange Example (Class Diagram) • Note how this avoids the need for dynamic relationships or roles (both of which are supported by UML)

  28. Aggregation • Captures the ‘part-of’ relationship. Diamond at the ‘whole’ end

  29. Object diagrams • Relationship between specific objects

  30. Object diagrams (ctd.) • Can show relationship between classes and instances (use label <<instanceOf>>)

  31. Summary • Remember that the fundamental OO modelling technique is class modelling • But class diagrams only allow us to name operations, rather than describe processes by which change occurs • The UML also allows us to model dynamic and functional aspects of a system using other kinds of diagrams

More Related