1. Software Engineering Chapter 8 Fall 2001

2. Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension of use cases, use cases are converted into a more formal description of the system.

3. Why?  Use cases must be kept as independent of each other as possible for simplicity.  Use cases must be described in the language of the customer.  Each use case must be structured to form a complete and intuitive specification of functionality.

4. After getting the requirements from the users and describing them as use cases, these use cases need to be analyzed.  Resolve issues such as concurrency.  Multiple accesses to the same data at the same time.  Relationships and dependencies among use cases.  Other system requirements that are transparent to the user.

5. Structure the requirements to facilitate:  understanding them by the developers  preparing them  changing them  reusing them  maintaining them

6. The analysis model  analysis classes  packages  interaction diagrams  handles shared resources See Table 8.1 page 175 (Use case model vs. analysis model)See Table 8.1 page 175 (Use case model vs. analysis model)

7. The purpose of the analysis is to produce a precise and detailed understanding of the requirements. This goes beyond what the user is directly concerned with. We are still talking about the requirements from the user’s perspective, but in much more detail than the use cases. Although the analysis may bring up questions that need to be discussed with the user, the user is not necessarily involved in the analysis. After the users help specify the requirements as use cases, the developers analyze those requirements. In particular, they analyze how the pieces fit together into a system and what problems might arise.

8. For example, in the use case model: Use Case 1Use Case 1  The bank teller processes a deposit for the customer.  The deposit is added to an account. Use Case 2Use Case 2  The customer later withdraws money.  The withdrawal is subtracted from an account.

9. In the analysis model:  It is determined that the deposit and withdrawal are affecting the same account if it is the same customer.  The relationship between the deposit and withdrawal may be better defined.

10. In the design model:  It is determined how the deposit and withdrawal use cases will be converted into program modules or classes.  For example, deposit might be one class in the actual program, and withdrawal might be another class.  As an alternative they might be combined into the same single class.

11. Artifact – Analysis Model

12. Analysis class  Boundary classes  Entity classes  Control classes

13. Class Diagram (see Fig. 8.11 page 187 and page 45)(see Fig. 8.11 page 187 and page 45)  realization of a use case in classes

14. Collaboration Diagram (Interaction Diagram) (see Fig 8.12 page 188)(Interaction Diagram) (see Fig 8.12 page 188)  puts actions on the lines of the class diagram to show the interactions among the classes

15. Trace Diagram (see Fig 8.9 page 186 and page 44)(see Fig 8.9 page 186 and page 44)  shows which use cases are realized by which classes

16. Flow of Events (see Example page 189)(see Example page 189)  A text description that explains the collaboration diagram

17. Special Requirements (see Example page 190)(see Example page 190)  description of nonfunctional requirements

18. Analysis Package  a grouping of analysis classes into a package  a way to organize classes into different groups and subgroups

19. Service Package  a group of functionally related classes  this group of classes can be used generally by several use cases  spell check might be an example  service packages are reusable  service packages are loosely coupled

20. Architecture Description  Architecturally significant artifacts of the Analysis Model  Analysis packages and their dependencies  Key analysis classes  Use-case realizations that realize critical functionality

21. Workers

22. Architect  responsible for overall integrity of the analysis model  ensures the analysis model as a whole is correct, consistent, and readable

23. Use-Case Engineer  make sure the diagrams and text are correct  responsible for the integrity of one or more use case realizations  and correctly realize the use case from the use case model

24. Component Engineer  make sure each analysis class fulfills the requirements made on it from the use case realizations in which it participates  maintains the integrity of one or more analysis packages

25. Workflow

26. Activity – Architectural Analysis  Identify analysis packages  Handle commonality among analysis packages  Define analysis package dependencies  Identify service packages  Identify obvious entity classes  Identify common special requirements

27. Activity – Analyze a Use Case  Identify analysis classes  Describe analysis object interactions  Capture special requirements

28. Activity – Analyze a Class  Identify responsibilities  Identify attributes  Identify associations and aggregations  Identify generalizations  Capture special requirements

29. Activity – Analyze a Package  Make sure the package contains the right classes  Limit the dependencies to other packages  Define and maintain the dependencies that do exist

30. Summary of Analysis  Analysis model  Analysis packages and service packages  Analysis classes and their responsibilities, attributes, relationships, and special requirements.  Use-case realizations  Architectural view of the analysis model