5 design classes 2

8/11/2019 5 Design Classes 2

1/53

SWE206: OOAD Thilagavathi M, AP, SITE 1

UNIT IV


2/53


3/53


4/53


Object-Oriented Design Process - Activities

1. Designing Business Layer classes

1.1 Apply design axioms to design classes, their attributes,

methods, associations, structures, and protocols.1.2 Refine and complete the UML Class Diagram by adding

details. This step consists of Refine attributes, methods,cardinality, visibility, association and class hierarchy.

1.2.1 Refine attributes1.2.2 Design methods and protocols by utilizing a UML

activity diagrams to represent the methods algorithm.

1.2.3 Refine associations between classes (if required).

1.2.4 Refine class hierarchy and design with inheritance (ifrequired).

1.3 Iterate and refine again.


5/53



2. Design Access Layer Classes2.1 Create access layer classes for every class identified and

created in Business Layer (simply mirror the class).

2.2 Identify access layer class relationships.2.3 Simplify classes and their relationships by eliminating

redundant classes and classes with a single method.2.3.1 Redundant Classes: Classes that perform similar

translate request and translate result activities are

called as redundant classes. Selecting one andeliminating other simplify these classes.

2.3.2 Method Classes: Classes that consist of only one ortwo methods are called as method classes. They canbe eliminated or combined with existing classes if

possible.2.4 Iterate and refine again.


6/53


7/53



4. Iterate and refine the whole design. Re-applythe design axioms and if needed repeat the

preceding steps.


8/53


Object-Oriented Design Process in the Unified Approach

Continuous Testing

Designclasses, theirattributes,

methods,association,structure

Build UMLclass

diagram

ApplyDesign

Axioms

Design viewand accesslayers and

prototypes

Usersatisfactionand usability

tests basedon use cases

O-O Design


9/53


Object-Oriented Design Axioms

An axiom is a fundamental truth that always isobserved to be valid and for which there is no

counterexample or exception. (i.e., they cannotbe proven or derived).

A theorem is preposition that may not be self -

evident but can be proven from acceptedaxioms.

A corollary is a preposition that follows from an

axiom or another preposition that has beenproven.


10/53


Object-Oriented Design Axioms

