Re: basic q about sequence diagrams

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 03/18/04 

Date: Thu, 18 Mar 2004 20:03:42 GMT

Responding to Hungus...

>>>A user wants to know how many, so enquires from the system, by sending
>>>a 'how many passengers do you have?' message to the car.
>>>
>>>so the answer is:
>>>[system] ------getPassengers----->[car]
>>
>>Taken literally, that would not be a good practice. If all the client
>>cares about is the number of passengers, it doesn't need the passengers
>>themselves to determine that. It should ask for only what it does need,
>>which is a count. Which is why giving [Car] a public responsibility for
>>knowing how many passengers it has is reasonable.
>
>
> in my original example, I just wanted to return a collection of passengers.
> Assuming the system manipulates some attributes of the passengers outside
> the context of car, I would think its ok (to do that in system). I agree the
> car should keep count of its passengers.

My gut instinct here (without knowing anything more about the problem!)
is: Don't Do That! More precisely: Don't Think Like That!

Relationship navigation is orthogonal to class semantics. If [System]
needs to access to [Passengers] it should navigate directly to them via
an appropriate relationship path. That's why in my Sequence Diagram
example a Cop sends a message to Passenger rather than Car. If the path
to deliver that message happens to go through [Car], that is serendipity
in the problem space structure.

The notion of Car returning a set of Passengers only becomes relevant
when encoding the relationship navigation implementation at the OOP
level. That doesn't really depend upon Car or even the semantics of
'passenger'. When manually building code we would use a meaningful name
like getPassengers and use appropriate types because we have to live
with the code.

But a translation quality automatic code generator would employ a
generic collection class returning Object* references and would create
an attribute "GenericCollection* R2;" in [Car] to support the
navigation. Ugly but thoroughly independent of the class semantics.
(Fortunately, translationists never have to see the code; they just
rebuild it if something changes in the OOA model.)

Regardless of translation vs. elaboration of how one implements things,
one should think of the navigation as peer-to-peer (i.e., System to
Passenger) throughout the construction. That is, conceptually the
problem solution shouldn't depend on Car doing anything in that
collaboration.

In contrast, once one defines the number of Passengers to be a
reasonable knowledge responsibility of Car, then System can navigate
there when it needs to know the number of Passengers rather than
navigating to the Passengers and counting them. IOW, the allocation of
responsibilities now supports a direct collaboration between System and
Car -- for that particular responsibility.

>
> Another more general question is, do you feel that sequence diagrams should
> avoid method-like names in the messages? or is this another example of
> conceptual vs specification vs implementation diagrams.

Since a Sequence Diagram is an OOA/D model, one should honor the
separation of message and method in OOA/D. So one should identify the
message on the horizontal lines in the Sequence Diagram rather than the
method that responds to it. Messages usually announce something that
happened in the sender (i.e., state of the execution somehow changed),
so they tend to reflect the sender perspective.

However, that assumes one has separated message and method.
Conventionally most people do not in a UML model. That's mainly because
most people do not separate the Interface (the lollipop symbol) from the
Class in a Class Diagram because it tends to clutter things badly when
the mapping is 1:1. [One maps message to method in the Interface, as in
Signal to Reception.]

Though I am a strong advocate of the conceptual separation of message
and method in OO construction, I am ambivalent about doing so explicitly
in the Class Diagram. That's simply because the UML notation for the
mapping is pretty clutzy. The important thing is to construct methods
_as if_ message and method are separated so that implementation
dependencies are prevented.

That's one reason why I jumped all over the notion of Car returning a
set of Passengers above. It is important to keep the right mindset if
one is going to "short-cut" the diagramming for message and method.
Similarly, when encoding getPassengers at the OOP level, one needs to be
very clear that it is to provide program readability rather than an
allocation of some problem space responsibility to Car. That ensures
that however one actually implements the navigation, it will behave as
if System and Passenger talked directly to one another with no Car in
the picture at all.

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

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages

  • Re: basic q about sequence diagrams
    ... and the Client needs to collaborate with the Car's Passengers. ... Client sends a message directly to each Passenger. ... "Collection* R2" in [Car] that only a code generator could love. ... That seems like a reasonable responsibility of. ...
    (comp.object)
  • Re: I bet hes Polish
    ... It became compulsory in Britain in September last year for passengers & a number of years ago for drivers & crew sitting in the crew seats. ... It is, however, virtually unenforceable, as it is the driver's responsibility to warn the passengers of the requirement, but he isn't responsible for enforcement of wearing of belts by passengers over 14, & by the time a police officer has boarded to check compliance, the vehicle is stationary, so there is no requirement to wear the belt. ... For passengers under 14, the responsible adult in charge of the child is responsible for failure to wear the belt, as in a car. ...
    (uk.transport.buses)
  • Re: Retrieving unnecessary data
    ... Pretend I am modeling a Car. ... Typically that would be done with a collection class and would have a reference to the collection class. ... If no one but ever needs to know about passengers, then that reference could be private or the collection class instance could be an embedded object in 's implementation. ... If the solution needs both then an interface method would provide that. ...
    (comp.object)
  • Re: Mass Transit
    ... What about passengers, then (since I am almost always a passenger ... a car, bus, train, plane, etc., is very different from driving one. ... Yet a passenger in a car can do useful things to help the driver, ... show how you will route transit to where presently non served by any ...
    (rec.arts.sf.fandom)
  • Re: Minibus hire company backs out of arrangement.
    ... I didn't think I was proposing to use the vehicle for hire or reward. ... people who use their car to take ... Your policy covers you for carrying passengers for social or similar ...
    (uk.legal)