|
|
This chapter addresses a fundamental question that every development effort must ask: What are the users of the system trying to do? We're going to focus our efforts on trying to capture our users' actions, and the associated system responses, in great detail because the software behavior is dictated by the user requirements. In other words, what we need the software to do depends on how the users are accessing it and what the users are trying to do. This often relates to screens and user interfaces.
Figure 3-1 shows where use case modeling resides within the "big picture" for the ICONIX process. As you can see, we think it's a good idea to use prototypes to help define the use cases. And, we do our use case model, along with our domain model, right at the very beginning of our project. The entire dynamic part of the object model is directly driven from the use case model we put together. Since the dynamic model drives the static model, the use cases are also driving our static model, as well.
Figure 3-1 also shows that we're continuously updating and refining our static model based on further analysis of these use cases as we do our robustness and sequence diagrams. We're constantly updating our static model as we walk through the scenarios. That's how it evolves from the first-cut domain model to our detailed design-level static model. We're completely use case driven in this approach, in that our software architecture and our software design are both driven from our analysis of usage scenarios.
The whole dynamic model is very much an outside-in type of approach. We start with users who are outside our system, and we work our way in to expose all details of the software behavior. From that, the software structure that supports that behavior is created. But we're working inward from the outside of the system, one scenario at a time. Because the use cases are the fundamental unit of decomposition in this modeling effort, everything else is directly driven from this outside-in approach. As a result, we're reliably able to design systems that meet our user requirements, which is no small accomplishment.
|
|