OOSAD

Chapter Four

Object Oriented Design

Introduction
• Purpose of design is to determine how you are going to build
your system.

• Where as analysis modeling concentrated on the functional

requirements of the evolving system, design modeling
incorporates the nonfunctional requirements.

• It is highly iterated

• Analysis and design are highly interrelated and iterative

Unity University 2
 Cont.
Design Artifacts And Their Relationship

Unity University 3
Layering your models – Class Type Architecture

• Layering is the concept of organizing your software design

into layers/collections of functionality that fulfill a common
purpose.

• A class- type architecture provides a strategy for layering the

classes of your software to distribute the functionality of your
software among classes.

• Class-type architectures provide guidance as to what other

types of classes a given type of class will interact with, and
how that interaction will occur
Unity University 4
 Cont.
What are the qualities that make up good layers?

First, you should be able to make modifications to any given layer

without affecting any other layers.
This will help to make your system easy to extend and to
maintain.

Second, layers should be modularized.

You should be able either to rewrite or to replace a layer
This will help increase the portability of your software.

Unity University 5
 Cont.
1. Interface classes.

• These classes wrap access to the logic

of your system.

• Two categories of interface class—

UI classes that provide people access to
your system and

System interface (SI) classes that

provide access to external systems to
your system.

• UI for any given system can take on

many possible forms even though the
underlying business is still the same
Unity University 6
 Cont.
2. Domain classes.

• These classes implement the concepts

pertinent to your business domain
such as Student or Seminar,
focusing on the data aspects of the
business objects, plus behaviors
specific to individual objects.

Unity University 7
 Cont.
3. Process classes

• Also called controller classes, these

classes implement business logic that
involves collaborating with several
domain classes or even other process
classes.

4. Persistence classes.

• These classes encapsulate the

capability to store, retrieve, and
delete objects permanently without
revealing details of the underlying
Unity University 8
storage technology
 Cont.
5. System classes

• These classes provide operating-

system-specific functionality for your
applications, isolating your software
from the operating system (OS) by
wrapping OS-specific features,
increasing the portability of your
application.

Unity University 9
 Cont.
• Collaboration between classes is allowed within a layer;
 UI classes UI classes and business/domain classes can send messages to other
business/domain classes.

• Collaboration can also occur between classes in layers connected

by arrows.
interface classes may send messages to domain classes but not to persistence
classes.

 Domain classes may send messages to persistence classes, but not to interface
classes.

• By restricting the flow of messages to only one direction, you

dramatically increase the portability of your system by reducing
the coupling between classes..
Unity University 10
 Cont.
• All types of classes may interact with system classes.

• This is because your system layer implements fundamental

software features such as inter-process communication (IPC).

• For example, if your user-interface classes are running on a

personal computer (PC) and your domain classes are running on an
EJB application server on another machine, then your interface
classes will send messages to the domain classes via the IPC
service in the system layer.

Unity University 11
 Cont.
A simple example of an e-commerce system

Domain Classes:

• Example: Product, Customer, Order

• The Product class represents a product available for sale, with

attributes like name, price, and description.

• The Customer class represents a customer of the e-commerce

system, with attributes like name, address, and email.

• The Order class represents an order placed by a customer, with

attributes like order ID, date, and total amount.

Unity University 12
 Cont.
A simple example of an e-commerce system

Process Classes:

• Example: OrderProcessor, PaymentProcessor, InventoryManager

• The OrderProcessor class handles the processing of orders, including

validation, calculation of totals, and updating the order status.

• The PaymentProcessor class handles payment processing, integrating

with external payment gateways to authorize and process payments.

• The InventoryManager class manages the inventory of products,

tracking stock levels and updating availability based on orders.

Unity University 13
 Cont.
A simple example of an e-commerce system

System Classes:

• Example: Logger, ConfigurationManager, EmailService

• The Logger class manages logging and error handling in the system,
providing functionality to record and track system events.

• The ConfigurationManager class handles system configuration

settings, allowing access to and management of various system
parameters.

• The EmailService class provides functionality for sending emails to

customers, such as order confirmations or notifications.
Unity University 14

•.
A simple example of an e-commerce system Cont.
Persistence Classes:

• Example: ProductDAO, CustomerDAO, OrderDAO

• Persistence classes are responsible for interacting with the database or

data storage to perform CRUD (Create, Read, Update, Delete)
operations on specific entities or tables.

• the persistence classes (ProductDAO, CustomerDAO, OrderDAO) are

responsible for handling the database operations related to their
respective domain classes (Product, Customer, Order).

Unity University 15
A simple example of an e-commerce system Cont.
Interface Classes:

• Example: PaymentGateway, NotificationService

• The PaymentGateway interface class defines a contract that payment

processor classes must implement, specifying methods like
authorizePayment() and processPayment().

• The NotificationService interface class defines a contract for sending

