Sequence Diagram + Method Parameter's Class

[David Rougier]

Hi everyone,

I am designing a sequence diagram.
I have represented a call to an object's method from another object.
The method is offered by the object called object1.
The calling object is object2.
I need to pass two input parameters into the method.
Let's call the parameters parameter1 and parameter2.
parameter1 is an instance from ClassA.
parameter2 is an instance from ClassB.
I have represented the call to the method as follows :

|--------------------------| |--------------------------|
| object1 : ClassC | | object2 : ClassD |
|--------------------------| |--------------------------|
| method(parameter1, parameter2) |
|-----------------------------------------------------------------------------
>|
| |
| |
| |
| |

How can I represent the parameters' class regarding the UML2
notations.

In addition, I would like to know if there is a way to to represent
the parameters' class via the modeling tool StarUML.

Thanks in advance for your future help.

[RJB]

The usual way
object : Class
like this
method(parameter1:ClassP1, parameter2:ClassP2)

Hope this helps.

[H. S. Lahman]

Responding to Rougier...

	|--------------------------|				|--------------------------|
	| object1 : ClassC |				| object2 : ClassD |
	|--------------------------|				|--------------------------|
		|	method(parameter1, parameter2)		|
		|-----------------------------------------------------------------------------

|

		|					|
		|					|
		|					|
		|					|

When doing text diagrams in email where the mailer tool assumes HTML, there are some things you can do to avoid this distortion.

Surround the diagram with <pre>...</pre> to prevent the sender or receiver mailer from reformatting to its default style

Use a fixed font for the diagram. Preferably, use a very common fixed font that will usually be available on most computers. (If the receiver mailer can't find the fixed font the sender used, it may revert to its overall default font, which is usually variable.)

Don't use tabs; the number of spaces is far from standard.

Check out your mailer's formatting options for email. There may be ways to avoid problems by modifying the default settings.

How can I represent the parameters' class regarding the UML2
notations.

First, remember the SD is meant to provide a high level view of flow of control. It is not meant to specify the details of dynamic design. If you are passing objects around in messages, the relevant class will be clear wherever the message is formed (i.e., in the specification of the sending method).

Second, Don't Do That! B-)

Sending object references in messages is the worst form of coupling. To minimize coupling, messages should be simple by-value data transfers. In addition, it allows abuses of the object (e.g., deleting it when it is still needed elsewhere) far from the context where it exists and was selected. Generally the only objects you want to send in messages are computing space data holders like String and Array where the class is hidden behind an attribute ADT.

In fact, methodologically one should avoid passing any data in messages in OOA/D except in collaborations between subsystems. In the OO paradigm object methods are expected to access the knowledge attributes they need directly (synchronously)  on an as-needed basis. There are two good reasons for this.

It ensures the timeliness of the data in situations where the OOP implementation may be distributed, concurrent, or whatever. In such situations there may be arbitrary delays between when a message is generated and when it is consumed. However, if the method goes and gets the data synchronously in the OOA/D, at OOP time one can do whatever is necessary to ensure the processing works as if it were instantaneous access (e.g., providing things like locking when the method starts).

This segues to the next and more important reason. When a method directly accesses the data that defines the scope of data and referential integrity issues to a single method. When data is passed in messages, that scope expands to include the sending method and any intermediate methods through which the data passed. If the application executes in distributed, multi-tasking, asynchronous, multi-user, or concurrent environments, this becomes enormously important in managing complexity. If the OOA/D already narrows the scope by requiring methods to access their data, the design will be far more robust and easier to implement at the OOP level.

General rule: the only time behavior messages between collaborating objects should carry data is when the requirements explicitly define the need for a "snapshot". A classic example is sampling where one needs to collect data from multiple sensors and the data from a single time slice must be processed together.

P.S., if you are worried about cluttering your SD with all those method getters, don't be. By convention one does not show knowledge accesses on the UML interaction diagrams. The interaction diagrams describe dynamic flow of control while knowledge access is regarded as static access (i.e., the calling method already implicitly defines When the data is accessed through its own dynamic invocation).

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html