Chapter 20 Object-Oriented Analysis

1. Chapter 20Object-Oriented Analysis

2. The Objective of OO Analysis • The objective of OO analysis is to develop a model that describes computer software as it works to satisfy a set of customer-defined requirements. • Elicit customer requirements for the system; • Identify scenarios or use-case; • Select classes and objects using basic requirements as a guide; • Identify attributes and operations for each system object; • Define structures and hierarchies that organize classes; • Build an object-relationship model; • Build an object-behavior model; • Review the OO analysis model against use-cases / scenarios;

3. The OOA Landscape • OOA methods: • The Booch Method; • The Rumbaugh Method; • The Jacobson Method; • The Coad and Yourdon Method; • The Wirfs-Brock Method;

4. The Booch Method • Booch’s OOA micro development process: • to identify classes and objects; • to identify the semantics of classes and objects; • to define relationship among classes and objects; • to conduct a series of refinements to elaborate the analysis model;

5. The Coad and Yourdon Method • A brief outline of Coad and Yourdon’s OOA process follows: • identify objects using “what to look for” criteria; • define a generalization-specification structure; • define a whole-part structure; • identify subjects (components); • define attributes; • define services;

6. The Jacobson Method (OOSE) • OOSE: Object-Oriented Software Engineering • The Jacobson OOA process: • identify system user and their responsibility; • construct requirement model; • construct analysis model;

7. The Rambaugh Method (OMT) • OMT: Object Modeling Technique • The analysis activity creates three models: • the object model; • the dynamic model; • the functional model;

8. The Wirfs-Brock Method • A brief outline of Wirfs-Brock’s analysis-related tasks follows: • Evaluate the customer specification; • Extract candidate classes from the specification via grammatical parsing; • Group classes in an attempt to identify super-classes; • Define responsibilities for each class; • assign responsibilities to each class; • Identify relationship between classes; • Define collaboration between classes based on responsibilities; • Build hierarchical representations of classes; • Construct a collaboration graph for the system;

9. Unified Modeling Language 1.0 Unified 0.8 Booch ‘93 OMT-2 Booch ‘91 OOSE OMT-1 UML: 设立对象建模标准

10. Domain Analysis The input and output for domain analysis: class taxonomies technical 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

11. The Domain Analysis Process • Define the domain to be investigated; • Categorize the items extracted from the domain; • Analysis each application in the sample; • Develop an analysis model for the objects;

12. Generic Components of OOA Model • Static view of semantic classes; • Static view of attributes; • Static view of relationships; • Static view of behaviors; • Dynamic view of communication; • Dynamic view of control and time;

13. 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

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 member 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 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. Selecting Classes—Criteria retained information needed services multiple attributes common attributes common operations essential requirements

17. 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.

18. UML: Use-Case Diagram

19. 单向关联 使用用例 使用者 共享继承 自定义关联

20. 可能继承 自定义关联

21. 对象: 类 事件流 及其方向 各种说明和 标记说明 不同的类 时间 Sequence Diagram

22. 类 对象 和类 对象 Actor

27. Class-Responsibility-Collaborator(CRC) Modelling • A CRC model is really a collection of standard index cards that represent classes. • The name of class; • The class responsibilities; • The collaborators; • The taxonomy of class types: • Device classes; • Property classes; • Interaction classes;

28. CRC Modeling

29. Class Diagram

30. Class Diagram

31. 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.

32. Collaborations • Collaborations represent requests from a client to a server in fulfillment of a client responsibility. • The is-part-of relationship; • The has-knowledge-of relationship; • The depends-upon relationship;

33. Collaborations Diagram

36. 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.

37. Defining Structures and Hierarchies UML: Class Diagrams Generalization-specialization Composite aggregates

38. Defining Subjects and Subsystems UML: Package Reference

39. The Object-Relationship Model Relationships between Objects:

40. 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

41. UML: State Transition

42. State Diagram

45. UML: Event Trace

46. 4+1视图结构模型 Logical View Functionality Implementation View Software Management Reuse,Portability Use Case View Understandability Usability 最终用户 软件工程者 Process View Performance Availablity Fault Tolerance Deployment View Performance Availablity Fault Tolerance Scalability Delivery and Installation 系统工程者 系统集成者

47. 例子：逻辑视图

48. 例子：Use Case View

49. 用UML建立学籍管理过程模型 • 上海交通大学想开发一个学籍管理系统，包括下列内容： • 研究生院/教务处建立一个本学期的课程目录 • 一种课程可能有不同的时间、地点和听课对象的安排 • 有不同的数据库来管理有关课程，学生和教师的不同信息 • 每个学生可选4门必修课和2门选修课 • 一旦学生进行了选课注册，学校财务系统根据学生的注册和奖学金状态向学生发出交款通知 • 学生可以利用这个系统在注册后的一段时间内修改选课计划 • 教授们可以用这个系统查询他要上的课程的注册情况 • 系统的每一个用户通过他自己的口令验证来访问系统

50. 确定系统用户 • 系统用户是人或其它外部系统他/它将在系统开发和运行过程中和系统进行交互、对话。 Administrators Professors Students Billing System