notifications, allowing different notification providers to implement the
interface and send notifications through various channels.

Unity University 16
Class Modeling

• The design class model will reflect the wide variety of

technology decisions you make

• The techniques of analysis class modeling that you learned

still apply. The only difference is your focus is on the
solution domain instead of on the problem domain.

• Introduce change to your class model based on

implementation technologies

• Implement business rules using business rules engine – your

business class will invoke the rule, instead of directly
implementing them in methods
Unity University 17
 Cont.
Modeling Methods during Design

On design class diagrams, indicate the visibility, name,

parameters, return value, and stereotype of methods

Names of parameters, as well as their types and default values

should be indicated for each methods

Scope of a method, weather it is a static method that works on the

class or an instance method, that works on instances of the class
Static Methods are underlined, instance methods are not

Unity University 18
 Cont.
Modeling Methods during Design

Visibility
How a method is accessed by objects

Three levels of visibility

Public, Protected and Private

To reduce coupling within your system, the general rule of thumb
is to be as restrictive as possible when setting the visibility of a
method
A method doesn’t have to be public, then make it protected, if it doesn’t have to be
protected make it private

Unity University 19
 Cont.
Modeling Methods during Design

Visibility

Unity University 20
 Cont.
Modeling Methods during Design

Naming
Use a full description, using mixed case with the first letter of any non
initial word capitalized

“methodName()”

First word – strong action verb

Unity University 21
 Cont.
Modeling Methods during Design

The Student Class with its methods fully modeled

Student
name
phoneNumber
emailAddress
studentNumber
averageMark

+isEligible(name:string, studentNumber:StudentNumber):boolean
+Student(studentNumber: StudentNumber ): Student<<constructor>>
+ getCoursesTaken(): Vector
+ purchaseParkingPass()
+getAverageMark(): long
- setAverageMark(newAverageMark:long)
Unity University 22
 Cont.
Modeling Attributes during design

 Visibility (optional). This is the level of access external objects

have to an attribute, on your class diagrams.

Name. Strategies for naming attributes are similar with methods

Type (optional). The type of an attribute may be a primitive type,

such as string or int, or a class such as Address.

Initial value (optional). The initial value (if any) for an attribute
should also be indicated.

Scope. Static attributes, those with class scope, are underlined.

Instance attributes are not underlined.

Unity University 23
 Cont.
Modeling Attributes during Design

The Student Class with its attributes fully modeled

Unity University 24
Techniques for Attributes Cont.
• Assign private visibility to all attributes;
• Update attributes only in their setter methods;
• Directly access attributes only in their getter methods;
• Always invoke a setter method for an attribute to update its value, even
within the class where it is defined;
• Always invoke a getter method for an attribute to obtain its value, even
within the class where it is defined;
• Implement simple validation logic for an attribute in its setter method;
• Implement complex validation logic in separate methods; and
• Apply lazy initialization in getter methods for attributes that are rarely
needed Unity University 25
Modeling Association and Dependencies Cont.
• Model (don’t) the scaffolding for your associations
• Multiplicity must be shown
• Question multiplicities involving minimums and maximums
• Associations and dependencies are inherited
• Collaboration goes hand in hand with relationships
• Model a unidirectional association when collaboration is
only one way
• Model a dependency when one of the instances is transient
• Model a dependency when an object interacts only with a
class, but not the instance

Unity University 26
State Chart/Machine Modeling

• Some objects are incredibly complicated, so complex that

developers can have difficulty understanding them.

• To understand complex classes better, particularly those that

act in different manners depending on their state, you
should develop state machine diagrams describing how their
instances work.

• UML state machine diagrams depict the various states that

an object may be in and the transitions between those states.

Unity University 27
 Cont.

• A state represents a stage in the behavior pattern of an

object, and like UML activity diagrams it is possible to have
initial states and final states.

• An initial state, also called a creation state, is the one that an

object is in when it is first created.

• A final state is one in which no transitions lead out of.

• A transition is a progression from one state to another and

will be triggered by an event that is either internal or
external to the object.
Unity University 28
 Cont.

• The arrows represent transitions, progressions from one state to another.

• The notation for the labels on transitions is in the format
event [guard][/method list].
It is mandatory to indicate the event which causes the transition.
Guard (conditions that must be true for the transition to be triggered) are optionally
indicated.
Unity University 29
 Cont.

Unity University 30
 Cont.

Unity University 31
 Cont.
Drawing State Machine Diagrams

• Identify the creation state and whether any final states exist.

• What other states or stages in the life of an object does it pass

through?

• Start looking for transitions.

For each state, ask yourself how the object can get out of it

don't forget about recursive transitions that lead to the same state

• Identifying potential error conditions

"should this transition be allowed when the object is in this state?"

Unity University 32
Collaboration/ Communication Diagrams

• Show the behavior of several objects collaborating together to

