Next: Interaction modeling
Up: A sample process
Previous: Use case modeling
Contents
Subsections
Robustness analysis involves:
- analyzing the text of each of your use cases,
- identify a first-guess set of objects that will participate in the use case, then
- classify these objects into
- Boundary objects
- Entity objects
- Control objects
- This has parallels in the Model/View/Controller paradigm.
- Boundary objects - Actors use these to communicate with the system ("View").
- Entity objects - Usually objects from the problem domain ("Model").
- Control objects - Serve as the "glue" between Boundary and Entity objects ("Controller").
- Sanity check - make sure your use case text is correct.
- Completeness check - make sure your use cases address all the necessary alternate courses of action.
- Ongoing discovery of objects - you may have missed some objects during domain modeling.
- "View".
- Objects that the Actors will be interacting with.
- Windows, screens, dialogs, menus.
- Get many from prototypes.
- "Model".
- Often map to database tables and files.
- Many come from the domain model.
- Simpler and more generic - easier to reuse in other projects.
- "Controller".
- Embody much of the application logic.
- Where you capture business rules and application logic.
- Not necessarily meant to endure as stand-alone classes as you proceed.
- Sometimes serve as placeholders to make sure you don't forget any functionality and system behavior required by your uses cases.
- Actors can talk only to Boundary objects.
- Boundary objects can talk only to Controllers and Actors.
- Entity objects can only talk to Controllers.
- Controllers can talk to both Boundary objects and Controllers, but not to Actors.
- Update your static model.
Milestone 2: Preliminary Design Review
Next: Interaction modeling
Up: A sample process
Previous: Use case modeling
Contents