SAD Chapter 6
Behavioral Modeling in Object-Oriented Systems
Behavioral models describe the internal dynamic aspects of an information system that support business processes. They focus on the internal logic and interactions of objects during analysis, before detailing implementation in design/implementation phases.
Three UML diagrams used for behavioral modeling in this chapter: activity diagrams, sequence diagrams, and behavioral state machines.
CRUDE (Create, Read, Update, Delete, Execute) matrices are a key tool for analyzing interactions among objects at the system level.
Behavioral modeling is use-case driven and iterative, balancing with functional and structural models to support an architecture-centric approach.
The behavioral view complements functional (external behavior) and structural (static internal) views; the dynamic view is driven by the original use cases identified in business processes and functional modeling.
Object-oriented development emphasizes collaboration among objects to support use cases; real-world domains are messy, so models are refined iteratively.
Key Concepts and Terminology
Object, class, and instance concepts
An object is an instantiation of a class (e.g., Patient instance Jim_Malone of class Patient).
Attributes describe an object's data; operations describe behaviors (methods later in development).
Messages are requests sent from one object to another to invoke an operation.
Behavioral models types
Interaction-based behavioral models show how objects collaborate to support a use case: Activity diagrams and Sequence diagrams.
Data/state-focused behavioral model shows changes in underlying data: Behavioral State Machines.
Iterative and cross-view refinement
As behavioral models are refined, functional and structural models may also be updated; diagrams are created for a complete view of dynamic behavior.
Interaction diagrams focus on objects, not just classes
Class diagrams model static structure; interaction diagrams model runtime behavior among objects.
Relationships Between Models
Functional models describe what the system does; Structural models describe how the system is built; Behavioral models describe how the system behaves internally during use cases.
Behavioral models are tightly coupled to use cases and to the objects that implement those use cases.
The three views (functional, structural, behavioral) must be balanced for consistency:
Sequence diagrams map to use cases and to functional descriptions.
CRUDE matrices map to interactions among classes/actors.
Behavioral state machines map to lifecycles of complex objects and their states.
Interaction Diagrams: Objects, Messages, and Lifelines
Objects, operations, and messages
An object is an instance of a class (e.g., aPatient is an instance of class Patient).
An operation is an action an object can perform (e.g., scheduleNewAppointment).
Messages are calls from one object to another to execute an operation (e.g., insert new patient).
Lifelines, execution occurrences, and destruction
Lifeline: vertical dashed line under an object depicting its lifespan in the diagram.
Execution occurrence: a thin rectangle on a lifeline showing when the object is executing an operation.
Destruction: an X at the end of a lifeline indicates object destruction (temporary objects like a shopping cart may be destroyed after use).
Messages and message types
Operation call messages: solid line with a directed arrow from sender to receiver; may include parameters in parentheses.
Return messages: dashed line with an arrow; often omitted if not informative.
Self-delegation: an object can send a message to itself (e.g., CreateSandwich()).
Object creation by message: an object can be created directly by a message to another object.
Sequence diagrams focus on a single use-case scenario (instance sequence diagrams) rather than a generic diagram for all scenarios.
How to model conditions in sequence diagrams
Conditions can be shown in brackets before a message (e.g., [aPatient Exists] LookupBills()). However, for a specific scenario, conditions are typically represented by separate instance diagrams rather than cluttering one diagram.
Relationship types in sequence diagrams
Include relationship: one use case includes another (call to child use cases).
Extend relationship: one use case extends another.
To depict include/extend in a sequence diagram, frame symbols and an Execute message are used to call the child use cases.
Left-to-right and top-to-bottom guidelines (Amble guidelines)
Order messages from top to bottom, and where possible left-to-right to reflect execution order and readability.
Align actors/objects on the top in the order they participate in the scenario.
If an actor conceptually represents the same idea as an inside object, name them the same to reflect the conceptual equivalence.
Creating a sequence diagram: six-step process
1) Set context: frame around the diagram denotes system/use-case/scenario.
2) Identify actors and objects: reference to functional and structural models; CRC cards can help identify scenarios and missing objects.
3) Set lifelines: draw vertical dotted lines under each actor/object; place an X where an object ceases to exist.
4) Add messages: draw arrows in time sequence from sender to receiver; include parameters in parentheses.
5) Place execution occurrences: add narrow rectangles on lifelines to show active processing.
6) Validate: ensure the diagram fully represents the underlying process and all steps are depicted; revise as needed.Instance sequence diagram examples
Make Old Patient Appt: involves aPatient, aReceptionist, UnpaidBill, Appointment; shows Create, Read, Update, etc., messages like LookupBills(), MatchAppts(), etc.
Campus Housing Add Apartment: actors Apartment Owner and Campus Housing Service; single scenario; one instance sequence diagram is sufficient.
Library Borrow Books: multiple scenarios per use case; for Students with a valid ID, a Librarian, Registrar's Office, and Book entities interact to check out books.
CRUDE Analysis and Matrices
CRUDE stands for Create, Read (Reference), Update, Delete, Execute.
The CRUDE matrix is a system-wide representation of interactions between actors and classes.
Matrix cells contain one of {C, R, U, D, E} indicating the interaction type.
Example: Receptionist → Appointment: C (Create an appointment); Receptionist → Appointments: R (Read/Reference).
Using CRUDE matrices helps identify life-cycle needs and verify that objects can be instantiated and life cycles are consistent.
Campus Housing example (simple 4×4 matrix) shows:
Apartment Owner can create and delete Apartment instances.
Student can read Apartment and Apartment Owner.
Some interactions may reveal missing use cases (e.g., creating/deleting Apartment Owners) that require model updates (adding a staff member actor, new use cases).
Rules for validating CRUDE with other models
When a CRUDE cell indicates an (U)pdate, there should be a corresponding state transition in the behavioral state machine affecting the receiving class.
All CRUDE interactions imply a message on a sequence diagram or an activation of a corresponding operation; otherwise, the model is inconsistent.
Advancing CRUDE matrices to reflect complex collaborations
Iterative refinement; clustering interactions into collaborations helps manage complexity.
Library CRUDE matrix example (expanded across actors/classes) helps verify consistency between CRUDE entries, CRC cards, and class diagrams.
Behavioral State Machines
What they model
A behavioral state machine models the lifecycle of a single, often complex, object and how events trigger state changes.
States represent conditions of an object; transitions show how events cause changes in state, often with actions and guard conditions.
Core elements
States: descriptive names (e.g., Entering, Admitted, Under Observation, Released).
Events: triggers causing transitions (e.g., CheckIn, DiagnoseHealthy).
Transitions: movement between states, often with an accompanying action/operation and an optional guard condition (Boolean expression).
Actions: operations invoked during transitions (often methods on the class).
Guard conditions: ensure transitions occur only when certain conditions hold.
Initial and final states: initial state is a filled dot; final state is a circle around a filled dot.
Guidelines for creating state machines
Create state machines for objects whose behavior changes with state; avoid for simple, constant-behavior objects.
Place initial state in the top-left, final state in the bottom-right to reflect left-to-right/top-to-bottom reading.
Keep state names simple, intuitive, and descriptive.
Avoid black-hole states (states that never exit) and miracle states (states from which you never entered).
Ensure guard conditions are mutually exclusive to avoid ambiguity (e.g., [Diagnosis = Healthy] vs. [Diagnosis = Unhealthy]).
Every transition should be associated with a message/operation; otherwise, the state change is not justified.
Behavioral state machines in practice
Apartment class: a simple lifecycle with a single state “For Rent” (often simplified and sometimes removed for clarity).
Book class (Library system): multiple states such as Available, Checked Out, Overdue, Requested, Damaged, Being Repaired; transitions driven by events like CheckOut, Return, PayFine, Repair.
The Book machine validates possible state sequences and guards against illogical transitions (e.g., an Available book should not move directly to Damaged without being Checked Out or similar realism constraints).
Additional examples and variations
Lunch object and Order object state machines illustrate more complex lifecycles where additional states and transitions exist beyond the core flow.
Life-cycle models can reveal extra processing needs, guiding further sequence diagrams and CRUDE interactions.
Validating behavioral state machines
Check reachability of all states; confirm that it is possible to leave all states except final states.
Ensure that the states reflect meaningful attributes or conditions (e.g., an attribute current_status for a Patient reflecting state).
Verifying and Validating Behavioral Models
Validation across models
All transitions in a behavioral state machine must be linked to a corresponding message in at least one sequence diagram and be mapped to a CRUDE entry (C/U/D/E) in the CRUDE matrix.
Each CRUDE matrix entry implies a message on a sequence diagram; if the matrix shows an Update, there should be a corresponding state change in the state machine for the affected class.
Completeness: ensure that a sequence diagram depicts all steps that the CRUDE matrix and activities describe; otherwise, refine the diagrams.
Balancing approach
Balance functional and behavioral models: ensure the activity diagrams, use-case descriptions, and use-case diagrams are in agreement with sequence diagrams, behavioral state machines, and CRUDE matrices.
Actors in sequence diagrams and CRUDE matrices should align with use-case diagrams and descriptions; internal actors (like Receptionist) may not appear in use-case diagrams but must be represented in the behavioral models.
Ensure that behavioral events map to activity diagram events and to use-case events, and vice versa.
Cross-model consistency checks
Objects appearing in CRUDE matrices must be represented by CRC cards and present in class diagrams.
Behavioral state machines should be tied to instances of classes and CRC cards; sequence diagram objects must instantiate existing classes.
Messages on sequence diagrams, transitions on state machines, and CRUDE entries must map to responsibilities and associations in CRC cards and in class diagrams.
States in state machines should correspond to values of attributes in the class definition (e.g., an attribute current_status).
Walkthrough and iterative refinement
Use walkthroughs to verify consistency among CRUDE, state machines, and sequence diagrams alongside functional and structural models.
The process is iterative; modifications in one model often necessitate updates to others (use-case diagrams, activity diagrams, class diagrams, CRC cards).
Practical Examples and Case Studies
Campus Housing Example
Context: campus housing service with Apartment Owner and Student actors; Apartment and Apartment Owner classes.
CRUDE matrix (simplified):
Apartment Owner (actor) → Apartment (class): C, D (can Create and Delete Apartment instances).
Student (actor) → Apartment (class): R (Read/Reference).
Student → Apartment Owner: R (Read/Reference).
Observations
The initial CRUDE matrix may reveal missing interactions (e.g., creating/deleting apartment owners) requiring new use cases and updates to diagrams.
After adding a campus housing staff member actor and corresponding use cases, the matrix is updated accordingly (see updated CRUDE matrix in Figure 6-18).
Behavioral state machine for Apartment class (simplified)
Context: Apartment (instance) lifecycle; single simple state may be For Rent in many scenarios.
States and transitions can be simple; often, the machine is small and may be omitted in some cases for clarity.
Library Example
Context: Library Book Collection Management System; Borrow Books use case with multiple scenarios (nine total scenarios across borrower types: Student, Faculty/Staff, Guest).
Instance sequence diagrams per scenario
Example scenario: Students with valid ID, no overdue items, no fines; Librarian interacts with Registrar's Office for ValidID checks and manages book checkout.
Steps: Librarian requests CheckOutBooks from Student; Student provides ID; Librarian consults Registrar's Office to validate ID via ValidID procedure; process continues until Book and ID are returned.
CRUDE approach for library system
Matrix includes interactions among Students, Librarians, Registrar's Office, Book, Book Collection, Library, Storage, Interlibrary Loan System, etc.
The CRUDE matrix helps identify whether certain objects (e.g., Library, Storage) are truly used or should be removed.
Behavioral state machine for Book class (Library System)
States include: Available, Checked Out, Overdue, Requested, Damaged, Being Repaired.
Transitions driven by events such as CheckOut, Return, PayFine, Repair; guard conditions ensure valid state changes.
Balancing and verification for library example
Ensure that sequence diagrams align with use-case steps and CRC cards; update class diagram if a new object (e.g., UnpaidBills) appears in a sequence diagram but not in the class model.
Notation and Modeling Details
Lifelines and frames
Lifelines depict the existence of actors/objects over time; frames enclose context (use-case or system boundary) on diagrams.
Execution occurrences and messaging
Execution occurrences show when an object performs an operation.
Messages have optional arguments; return messages are usually omitted unless informative.
Guard conditions and loops
Guard conditions determine when transitions occur (Boolean expressions).
Loops in sequence diagrams can be modeled with a frame labeled Loop and a termination condition (e.g., while more courses to request).
Frames for include/extend relationships
Include frames illustrate invoked use cases; execute messages trigger child use cases.
Extend frames show optional extended behavior in a use case.
Summary of the Verification and Validation Process
Ensure all transitions in state machines correspond to a message in sequence diagrams and map to a CRUDE entry (C/U/D/E).
Ensure all CRUDE entries imply messages on sequence diagrams; if an update leads to a state change, there should be a corresponding state machine transition.
Validate the entire set of models for consistency: use-case descriptions, use-case diagrams, activity diagrams, sequence diagrams, CRUDE matrices, and class diagrams.
Behavior and structure must be aligned: objects in sequence diagrams must be instantiations of classes in the class diagram and described by CRC cards; operations in classes should support the messages observed in sequence diagrams.
Be prepared to iterate: adding a new use case or adjusting a class may require updating activity, sequence, and state machine diagrams accordingly.
LaTeX Highlights for CRUDE and Notation
CRUDE set:
Each element maps to an action:
Interactions in CRUDE matrix example:
(Receptionist creates an Appointment).
(Receptionist reads Appointments).
Behavioral state machine notations
States: e.g., S = {\text{Entering},\ \text{Admitted},\ \text{Under_Observation},\ \text{Released}}\n- Guard conditions: G: \text{Boolean expression}\text{Available},\ \text{Checked Out},\ \text{Overdue},\ \text{Requested},\ \text{Damaged},\ \text{Being Repaired}$$
Initial/final state notation: initial state represented by a filled dot; final state by a circle enclosing a filled dot.
Practical Takeaways for Exam Preparation
Understand the purpose and scope of each behavioral modeling artifact:
Activity diagrams with swimlanes assign activities to actors and classes; useful for aligning external roles and internal objects in workflows.
Sequence diagrams show the explicit order of messages among objects for a use-case scenario; instance-level focus.
Behavioral state machines model the lifecycle of complex objects; emphasize states, transitions, events, actions, and guard conditions.
CRUDE matrices provide a high-level system view of how objects are created, read, updated, deleted, and executed; helpful for global validation and spotting missing interactions.
Be able to create and relate all four: activity diagrams, sequence diagrams, CRUDE matrices, and behavioral state machines, and to explain how changes in one require updates in the others.
Be able to discuss how these models support an architecture-centric, use-case-driven approach to object-oriented development, and why iteration across all three views is essential.