fulfill a common purpose? Communication diagrams

• They provide a birds-eye view of a collection of collaborating

objects.

• Show the message flow between objects in an OO application and

also imply the basic associations (relationships) between classes.

• The main difference between communication diagrams and

sequence diagrams is that sequence diagrams are good at showing
sequential logic but not that good at giving you a "big picture
view" whereas communication diagrams are the exact opposite.
Unity University 33
 Cont.

• Rectangle – various objects involved that make up the application

• Lines – represent the relationships (associations, aggregation,

composition, dependencies)

• The same notation for classes and objects used on UML sequence
diagrams are used .

• The details of your associations, such as their multiplicities, are not

modeled

• Messages are depicted as a labeled arrow that indicates the direction

of the message.

[sequenceNumber:] methodName(parameters)
Unity University
[: returnValue]
34
 Cont.

Unity University 35
 Cont.

Unity University 36
 Cont.
Drawing Communication Diagrams

• Identify
The scope of the diagram
The objects
The relationships between the objects
The messages passed between the objects

• Draw whenever you want to fully understand the behavior of an

OO application and to show the objects that makeup the
application and the message flow between them

Unity University 37
Component Modeling
• The component model illustrates the software components that will be
used to build the system.

• Component diagrams show the organization and dependencies among a

group of components.

• Architectural-level artifact, used to model the logical architecture of

your technical or business/domain infrastructures.

• Components are modeled as rectangles with two smaller rectangles

jutting out from the left-hand side (UML 1) or not (UML 2)

Implement one or more interfaces, modeled using the “lolipop” notation

Components have dependencies on the interfaces of other components,

modeled using the standard UML dependency
Unity University
notation 38
UML 2.x component diagram for the university. Cont.

Unity University 39
UML 1.x component diagram for the university. Cont.

Unity University 40
Deployment Diagram

• A deployment diagram depicts a static view of the run-time

configuration of processing nodes and the components that run on
those nodes.

• In other words, deployment diagrams show the hardware for

your system, the software that is installed on that hardware,
and the middleware used to connect the disparate machines to
one another.

Unity University 41
deployment diagram for the university information system Cont.

Unity University 42
deployment diagram for the university information system Cont.

Unity University 43
Relational Persistence Modeling

• Useful if you are using relational database

• Used as a mechanism to make your objects persistent

• Different from the design of a class diagram

• Persistence models are often called data models or entity

relationship (ER) models– are used to communicate the design of
a database

Unity University 44
 Cont.
Rules to transform/convert class diagrams to the relational database:

1. Classes are converted/mapped to tables. The attributes become

columns

2. Inheritance:

Map in to a single table(type attribute could be used to differentiate the

two classes)

Map the sub classes in to tables

Map all classes in to tables

Unity University 45
 Cont.
Rules to transform/convert class diagrams to the relational database:

Unity University 46
 Cont.
• Rules to transform/convert class diagrams to the relational database:

3.Mapping relationship:

One-to-one: Maintain through a foreign key in either of the table

One-to-many: Maintained through a foreign key on the many side

Many-to-Many: Maintain it through another intermediate associate table

Unity University 47
 Cont.
• Rules to transform/convert class diagrams to the relational database:

Unity University 48
User Interface Design
• A fundamental reality of application development is that the user
interface is the system to the users.

• Focuses on applying common user interface design principles and

techniques

• Complex task, on that requires a wide range of skills to be successful.

• Developers need to have an understanding of the basics of user

interface design principles

Unity University 49
 Cont.
The structure principle. concerned with your overall user interface
architecture. Putting related things together and separating unrelated
things, differentiating dissimilar things and making similar things
resemble one another.

The simplicity principle. should make simple, common tasks simple to

do, communicating clearly and simply in the user's own language, and
providing good shortcuts

The visibility principle. should keep all needed options and materials
for a given task visible without distracting the user with extraneous or
redundant information.

Unity University 50
 Cont.
The feedback principle. should keep users informed of actions or
interpretations, changes of state or condition, and errors or exceptions

The tolerance principle. allowing undoing and redoing, while also

preventing errors wherever possible

The reuse principle. Your design should reuse internal and external
components and behaviors, maintaining consistency with purpose rather
than merely arbitrary consistency, thus reducing the need for users to
rethink and remember.

Unity University 51
 Cont.
Techniques for improving your UID

Consistency, Consistency, Consistency

Set standards and stick to them

Explain the rules

Support both novices and experts

Navigation between major user interface items is important

Navigation within a screen is important

Word your messages and labels appropriately

Understand your widgets

Look at other application with a grain of salt

Unity University 52
 Cont.
Techniques for improving your UID

Use color appropriately

Follow the contrast rule

Align field effectively

Expect your users to make mistakes

Justify data appropriately

Don't create busy user interfaces

Group things effectively

Unity University 53