Object-Oriented Design : Module 3

Class Diagrams
John Leaney, Lian Loke, Lizveth Robles University of Technology, Sydney
Contributors
John Reekie, University of Technology, Sydney

Terms of Use: Creative Commons Attribution-ShareAlike 2.5 http://creativecommons.org/licenses/by-sa/2.5/

Overview
So far:
Object-oriented design what it is Expressing requirements what system are we building

This week:

How do we express our design How do we discover classes

Class A

MyClass
Class B Class C

Responsibility 1 Responsibility 2 Responsibility 3

Collaborator 1 Collaborator 2 Collaborator 3

Class diagrams

CRC cards

Class Diagram
UML structural diagram for presenting the static model of a system
Use cases express a dynamic relationship (this, then that ..)

The static model is first constructed in the requirements analysis phase, ( for example with CRC cards) and greater detail is added in design, and as the design progresses. Typically shows:
Classes with attributes, operations, invariants. Relationships between classes

Example Class
+ + +

Class name

UML

BankAccount accountNumber: Integer Attributes balance: Money = 0 open(accountName: String): Boolean close( ): Boolean Operations withdraw (amount: Money): Boolean

Java

public class BankAccount { private int accountNumber; private Money balance; public boolean open(String accountName){ } }

Discuss!

More info
Class names are capitalized Attributes and operations have visibility, type, name Operations represent:
common behaviours of all instances of a class actions that can be carried out by, or on, an object services offered by a class specification for some aspect of behaviour of a class

For example:
change an instances data (i.e. attributes) respond to simple queries perform calculations send messages or events to other objects

Visibility
Public (+)
member of class is directly accessible to other objects; part of public interface

Private (-)
member is hidden from public use; only accessible to other members within the class

