Module UFC016QM Object-Oriented Design and Programming O-O Design Unit 2: Objects and Classes Faculty of Computing, Engineering and Mathematical Sciences
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
UML Use Case Diagram Add Film Remove Film Cinema Manager Add Showing Cinema Booking System
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
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
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
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
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)
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]
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
Recap - a system made up of objects... Computer System Object Function Data
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
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
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
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
Classes & Objects Class - the template for all instances (or objects!) Brown 123456 150 1999 Query Balance Check Pin Name Account # Balance Pin # Show Details Deposit Withdraw Objects
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
Class Design Object - Real
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
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
Bank Account Example Directly manipulating balance would cause failure but data encapsulation won t! Evil Object Account Object Function - 50 AddFunds Data 100
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
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
Objects Collaborate With Other Objects Get Total Price Get Cost Shopping Basket Get Cost Computer System War & Peace Book 19.99 Get Cost Best Ever Hits 2002 CD 17.99 Mission Impossible Impossible DVD DVD 29.99
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.
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!
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
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
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
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.
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
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
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
Elimination Remove classes that are actually the same: ATM = Automated Teller Machine Normal keypad = Numeric keypad Personal Identification Number = PIN Printer = Receipt Printer
Outside of System Eliminate classes outside of system scope, e.g. Authorized bank employee Bank Card Deposit Envelope Receipt
Keep Physical! For example: Display Screen Deposit Slot Numeric Key Receipt Printer Cancel Key
Candidate Classes Arrive at Candidate Classes: Account ATM Balance Inquiry Bank Card Reader Cancel Key Cash dispenser
From Brock Pages 51-60
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)
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!
UML Notation - the class Stereotype Class Name Attributes Operations <<business>> Customer Date of Birth Address Get Birthday() Change Address()
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
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
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
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
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.
Next Week Class relationships UML package (class) diagrams Dependency Association Aggregation Read chapter on class diagrams in Fowler
References [Brock] Designing Object-Orientated Software Wirfs-Brock et al (The blue book!) [Fowler] UML Distilled 2 nd Edition