Ooad Session 11

Session - 11
Dr. K. SATYANARAYAN REDDY

Object Oriented Analysis and
Design using UML
Designing for Visibility
Objectives
Identify four kinds of visibility
Design to establish visibility
Illustrate kinds of visibility in the UML notation
July 30, 2014 3
BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy
Introduction
Q. What is visibility?
A. Visibility is the ability of one object to see or
have reference to another.
July 30, 2014 4
Visibility Between Objects
Q. When is visibility necessary?
A. To send a message from one object to
another, the receiver object must be visible to
the sender, so the sender has to have a
pointer or reference to the receiver.
July 30, 2014 5
Visibility Between Objects
Example:
Q. If A sends messages to B, which must be
visible to which?
A. B is visible to A means A can send a
message to B.
Some say that "B is an acquaintance of A".
July 30, 2014 6
Visibility
Visibility is related to the scope:
Is one resource (such as an instance) within the scope
of another?
The motivation to consider visibility:
For an object A to send a message to an object B, B
must be visible to A.
July 30, 2014 7
Four Kinds of Visibility
How visibility can be achieved from object A
to object B:
Attribute visibility - B is an attribute of A
Parameter visibility - B is a parameter of a method of A
Local visibility - B is a local object in a method of A
Global visibility - B is in some way globally visible
July 30, 2014 8
Attribute Visibility
Attribute visibility from A to B exists when B is
an attribute of A
Relatively permanent visibility because it persists as
long as A and B exist
Common form of visibility
public class Register
{
private ProductCatalog Catalog;
}
July 30, 2014 9
Parameter Visibility
Parameter visibility from A to B exists when B is
passed as a parameter to a method of A.
Relatively temporary visibility because it persists only
within the scope of the method
The 2
nd
most common form of visibility in the OO
systems
July 30, 2014 10
Local Visibility
Local visibility from A to B exists when B is
declared as a local object within a method of
A.
Relatively temporary visibility since it persists only
within the scope of the method.
July 30, 2014 11
Local Visibility
There are two common means by which
local visibility is achieved:
Create a new local instance and assign it to a
local variable.
Assign the returning object from a method
invocation to a local variable. A variation of
this method does not explicitly declare a
variable, but one implicitly exists as the result
of a returning object from a method
invocation
Ex:
anObject.getAnotherObject.doSomething()
;
July 30, 2014 12
Global Visibility
Global visibility from A to B exists when B is
global to A.
Relatively permanent visibility since it persists as long
as A and B exist.
The least common form of visibility in OO Systems.
July 30, 2014 13
Global Visibility
Ways to achieve global visibility:
Assign an instance to a global variable.
Use the Singleton pattern
July 30, 2014 14
Singleton Pattern (Gang of Four)
Problem:
Exactly one instance of a class is needed. Objects
need a single point of access.
Solution:
Define a class method that returns the singleton
object, instantiating it if it does not exist.
Example:
A print queuemany programs must access one
queue
July 30, 2014 15
Visibility in the UML
Public:
Any outside classifier with visibility to the given
classifier can use the feature; specified by pre-
pending the symbol +
Protected:
Any descendant of the classifier can use the
feature; specified by pre-pending the symbol #
Private:
Only the classifier itself can use the feature;
specified by pre-pending the symbol -
July 30, 2014 16
Terms: Classifier
A classifier is a mechanism that describes
structural and behavioral features.
Modeling elements that can have instances
are called classifiers.
Classifiers include classes, interfaces,
datatypes, signals, components, nodes, use
cases, and subsystems.
A classifier has structural feature (in the form
of attributes), as well as behavioral features
(in the form of operations).
July 30, 2014 17
Terms: Feature
A feature is a property, such as operations or
attributes that is encapsulated within entity
such as an interface, a class, or a datatype.
July 30, 2014 18
Applying
GOF Design Patterns
Objectives
Study GOF design patterns
to the design OO system.
July 30, 2014 20
Introduction
The following GOF design patterns are
explored in the subsequent sections :
Adapter
Factory
Singleton
Strategy
Composite
Facade
observer
July 30, 2014 21
Adapter(GOF)
Context/problem
How to resolve incompatible interfaces or provide a
stable interface to similar components with different
interfaces?
Solution
Convert the original interface of a component into
another interface through an intermediate adapter
object.
July 30, 2014 22
The Adapter Pattern
Adapters use interfaces and polymorphism
to add a level of indirections to varying APIs
in other components.
July 30, 2014 23
Protected Variations, Low Coupling,
Polymorphism,Indirection helps us to view through
the myriad details and see the essential alphabet of
design techiques being applied.
Naming Convention has the advantage of easily
communicating to others reading the code or
diagrams what design patterns are being used.
Using An Adapter
July 30, 2014 24
Factory(GOF)
Context/Problem
Who should be responsible for creating
objects when there are special
considerations, such as complex logic,a
desire to separate the creation
responsibilities for better cohesion, and so
forth
Solution
Create a Pure Fabrication object called a
Factory that handles the creation
July 30, 2014 25
Advantages of Factory Objects
Separate the responsibility of complex
creation into cohesive helper objects.
Hide potentially complex creation logic
Allow introduction of performance-
enhancing memory management
strategies,such as object caching or
recycling.
July 30, 2014 26
Singleton(GOF)
The Factory raises a new problem in the design:
Who creates the factory itself?
How is it accessed?
One solution is pass the Factory instance around as
a parameter to wherever a visibility need is
discovered for it, or to initialize the objects that need
visibility to it,with a permanent reference.
Alternative is Singleton pattern.
July 30, 2014 27
Solution
Define a static method of the
class that returns the singleton.
With this approach, a developer
has global visibility to this
single instance,via the static
getInstance method of the
class.
July 30, 2014 28
Preferred Methods
Instance-side methods permit subclassing
and refinement of the singleton class into
subclasses.
Most object-oriented remote
communication mechanisms only support
remote-enabling of instance methods,not
static methods.
A class is not always a singleton in all
application contexts.
July 30, 2014 29
Strategy(GOF)
Context/Problem
How to design for varying, but related,algorithms or
policies?
How to design for the ability to change these
algorithms or policies
Solution
Define each algorithm/policy/strategy in a separate
class, with a common interface
July 30, 2014 30
Strategy in Collaboration
A strategy object is attached
to a context object- the
object to which it applies
the algorithm.
In this example the context
object is a sale.
July 30, 2014 31
Creating a strategy with a factory
There are different pricing algorithms or
strategies, and they change over time.
Who should create the strategy?
A straight forward approach is to apply the
Factory pattern again: a
PricingstrategyFactory can be
responsible for creating all strategies
needed by the application.
July 30, 2014 32
Creating a Strategy
July 30, 2014 33
Protected Variations with respect to
dynamically changing pricing
policies has been achieved with
the Strategy and Factory patterns.
Strategy builds on Polymorphism
and interfaces to allow pluggable
algorithms in an object design.
Creating a Strategy(2)
July 30, 2014 34
Composite(GOF) and other Design Principles
Context/Problem
How to treat a group or composition of objects the
same way(polymorphically) as a non-
composite(atomic object)?
Solution
Define classes for composite and atomic objects so
that they implement the same interface.
July 30, 2014 35
Understanding composite (GOF) with an example
Suppose a store has the following
policies in effect for a particular day:
20% senior discount policy.
Preferred customer discount of 15% off
sales over $400.
On day,there is $50 off purchases over
$500.
Buy 1 case of Darjeeling tea, get 15%
discount off of everything.
July 30, 2014 36
Problem
Suppose a senior who is also
a preferred customer buys 1
case of Darjeeling tea, and
$600 of veggieburgers.
What pricing policy should be
applied?
July 30, 2014 37
Solution using conflict resolution strategy
In this strategy a store applies the
following:
Best for the customer (lowest
price)
Highest pricing strategy (during a
difficult financial period)
July 30, 2014 38
Multiple Co-Existing Strategies
One sale may have several
pricing strategies
Pricing strategy can be related
to the type of customer
Pricing strategy can be related
to the type of product being
brought
July 30, 2014 39
Multiple co-existing strategies(2)
The Product Specification must be known by
the StrategyFactory at the time of creation
of a pricing strategy influenced by the
product.
Is there a way to change the design so that
the Sale object does not know if it is dealing
with one or many pricing strategies, and
offer a design for the conflict resolution?
And the answer is yes, with the composite
pattern.
July 30, 2014 40
Collaboration with a Composite
In this the Sale does not
know or care if its pricing
strategy is an atomic object
or a composite strategy that
is it looks the same to the
Sale object.
July 30, 2014 41
Creating Multiple Sale Pricing Strategies
There are three points in the scenario
where pricing strategies may be
added to the composite:
Current store-defined discount,added
when the sale is created.
Customer type discount,added when the
customer type is communicated to the
POS.
Product type discount added when the
product is entered to the sale.
July 30, 2014 42
Creating a Composite Strategy for the First Case.
July 30, 2014 43
Creating a Process sale for the Second Case
Use case UCI: Process Sale
Extensions (or Alternative Flows)
Customer says they are eligible for a discount (e.g
employee, preferred customer)
Cashier signals discount request.
Cashier enters Customer identification
System presents discount total, based on
discount rules.
July 30, 2014 44
Creating a Pricing Strategy for a Customer
Discount
July 30, 2014 45
Note
Although this application of composite
was to a strategy family, the
Composite pattern can be applied to
other kinds of objects
For example, it is common to create
"macro commands " - commands
that contain other commands -
through the use of Composite.
July 30, 2014 46
Note(2)
Composite is often used with the
Strategy and Command Patterns.
Composite is based on
Polymorphism and provides
Protected Variations to a client so
that it is not impacted if its related
objects are atomic or composite.
July 30, 2014 47
Facade(GOF)
Context/Problem
A common, unified interface to a
disparate set of implementations or
interfaces- such as within a subsystem-
is required. There may be undesirable
coupling to many things in the
subsystem, or the implementation of
the subsystem may change.
What to do?
July 30, 2014 48
Faade(GOF) (2)
Solution
Define a single point of contact to
the subsystem- a facade object that
wraps the subsystem. This facade
object presents a single unified
interface and is responsible for
collaboration with the subsystem
components.
July 30, 2014 49
Facade
A Facade is a front-end object that is the
single point of entry for the services of
a subsystem; the implementation and
other components of the subsystem
are private and can't be seen by
external components.
Facade provides Protected Variations
from changes in the implementation of
a subsystem.
July 30, 2014 50
Example for a Facade
Define a rule engine subsystem, whose
specific implementation is not yet known.It
will be responsible for evaluating a set of
rules against an operation, and then
indicating if any of the rules invalidated the
operation.
The facade object to this subsystem will be
called POSRuleEngineFacade.
The designer decides to place calls to this
facade near the start of the methods that
have been defined as the points for
pluggable rules.
July 30, 2014 51
Explanation
With this design, the complexity and
implementation of how rules will be
presented and evaluated are hidden in the
rules engine subsystem. Accessed through
the POSRuleEngineFacade facade.
The subsystem hidden by the facade object
could contain dozens or hundreds of
classes of objects, or even a non-object-
oriented solution, yet as a client to the
subsystem one can see only its one public
access point.
July 30, 2014 52
Summary of Facade Objects
Facades are often accessed
through singleton.
The facade pattern is simple,
and widely used.
It hides a subsystem behind
an object.
July 30, 2014 53
UML Package Notation
July 30, 2014 54
Observer/Publish-Subscribe/ Delegation Event
Model
Context/Problem
Different kinds of subscriber objects are
interested in the state changes or
events of a publisher object, and want
to react in their own unique way when
the publisher generates an event.
Moreover, the publisher wants to
maintain low coupling to the
subscribers.
July 30, 2014 55
Solution
Define a subscriber or Listener
interface.
Subscribers implement this
interface.
The publisher can dynamically
register subscribers who are
interested in an event, and notify
when an event occurs.
July 30, 2014 56
The Observer Pattern
Observer Is not only for connecting
UIs and Model Objects but also
used for GUI widget event
handling in both Java technology
and Microsoft's .Net.
One publisher can have many
subscribers for an event.
July 30, 2014 57
Observer
Observer provides a way to loosely
coupled objects in terms of
communication.
Publishers know about subscribers
only through an interface, and
subscribers can register
dynamically with the publisher.
July 30, 2014 58
Conclusion
Objects can be designed and
responsibilities assigned with
the support of patterns.
They provide an explainable set
of idioms by which well
designed object-oriented
systems can be built.
July 30, 2014 59
THANK YOU
July 30, 2014 BITS-WASE OOAD Session 11: By Dr. K. Satyanarayan Reddy
60

Ooad Session 11

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ooad Session 11

Загружено:

Авторское право:

Доступные форматы

Session - 11

Dr. K. SATYANARAYAN REDDY

Вам также может понравиться