|
Tigris.org
Open Source Software Engineering Tools
|
|
|
Table of Contents
Analysis is the process of taking the “customer” requirements and re-casting them in the language of, and from the perspective of, a putative solution. We are not actually trying the flesh out the detailed solution at this stage. That occurs in the Design Phase (see Chapter 6, Design). Unlike the boundary between Requirements and Analysis Phases, the boundary between Analysis and Design Phases is inherently blurred. The key is that analysis should define the solution no further than is necessary to specify the requirements in the language of the solution. The model elements in Analysis generally represent a high level of abstraction. Once again the recursive, and iterative nature of our process means we will come back to the Analysis phase many times in the future. There are three schools of thought on how Analysis should be approached. The ontologist defines the data (actually the metadata) first and worries about processes later. The true ontologist would prefer not to have to think about processes at all. The phenomenonologist reverses this and favors process over data. The panparadigmist considers both process and data to be equally important and addresses both from the start. When it comes to being a purist the ontologist has the upper hand. It is possible to define and build a database into which data can be entered and retrieved without concern for what happens to it or is done with it. On the other hand implementing a process without having any data structures for it to operate on is not very meaningful. The CRC methodology favors the phenomenonologists preference for analysis. It is the equivalent of starting with the use cases, the process aspects (operations) of the class diagrams, and scenarios from which sequence diagrams can be initiated. CRC cards and the associated methodology are described in detail in Appendix G, The CRC Card Methodology. They are used again in the design phase and are further discussed in Chapter 6, Design. The strength of CRC cards during analysis.
In this phase the group should consist of two or three domain experts, one object-oriented technology facilitator, and the rest of the group made up of people who are responsible for delivering the system. The first time that the Analysis phase occurs a special case of the CRC session happens as there are no classes or scenarios to choose from to define a CRC session. At this point a special type of session known as brainstorming is held. During this session you identify the initial set of classes in the problem domain by using the problem statement or requirements document or whatever you know about the desired result for a starting point. The nouns that are found in whatever you are starting from are a good key to an initial set of classes in the system. In a brainstorming session there should be little or no discussion of the ideas. Record them and filter the results after the brainstorming. At this stage the distinction between class and object is blurred. Once a reasonable set of classes has been defined by the group, responsibilities can be added. Add responsibilities that are obvious from the requirements or the name of the class. You don't need to find them all (or any for that matter). The scenarios will make them more obvious. The advantage of finding some in the beginning is that it helps provide a starting place. Select the initial scenarios from the requirements document by examining it's verbs in much the same way that we scanned its nouns earlier. Then as many walk through sessions as necessary to complete the analysis phase are performed. When is enough of the analysis complete that design can begin? When all the different responsibilities are in place and the system has become stable. After all the normal behavior has been covered, exceptional behavior needs to be simulated. When you notice that the responsibilities are all in place to support the new scenarios, and there is little change to the cards, this is a sign the you are ready to start design. |
|||||||||||||||||||||||||||||
