How Objects Interact

Within the world of OOAD, the interaction of objects will occur within patterns, and these patterns may be broken down into two categories, which are different because of the roles which are associated with the participants.

The first of these patterns is the event producer object and one or more objects which are connected to the event consumer. The consumer interaction which is associated with the producer may make use of communication which is one-way.

Some examples of this include the items on a menu, a buyer requesting a specific product from a supplier, or a generator for reports which sends reports to the printer. It is possible for the event to have many consumers. For instance, the stock quotation could be broadcast for every party which is interested.

The second pattern is the server object along with the client object. The interaction of the client with the server must make use of synchronized communication which is bidirectional. The client must request that the operation be carried out via the server, and will need to wait for the reply.

The reply and the request may be comprised of data which is transmitted. The pattern may be seen in standard service procedures or the invocations for the functions.

The bidirectional patterns tend to be wildly popular within OOA, and one reason for this is because they take the time to map the interaction mechanisms that exist among the objects, which are associated with many object oriented programming languages. This can sometimes cause terminology mismatches.

You may sometimes think that the message passing phenomenon which is found within many object oriented programming languages may correspond to an asynchronous interaction which is one directional.

However, this is in fact not true. In contrast, the languages like C++ will have messages which are synchronized for bidirectional procedures and invocations. When it comes to bypassing these connotations, you may sometimes make use of the expression "event" as opposed to "message" for encompassing the different interactive styles or variants.

Another thing that you must always take into consideration are the transitions. The notation for transition places a heavy emphasis on the properties for behavior which are associated with one object.

The Power of Transitions

The transition notation is also responsible for offering a description for what the object gains via the context without taking the time to define the specific context, and the ways in which the object offers contributions for the context. It will attempt to do this without making use of assumptions which are associated with the context, along with the existence for both the event consumers and the event handlers.

For transitions which are interactive, you will want to take the time to split the box which is holding the guard to make a boolean condition which is separate, one which is based on the dependency of the object. You will want to leave the action box alone. The box for an event which is optional must be used to provide a description for values which have been made available for the audience members.

Guards

The next thing that you must consider is the guard. The guard may comprise conditions which reference a number of different attributes. Some of these include the attribute for self, the attribute for other objects, the attribute for an event which is named, and the data which is connected to the event.

Within the design phase, references may be made to the objects besides the self, particularly within the guards that make use of the "read-only" attributes. This may allow operations to be accessed which do not have an impact on the existing level for descriptions.

In the world of analysis, you have the option of listing the guard conditions which are required, without having to concern yourself with the mechanics that comprise them. Firing the transitions will need the condition along with the event.

When the event does not need a transfer of data, it may be described as a trigger which is pure. The invitation which is available for the recipient must take the time to engage the transitions which is in state.

Declarative descriptions such as the trigger may be dependent on the invariants which may indicate that many state combinations for objects should be maintained. For instance, whether an engine is an in "on" or "off" state may be dependent on the type of indicator light that is seen.