Understanding Use Cases, Object Interaction, and Domain Models

Posted on Mar 19, 2025 in Computer Engineering in Computer Engineering

Understanding Use Cases

Use Case: A business process that begins and ends with an actor, accomplishing a business task for that actor.

Components:

• Operation: A series of actions or instructions to accomplish a step in a business process.
• Action: An indivisible act, movement, or instruction performed during an operation.

Steps in Use Case Development

• Identifying use cases: deriving use cases, actors, and subsystems.
• Rearranging use cases among subsystems.
• Constructing a traceability matrix.
• Specifying use case scopes.
• Visualizing use case contexts.
• Reviewing use case specifications.
• Allocating use cases to iterations.

Use Case Checklist

Used to ensure proper use case specifications. Checks include:

• Abstract Use Cases: Formed properly? Correct information? Could be merged or split?
• Use Case Traceability Matrix: Formatted correctly? Use cases necessary and sufficient for each requirement?
• High-Level Use Cases: Specified start times, end times, and what it is to accomplish?
• Use Case Diagram: Does the use case diagram perform correctly, clearly, and efficiently?

Guidelines for Use Case Derivation

• Use cases should be derived from and satisfy functional requirements.
• Use cases may also be derived from nonfunctional requirements.
• Use phrases to communicate exactly what the use cases will accomplish for the actors.
• High-level use case specifications should end with what the actor wants to accomplish.
• A use case should accomplish exactly one business task for the actor (functional cohesion).
• High-level use cases should not specify background processing activities.
• Avoid:
  • Many use cases in one diagram.
  • Many use case diagrams containing only one use case.
  • Many relationships between use cases.
  • Overly complex use case diagrams.

Applying Agile Principles to Use Cases

• Use cases represent business processes.
• Work closely with customers and users to understand their business processes and priorities, helping them identify their real needs.
• Requirements evolve, but the timescale is fixed.
• Focus on frequent delivery of small increments.
• Do not attempt to derive an optimal set of use cases. Good enough is enough.

Object Interaction Modeling

Object Interaction: A process to understand how objects interact in existing systems or business processes. It helps identify problems and limitations and design object interactions in the proposed software system to carry out use cases.

Object interaction modeling helps the development team understand existing business processes and design object interaction behaviors to improve the business.

Actor-system interaction modeling and object interaction modeling deal with foreground and background processing of a use case, respectively.

Steps in Object Interaction Modeling

• Collecting information about existing business processes.
• Specifying scenarios for the nontrivial steps of the expanded use cases.
• Constructing scenario tables.
• Deriving sequence diagrams from scenario tables.
• Reviewing the object interaction models.

Scenario: A declarative sentence consisting of a subject, an action of the subject, an object acted upon, and possibly other objects required by the action.

Guidelines for Object Interaction Modeling

• Specify the normal scenario first.
• Augment the normal scenario with alternative flows.
• Keep it simple (leave details to coding).
• Leave exception handling to coding.
• Constructing a prototype to validate design ideas is desirable.

Object State Modeling

Object State: A tool for modeling and designing event-driven systems.

• Event: Something that happens (such as a request) to a subsystem, object, or component.
• State: A named abstraction of a condition or situation that is entered or exited due to the occurrence of an event.

Why Use Object State Modeling?

• Collecting information helps team members understand state behavior, which is crucial for success.
• State model diagrams are easily understood and useful for effective communication.
• The model can be checked for desired properties, like how a subsystem processes and reacts to an event.
• Test cases and fault analysis can be generated rather than relying on trial-and-error testing.

Object State Modeling Steps

• Collecting and Classifying State Behavior Information.
• Constructing a Domain Model.
• Constructing State Transition Tables (optional).
• Visualizing the State Behavior.
• Reviewing the State Models.

A UML State Diagram is a behavioral diagram that shows state behavior as a hierarchy of concurrent, communicating state machines, each depicting the states, state transitions, and response actions associated with the state transitions.

Activity Modeling

Activity Model: Modeling focuses on systems that perform complex information processing. It’s a way to detail use cases, where each activity is a task to be modeled.

Why Use Activity Modeling?

• Helps team members understand and communicate interaction between activities.
• Helps refine high-level requirements and identify use cases.
• Concerned with complex information processing dealing with the characteristics of a transformational system.

Activity Modeling Review Checklist

• Does the activity diagram describe the correct business process?
• Is the activity diagram overly complex?
• Is the activity diagram syntactically correct?
• Is each conditional branching associated with a condition that can be evaluated?
• Are the branching conditions mutually exclusive?
• If the activity diagram is a refinement of an activity, does the refinement satisfy the consistency rules?

Applying Agile Principles to Activity Modeling

• Use activity modeling to understand activities and workflows.
• Do not use activity modeling as a form of documentation.
• Involve users in activity modeling.
• Leave out unnecessary details; capture activities and workflows at a high level.

Domain Model

Domain Model: A conceptualization process that aims to identify important domain concepts, their properties, and relationships between the concepts. The result is portrayed in a diagram called a domain model.

Why Use a Domain Model?

• Helps understand the application and the application domain.
• Lets team members communicate and improve their common perception of the application and application domain.
• Helps the development team communicate their perception to customers/users and seek feedback.
• Provides a common conceptual basis for subsequent design, implementation, testing, and maintenance.
• Helps new members understand the relevant application and the application domain.

Steps in Domain Modeling

• Collecting application domain information.
• Brainstorming.
• Classifying brainstorm results.
• Visualizing the domain model.
• Reviewing the domain model.