Object-Oriented Analysis: Importance, Steps, and Approaches

1. Chapter 21Object-Oriented Analysis

2. What is OOA? Before you can build an object-oriented system, you • Have to define the classes • (objects) that represent the problem to be solved, • The manner in which the classes relate to and interact with one another • The inner workings (attributes and operations) of objects, and • The communication mechanisms (messages) that allow them to work together.

3. Why it is impotant and What are steps? The intent of OOA is to define all classes that are relevant to te problem to be solved—the operations and attributes associated with them, the relationships between them, and behavior they exhibit. To accomplish this, a number of tasks must occur: 1. Basic user requirements must be communicated between the customer and the software engineer. 2. Classes must be identified (i.e., attributes and methods are defined). 3. A class hierarchy must be specified. 4. Object-to-object relationships (object connections) should be represented. 5. Object behavior must be modeled. 6. Tasks 1 through 5 are reapplied iteratively until the model is complete.

4. A Unified Approach to OOA • Over the past decade, Grady Booch, James Rumbaugh, and Ivar Jacobson have collaborated to combine the best features of their individual object-oriented analysis and design methods into a unified method. • The result, called the Unified Modeling Language (UML), has become widely used throughout the industry. • UML allows a software engineer to express an analysis model using a modeling notation that is governed by a set of syntactic, semantic, and pragmatic rules.

6. The Wirfs-Brock method. Wirfs-Brock, Wilkerson, and Weiner [WIR90] do not make a clear distinction between analysis and design tasks. Rather a continuous process that begins with the assessment of a customer specification and ends with design is proposed. A brief outline of Wirfs-Brock analysis-related tasks follows: • Evaluate the customer specification. • Extract candidate classes from the specification via grammatical parsing. • Group classes in an attempt to identify superclasses. • Define responsibilities for each class. • Assign responsibilities to each class. • Identify relationships between classes. • Define collaboration between classes based on responsibilities. • Build hierarchical representations of classes. • Construct a collaboration graph for the system.

7. Although the terminology and process steps for each of these OOA methods differ, the overall OOA processes are really quite similar. To perform object-oriented analysis, a software engineer should perform the following generic steps: 1. Elicit customer requirements for the system. 2. Identify scenarios or use-cases. 3. Select classes and objects using basic requirements as a guide. 4. Identify attributes and operations for each system object. 5. Define structures and hierarchies that organize classes. 6. Build an object-relationship model. 7. Build an object-behavior model. 8. Review the OO analysis model against use-cases or scenarios.

8. OOA- A Generic View • define use cases • extract candidate classes • establish basic class relationships • define a class hierarchy • identify attributes for each class • specify methods that service the attributes • indicate how classes/objects are related • build a behavioral model • iterate on the first five steps

9. Unified Modeling Language (UML) User model view. This view represents the system (product) from the user’s (called “actors” in UML) perspective. Structural model view. Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled. Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the system. Implementation model view. The structural and behavioral aspects of the system are represented as they are to be built. Environment model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented.

10. Domain Analysis class taxononmies techncial literature DOMAIN SOURCES OF reuse standards DOMAIN ANALYSIS existing applications DOMAIN functional models ANALYSIS MODEL KNOWLEDGE customer surveys domain languages expert advice current/future requirements Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain

11. Define the domain to be investigated • Categorize the items extracted from the domain • Collect a representative sample of applications in the domain. • Analyze each application in the sample • Develop an analysis model for the objects.

14. Use Cases • a scenario that describes a “thread of usage” for a system • actors represent roles people or devices play as the system functions • users can play a number of different roles for a given scenario

15. Developing a Use Case • What are the main tasks or functions that are performed by the actor? • What system information will the the actor acquire, produce or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes?

16. UML: Use-Case Diagram

17. CRC Modeling

19. Guidelines for Allocating Responsibilities to Classes 1. System intelligence should be evenly distributed. 2. Each responsibility should be stated as generally as possible. 3. Information and the behavior that is related to it should reside within the same class. 4. Information about one thing should be localized with a single class, not distributed across multiple classes. 5. Responsibilities should be shared among related classes, when appropriate.

20. Reviewing the CRC Model 1. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. 2. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. 3. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card. 4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. 5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

21. UML: Class Diagrams Generalization-specialization Composite aggregates

22. UML: Package Reference

23. Relationships between Objects

24. Object-Behavior Model 1.Evaluate all use-cases to fully understand the sequence of interaction within the system. 2. Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3. Create an event trace [RUM91] for each use-case. 4. Build a state transition diagram for the system 5. Review the object-behavior model to verify accuracy and consistency

25. UML: State Transition

26. UML: Event Trace