Chapter 20 Object-Oriented Analysis

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;

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

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;

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;

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;

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

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;

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

Domain Analysis The input and output for domain analysis: class taxonomies technical literature SOURCES OF reuse standards DOMAIN DOMAIN existing applications DOMAIN ANALYSIS functional models KNOWLEDGE ANALYSIS MODEL customer surveys domain languages expert advice current/future requirements

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;

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;

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

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

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?

Selecting Classes—Criteria retained information needed services multiple attributes common attributes common operations essential requirements

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.

UML: Use-Case Diagram

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

自定义关联 可能继承

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

Actor 对象 和类 类

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;

CRC Modeling

Class Diagram

Class Diagram

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.

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;

Collaborations Diagram

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.

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

Defining Subjects and Subsystems UML: Package Reference

The Object-Relationship Model Relationships between Objects:

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

UML: State Transition

State Diagram

UML: Event Trace

4+1视图结构模型 Logical View Implementation View Use Case View Process 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 系统集成者 系统工程者

例子：逻辑视图

例子：Use Case View

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

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

使用用例 使用用例描述了系统对外表现的特征和性能 对每个系统用户进行分析，抽象他和系统之间可能的交互方法 每个使用用例是由系统用户通过对话框进行的一系列相关活动 对每个系统用户进行分析，抽象他和系统之间可能的交互方法 系统管理员－维护课程数据库，学生数据库和教师数据库 教授－选课，课程注册情况查询 学生－注册，浏览，增加，删除具体课程 财务系统－接受注册情况、计算注册费用，发出交款通知 Maintain Curriculum Request Course Roster Maintain Schedule

通过顺序事件流描述说明每一个使用用例 对每一个使用用例，从系统用户的角度，写出它的正常事件流 具体说明为了执行这样一个使用用例，系统需要经历哪些过程内容 典型的过程内容包括： 使用用例的激发和停止方法 正常事件流 其它可能的正常事件流 所有的异常事件流

确定不同事件间的相关关系 我们从学生注册开始。为了注册，他需要先行登录到学籍管理系统中来。首先，他先要输入他的口令进行身份验证。系统在验证了身份之后将检查他的注册状态：如果没有注册，弹出对话框请他选课注册；如果已经注册了，提示他选择对现有的课程目录做些什么改动 如果选择的操作是增加，那么加课的子事件流将被激发。 如果选择的操作是删除，那么删除课程的子事件流将被激发。 如果选择的操作是浏览，那么浏览的子事件流将被激发。 如果选择的操作是退出，那就标志着该事件流的结束，注册管理员将自动退出系统。 ...

Use Case 图 Use case图用来描述系统用户和使用用例之间的关系 Request Course Roster Professors Students Maintain Schedule Billing System Maintain Curriculum Administrators

Uses and Extends Use Case Relationships 随着使用用例的细化，我们将发现更多的使用用例之间的关系 «uses»关系可用来描述某一个特性可能为一个或多个其它使用用例所共有。 « extends »关系描述的是可能扩展（ optional ）的特性 Register for courses <<uses>> Logon validation Maintain curriculum

使用用例之间的关系 使用用例描述了系统的外在特性 交互过程图描述了不同的使用用例的执行过程和不同对象之间的关系。 UML提供了两种不同的交互过程图 事件顺序图（Sequence diagrams） 对象合作图（Collaboration diagrams）

事件顺序图-Sequence Diagram 事件顺序图按事件发生的时间顺序来描述不同对象之间的交互和联系 : Student registration registration manager math 101 math 101 section 1 form 1: fill in info 2: submit 3: add course(joe, math 01) 4: are you open? 5: are you open? 6: add (joe) 7: add (joe)

对象合作图-Collaboration Diagram 对象合作图以对象为核心来表示各个不同对象之间的连接关系 : Registrar course form : CourseForm theManager : CurriculumManager aCourse : Course 1: set course info 2: process 3: add course 4: new course 

类图 类图是系统逻辑视图的表示方法。它用来描述对象的特性以及不同对象之间的关系 UML通过类图来描述下列基本元素 不同的类以及它们的属性 (attribute) 和行为特性 (behavior) 不同类之间的关联 (association)、聚合 (aggregate)、相关 (dependence) 和继承 (inheritance) 关系 类的实例数量特性（Multiplicity）和边历方向（ navigation indicators） 角色名（Role names）

