unit-iv&v OOAD

8/10/2019 unit-iv&v OOAD

1/23

UNIT IV

GRASP:

GRASP stands for General Responsibility Assignment Software Patterns , used for

assigning responsibilities to software classes.

The different patterns and principles used in GRASP are: Information Epert! "reator!"ontroller! #ow "oupling! $igh "ohesion! Pol%morphism! Pure &abrication! Indirection

and Protected 'ariations.

i! "R#AT$R PATT#RN:

"reator pattern is responsible for creating an ob(ect of class.

Problem: Who should be responsible for creating a new instance of some class?

Solution: Assign class B the responsibility to create an instance of class A if one of

these is true (the more the better):

B contains or compositely aggregates A.

B records A.

B closely uses A.

B has the initializing data for A that will be passed to A when it is crated. hus

B is an !"pert with respect to creating A.

A perfect e"ample is adding a new #ata$ow to a #ataable. o get a new row% youas& the #ata able to create a new #ata$ow for you and then add the row to the

table.

#ata $ow my$ow ' myable.ew$ow()

...

myable.$ows.Add(my$ow)

Since the Sale ob(ect contains the Sales#ineItem! the Sale is a good candidate for this

responsibilit%


2/23

(ii) INFORMATION EXPERT:

Problem : )hat is a general principle of assigning responsibilities to ob(ects*

Solution: Assign a responsibilit% to the information epert + a class that has the

information necessar% to fulfill the responsibilit%.

Start assigning responsibilities b% clearl% stating the responsibilit%.

Eample

o )ho should be responsible for ,nowing the grand total of a sale*

-% Information epert! we should loo, for the class of ob(ects that has the

information needed to determine the total.

)here to loo,*

o esign model

o omain model

The s%stem must calculate a grand total of the items in the sale. $ow would %ou assignthe responsibilities*

After appl%ing Information Epert to this problem we end up with a solution shown in

the following collaboration diagram:


3/23

(iii). CONTROLLER:

A "ontroller is a non+user interface ob(ect responsible for recei/ing or handling a

s%stem e/ent. It defines methods for s%stem operation.

Problem :

o )ho should be responsible for handling an input s%stem e/ent*

Solution

o Assign the responsibilit% for recei/ing or handling a s%stem e/ent message to a

class representing one of the following choices:

Represent the o/erall s%stem! de/ice! or subs%stem

Represents a use case scenario within which the s%stem e/ent occurs

P0S Eample

o )ho should be controller for s%stem e/ents such as enterItem and endSale*

.


4/23

(iv) LOW COPLIN!:

"oupling is a measure of how strongl% one element is connected to! has ,nowledge

of! or relies on other element.

Problem:

o $ow to support a low dependenc%! low change impact! and increased reuse*

Solution:

o Assign a responsibilit% so that coupling remains low.

P0S Eample

o Assume we ha/e a need to create a Pa%ment instance and associate it with the

Sale.o )hat class should be responsible for this*

P$S #%ample "lasses

Is It a Goo& Sol'tion(

A better sol'tion: Sale )reate Payment


5/23

V! *IG* "$*#SI$N:

"ohesion is a measure of how strongl% related and focused are the responsibilities of

an element.

$igh "ohesion: An element with highl% related responsibilities! and which does not

do a tremendous amount of wor,! has high cohesion.

Problem:

o $ow can compleit% be ,ept manageable*

Solution:

o Assign responsibilit% so that cohesion remains high.

P0S Eample

o Assume we ha/e a need to create a Pa%ment instance and associate it with the

Sale.o )hat class should be responsible for this*

P$S +omain "lasses

Is it a goo& Sol'tion(


6/23


7/23

