Object-Oriented Design. Module UFC016QM. and Programming. Objects and Classes. O-O Design Unit 2: Faculty of Computing, Engineering

Transcription

1 Module UFC016QM Object-Oriented Design and Programming O-O Design Unit 2: Objects and Classes Faculty of Computing, Engineering and Mathematical Sciences

2 Schedule Quick recap on Use Case diagrams UWE Flix What are Objects and Classes? How to identify them. Class / Responsibility / Collaboration (CRC) Encapsulation, Abstraction, Cohesion, Coupling, Stereotypes UML diagrams and notation

3 UML Use Case Diagram Add Film Remove Film Cinema Manager Add Showing Cinema Booking System

4 What is a Use Case? Collection of related scenarios. Textual narrative Unit of interaction between actor and system what the system does, not how Sequence / Flow yielding result of value to actor* Basis of system scope, construction and testing

5 How do Actors interact with system? Amend Widget Details Sequence ACTOR Actor requests to search for Widget Actor chooses Widget Actor amends Widget Details SYSTEM System displays list of potential Widgets System provides Widget Details System updates Widget Details ping-pong interaction

6 Use Case Recap There is a lot of variation as far as how you might describe the contents of a use case; the UML does not specify any standard. [Fowler] This can be a problem, particularly: Actors, level of detail Depends upon risk the greater the risk the greater the detail

7 Actors Actors do not need to be human e.g. external system. Some people refer to all external systems as actors, others just some or none at all

8 How do I Identify Use Cases? Identify candidate system actors identify candidate use cases Refine and scope units of interaction (use cases) start point (look for actor and initial event) end point (look for beneficial result the goal - for actor)

9 Some Rules Use include when repeating in two or more separate use cases. Use generalization when casually describing variation on normal behaviour. Use extend when describing variation on normal behaviour in a more controlled form. [Fowler]

10 Key Points There is a lot of variation as far as how you might describe the contents of a use case; the UML does not specify any standard. [Fowler] Risk = level of detail Think and justify

11 Recap - a system made up of objects... Computer System Object Function Data

12 What is an Object? An object is the primitive element of object-orientation. An Object will: provide services to other objects via methods (or functions, or operations!) exist at runtime encapsulate data

13 Object terminology Function 1 Function 4 Function 6 Data Function 2 Function 7 Function 3 Function 5 Function 8 Implementation of operation also known as: Method Object data values also known as: Attributes or Properties

14 So what about classes? A blueprint for an object. A class defines an objects generic behaviour and the type of data it may store. Exist in code An instance of a class = an object

15 Instances of Classes Objects that behave in a manner specified by a class are called instances of that class. [Brock] Instances of the same class provide the exactly the same services* Data held in instances of the same class will typically vary. *Subject to data not controlling flow

16 Classes & Objects Class - the template for all instances (or objects!) Brown Query Balance Check Pin Name Account # Balance Pin # Show Details Deposit Withdraw Objects

17 Classes & Objects Classes - * found in model, code * reveal static semantics * reveal structure & architecture of system Objects - * found in the machine memory at runtime (and model, code) * reveal behaviour of system * reveal dynamic semantics of system

18 Class Design Object - Real

19 Encapsulation Send a Message Client objects see a service revealed as an operation Client objects cannot see encapsulated data! Function 1 Function 4 Data Function 6 Function 2 Function 7 Function 3 Function 5 Function 8

20 What is Encapsulation? Information-hiding What I can do NOT how I do it Bank Account example Achieved by: Public service (methods that other objects can call) Private data

21 Bank Account Example Directly manipulating balance would cause failure but data encapsulation won t! Evil Object Account Object Function - 50 AddFunds Data 100

22 Benefits of Encapsulation Promotes maintenance Code changes can be made independently Increases usability Public interfaces Promotes coherence of object does only one thing, and does it well controls of visibility of operations & state data is private / not accessible

23 Collaboration Objects must collaborate Client-Server style requests Designing for collaborations create reusable components Different types of collaboration relationships: is-part-of, has-knowledge-of, and depends-upon

24 Objects Collaborate With Other Objects Get Total Price Get Cost Shopping Basket Get Cost Computer System War & Peace Book Get Cost Best Ever Hits 2002 CD Mission Impossible Impossible DVD DVD 29.99