Protected (#)
special visibility scope applicable to inheritance only

My advice: Unless you have a good reason to do otherwise, make all operations public, and all attributes private

Java vs UML
You will note that the syntax is different
UML is a design language. It does not depend on any particular implementation language Java is an implementation language. It has nothing whatsoever to do with UML You have to know both!

Assumed or implicit operations may not be explicitly shown on class diagram:

create instances get and set methods destroy object

Java code naturally grows data members and operations that arent in the UML
This is the old problem of keeping design specifications in sync with implementations

Solving a complex problem

Dont get stuck! Start somewhere, and then iterate

How do we start finding classes?

CRC Cards:
An informal approach to OO modelling. Created through scenarios, based on the system requirements, that model the behaviour of the system.

CRC stands for

Class
A set of objects that share common structure and behaviour

Responsibility
Some behaviour for which an object is held accountable

Collaboration
Process whereby several objects cooperate to provide some higherlevel behaviour

CRC Cards
Class Name: Responsibilities Responsibilities of a class are listed in this section. Collaborations Collaborations with other classes are listed here, together with a brief description of the purpose of the collaboration.

Class Name Responsibilities Provide client information. Provide list of campaigns. Class Name Responsibilities

Client Collaborations

Campaign provides campaign details. Campaign Collaborations

Provide campaign information. Provide list of adverts. Add a new advert. Class Name Responsibilities Provide advert details. Construct adverts. Advert

Advert provides advert details. Advert constructs new object.

Collaborations

Types of Responsibilities
Knowing
knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate

Doing
doing something itself, such as creating an object or doing a calculation initiating action in other objects controlling and coordinating activities in other objects

Examples
a Sale is responsible for knowing its total (POS example) a Sale is responsible for creating SalesLineItems

A CRC Session
The participants are users (ideally) and designers. A designer runs the session, records the data and resolves any disputes. The users contribute most of the ideas, as they are the people who know the current system. As classes, responsibilities and collaborators are discovered, they are written down, one class per card.

Running a CRC Session (1)

1. Brainstorm the classes.
Ask the users to suggest possible classes.
At this point, the key is to get people involved so no decision is made about whether a class is right or not; they are possible classes.

2. Filter the classes.

eliminate redundant classes identify missing classes recognise related classes

3. Define the data in each class.

All participants should have the same meaning
for the words used in the session. The definition can be a simple phrase, or attributes can be added to the class. This is usually done on the back of the card.

Running a CRC Session (2)

4. Assign classes to participants. 5. Run the scenarios.
Step through each scenario. For each event or action, decide which class should have the responsibility to fulfil it. Write down the name of the action under the Responsibilities column for the chosen card. Decide which classes collaborate to fulfil this responsibility, and write down their names in the Collaborators column.

Other techniques
Users, experts, commonsense, imagination Noun phrase identification
Extract the nouns from a written description of the vision for the system (or from similar kinds of texts, eg. brief, system narrative, etc.) Classes are named by nouns

Stereotype classes Analysis patterns

Stereotype classes
Classes can have stereotypical, or often found, roles. 3 main stereotypes in UML
Entity
representative of key entities or things in the application domain

Boundary
user or external interfaces

Control
coordinate or delegate to other objects

Other:
Collection classes
provide storage and management of a set of objects of the one type. e.g. array, linked list, vector

Patterns
A pattern is a common, recurring set of objects and relationships that exhibits characteristic behaviours.

http://java.sun.com/blueprints/patterns/MVC-detailed.html

Reasonability Checks for Candidate Classes

A number of tests help to check whether a candidate class is reasonable
Is it beyond the scope of the system? Does it refer to the system as a whole? Does it duplicate another class? Is it too vague? Is it too tied up with physical inputs and outputs? Is it really an attribute? Is it really an operation? Is it really an association?

If any answer is Yes, consider modelling the potential class in some other way (or do not model it at all)

Generalisation aka inheritance

Some classes have common attributes and/or operations. It is pointless to define each such class separately. We need to define only the super class (parent) while the subclasses (children) inherit all properties of the super class. Inheritance is an is-a relationship.

Cherry

Fruit

Specialisation

Inheritance cont.
In UML

Advert

NewspaperAdvert

In Java public class Advert{ } public class NewspaperAdvert extends Advert{ }

When to use inheritance?

Ask the question: Is A a B? Designing a more specialised class from an existing class. Capturing common information in a super (base) class
and specialised functionality in sub (derived) classes.

Inheritance leads to creation of a class hierarchy

The AWT (Abstract Windowing Toolkit) in Java has an inheritance hierarchy of many levels At the top of the hierarchy of every class in Java is the Object class.

AWT Inheritance Hierarchy

Polymorphism (1)
Dance time dress
numberDancers

Ball Room

Ballet

Break Dance

bow() perform()

Flamenco

Line Dance

Polymorphism (2)
Each child class has the operation perform. Perform has a different meaning for each class.
The dance is performed in a completely different way.

Each subclass must define its own perform operation. It should be possible to use any of the subclasses where the base class can be used (the Liskov substitution principle)

poly = many, morph = shape

Pros and Cons

Pros
Conceptually straight-forward translation from modeling to implementation (is-a -> extends) Can be used to improve reusability Can be used to improve extensibility (the open-closed principle)

Cons
Excessively deep hierarchies become brittle and hard to understand There is on-going controversy on whether implementation inheritance is good (or whether we should just have interface inheritance)

Regardless, inheritance is firmly established in objectoriented analysis, design, and implementation. You must understand and be able to use it well.

Association
This relationship specifies the structural relationship between two classes (it is a needs-a relationship). Both classes are conceptually at the same level (i.e., none is more important than the other). An association can be named, for clarity.

throws
Dart needs the person, in order to be thrown

Dart

Person

Multiplicity
Multiplicity of an association shows how many of one class is related to how many of the other class.
Typical numbers are 0, 1, .. * (many) or 1..* (1 to many),

Person

1..* works for

Company

Role
A role is the face that a class at one end of an association presents to the class at the other end of the association.
If you use roles with an association, then you dont need to name the association.

Person

employee

employer

Company
role name may be implied as employer-employee relation

Navigation
In which direction(s) are messages sent along an association?
This is referred to as the navigability of the association.

Navigability can be uni-directional, bi-directional or undecided.

Customer Person

1 places 1 throws

* *

Order Dart

Aggregation : whole-part
Sometimes we need to show the importance, the cumulative role, the bringing together relationship of one class. Thence we show the association as a whole-part (i.e., a has-a) relationship.
1

City

Skyscraper

Aggregation cont.
In UML

Campaign

0..*

Advert

In Java public class Campaign{ private Advert adverts[]; public Advert getAdvert(int id){ } }

An Example: Agate class diagram fragment

What we havent done

Dependency
An instance of class A depends on an instance of class B

Interfaces
A class realizes an interface So: read (at least) the references here:
http://www.softwarepractice.org/courseware/index.php/design/class_diagrams

And practice creating your class diagrams!

Start with CRC cards to identify objects Identify attributes and operations Identify inheritance relationships Identify associations As you get more used to the notation, you can start making your diagrams more sophisticated and precise.