$ow /isibilit% can be achie/ed from ob(ect A to ob(ect -:

o Attribute /isibilit% 3 - is an attribute of A

o Parameter /isibilit% 3 - is a parameter of a method of A

o #ocal /isibilit% 3 - is a local ob(ect in a method of A

o Global /isibilit% 3 - is in some wa% globall% /isible

Attrib'te Visibility

Attribute /isibilit% from A to - eists when - is an attribute of A

o Relati/el% permanent /isibilit% because it persists as long as A and - eist

o "ommon form of /isibilit%

public class Register{

private ProductCatalog Catalog;

}

Attrib'te Visibility

Parameter Visibility

Parameter /isibilit% from A to - eists when - is passed as a parameter to a

method of A.

o Relati/el% temporar% /isibilit% because it persists onl% within the scope of

the method

o The 4nd most common form of /isibilit% in the 00 s%stems


8/23

Patameter Visibility

It is common to transform parameter /isibilit% into attribute /isibilit%.

-o)al Visibility

#ocal /isibilit% from A to - eists when - is declared as a local ob(ect within a

method of A.o Relati/el% temporar% /isibilit% since it persists onl% within the scope of

the method.

There are two common means b% which local /isibilit% is achie/ed:

o "reate a new local instance and assign it to a local /ariable.

o Assign the returning ob(ect from a method in/ocation to a local /ariable. A

/ariation of this method does not eplicitl% declare a /ariable! but oneimplicitl% eists as the result of a returning ob(ect from a method

in/ocation

E: an0b(ect.getAnother0b(ect.doSomething567

-o)al Visibility


9/23

Global Visibility

Global /isibilit% from A to - eists when - is global to A.

o Relati/el% permanent /isibilit% since it persists as long as A and - eist.

o The least common form of /isibilit% in 00 S%stems.

)a%s to achie/e global /isibilit%:

o Assign an instance to a global /ariable.

o 8se the Singleton pattern

Singleton Pattern 5Gang of &our6

o Problem:

Eactl% one instance of a class is needed. 0b(ects need a single

point of access.

o Solution:

efine a class method that returns the singleton ob(ect!

instantiating it if it does not eist.

o Eample:

A print 1ueue9man% programs must access one 1ueue


10/23


11/23

Gang 0f &our Pattern

i6 Singleton Pattern

ii6 Adopter Pattern

iii6 0bser/er Pattern

i/6 &actor% Pattern

i) SIN!LETON PATTERN:

Problem:

Eactl% one instance of a class is allowed + it is a singleton;.

0b(ects need global and single point of access.

Solution:

efine a static method of the class that returns the singleton.

)ith this approach! a de/eloper has global /isibilit% to this single instance!

/ia the static getInstance method of the class.

ii) A"OPTER PATTERN:

"ontet=problem

o $ow to resol/e incompatible interfaces or pro/ide a stable interface to

similar components with different interfaces*

Solution

o "on/ert the original interface of a component into another interface

through an intermediate adapter ob(ect.


12/23

Eample: ifferent Ta "alculators

Using An A&aptor

iii) FACTOR PATTERN:

Problem:

o )ho should be responsible for creating ob(ects when there are special

considerations! such as comple logic!a desire to separate the creation

responsibilities for better cohesion! and so forth

)ho should responsible for the creating of the adapters* "reate

which one*


13/23

If some domain ob(ect creates them! the responsibilities of the

domain ob(ect are going be%ond pure application logic and into

other concerns related to connecti/it% with eternal softwarecomponents.

Solution:

o "reate a Pure &abrication ob(ect called a &actor% that handles the

creation

Eample:

1a)tory Pattern

Ad/antages of &actor% 0b(ects

o Separate the responsibilit% of comple creation into cohesi/e helper

ob(ects.o $ide potentiall% comple creation logic

o Allow introduction of performance3enhancing memor% management

strategies!such as ob(ect caching or rec%cling.

iv) OSER*ER PATTERN

0bser/er Is not onl% for connecting 8Is and >odel 0b(ects but also used for

G8I widget e/ent handling in both ?a/a technolog% and >icrosoft@s .et.

0ne publisher can ha/e man% subscribers for an e/ent.


14/23


15/23

UNIT V


16/23

"omponent an& +eployment +iagrams :

"omponent +iagram: The component diagram@s main purpose is to show the structural relationships

between the components of a s%stem. BI-> Rational #ibrariesC 8># component diagrams are great for identif%ing the architectural landscape for

%our s%stem as the% enable %ou to model the high3le/el software components! and

more importantl% the interfaces to those components. BAgile >odelingC A component diagram pro/ides a ph%sical /iew of the s%stem. Its purpose is to

show the dependencies that the software has on the other software components

5e.g.! software libraries6 in the s%stem. The diagram can be shown at a /er% highle/el! with (ust the large3grain components! or it can be shown at the component

pac,age le/el.

>odeling a component diagram is best described through an eample. &igure

below shows four components: Reporting Tool! -illboard Ser/ice! Ser/let 4.4

API! and ?-" API. The arrowed lines from the Reporting Tool component to the-illboard Ser/ice! Ser/let 4.4 API! and ?-" API components mean that the

Reporting Tool is dependent on those three components.

"omponent iagram Eample in 8>#


17/23

+eployment +iagram :

The deplo%ment diagram shows how a s%stem will be ph%sicall% deplo%ed in the

hardware en/ironment. Its purpose is to show where the different components of

the s%stem will ph%sicall% run and how the% will communicate with each other.Since the diagram models the ph%sical runtime! a s%stem@s production staff will

ma,e considerable use of this diagram.

The notation in a deplo%ment diagram includes the notation elements used in a

component diagram! with a couple of additions! including the concept of a node.

A node represents either a ph%sical machine or a /irtual machine node 5e.g.! a

mainframe node6. To model a node! simpl% draw a three3dimensional cube withthe name of the node at the top of the cube. 8se the naming con/ention used in

se1uence diagrams.

The component diagram is one of the easier3to3understand diagrams! so there is

not much to co/er be%ond the basics.

There will be times when it ma,es sense to displa% a component@s internalstructure. To show a component@s inner structure! %ou merel% draw the component

larger than normal and place the inner parts inside the name compartment of theencompassing component. &igure below! show@s the Store@s component inner

structure.


18/23

0apping +esign to )o&e:

+efining a "lass wit meto&s an& simple attrib'te

efining a "lass with methods and simple attribute

1ig're 45676 #%ample Implementation

"reating 0eto&s form Intera)tion +iagrams

Interaction iagrams and 0peration "ontracts are used to specif% methods. The% gi/e most of the details for what the method does. It is usuall% best to ha/e a

Sub(ect >atter Epert a/ailable to answer 1uestions about implementation details.

#nter Item Intera)tion +iagram


19/23

#nterItem +"+ #%ample

"reating 0eto&s from Intera)tion +iagrams

"ontainers an& "olle)tions

)here an ob(ect must maintain /isibilit% to a group of other ob(ects! such as a

group of Sales #ine Items in a Sale! ob(ect3oriented languages often use an

intermediate container or collection.

These will be suggested b% a multiplicit% /alue greater than one on a class

diagram.


20/23


21/23

#%ample or&er of Implementation

$P#RATI$N "$NTRA"TS:

A 8># 0peration contract identifies s%stem state changes when an operationhappens. Effecti/el%! it will define what each s%stem operation does. An operation is

ta,en from a s%stem se1uence diagram. It is a single e/ent from that diagram. Adomain model can be used to help generate an operation contract. The domain modelcan be mar,ed as follows to help with the operation contract:

Green 3 Pre eisting concepts and associations.

-lue 3 "reated associations and concepts.

Red 3 estro%ed concepts and associations.

$peration "ontra)t Synta%

ame: appropriateame

Responsibilities: Perform a function

"ross References: S%stem functions and 8se "ases

Eceptions: none

Preconditions: Something or some relationship eists

Postconditions: An association was formed


22/23

STATE DIAGRAM

State diagrams 5also called State "hart diagrams6 are used to help the de/eloper

better understand an% comple=unusual functionalities or business flows of specialiDed

areas of the s%stem. In short! State diagrams depict the d%namic beha/ior of the entires%stem! or a sub3s%stem! or e/en a single ob(ect in a s%stem. This is done with the help of

Behavioral elements.

Defining a State diagram

?ust as we define classes for a "lass diagram! it is necessar% to define the

elements of a State diagram. #et us first see what the elements of a State diagram are.

Elements of a State diagram

A State diagram consists of the following behavioral elements:

Element and its Description Symbol

Initial State:This shows the starting point or first activity of the flow.

Denoted by a solid circle. This is also called as a "pseudo state,"

where the state has no variables describing it further and no activities.

State:Represents the state of obect at an instant of time. !n a state

diagram, there will be multiple of such symbols, one for each state of

the bect we are discussing. Denoted by a rectangle with rounded

corners and compartments #such as a class with rounded corners to

denote an bect$. %e will describe this symbol in detail a little later.

Transition:An arrow indicating the bect to transition from one state

to the other. The actual trigger event and action causing the transition

are written beside the arrow, separated by a slash. Transitions that

occur because the state completed an activity are called "triggerless"

transitions. !f an event has to occur after the completion of some event

or action, the event or action is called the guard condition. The

transition ta&es place after the guard condition occurs. This guard

condition'event'action is depicted by s(uare brac&ets around the

description of the event'action #in other words, in the form of a )oolean

e*pression$.


23/23

History States:A flow may re(uire that the obect go into a trance, or

wait state, and on the occurrence of a certain event, go bac& to the

state it was in when it went into a wait state+its last active state. This

is shown in a State diagram with the help of a letter enclosed within

a circle.

Event and Action:A trigger that causes a transition to occur is called

as an event or action. -very transition need not occur due to the

occurrence of an event or action directly related to the state that

transitioned from one state to another. As described above, an

event'action is written above a transition that it causes.

Signal:%hen an event causes a message'trigger to be sent to a state,

that causes the transition then, that message sent by the event is

called a signal. Represented as a class with the //Signal00 icon

above the action'event.

inal State:The end of the state diagram is shown by a bull1s eye

symbol, also called a final state. A final state is another e*ample of a

pseudo state because it does not have any variable or action

described.

"hanges in the s%stem that occur! such as a bac,ground thread while the main process is

running! are called 2s'b states.2 E/en though it affects the main state! a sub state is not

shown as a part of the main state. $ence! it is depicted as contained within the main state

flow.

As %ou saw abo/e! a state is represented b% a rectangle with rounded edges. )ithin a

state! its ame! /ariables! and Acti/ities can be listed as shown in &igure .

The structure of the state element

unit-iv&v OOAD

Documents