2. design classes

7/29/2019 2. Design Classes

1/29

Designing Classes

Module -4


2/29

Goals

Designing classes.

Designing protocols and class visibility.

Defining attributes.

Designing methods.


3/29

OO Design Philosophy

The first step in building an application

should be to design a set of classes, each

of which has a specific expertise and all ofwhich can work together in useful ways.


4/29

Designing Class: the Process

1.Apply design axioms to design classes, theirattributes, methods, associations, structures, and

protocols.1.1. Refine and complete the static UML class diagram (object

model) by adding details to that diagram.1.1.1. Refine attributes.

1.1.2. Design methods and the protocols by utilizing a UML

activity diagram to represent the method's algorithm..

1.1.3. Refine the associations between classes (ifrequired).

1.1.4. Refine the class hierarchy and design with

inheritance (if required).

1.2. Iterate and refine again.


5/29

UML Object Constraint Language (OCL)

UML graphical language with a set of rules andsemantics

OCL The UML rules and semantics are expressed in

English in a form known as object constraint language.

This is a specification language that uses simple logicfor specifying the properties of a system

Expressions for Boolean values, numbers etc Stated as strings in OCL

expressions meant to work on sets of values like

Item.selector: selector is the name of the attribute in the itemlike John.age

Item.selector [qualifier-value] like John.Phone[2]

Set->select (boolean-expression) Company.employee->salary > 30000


6/29

Class Visibility: Define well defined protocols

In designing methods or attributes for

classes, you are confronted with two

issues

One is the protocol, or interface to the classoperations and its visibility

The other is how it should be implemented


7/29

Class visibility

Private

Public

Protected


8/29

Private (internal) Protocol

Protected Protocol

Public Protocol

Messages

Sub class

Public protocols define

the functionality and

external messages of an

object, while privateprotocols define the

implementation of an

object.

Class Visibility (Cont)


9/29

Encapsulation leakage and Protocol issues

Lack of a well designed protocol will lead to

Encapsulation leakage: details about the internalimplementation of a class are disclosed through theinterface

Impacts flexibility to accommodate future changes inimplementation


10/29

Private Protocol (Visibility)

A set of methods that are used onlyinternally

Object messages to itself

Define the implementation of the object

(Internal)


11/29

Protected Protocol (Visibility)

In a protected protocol, subclasses can

use the method in addition to the class

itself

In private protocols, only the class itself

can use the method


12/29

Public Protocol (Visibility)

Defines the functionality of the object

Guidelines in designing class protocols Good design allows for polymorphism

Not all protocol should be public

Decide what should be public (External)

apply design corollaries


13/29

Refining Attributes

In analysis phase, name of attribute wassufficient

In design phase, add detailed information Type of attributes

Range of values allowed

Initial values

Visibility

Goals Refine existing attributes

Or add attributes to enable implementation of system


14/29

UML Attribute Presentation: OCL

visibility name : type-expression=initial-value Initial-value is optional

Visibility + public visibility (accessible to all classes)

# protected (accessibility to subclasses and operations ofthe class)

- private (accessibility only to operations of the class)

Examples:

+ names[10]:String=hello points[2..*]: Point

Add short descriptions for each attribute and

also constraints if any


15/29

Attribute Types

Attribute state of an object The three basic types of attributes are:

1. Single-value attributeshas one value or statee.g, name, address

2. Multiplicity or multivalue attributeshave acollection of many values at any point of time. E.g to keep

track of the names of the people who called a customer

support line for help, we use the multivalues attribute


16/29

3. Reference to another object, or instance

connection

provide the mapping needed by an object to fulfill itsresponsibilities

For example,

a person might have one or more bankaccounts. A person has zero to many instance

connections to Account(s).

Similarly, an Account can be assigned to one or

more persons (i.e., joint account). Therefore, anAccount also has zero to many instance

connections to Person(s).


17/29

Designing methods

Goal

Specify algorithm for methods

Algorithms can be designed with the help of

activity diagrams and OCL

Many times pseudo code is used instead of

activity diagrams

Provide short textual descriptions of methodsalso


18/29

UML OCL for methods Classname :: visibility name : (parameter list) :

return-type-expression parameter list: list of parameters, separated by commas

each specified by name:type-expression = default value

Default value is optional

Return- type- expression and type- expression are languagedependant specification of an implementation types

Ifreturn-type omitted, no return value

Eg

BankClient::+verifyPassword (cardNumber: String,aPIN:String)

UML convention: Attributes and operations start withlower case


19/29

Designing Methods and Protocols

A class can provide several types of

methods:

Constructor

Method that creates instances (objects) of the

class

Destructor

The method that destroys instances Conversion method

The method that converts a value from one unit

of measure to another

D i i M th d d


20/29

Designing Methods and

Protocols

Copy methodThe method that copies the contents of one

instance to another instance

Attribute setThe method that sets the values of one or more

attributes

Attribute getThe method that returns the values

of one or more attributes


21/29

Designing Methods and Protocols

I/O methods

The methods that provide or receive data to

or from a device

Domain specific

The method specific to the application


22/29

Five Rules For Identifying Bad Design

I. If it looks messy then it's probably a

bad design.


23/29

II. If it is too complex then it's probably a

bad design.


24/29

III. If it is too big then it's probably a bad

design.


25/29

IV. If people don't like it then it's probably a

bad design.


26/29

V. If it doesn't work then it's probably a

bad design.


27/29

Avoiding Design Pitfalls

Keep a careful eye on the class designand make sure that an object's role

remains well defined.

If an object loses focus, you need tomodify the design.

Apply Corollary2

(single purpose).


28/29

Move some functions into new classesthat the object would use.

Apply Corollary 1 (uncoupled design with

less information content).

Break up the class into two or more

classes.

Apply Corollary 3 (large number of simple

classes).


29/29

END

2. design classes

Documents