Reconcile Sequence Diagrams to Object Model

Reconciling a sequence diagram with an object model in UML involves mapping the dynamic behavior captured in the sequence diagram to the static structure described in the object model. This process ensures consistency between how objects interact over time and their definitions in the static model.
Here’s a step-by-step guide to reconcile the two:

1. Identify Objects in the Sequence Diagram
   • Look at the lifelines in the sequence diagram. Each lifeline represents an instance of a class or object.
   • Match these objects to corresponding classes in the object model (class diagram or object diagram).
   • If an object doesn't exist in the object model, consider whether:
     • It should be added as a new class.
     • It's a temporary or auxiliary object (e.g., a data transfer object) that doesn't require modeling.
2. Validate Class Responsibilities
   • Compare method calls in the sequence diagram with the methods defined in the class diagram:
     • Ensure the classes associated with the lifelines have the methods invoked in the sequence diagram.
     • Add missing methods to classes if they logically belong there.
   • Check that the responsibilities of each class align with the interactions in the sequence diagram.
3. Analyze Relationships
   • Inspect the message flows between lifelines in the sequence diagram:
     • Ensure that associations between classes in the object model (e.g., associations, dependencies, or aggregations) support these interactions.
     • Add new relationships to the object model if they are missing.
4. Check Message Parameters
   • Validate that the messages exchanged in the sequence diagram (including arguments and return types) align with the class attributes and methods in the object model.
   • Ensure that the data types used in the messages are consistent with those defined in the object model.
5. Review Object States (if applicable)
   • If the sequence diagram involves state changes (e.g., object creation, deletion, or transitions), ensure that:
     • The object model reflects these states (e.g., state machine diagrams, state attributes).
     • The lifecycle events in the sequence diagram correspond to operations in the class definitions.
6. Update Object Model or Sequence Diagram as Needed
   • If inconsistencies arise:
     • Update the object model to include missing classes, methods, or relationships.
     • Modify the sequence diagram to better align with the object model, ensuring its behavior remains consistent with the static structure.

Example

• Classes:
  • Customer
  • Order
  • PaymentProcessor
• Associations:
  • Customer has an association with Order (e.g., "places").
  • Order has an association with PaymentProcessor (e.g., "uses").

Sequence Diagram:

• Message flow: `Customer` sends a `placeOrder()` message to `Order`, which then interacts with `PaymentProcessor` to process payment.

Object Model:

• Classes:
  • Customer
  • Order
  • PaymentProcessor
• Associations:
  • Customer has an association with Order (e.g., "places").
  • Order has an association with PaymentProcessor (e.g., "uses").

If the `Order` class in the object model lacks a `placeOrder()` method, it should be added. Similarly, the relationships between `Order` and `PaymentProcessor` should be validated or added.
7. Use Tools (Optional)

• Many UML tools, like Visual Paradigm, Enterprise Architect, or StarUML, allow automatic consistency checks between sequence diagrams and class diagrams.

Reconciling sequence diagrams with an object model ensures your design is both behaviorally correct and structurally sound. This alignment minimizes discrepancies during implementation and fosters a robust software architecture.

Name ( argument:datatype, ...): 
  returndatatype {constraints} 

Above is the standard operation signature format: Every event should translate into an operation. Once the operation signature has been defined, there are at least four tests to apply to your class diagrams:

1. Verify that every operation on your sequence diagrams appears on the class diagram. Most computer-assisted software engineering (CASE) tools will automatically add interfaces to the class diagram when you add them to the sequence diagram. However, as you add and remove interfaces, the tools will not necessarily keep the two diagrams in sync. Operations deleted from your sequence diagrams may still appear on your classes. An operation moved from one class to another might still also be on the original class.
2. Test for class cohesion. Verify that each interface supports the purpose of the object. Then look at all the interfaces for the class and determine whether all the interfaces support the same purpose. If the operations seem to work at two or more objectives, then you might want to split the class to improve cohesion.

View the following series of images below to see an example of splitting a class.

Cohesion is a measure of how well the parts of an object support the same purpose. Cohesion measures two factors:

1. how well-defined the purpose of the object is, and
2. whether every part of the object contributes directly to fulfilling the purpose.

High cohesion means that an object has one well-defined purpose and everything in the object contributes directly to that purpose. Low cohesion means that either the purpose of the object is ambiguous (as when an object has multiple jobs or a poorly defined job) or not all the parts of the object contribute directly to the object's purpose, or both. To describe how objects work, I often refer to the way people work. The similarities are strong and the principles work very much the same. So I will use the example of an employee's job description and then compare it with a class description to illustrate the significance of these two factors in measuring cohesion.
When you hire a person to do a job, it is very important that the job be clearly defined. When the job is not clear, a lot of time is wasted trying to figure out what the person is supposed to do. Many of us have been in this position and know how frustrating and inefficient it can be. To avoid this problem we often write a job description such as "Java Developer", for example. The job description starts with a few lines about the purpose of the job, such as, "A Java developer is responsible for creating quality software solutions to company needs on time and within budget". Next, the job description lists duties that a person in that position must perform to fulfill the purpose of the job. The list might include gathering requirements, researching those requirements, designing and constructing a solution to those requirements, testing the solution, putting it into production based on the Software Life Cycle.

1. Test for consistency. If the same interface is referenced in more than one scenario, then verify that it is used the same way in each scenario. It is very easy to end up with identical names for operations that perform similar but distinct functions.
2. Answer the following questions. Does the class have everything it needs to fulfill its defined purpose? Do the interfaces provide all the functionality that you would normally associate with the scope of responsibility that you assigned to the class? If not, then you will want to revisit the use cases and scenarios to find out what you might have overlooked. It is possible that the functionality was simply out of scope for this project. If so, leave it out. Otherwise, update the use cases, scenarios, and sequence diagrams to determine when the new interfaces are used and why.

Click the Exercise link below to update the course project interfaces for a class.
Add New Interface to Model - Exercise