Mastering Structural and Behavioral Modeling in UML

Understanding Structural and Behavioral Models

A structural model is used to analyze the structure of a system of objects and their relationships. This model is developed in layers. Within this framework, structural modules (mod_estrutural) are used to mount interaction diagrams that show the relationship between modules and subsystems.

The Role of Interaction Diagrams

An interaction diagram (D_interação) is a behavioral specification that includes a sequence of message exchanges between a set of objects to achieve a purpose. These should be used when you wish to view the behavior of various objects within a single use case, based on the messages passed between them. The strength of these diagrams is their simplicity.

Sequence and Collaboration Diagrams

Sequence and Collaboration Diagrams are descendants of the interaction diagrams of objects proposed by Booch and Jacobson; they emphasize the behavior of objects in a system.

Synchronous and Asynchronous Communication

• Synchronous: The sender is stopped while waiting for a reply; this is typically called an operation or procedure. In the recipient's return, it is often unnecessary to use a synchronous message when using asynchronous activation bars.
• Asynchronous: The sender does not stand still while waiting for a reply; this is typically the signal transmission between two simple or undifferentiated objects.
• Competitors: These occur when one cannot decide whether a message is synchronous or asynchronous.

Modeling Interactions and System Boundaries

Returns are currently used in the modeling of interactions at the system boundary, specifically between actors and the system represented by one or more structural objects (static items) or behavioral objects (dynamic items). In Together, the different views capture important decisions. Individually, each vision turns its attention to a specific system perspective.

To optimize the architecture, you must:

• Decide which views are necessary to express the best system architecture.
• For every vision, decide which artifacts should be created to capture details.
• Decide which view diagrams should be placed under some type of formal or semi-formal control.

Collaboration Diagrams and Object Topology

Collaboration Diagrams show the interactions that occur between objects participating in a specific situation, placing more emphasis on relationships between objects and their topology. The messages sent from one object to another are represented by arrows, showing the message name, parameters, and the sequence of the message.

State Diagrams and Their Components

A State Diagram has several parts:

1. Name: The identifier of the state.
2. Actions of Input/Output: Actions taken at the entrance or exit from the state, respectively.
3. Internal Transitions: Transitions that do not cause a change of state.
4. Sub-states: The nested structure of a state, involving sub-states that are disjoint (sequentially active) or competitors (concurrently active).
5. Events Postponed: A list of events that are not handled in this state but are instead postponed and queued to be handled by the object in another state.

Understanding Transitions

A transition represents a change of state. Transitions can be automatic or triggered through events. The parts of a transition include:

• Event: Triggers the state transition. It can be generated by an actor external to the system or by a system object.
• Condition (Guard Condition): Indicates when the state transition should occur.
• Action: Indicates an object method to be executed when the state transition takes place.