A recurring problem in systems development is getting started with the requirements and organizing them into some comprehensible framework. In this chapter we will see how to gather the requirements for the system and organize them into separate domains. Use cases view a system from the outside they take an external view of the system in terms of what happens. Executable UML models, on the other hand, take an internal view of a domain in terms what the conceptual entities are and how they behave. Use cases, then, are a useful tool for gathering requirements, but they do not immediately yield classes. Figuring out the classes requires abstraction based upon the requirements. Once we have built the executable UML models, we can assign specific values to the current state of the system and the data that activates the use case. These scenarios become the test cases for the system. We take up this topic later, in Chapter 15: Domain Verification. There are many fine books on organizing requirements and writing use cases. This chapter is not intended to replace these for those purposes. Rather, it is intended to describe how to apply the appropriate level for use cases to organize information for modeling, to expose the different subject matters in a system, and to form the basis for test cases. |