Axiom 1. The independence axiom. Maintain theindependence of components. (deals with

relationships between system components (suchas classes, requirements, software components)

Axiom 2. The information axiom. Minimize the

information content of the design. (deals withcomplexity of design).


11/53


Corollaries

Derived from the two design axioms.

Useful in making specific design decisions.

May even be called as design rules.


12/53


13/53


Corollaries

Corollary 1. Uncoupled design with lessinformation content

Corollary 2. Single purpose Corollary 3. Large number of simple classes

Corollary 4. Strong mapping

Corollary 5. Standardization

Corollary 6. Design with inheritance


14/53


Corollary 1: Uncoupled Design with Less Information Content

Goal is to maximize objects cohesiveness amongobjects and software components in order to

improve coupling, because only a minimalamount of information need to be passedbetween components.


15/53



Coupling

Coupling is a measure of the strength of

association established by a connection from oneobject or software component to another.

Coupling is a binary relationship.

Strong coupling among objects complicates asystem.

The degree of coupling is a function of How complicated the connection is.

Whether the connection refers to the object itself orsomething inside it.

What is being sent or received.


16/53



The degree, or strength, of coupling between twocomponents is measured by the amount and

complexity of information transmitted betweenthem.


17/53



Types of coupling Interaction Coupling

Involves the amount and complexity of messages between

components. Guideline keep the messages as simple as possible. For

an example if a message connection involves more thanthree

Inheritance Coupling Is a form of coupling between super- and subclasses. A

subclass is coupled to its superclass in terms of attributesand methods. We need high inheritance coupling. For thiseach specialization class should not inherit lot of unrelated

and unneeded methods and attributes. If the superclass isoverwriting most of the methods or not using them, then itis an indication that the inheritance coupling is low.


18/53



Types of Interaction coupling

The connection involves either simple data items oraggregate structures all of whose elements are used by thereceiving object. This should be the goal of an architecturaldesign.

Data CouplingVery low

The connection involves passing an aggregate datastructure to another object, which uses only a portion ofthe components of the data structure.

Stamp CouplingLow

The connection involves explicit control of the processinglogic of one object by another.

Control CouplingMedium

The connection involves two objects accessing a "globaldata space", for both to read and write.

Common CouplingHigh

The connection involves direct reference to attributes ormethods of another object.

Content CouplingVery high

DescriptionNameDegree ofCoupling


19/53


Cohesion

Cohesion: The interactions within a single object or softwarecomponent is called cohesion.

Cohesion reflects the "single-purposeness" of an object.

Highly cohesive components can lower coupling because onlya minimum of essential information need be passed betweencomponents.

Method cohesion, means that a method should carry onefunction.

A method that carries multiple functions is undesirable.

Class cohesion means that all the classs methods andattributes must be highly cohesive, meaning to be used byinternal methods or derived classes methods.


20/53


Corollary 2: Single Purpose

Every class should be clearly defined and necessary inthe context of achieving the systems goals.

When we document a class, we should be able toexplain its purpose in a sentence or two.

If we cannot, then the class should be subdivided intoindependent pieces.

Each method must provide only one service. Each method should be of moderate size, no more than

a page; half a page is better.


21/53


Corollary 3: Large number of simpler classes, Reusability

There are benefits in having a large number ofsimpler classes because the chances of reusing

smaller classes in other projects is high. Large and complex classes are too specialized to

be reused.

Object-oriented design offers a path forproducing libraries of reusable parts.


22/53


Why reusability is not used?

Software engineering textbooks teach new practitioners to buildsystems from "first principles"; reusability is not promoted or evendiscussed

The "not invented here" syndrome and the intellectual challenge of

solving an interesting software problem in ones own unique waymitigates against reusing someone elses software component.

Unsuccessful experiences with software reusability in the past haveconvinced many practitioners and development managers that theconcept is not practical.

Most organizations provide no reward for reusability; sometimesproductivity is measured in terms of new lines of code written plus adiscounted credit


23/53


Corollary 4: Strong mapping

A strong mapping links classes identified duringanalysis and classes designed during the designphase eg., view and access classes.

The analyst identifies objects types andinheritance, and thinks about events that changethe state of objects.

The designer adds detail to this model perhapsdesigning screens, user interaction, and client-server interaction.


24/53


Corollary 5: Standardization

To reuse classes, we must have a goodunderstanding of the classes.

Most object-oriented systems come with severalbuilt-in class libraries.

But these class libraries are not always welldocumented.

Sometimes they are documented, but notupdated.

They must be easily searched, based on users

criteria.


25/53


Corollary 6: Designing with inheritance

When we implement a class, we have todetermine its ancestor, what attributes it will

have, and what messages it will understand. Then we have to construct its methods and

protocols.

Ideally, one has to choose inheritance tominimize the amount of program instructions.

The primitive form of reuse is cut-and-paste

reusability.


26/53


Achieving Multiple Inheritance in a SingeInheritance System

Single inheritance means that each class has only a single superclass.

The result of using a single inheritance hierarchy is the absence ofambiguity as to how an object will respond in a given method;

We simply trace up the class tree beginning with the objects class,looking for a method of the same name. But languages like LISP or C++ have a multiple inheritance scheme

whereby objects can inherit behavior from unrelated areas of theclass tree.

The complication here is how to determine which behavior to getfrom which class, particularly when several ancestors define thesame method.

One way of resolving this is to inherit from the most appropriateclass and add an object of another class as an attribute or

aggregation. The other is to use the instance of the class (object)as an attribute.


27/53


Avoiding Inheriting Inappropriate Behaviors

Before a class inherits, ask the followingquestions:

Is the subclass fundamentally similar to itssuperclass (high inheritance coupling)?

Is it an entirely new thing that simply wants to

borrow some expertise from its superclass (lowinheritance coupling)?


28/53


Designing Classes


29/53


Objectives

Students should be able to define andunderstand

Designing Classes Designing Protocols and Class Visibility

The UML Object Constraint Language (OCL)

Designing Methods


30/53


Introduction

OOD involves designing classes for the objectidentified during OOA.


31/53


The Object-Oriented Design Philosophy

Important activity in building an application,should be to design a set of classes, each of

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


32/53


UML Object Constraint Language

UML is a graphical language with a set of rules andsemantics.

The rules and semantics are expressed in English, ina form known Object Constraint Language (OCL).

OCL

Is a specification language. Uses simple logic for specifying the properties of a

system.

UML modeling constructs require expressions.(eg., type, Boolean values, numbers).

Expressions are stated as strings in OCL.


33/53


UML Object Constraint Language

Syntax for some common navigationalexpressions Item.selector: The selector is the name of an attribute

in the item. (eg., Jhon.age) Item.selector[qualifier-value] : The selector indicates a

qualified association that qualifies the item. The result isthe related object selected by the qualifier. (eg.,

John.Phone[2]) Set -> select (Boolean-expression) : The Boolean

expression is written in terms of objects within the set.The result is the subset of objects in the set for which

the Boolean expression is true.(eg., company.exployee -> salary>30000)


34/53


35/53


Class Visibility: Designing Well-Defined Public, Private, and Protected Protocols

Two problems confronted in designing methodsor attributes for classes

Protocol or interface to the operations and itsvisibility

How is it implemented.


36/53



Theprivate protocol

Includes messages that should not be accessed

by other objects; it is accessible only tooperations of that class.

Thepublic protocol

Is accessible to all classes Theprivate protocol

Is accessible to the class and its subclasses.


37/53



Encapsulation Leakage

Occurs when details about a classs internal

implementation are disclosed through theinterface.

As more internal details become visible, theflexibility to make changes decreases.


38/53



Private and Protected Protocol Layers: Internal

Items in these layers define the implementation ofthe object.

Apply the design axioms and corollaries, especiallyCorollary 1 (Uncoupled design with lessinformation content) to decide what should be

private: What attributes (instance variables) ?

What methods?

Highly cohesive objects can improve couplingbecause only a minimal amount of informationneed to be passed between objects.


39/53



Public Protocol Layer: External

Items in this layer define the functionality of the object.

Things to keep in mind when designing class protocols

Good design allows for polymorphism.

Not all protocol should be public.

Key questions to be answered

What are the class interface and protocols? What public (external) protocol will be used or what external

messages must the system understand?

What private or protected (internal) protocol will be used or

what internal messages or messages from a subclass must thesystem understand?


40/53


Designing Classes: Refining Attributes

Attributes identified in OOA must be refined withrespect to implementation during OOD.

In Analysis Phase Attribute Name is sufficient. In Design Phase detailed information must be

added to the class (defining attributes,

operations). Goal

Refine existing attributes (identified in analysis) or

add attributes that can elevate the system intoimplementation.


41/53



Attribute Types

Single-value attributes

Multiplicity or multivalue attributes Reference to another object, or instance

connection


42/53



UML Attribute Presentation OCL can be used to define the class attributes. Syntax

visibility name : type-expression = initial-valuewhere, Visibilityis one of the following

+ public visibility# protected visibility

- private visibility Type-expression is a language-dependent specification of the

implementation type of an attribute. Initial-value is a language-dependent expression for the initial

value of a newly created object. (optional)

Multiplicity indicator (array) can be represented asEg., Names[10]: String points[2..*] : Point


43/53


Designing Classes: Refining Attributes ATM Example

Account-Transaction

Savings-Checking

1

*

11

Has 1

1,2

Bank

BankClient

#firstName: String

#lastName: String

#cardNumber: String

#pinNumber: String

#account: Account

Transaction

#transID: String#transDate: Date

#transTime: Time

#transType: String

#amount: float

#postBalance: float

Account

#number: String

#balance: float

#bankClient: BankClient

#transaction: Transaction

CheckingAccount SavingsAccount

#savings: Account #checking: Account

ATMMachine

#address: String

#state: String


44/53


Designing Methods and Protocols

Goal

Is to specify the algorithm for methods identified.

Once methods are designed in some formalstructure such as UML activity diagrams with anOCL description, they can be converted to

programming languages manually or automated(i.e., using CASE Tools).


45/53



Types of methods

Constructor

Destructor Conversion method

Copy method

Attribute set Attribute get

I/O methods

Domain specific methods


46/53



Note

Corollary 1 states that, when designing methods

and protocols The complexity of the message connections should be

minimized.

The number of messages that an object sends and

receives must be low.

h d d l


47/53



Highly cohesive objects can improve couplingbecause only a minimal amount of informationneed to be passed between objects.

Abstraction leads to simplicity and also increasesclass versatility.

The requirement of simplification, while retainingthe functionality, seems to lead to increasedutility.

D i i M th d d P t l


48/53



Rules

If it looks messy, then it's probably a bad design.

If it is too complex, then it's probably a bad design.

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

If people don't like it, then it's probably a bad design.

If it doesn't work, then it's probably a bad design.



49/53



Design Issues : Avoiding Design Pitfalls

Keep a careful eye on the class design and makesure that an objects role remains well defined. Ifan object loses focus, you need to modify thedesign. Apply Corollary 2 (Single purpose).

Move some functions into new classes that the

object would use. Apply Corollary 1 (Uncoupleddesign with less information content).

Break up the class into two or more classes. ApplyCorollary 3 (Large number of simple classes).

Rethink the class definition based on experiencegained.



50/53



UML Operation Presentation

OCL can be used to define the class attributes.

Syntax

visibility name : (parameter-list) : return-type-expressionwhere, Visibilityis one of the following

+ public visibility

# protected visibility- private visibility

Parameter-list is a list of parameters, separated by commas,each specified by name : type-expression = default value

Return-type-expression is a language-dependent specificationof the implementation of the value returned by the method. Ifreturn-type is omitted, the operation does not return a value.

Designing Methods and Protocols ATM Example


51/53


Designing Methods and Protocols ATM Example

Account-Transaction

Savings-Checking

1

*

11

Has 1

1,2

Bank

BankClient

#firstName: String

#lastName: String

#cardNumber: String

#pinNumber: String#account: Account

Transaction

#transID: String

#transDate: Date

#transTime: Time#transType: String

#amount: float

#postBalance: float

Account

#number: String

#balance: float

#bankClient: BankClient#transaction: Transaction

+deposit()

+withdraw()

#retrieveAccount()

#updateAccount()

#createTransaction()



+withdraw()

ATMMachine

#address: String

#state: String

+verifyPassword()

Packages and Managing Classes


52/53



A package groups and manages the modelingelements, such as classes, their associations,

and their structures. A package may contain both other packages and

ordinary modeling elements.



53/53


Account-Transaction

Savings-Checking

1*

11

1,2

BankClient

#firstName: String

#lastName: String

#cardNumber: String

#pinNumber: String

#account: Account

Transaction

#transID: String

#transDate: Date

#transTime: Time#transType: String

#amount: float

#postBalance: float

Account

#number: String

#balance: float#bankClient: BankClient

#transaction: Transaction

+deposit()

+withdraw()

#retrieveAccount()

#updateAccount()

#createTransaction()



+withdraw()

ATMMachine

#address: String

#state: String

+verifyPassword()

Account

ATM System

5 design classes 2

Documents