Prev: Difference between Design and Architecture
Next: UML Use cases --> Context diagram
From: chandra.somesh on 28 May 2006 03:03
hi

i have been trying to design sequence diagram for the Observer patterns
but have hit a road block....given below is the brief description...

Given below is a single Subject and three observers (for example
sake)...the Subject is responsible for invoking the notify on it self
whenevr its state changes...and then it sends the update() message to
all its observers....

Subject ObserverA ObserverB ObserverC
|--------l
|<------l notify()
|
| update() |
|------------------------->| |
| update() |
|---------------------------------------------------->|
|
| update()
|-------------------------------------------------------------------------->|

Now this sequence diagram is constrainted in a way that..after a
notify..we have subject sending update to ObserverA and then to
ObserverB and then to ObserverC......
I can show the other variants such as A,C,B and B,C,A and B,A,C and
C,A,B and C,B,A and wrap each of them inside an "alt" block .
However this approach will lead to an explosion of "operands" in case
we have more Observers...so i would like to know how better could i
represent the observer patterns SD with all the possible order of
update() messages taken care of ??

Is there some way that UML 2.0 can represent this behavior ??

From: Phlip on 28 May 2006 03:11
chandra.somesh wrote:

> Is there some way that UML 2.0 can represent this behavior ??

Subject Observer(s)
|-------l |
|<------l notify() |
| |
| update() |
|------------------------->|

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


From: chandra.somesh@gmail.com on 28 May 2006 03:23
well the above SD does solve the problem..but what if i need to
represent some messages being passed among individual observers...then
just clubbing the observers as a single object will not be able to
represent that...can we have individual as well as broadcast messages
to be represented using the above representation ??

From: Phlip on 28 May 2006 08:55
chandra.somesh wrote:

> well the above SD does solve the problem..

The SD is only "above" in Google Groups. The majority of the planetary
population doesn't use that. Please, in GG, use Reply -> Preview -> Edit,
and then trim the quotes to form a complete post that could stand alone.

> but what if i need to
> represent some messages being passed among individual observers...then
> just clubbing the observers as a single object will not be able to
> represent that...can we have individual as well as broadcast messages
> to be represented using the above representation ??

Was your only objection that the messages might run out of order from what
the diagram said? UML is not source. (Down, Lahman, down! Sit! Stay!!)

Try this:

Subject ObserverA B C
|-------l | | |
|<------l notify() | | |
| | | |
| update() | | |
|------------------->|..--->|.->|

Instrestingly, this is a question of CORBA at my current work site: Can the
system chain events, so the plumbing layer itself knows a given event will
pass to a list of clients? Can clients modify the event as it goes, in a
known sequence?

If not, then we just manually chain the events. So I guess that would be "C
observes B observing A observing the Subject"...

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


From: H. S. Lahman on 28 May 2006 11:42
Responding to Chandra.somesh...

> i have been trying to design sequence diagram for the Observer patterns
> but have hit a road block....given below is the brief description...
>
> Given below is a single Subject and three observers (for example
> sake)...the Subject is responsible for invoking the notify on it self
> whenevr its state changes...and then it sends the update() message to
> all its observers....
>
> Subject ObserverA ObserverB ObserverC
> |--------l
> |<------l notify()
> |
> | update() |
> |------------------------->| |
> | update() |
> |---------------------------------------------------->|
> |
> | update()
> |-------------------------------------------------------------------------->|
>
> Now this sequence diagram is constrainted in a way that..after a
> notify..we have subject sending update to ObserverA and then to
> ObserverB and then to ObserverC......
> I can show the other variants such as A,C,B and B,C,A and B,A,C and
> C,A,B and C,B,A and wrap each of them inside an "alt" block .
> However this approach will lead to an explosion of "operands" in case
> we have more Observers...so i would like to know how better could i
> represent the observer patterns SD with all the possible order of
> update() messages taken care of ??

You are talking about a more complex problem than Observer addresses.
Observer just makes sure that a change in Subject's state gets
communicated to everyone who cares about that change. Who cares is
defined by the registration process where the ObserverX indicates it
wants to know about a particular state change. The sequence in which
observers are notified is not defined and is not part of the problem
being addressed. IOW, Observer assumes the order of notification is
arbitrary. (Thus a Collaboration Diagram might be a better choice for
describing Observer collaborations.)

However, that is easy enough to address in the registration process
PROVIDED the required sequence is fixed. The usual implementation of
registration is a lookup table for {message ID, observer}. All one
needs to do is register a priority along with the ObserverX and order
the lookup table by priority. One then just "walks" the lookup table in
the normal way looking for observers.

If your problem is more complicated where observers need to be notified
in particular order but the order changes depending on context, then
Observer will not work for you. You will probably need at least one
additional object for defining priorities. (This is potentially a nasty
synchronization problem, especially in a concurrent context.) However,
one way to look at this is that there is a second registration process
that defines the priorities in the paragraph above. (One simplistic
mechanism would be to sort the normal Observer lookup table when a new
set of priorities was assigned.) The trick then is to decide When one
can register a new set of priorities. B-)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



 |  Next  |  Last
Pages: 1 2 3
Prev: Difference between Design and Architecture
Next: UML Use cases --> Context diagram