25 Finding Collaborations 1. Can the class carry out the assigned responsibility on its own? 2. If not then what does it need? 3. Which other class can meet this need? [Brock] Helps identify misplaced responsibilities.

26 Object coupling & cohesion Tight Coupling Loose Coupling Objects of low cohesion are not sure what they do... Cohesive objects do one thing, and only one thing, well!

27 Definitions Cohesion 1. sticking or working together the state or condition of joining or working together to form a united whole, or the tendency to do this

28 Coupling and Cohesion Loose coupling, but not always, find a happy medium! Encapsulation enables a class to be highly cohesive (clear purpose) Highly cohesive classes have clearly defined relationships with other classes A collection of tightly formed objects can be grouped together to form a package

29 Where do classes come from? Analyse Nouns (in use cases etc.) Analyse Nouns (in use cases etc.) Analyse Nouns (in use cases etc.) ABSTRACTION Cluster Classes from Objects Cluster Classes from Objects Cluster Classes from Objects Whole Objects / Component Parts Whole Objects / Component Parts Whole Objects / Component Parts Reject Synonyms Reject Synonyms Reject Synonyms Evaluate Scope Evaluate Scope Evaluate Scope

30 Identifying Classes Many ways to do this but start by Select nouns from requirements Discard obvious Then (Recursive process) Physical objects Careful with adjectives You won t get all the classes initially.

31 Class Responsibility Collaboration Once you have the classes you need to identify what they do (responsibility) and who they do it with (collaboration) Validates class selection Again a recursive process Work in groups when possible

32 Class Responsibility Collaboration (CRC) Class Name: what am I? Responsibilities: Collaborations: What do I know? What do I Do? What do I Decide? Who do I interact with? A set of responsibilities is what a class does - its stereotypical behaviour

33 Example ATM - Brock Initial look through the requirements produces the following classes: Automated Teller Machine ATM Balance Cash dispenser Many more Customer Deposit Money dispenser slot Transaction Printer Withdrawal

34 Elimination Remove classes that are actually the same: ATM = Automated Teller Machine Normal keypad = Numeric keypad Personal Identification Number = PIN Printer = Receipt Printer

35 Outside of System Eliminate classes outside of system scope, e.g. Authorized bank employee Bank Card Deposit Envelope Receipt

36 Keep Physical! For example: Display Screen Deposit Slot Numeric Key Receipt Printer Cancel Key

37 Candidate Classes Arrive at Candidate Classes: Account ATM Balance Inquiry Bank Card Reader Cancel Key Cash dispenser

38 From Brock Pages 51-60

39 Quick Recap Objects are instances of classes Classes = blueprints of objects Classes exist in code, objects exist at runtime Encapsulation means private data and a public interface Encapsulation enables a class to be highly cohesive (clear purpose)

40 UML Notation - the object Object Name Class Name Smith:Customer NB (1): underline font indicates an instance! NB (2): Class and Object are NOT the same thing!

41 UML Notation - the class Stereotype Class Name Attributes Operations <<business>> Customer Date of Birth Address Get Birthday() Change Address()

42 Stereotypes some examples <<business>> class Abstraction derived from business concept in problem domain Name Address Locate «business» Customer <<interface>> class Abstraction representing a single point of entry to component or device, offering a collection of services «interface» Calendar ScheduleTask AddEvent

43 Further stereotype examples <<Controller>> Decision maker, state maintainer <<Information Holder>> Knows certain facts e.g. about concepts, rules <<Structurer>> Organises and presents objects e.g. lists, collections, stacks etc. <<Coordinator>> Reacts to events, delegates

44 Summary Objects encapsulated unit cohesion & coupling important during collaboration Classes abstractly classified from business domain concepts found in use cases CRC useful for validating candidate classes Stereotypes useful for intent of class

45 Tutorial - Identify candidate classes Divide into pairs Refer to the UweFlix Cinema Booking System case study, and your use cases Identify candidate classes using the CRC technique Identify significant attributes for your candidate classes Create a class diagram in the Poseidon tool

46 Test your knowledge Why are loosely coupled collaborations a good thing? Explain how clear class responsibilities lead to cohesive classes. Critically assess the analysis and design value of stereotypes.

47 Next Week Class relationships UML package (class) diagrams Dependency Association Aggregation Read chapter on class diagrams in Fowler

48 References [Brock] Designing Object-Orientated Software Wirfs-Brock et al (The blue book!) [Fowler] UML Distilled 2 nd Edition