The first step of an analysis process demands that we obtain requirements and complete them as necessary. In our case, we want to describe the OOA process, so we can refer to the previous section describing default steps and activities as the Fig. 6.1 Booch class image
(Booch1994)
requirements document for this enterprise. Subsequently, we ought to provide for system-context interaction, subsystem delineation and vocabulary development.
We will, however, bypass these steps. Our abstraction level eliminates the analyst.
We cannot effectively discuss system-context interaction or model construction.
Additionally, the OOA process is too abstract to allow subsystems to be properly distinguished. The vocabulary consists of concepts such as: class, relationship, instance, attribute, constraint, transition network, state, transition, etc. Such a vocabulary allows us to go straight into class elaboration.
In the analysis phase, a model of the real-world application is developed showing its important properties. It abstract concepts from the application domain aid in the describing of what the intended system must do, rather than how it will be done. Most proponents of object-oriented analysis (OOA) claim that the use of object-oriented concepts in the analysis phase (i.e., OOA) increases the under-standing of problem domains, that OOA promotes a smooth transition from the analysis phase to the design phase, and that OOA provides a more natural way of organizing specifications (Coad and Yourdon 1990). Extant object-oriented approaches can be classified into three categories (Monarchi and Puhr 1992):
combinative approaches use different modeling techniques in different stages of the system development process; adaptive approaches apply existing techniques (e.g., data-flow diagram and entity-relationship approach) in object-oriented ways to analyze the problem domain; and pure approaches adopt an object-oriented perspective in systems analysis and design.
Customer
Fig. 6.2 Class diagram (Miller2003)
114 6 Object-Oriented Analysis
6.6.1 Identifying Entity, Boundary, and Control Objects
Transforming use cases and scenarios into an effective analysis model begins with the identification and classification of the concepts enunciated in the requirements specification. These models must be broken down and torn apart in order to pinpoint the entity, boundary, and control objects that make them up. Great care must be taken to ensure that no objects are missed, or, conversely, that an excessive number of objects are not created. It is also vital to ensure that the objects identified are correctly interpreted and classified.
This process begins with the identification and determination of participating objects, which are candidate objects assigned to use cases. These participating objects are used to determine which concepts are to be used and manipulated in each use case, and should be standardized across all use cases. Because these objects are defined based on the requirements elicited during the various elicitation and analysis interviews, natural language analysis can be used for identification.
The system of natural language analysis, put forth by Abbott (1983), is is ‘‘an intuitive set of heuristics for identifying objects, attributes, and associations’’ from within the requirements specification (Bruegge and Dutoit2004). This system is used to map various language constructs, such as nouns, verbs, and adjectives, to component models. The following list illustrates related examples:
• Proper Noun: Instance of a class (an object). For example, Whiskers the cat.
• Common Noun: Class. For example, a cat.
• Doing Verb: Operation. For example, Whiskers eats.
• Being Verb: Inheritance. For example, a cat is a kind of animal.
• Having Verb: Aggregation. For example, a cat has the fur of a mammal.
• Modal Verb: Constraints. For example, a cat must be a mammal.
• Adjective: Attribute. For example, a cat is cute.
When a use case is analyzed, these concepts can be used for object identifi-cation. Unfortunately, natural language analysis is an imprecise method. The outcome hinges on the writing style and ability of the analyst, as well as his or her consistency and level of language competence. We said earlier that inconsistency and ambiguity are highly detrimental to a requirements specification. This is never more true than when analyzing those requirements for object identification.
Developers must be sure to refine and clarify the requirements specification during the identification process in order to establish a standard set of objects and ensure the use of a standard set of terms. However, even after such clarification, natural language analysis still faces another issue: ‘‘there are many more nouns than relevant classes’’ (Bruegge and Dutoit 2004). Beyond this, the use of nouns in normal speech does not always correspond with the concepts laid out in Abbott’s heuristics. Many nouns are used not to identify objects or concepts, but to convey attributes or likenesses. In addition, multiple nouns can be used to describe the same concept, further complicating the identification process. Tearing apart the various meanings and uses of such nouns can be a very lengthy and repetitive
process. For this reason, Abbott’s heuristics are well suited to the initial stage of the identification process, when candidate objects are determined.
Bruegge and Dutoit have created an additional set of heuristics to be used together with Abbott’s heuristics in determining each of the three analysis objects:
entity, boundary, and control objects. They suggest the following list be used in identifying entity objects:
• Terms that must be clarified by developers or users to get a better understanding of the use case.
• Nouns that show up multiple times.
• Real world entities that are to be tracked by the system.
• Real world activities that are to be tracked by the system.
• Data sources.
The following list they recommend for the identification of boundary objects:
• User interface controls that must be initiated by the user.
• Forms utilized by the user to pass data to the system.
• Responses the system presents to the user, such as notices, messages, and warnings.
• NOT visual aspects of the interface.
Finally, they suggest the following list be used to in conjunction with Abbott’s heuristics to identify control objects:
• One control object per use case.
• One control object per actor in the use case.
• The lifespan of a control object should correspond with the lifespan of the use case or user session being considered (Bruegge and Dutoit2004).
6.6.2 Identifying Use Cases
The best way to find use cases is to consider what each actor requires of the system. For each actor, human or not, ask:
• What are the goals that the actor will attempt to accomplish with the system?
• What are the primary tasks that the actor wants the system to perform?
• Will the actor create, store, change, remove, or read data in the system?
• Will the actor need to inform the system about sudden external changes?
• Does the actor need to be informed about certain occurrences, such as unavailability of a network resource, in the system?
• Will the actor perform a system startup or shutdown?
Understanding how the target organization works and how this information system might be incorporated into existing operations gives an idea of a system’s surroundings. That information may reveal other use case candidates. Give a
116 6 Object-Oriented Analysis
unique name and brief description that clearly describes the goals for each use case. If the candidate use case does not have goals, ask yourself why it exists, and then either identify a goal or eliminate the use case. The following process describes a technique that can be used to identify use cases:
First, prioritize the candidate list based on user input and importance to the release being built and begin describing the use cases. Define the use case, con-sidering the system as a black box, and focus on the interaction of the actors with the system. Remember that use cases can be represented both textually and graphically.
Next, describe the main interactions with the system. Focus on the priority use cases and on the basic course. These priority use cases are sequences of events and interactions that contain fundamental information about the system functions.
Consider each primary function of the system in order to properly document decisions made about the actions and sequence, provide an effective communi-cation vehicle for requirements, and serve as a set of instructions for the final implementation. Focus on the main interactions in the system. Start with an external user’s interactions with the system (e.g., for a bank, start with deposit cash, withdraw cash). Create a narrative that describes what happens as the system responds to the event. Use a checklist of questions to help build a complete description. Assess your descriptions using the guidelines for use case descriptions and the use case quality checklist. Use a sequence diagram to show the messages and responses of the objects with each other to complete the sequence. In analysis, describe the message with descriptive text. As the model is refined, use message names and parameter lists. Remember that use cases do not define the object model. Return to the object model to review inheritance, examine state transitions, or document flow of control.
The next step is to structure the use case. Use cases most often deal with varying degrees of complexity. Each use case considers only those objects relevant to the use case itself. An individual object may participate in many use cases. All responsibilities of an object are easily identified by considering all of the use cases in which it participates. Even the most complex systems can usually be described with a modest number of high-level use cases. These high-level use-cases, of course, can be used for organization as many more detailed use cases as are required by the given project. As the object model gets larger and more complex, use cases may be identified for subsets of the entire model, in an effort to refine the interactions and responsibilities of objects at a more detailed level.
Finally, the use case should be extended to subordinate use cases. A subordinate use case is a sequence of events and interactions that contains supplemental information about the system functions. The subordinate use case is used to document the following:
• Alternate paths through the sequence.
• Exceptions.
• Variations in the main functionality.
Define the subordinate as a complete stand-alone use case documenting the applicable sequence. Use it to support the main use case, however, do not repeat the information. For each main use case, consider the alternatives. For example, an application received by mail may have slightly different processing, than an application received in person. Identify the main exception processes. For exam-ple, applicants for driver’s license renewals may have their renewals automatically issued, unless they have outstanding summonses. Review the interactions by developing sequence diagrams for the subordinate use cases.
6.6.3 Scenario Development
The use of scenarios is a development technique by which the developer maps the possible user interactions with the system. An individual scenario represents the experience of a single actor during an interaction with the system. In order to identify the scenarios that will be used, developers observe users and create a set of scenarios to represent the functionality that the system will have. These scenarios represent hard evidence for the way in which the system will be used. They also provide another chance to gain user feedback on the system. Scenarios are distinct from use cases in that they provide information about ‘‘specific instances and concrete events’’ (Bruegge and Dutoit2004). For this reason, they cannot replace use cases, but they are extremely useful tools for communication with the user and client, and for classifying that information in a way that is meaningful to the development team.
The following list provides a number a scenario types (Carroll1995):
• As-is Scenario: Describes a current situation. Provides a picture of the system based on scenarios derived from observing users and classifying their actions.
User input can be used to ensure that the scenarios are correct and accurate.
• Visionary Scenario: Describes a future system. Used in refining the developer’s understanding of the system being developed by serving as a point in the modeling space. Also used as a way to communicate with users in order to elicit new requirements. Commonly considered a cheap, idea-based prototype.
• Evaluation Scenario: Evaluates the system by describing user tasks which have been selected for use as testing criteria for the system. Used to refine and improve the functionality definitions that they test.
• Training Scenario: Tutorials designed to introduce a new user to, and allow that user to get acquainted with, the system. The user is walked through com-mon tasks via a step-by-step tutorial of the system.
A scenario represents a single actor’s interactions with the system, and is thus a sequence of events that the system will manage and handle. In this way, a specific scenario describes one possible process and outcome for a single use case. Because a use case may be worked through in various ways, multiple scenarios may be needed to describe it completely (Stiller and LeBlanc2002).
118 6 Object-Oriented Analysis
6.6.4 Modeling the System
Analysis modeling uses a combination of text and diagrammatic forms to depict requirements for data, functions, and behaviors in a way that is relatively easy to understand, and, more importantly, straightforward to review for correctness, completeness and consistency. This section presents resources for conventional and object-oriented analysis (OOA) methods as well as resources for UML.
Data modeling is a method used to define and analyze data requirements needed to support the business processes of an organization. The data requirements are recorded as a conceptual data model with associated data definitions. Actual implementation of the conceptual model is called a logical data model. To implement one conceptual data model successfully, may require the implemen-tation of multiple logical data models. Data modeling defines the relationships between data elements and structures. Data modeling techniques are often used to model data in a standard, consistent, predictable manner in order to properly manage it as a resource. The use of this standard is strongly recommended for all projects requiring a standard means of defining and analyzing the data resources within an organization. Such projects include:
• Incorporating a data modeling technique into a methodology;
• Using a data modeling technique to manage data as a resource;
• Using a data modeling technique for the integration of information systems;
• Using a data modeling technique for designing computer databases.
Data modeling may be performed during various types of projects and in multiple phases of the projects. Data models are progressive; there is no such thing as the final data model for a business or application. Instead a data model should be considered a living document that will change in response to a changing business.
The data models should ideally be stored in a repository so that they can be retrieved, expanded and edited over time. Bentley (2004) determined two types of data modeling:
• Strategic data modeling: This is part of the creation of an information systems strategy, in which an overall vision and architecture for information systems is defined. Information engineering is a methodology that embraces this approach.
• Data modeling during systems analysis: In systems analysis, logical data models are created as part of the development of new databases.
6.6.5 Class Diagrams
We have described class diagrams in previous chapters. In this section, we will review that information in a way that is relevant to the analysis phase. Class diagrams are used to describe a class based on the elements that make it up, as well as its relationships to other classes. In a previous chapter, we said that class
diagrams are made up of classes, interfaces, relationships and collaborations. More than one diagram may be necessary to describe a specific class, as varying levels of specificity are needed to describe the class in a specific context.
6.6.6 Use Case Diagrams
This walkthrough will set out one example of how to go about a use case analysis.
There are many variations of how to develop a use case analysis, and finding the right method can take time. First, a use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects. The Realization step sets up the framework within which an emerging system is analyzed. This is where the first, most general, outline of what is required by the system is documented. This entails a rough breakdown of the processes, actors, and data required for the system. These are what comprise the classes of the analysis.
Once the general outline is completed, the next step is to describe the behavior of the system that will be visible to the potential user of the system. While internal behaviors can be described as well, this is more related to designing a system rather than gathering requirements for it. The benefit of briefly describing internal behaviors would be to clarify with potential users that the system is not missing a vital component externally due to it not being completed internally. The overall goal of this step is to provide just enough detail to understand what classes are required for the system. Too much detail can make it difficult to change the system later on.
The next step narrows down the class list into those classes that are capable of performing the behavior needed to make the system function successfully. If no classes yet exist for a system, they must be created before this step can be com-pleted. Classes can be created in many ways from many sources. A few examples are: previous—but similar—systems, enterprise models, and data mining. Once classes are created and narrowed down, relationships must be developed between classes, now called analysis classes, which model the tasks of the system.
For each analysis class identified in the previous step, the responsibilities of the class must be detailed clearly. This will ensure that an individual class has a task to complete for which no other class in the system will also perform. The respon-sibilities of the different classes should not overlap.
After detailing the responsibilities of each analysis class, the relationships between the classes must be clarified next. There are four parts to this step. First, identify the classes to be used. Then, identify possible relationships between the classes. Next, for those with relationships, describe the nature of the relationship.
Finally, if applicable, identify the multiplicity of the relationship, meaning determine how many of the first class correspond to one object in the second class of the relationship.
120 6 Object-Oriented Analysis
Once the relationships between classes is understood, the next process is to detail the behavior the classes will exhibit and how they will interact in order to complete the system. This entails determining how the classes communicate and send messages along the timeline of the system process being developed. This is derived from the responsibilities of the classes previously identified. Determining what class the message goes to is a simple matter of following the associations set up in the previous step.
Throughout the use case analysis so far, attributes of the classes and objects
Throughout the use case analysis so far, attributes of the classes and objects