Verifying and evolving the analysis models: walkthrough, balancing, layers
Checking whether the functional, structural and behavioral models are consistent within themselves and with each other (walkthrough, balancing), then factoring, packages and layers to move to design. The exam asks 'what is inconsistent in these models?'.
At the end of the analysis phase you have three models: functional (use case diagram, descriptions, activity diagrams), structural (CRC, class, object diagram) and behavioral (sequence, communication, state machine). These models were drawn by different people at different times. Before moving to design, two questions are asked: Is each model correct within itself? Are the models consistent with each other? Moving to design with inconsistent models is like building a building from a wrong plan. On the exam, two or three model fragments are given and you are told “find the inconsistencies”.
Golden rules:
- Verification: are we building the models right? Validation: are we modeling the right system?
- A walkthrough finds the error, it does not fix it.
- Everything comes from somewhere and goes somewhere: every class appears in a use case, every message is an operation, every event is a message.
- If you change one model, update the others too.
Walkthrough
A walkthrough is a step-by-step review of a model by the team. The model is tested by eyes other than those of the person who made it.
| Role | Task |
|---|---|
| Presenter | Explains the model, usually the analyst who made it |
| Recorder (scribe) | Writes down the errors, questions and suggestions found |
| Maintenance oracle | Questions it from the point of view of maintenance, standards and compatibility with existing systems |
| Other participants | Users and analysts; they ask questions and catch errors |
Rules:
- The goal is to find errors, not to fix them. Fixing is done after the session.
- The model is evaluated, not the person. That is why the presenter’s manager usually does not attend.
- If users take part, the walkthrough is also validation: “Does this describe your work correctly?”
- It is done early and often; the later an error is found, the more expensive it is.
Verifying each model within itself
Functional model:
- Does every use case in the use case diagram have a description? Does every description correspond to an oval in the diagram?
- Is the “relationships” field in the description the same as the include/extend/generalization in the diagram?
- Does every action in the activity diagram correspond to a description step (and vice versa)?
- Does every object node in the activity diagram correspond to a noun that appears in the descriptions?
Structural model:
- Does every CRC card correspond to a class? Do the “collaborators” on the cards exist as relationships in the class diagram?
- Are the “knowing” responsibilities on the cards the attributes of the class, and the “doing” responsibilities its operations?
- Does the object diagram violate the multiplicities in the class diagram?
Behavioral model:
- Are the messages in each sequence diagram the same as in the communication diagram?
- Does every state and transition in the state machine reflect the real life cycle of the object (as described in the descriptions)?
Balancing the models
The three models are compared in pairs.
Functional
(use case,
activity)
/ \
/ \
Structural ------- Behavioral
(CRC, class, (sequence,
object) comm., state)Functional ↔ structural
| Check | Example |
|---|---|
| Every important noun in the descriptions should be a class or attribute | “reservation code” → Reservation.code |
| Every class should appear in at least one description | The never-used “Coupon” class → a missing requirement or an unnecessary class |
| Object nodes in the activity diagram should be classes | Order [paid] → the Order class, a status attribute |
| Relationships in the description (a student reserves a copy) should be relationships in the class diagram | Student - Reservation - Copy |
Functional ↔ behavioral
| Check | Example |
|---|---|
| There should be a sequence diagram for every use case (at least the normal flow) | Reserve Book → Reserve Book sequence |
| The actors in the sequence should be the same as the actors in the use case diagram | It must not say “Student” in the diagram and “Member” in the sequence |
| Sequence messages should correspond to the description steps | 8 steps ↔ messages |
Structural ↔ behavioral
| Check | Example |
|---|---|
| Every lifeline in the sequence should be an object of a class | :Copy → the Copy class |
| Every message should be an operation of the receiving class | setStatus() → Copy.setStatus() |
| If two objects exchange messages, there should be a relationship between their classes | Controller-Copy exchange messages → a relationship or a temporary link |
| The class of the state machine should be in the class diagram; states should correspond to attribute values | Copy.status ∈ {Available, On Hold, …} |
| State machine events should be operations of the class or incoming messages | pickUp → Copy.pickUp() |
Worked example: find the inconsistency
Three fragments from the gym system:
Use case description (Book Class), normal flow:
1. The member views the class list.
2. The member selects a class.
3. The system verifies the membership.
4. The system checks that the class has a free place.
5. The system creates a reservation.
6. The system shows a confirmation.Class diagram (relevant part):
| Class | Operations |
|---|---|
| Member | getStatus() |
| ClassSession | getCapacity(), listSessions() |
| Booking | create() |
Sequence diagram messages:
1 aMember -> :BookingCtrl : selectSession()
2 :BookingCtrl -> :ClassSession : listSessions()
3 :BookingCtrl -> :Member : verifyMembership()
4 :BookingCtrl -> :ClassSession : hasFreeSeat()
5 :BookingCtrl -> :Booking : create()
6 :BookingCtrl -> :Trainer : notifyTrainer()Inconsistencies found:
| # | Problem | Type | Fix |
|---|---|---|---|
| 1 | In the sequence, listSessions (step 1) comes after selectSession (step 2) | Functional ↔ behavioral (order) | First listSessions, then selectSession |
| 2 | verifyMembership() is not in Member; Member has getStatus() | Structural ↔ behavioral | Add the operation or change the message to getStatus() |
| 3 | hasFreeSeat() is not in ClassSession | Structural ↔ behavioral | Add the operation (or check with getCapacity) |
| 4 | There is a :Trainer lifeline but no Trainer class in the class diagram and no trainer notification in the description | All three models | Is it a requirement? Ask the user; if so, add a step to the description and a class to the class diagram; if not, delete the message |
| 5 | :BookingCtrl is not in the class diagram | Structural ↔ behavioral | Add the controller class to the class diagram (or in analysis let the actor talk directly to the objects) |
Evolving the models: the bridge to design
The verified models are prepared for design.
Factoring
Extracting common behavior into a separate class or module.
- Abstraction: gather common properties into a superclass. The name, phone and e-mail attributes of Member and Trainer → Person.
- Refinement: split a class into specific subclasses. Membership → MonthlyMembership, AnnualMembership.
Partitions and collaborations
Classes that exchange many messages with each other form a collaboration and can be grouped as a partition (subsystem). The criterion: the number of messages between them (the CRUDE matrix shows this). If the reservation, class and membership classes work together, they become a “Booking” subsystem.
Packages and the package diagram
A package is a container that groups related elements (classes, use cases). A package diagram shows the packages and the dependency relationship (dashed arrow) between them.
+----------+ +-----------+ +----------+
| UI |- - >| Domain |- - >| Data |
+----------+ +-----------+ +----------+Dependency: if Domain changes, UI may be affected. In a good design, dependencies are one-directional and acyclic.
Layers
| Layer | Content | Example |
|---|---|---|
| Foundation | Basic classes, data structures | Date, String, List |
| Problem domain | Business classes from analysis | Member, ClassSession, Booking |
| Data management | Persistence, database access | BookingDAO, database connection |
| Human-computer interaction | Interface | Screens, forms, buttons |
| Physical architecture | Related to hardware, network, operating system | Server communication, deployment |
In analysis only the problem domain layer is modeled. In design the other layers are added; week 12 covers the physical architecture layer.
Common mistakes
| Wrong idea | The truth |
|---|---|
| Verification = validation | Verification is building the model right, validation is building the right system |
| Fix the error immediately in a walkthrough | Record it, fix it later |
| A manager attending would be good | It creates a defensive reflex; usually they do not attend |
| If each model is correct separately, we are done | The models must also be balanced with each other |
| An unused class is harmless | A sign of a missing requirement or unnecessary complexity |
| A message name can differ from the operation | A message is an operation of the receiver; the names must be the same |
| UI and database classes are drawn in analysis | In analysis the problem domain; the other layers in design |
| Package dependencies can be bidirectional | Avoid cyclic dependencies |
Test yourself
Exam-style questions. Solve them on paper first, then reveal the answer.
What is the difference between verification and validation?
Show answer
Verification checks the internal correctness and consistency of the model: does it follow the rules, are the models compatible with each other. Validation checks whether the model meets the real need: it is reviewed together with the users.
In a walkthrough, who answers questions about how the model would affect future maintenance and checks it against existing systems and standards?
- Presenter
- Recorder
- Maintenance oracle
- Project sponsor
Show answer
The presenter explains the model (usually the analyst who made it). The recorder (scribe) notes the errors and suggestions found. The maintenance oracle looks at whether the model will cause problems with regard to maintenance, standards and compatibility with existing systems.
Why should the person who built the model NOT be the one who fixes problems during the walkthrough?
Show answer
In a walkthrough, errors are identified and recorded, and the fixing is done afterwards. Fixing by discussion in the session wastes time. Also, a walkthrough evaluates the model, not the person; managers usually do not attend, so that people do not become defensive.
An activity diagram contains the action 'Apply Discount', but no use case and no use case description mention discounts. What kind of problem is this?
- A structural-behavioral imbalance
- A functional model inconsistency (activity diagram vs use cases)
- A physical architecture problem
- Not a problem
Show answer
Within the functional model, the activity diagram and the use case descriptions must be balanced: every action must correspond to a use case step, and every use case step to an action. Either the description is missing something or the diagram has an extra action.
A sequence diagram sends calculateFine() to :Loan, but the Loan class in the class diagram has no such operation. Which models are out of balance?
Show answer
Rule: every message in the sequence diagram must be an operation of the receiving class. Either calculateFine() is added to the class diagram, or the message is directed to the right class.
The class diagram has a class 'Coupon', but no use case description, CRC card or interaction diagram ever uses it. What should the analyst do?
Show answer
The structural model and the functional model must be balanced: every class should come from a noun that appears in at least one use case description. An unused class is either a sign of a missing requirement (ask the user) or unnecessary (delete it).
A state machine for Order has a transition triggered by refund(), but no sequence diagram ever sends refund() and Order has no refund operation. List the two fixes needed for balance.
Show answer
Every event in a state machine must correspond to an operation (or an incoming message). The interaction that triggers the event must also be based on a use case. Otherwise the state transition never happens.
What is factoring?
Show answer
Factoring is extracting common behavior into a separate module. Two ways: abstraction (gathering common properties in a superclass: Student and Librarian → Person) and refinement (splitting a class into more specific subclasses).
Which layer contains the classes identified during analysis, like Book, Copy and Reservation?
- Foundation
- Problem domain
- Data management
- Human-computer interaction
Show answer
The business classes from analysis are the problem domain layer. Foundation is basic data structures (Date, String, collections), data management is persistence (database access), human-computer interaction is the interface (screens, forms), and physical architecture is classes related to hardware/network.
In a package diagram, what does a dashed arrow from package UI to package Domain mean?
Show answer
A package diagram shows packages and the dependencies between them. The dashed arrow is a dependency; the arrow goes from the dependent to the one depended upon. In a good design the dependency is one-directional: UI → Domain → Data, not the reverse.
Name the three models that must be balanced with each other in the analysis phase.
Show answer
Each model is verified within itself, then the three models are balanced in pairs: functional-structural, functional-behavioral, structural-behavioral. If a change is made to one model, the others are updated too.
Verification: Conceptual questions; the walkthrough roles, model balancing rules and layer definitions were checked against the standard definitions (the Dennis, Wixom and Tegarden framework). The gaps in the 'find the inconsistency' questions were checked by hand on the model fragments on the page. There are no numeric answers.