类（Classes） 类是具有相同结构，相同特性，相同关系和相同语义的对象的集合 类是通过考察事件顺序图和对象合作图中的对象总结、抽象出来的 类用一个分成三部分的矩形来表示 类应该用特定领域的通用词汇来命名 应该建立一个类名的命名规范 如：可以规定所有的类都用第一个字母大写的名词或名词组合来命名。在名词组合中，要求每一个单词的第一个字母大写

类举例（Classes） ScheduleAlgorithm RegistrationForm RegistrationManager Course Student Professor CourseOffering

操作（Operations） 类的活动特性是由它的操作来定义的 类的操作可以有观察交互过程图来确定 registration form manager 3: add course(joe, math 01) RegistrationManager addCourse(Student,Course)

属性（Attributes） 类的静态结构是通过它的属性来描述的 类的属性可以通过观察类的定义，问题的需求定义和通过领域知识的分析来逐步确定 CourseOffering number location time Each course offering has a number, location and time

类的三部分的描述方法 ScheduleAlgorithm RegistrationForm Course name numberCredits open() addStudent(StudentInfo) RegistrationManager addStudent(Course, StudentInfo) CourseOffering location open() addStudent(StudentInfo) Professor name tenureStatus Student name major

对象间关系（Relationships） 对象之间的关系为不同对象之间通信通过了一条通道 可以通过对事件顺序图/对象合作图的观测来确定两个对象是否存在关系，如果有，属于哪一类关系 UML规定了三种关系 关联 聚合 相关

对象间关系（Relationships） 关联描述了两个类之间的双向联系 关联是用连接两个类的一根实线来描述的 聚合描述的是一种比较紧密的相关关系。它描述的整体和部分之间的关系 聚合用一根实线来连接相关的类。在表示整体的一端有一个菱形记号 相关关联（ dependency relationship）表示的是一种弱相关关系。她表示的是类似客户、服务方的关系，其中客户并不了解服务方的语义信息 相关关联用一个虚线从客户方指向服务方

确定不同类之间的关系 类之间的关系主要是通过考察交互过程图来确定的 RegistrationManager Course 如果两个对象要通信，它们之间必修存在一个通道（关系）。 RegistrationManager Course Registration Math 101: Manager Course 3: add student(joe)

各种关系示例（Relationships） ScheduleAlgorithm RegistrationForm RegistrationManager Course addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location tenureStatus Student Professor CourseOffering

数量修饰和边历方向 数量修饰定义有多少对象参与了这一关联关系 数量修饰是指某个类相对于另一个类的一个实例，这个类可能有的实例的数量 对于每一个关联和聚合关系而言，我们要分别确定关系两端的数量修饰 虽然关联和聚合在缺省情况下都定义成是双向关联的，但在很多情况下我们需要对此缺省值做出调整以确定明确的边历方向 如果有了明确的边历方向，则用箭头来指明边历方向

数量修饰和边历方向应用用例 ScheduleAlgorithm RegistrationForm 0..* RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location tenureStatus ScheduleAlgorithm 1 0..* 1..* 4 3..10 0..4

继承 继承描述的是父类和子类之间的继承关系 UML中定义了两种不同的继承描述方法: Generalization Specialization 通过继承关系，我们可以把系统的类构造成一个具有不同层次关系的结构树。并将其中不同类所共有的属性、操作和关系定义在较高的层次。 继承用一根实线来连接相关的类。在表示父类的一端有一个三角形记号

继承关系的图示 ScheduleAlgorithm RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location tenureStatus ScheduleAlgorithm name RegistrationUser

对象的状态 状态变换图描述了 给定类的生命历史 引起状态变换的事件 状态变换带来的新活动 状态变换图是为那些具有显著动态特性的对象而建立的

状态变换图 Add student[ count < 10 ] Add Student / Set count = 0 Cancel Initialization Open do: Initialize course do: Finalize course do: Notify registered students entry: Register student exit: Increment count Canceled Closed

物理世界的建模 软构件组成图说明了不同软构件之间的组织和依存关系 软构件的可能形式包括 源代码构件 实时构件或 可执行构件

部件结构图 Register.exe Billing.exe Billing System People.dll User Course.dll People.dll Course User Course Offering Student Professor

系统的物理部署图 系统构件的物理部署图描述了系统不同运行过程的配置以及建立在其上的软件的执行过程 物理部署图描述了软件模块在企业的分布情况

物理部署图 Registration Database Main Building Library Dorm 