需求的OO描述方法课件.ppt

1、需求的OO描述方法 本章内容先导案例概述1 统一建模语言和对象管理组织 2 OO的需求 3 系统活动：OO的用例/场景视图 4 确定输入和输出系统顺序图 5 问题域建模域模型类图 6 OO模型的集成 要点回顾阅读章节要求2022年6月7日星期二2/117先导案例 无限电子公司：供应链一体化2022年6月7日星期二3/117概述 在OOA中需要使用事实发现技术。 事实发现行为称做发现活动，发现必须先于理解。 本章学习发现的下一个阶段：建立理解。 事件发生在系统必须响应的商业环境中。事件被定义和记录在事件表中。新系统必须能够通过运行系统活动(用例)来响应商业事件。 2022年6月7日星期二4/11

2、7 系统的信息(包含在商业过程中的事物信息 )存储需求或使用传统方法中的ERD进行记录，或用OO方法中的类图进行记录。 学习：使用OO的分析模型和技术来理解和定义新系统的需求。 OO的分析和OO设计之间的界限并不明显，因为系统的设计就是对分析阶段中用于定义需求的模型进行改进和扩展得到的。2022年6月7日星期二5/117面向对象分析(OOA) 系统分析过程中使用对象建模的方法被称为面向对象分析(OOA)。 2022年6月7日星期二6/117OOA技术用于 研究现有对象，看它们是否能够被复用或者被调整用于新的用途； 定义各种新对象和修改后的对象，它们将与现有对象一起组合成一个有用的企业计算应用系

3、统。2022年6月7日星期二7/117对象建模(Object Modeling) 是一种用于辨识系统环境中的对象和这些对象之间关系的技术。 对象建模方法要求使用完全不同于数据建模和过程建模的方法和图形记号。 2022年6月7日星期二8/117术语 对象:某种存在的，或者能被看到、触摸或以其他方式感觉到的事物，用户就该事物存储数据和相关行为。 属性:表示关于一个对象相关特征的数据。 对象实例:由描述特定的人、地点、事物或者事件的属性值构成。 行为:指的是对象可以做的事情，以及在对象数据(或属性)上执行的功能。在OO环境中，对象的行为通常被称为方法、操作或者服务。 封装：几项内容一起打包成一个单元

4、(信息隐藏)。2022年6月7日星期二9/117考虑我们所处的环境 教室中的所有人，我们中的每一个都代表人对象的一个实例; 我们中的每一个都可以按照一些公共属性描述，例如：姓名、社会保险号、电话号码、地址等。2022年6月7日星期二10/117对象的行为 当看到周围环境中的门对象时，可能仅仅看到一个不能思考的静止对象几乎很少执行什么动作。 在用于系统开发的OO方法中，门对象可以同假定能够在其上的行为相关联。 例如，门可以打开，可以关闭，可以锁上，或者可以开锁。 所有这些行为都与门对象相关，并且由门对象实现，而不是由其他对象实现。2022年6月7日星期二11/117以电话对象为例 什么行为同一个

5、电话相关联？ 随着技术的进步，我们实际上有了语音激活的电话，我们可以应答、拨号、挂断，还可以执行其他与电话相关的行为。 因此，用于系统开发的OO方法要求我们调整通常看待对象的方式。2022年6月7日星期二12/117重要的OO原理 对象单独地负责执行任何在其数据(或属性)上操作的功能或者行为。 例如：只有你(一个对象)可以修改(行为)你的名字和家庭住址(你的属性)。 引出对象的一个重要概念，即封装。 对象的属性和行为都被封装到一起作为那个对象的一部分。 访问或修改对象属性只能通过那个对象的行为来实现。2022年6月7日星期二13/1171 统一建模语言和对象管理组织 OMG是一个由800多个软

6、件销售商、开发商和组织组成的共同体，他们致力于发展和传播OO系统。 成立于1989年。 使命：在分布式计算系统的开发中提高应用对象技术的理论和实践水平。 目标：为基于广泛接口规格的OO的应用程序提供一个通用的体系框架。 2022年6月7日星期二14/1172 OO的需求 系统开发过程开始于确定事件和事物。 事件：新系统所必须考虑的商业过程； 事物：包含在商业过程中的问题域对象。 过程和对象通常一起定义(不断切换)。 必须学会将所有不同的模型和它们组合在一起生成完整的系统功能需求图。 本章主要讨论一个关于模型的集合，它根据OO方法中的用例来捕获系统需求四种模型用例图、用例描述、活动图和系统顺序图

7、，用来从不同的观点描述系统用例。 2022年6月7日星期二15/117使用模型来记录需求最大的好处 在于它能帮助系统开发员仔细和清楚地考虑处理的细节，以及系统相关人员的信息需求。 2022年6月7日星期二16/117四种模型 1. 用例图 2. 系统顺序图 3. 消息 4. 状态图2022年6月7日星期二17/1171. 用例图 一种用以显示不同的用户角色和这些用户角色如何使用系统的图。 以图形化的方式描述系统与外部系统和用户的交互。 换言之，它们以图形化的方式描述谁将使用系统，以及用户期望以什么方式与系统交互。2022年6月7日星期二18/117 目的：识别新系统的“用法”或用例，即识别如何

8、使用系统。 用例图本质上是事件表的延伸。 用例图是用于记录系统必须支持的所有功能的一种简便方法。可以用一个综合的用例图来描述整个系统。 活动图可以用来定义用例。 2022年6月7日星期二19/1172. 系统顺序图(SSD) 在用例或场景中，用于显示外部参与者和系统之间的消息顺序的图。 以图形化的方式描述在一个用例或操作的执行过程中对象如何通过消息互相交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。 用来定义一个用例的输入和输出，以及在用户和系统之间交互的顺序。 用于联系用例详细描述或活动图。 顺序图中，出入系统的信息流被称为消息。2022年6月7日星期二20/1173. 消息 用例

9、内部对象之间的通信。 当一个对象调用另一个对象的方法(行为)以请求信息或者某些动作时发生的通信。2022年6月7日星期二21/1174. 状态图 一种用以显示对象在各阶段中的生命和转换的情况的图。 用于建模一个特定对象的动态行为，说明一个对象的生命周期对象可以经历各种状态，以及引起对象从一个状态向另一个状态转换的事件。 状态图表(状态图)描述了每个对象状态的集合。 类图中所标识的一些对象有些状态情形需要跟踪，这些状态直接决定了对象的处理过程。2022年6月7日星期二22/117 客户订单有几个比较重要的状态条件，它们控制订单的处理过程，例如，订单只有在完成后才会发货。 状态图标识这些状态条件并

10、且标明允许的处理过程。 同时，状态图也可用于设计过程，以确定系统本身的各种状态，以及能够处理的可允许的事件上。 状态图既可以看做是分析工具，也可以看做是设计工具。 2022年6月7日星期二23/1173 系统活动：OO的用例/场景视图3.1 用例和参与者3.2 用例图3.3 开发用例图3.4 用例详细描述2022年6月7日星期二24/117 用例分析的目标用来标识和定义系统必须支持的所有商业过程。 分析员在综合等级和详细等级两个层次上定义用例。 事件表和用例图为一个系统提供了所有用例的综合。 关于每个用例的详细信息使用用例描述、活动图和系统顺序图，或者这些模型的组合进行说明。 2022年6月7

11、日星期二25/1173.1 用例和参与者 用例：系统运行的活动，通常由系统用户来响应需求。 用例中蕴涵使用系统的人：参与者。 参与者通常处于自动化系统边界之外，但是它也有可能是系统手动部分的成员。2022年6月7日星期二26/117参与者与事件的源的区别 参与者的概念与在事件表中所定义的事件的“源”在内涵上略有不同。 事件的源：指事件的发起者，例如一个用户，并且它通常在系统(包括手动系统)的外部。 参与者实际上是亲自和计算机系统进行交互的人。2022年6月7日星期二27/117定义参与者和系统进行交互的人定义为参与者。 (自动化系统所必须响应的交互)将能够接触自动系统的人定义为参与者。有些参与

12、者可能是其他的系统或者从系统接受服务的设备。把参与者看成一个角色。 考虑参与者和用例，认为用例是参与者想要完成的目标。 2022年6月7日星期二28/117例：RMO中用例“产生新订单”的情况可能会涉及一个销售代表在电话里与一名客户进行交谈。如果这位客户直接在Internet上订货，那他也是个参与者。 标志目标的方法：订单职员使用系统来生成新订单。 3.2 用例图 用例图：概括有关参与者和用例信息的一个图形化的模型。 1. 自动化边界和组织 2. 组织用例图的方法 3. 用例之间的关系 4. 用例图与事件表的比较2022年6月7日星期二29/117例：有一个参与者的简单用例。*1. 自动化边界

13、和组织 在全套的用例上画一条边界线。该边界是自动化边界。它表示环境(参与者的居住地)和自动系统的内部功能之间的边界。2022年6月7日星期二30/117员对前面的图进行了扩展，增加了参与者和用例。在该实例中，订单员和用户都可直接访问系统。正像有关系线连接表示的那样，每个参与者可以操作所有的用例 。2. 组织用例图的方法使用子系统 包含涉及一个特定参与者的所有用例2022年6月7日星期二31/117使用子系统 订单输入子系统用例图，显示系统边界 2022年6月7日星期二32/117员RMO客户支持系统用例图(子系统) 2022年6月7日星期二33/117*包含涉及一个特定参与者的所有用例2022

14、年6月7日星期二34/117图表示了与一个客户参与者相关的所有用例。该图在表明所有通过Internet访问的活动时非常有用。分析员可以选择绘制基于项目团队需要的用例图。如果计划与市场部门经理会面讨论所有涉及直接客户交互的用例，则图中的用例图会很有用。3. 用例之间的关系 扩展 包含泛化2022年6月7日星期二35/117关系 通常在用例图的开发过程中，一个用例需要用到通用子程序所提供的服务。 例如，“订单输入子系统”的两个用例是“产生新订单”、“更新订单”，这两个用例均须检查客户的账号是否正确。 因此，可以定义一个通用的子程序来完成这个功能，并且它变成了一个附加用例。 2022年6月7日星期二

15、36/117有关系用例的订单输入子系统 关系可读做“产生新订单验证用户账号”。 关系也称关系或者关系。2022年6月7日星期二37/117名为“验证用户账号”的用例，它被 “产生新订单”、“更新订单”两个用例调用。用例之间的关系由带箭头的连接线表示。 “检查条目可用性”可能是关系的一部分。分析员可定义两种类型的关系：一种是通用内部子程序，如“验证用户账号”，它不被外部参与者直接引用；另一种是能被外部参与者直接引用，如“检查条目可用性”。扩展 当某个基本用例由于需要附加一个用例来扩展或延伸其原有功能时，附加的扩展用例与原有的基本用例之间的关系就体现为扩展关系。 在UML中可使用带有说明的依赖关系

16、表示“扩展关系”。 例：网上购物系统中有“支付”用例，而“网上支付”用例是“支付”用例的扩展用例。 2022年6月7日星期二38/117 支付网上支付基本用例扩展用例* 从基本用例A到扩展用例B的扩展关系表明：按基本用例A中指定的条件，把扩展用例B的行为插入到由A中的扩展点定义的位置。 也就是说基本用例A可以单独存在，但在一定的条件下，它的行为可被另一个用例B的行为扩展。 一个用例可以扩展多个用例，一个用例也可以被多个用例扩展。 扩展用例不能作为动作序列单独出现，但基本用例在缺少任何扩展用例的情况下也必须是独立的用例。2022年6月7日星期二39/117包含 如果在若干个用例中有某些相同的动作

17、，则可把这些相同的动作提取出来单独构成一个用例(称抽象用例)。(将多个用例中的公共部分抽取出来作一个单独用例)。 当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例中的所有动作。 UML中使用带有说明的依赖关系表示“包含关系”。 例：网上购物系统中有一个“订购”用例，而“查询”用例是“订购”用例的包含用例。2022年6月7日星期二40/117*订购查询包含用例 如果从用例A到用例B存在包含关系，则用例A在它内部说明的某一位置上显式地使用用例B的行为的结果。 被包含的用例B作为包含它的用例A的功能的一部分出现。 可以把包含关系想像为基本用例调用供应者用例，基本用例仅仅依赖供应者用例执行的结

18、果，而不依赖供应者用例的内部结构。 一个用例可以包含多个用例，一个用例也可以被多个用例包含。2022年6月7日星期二41/117例：网上订购商品 软件系统需要对顾客的信用进行检查，检查输入的信用卡号是否有效，信用卡是否有足够的资金支持本次订购。由于该功能在“订购”过程中使用，因此是包含关系。 在执行“改变订购量”用例时，只有预定量改变时才执行“检查信用”用例，如果预订量不改变，则不执行“检查信用”用例。 由于“检查信用”用例是可选执行的，因此，用例之间存在扩展关系。箭头从可选运行的用例“检查信用”指向被扩展的用例。2022年6月7日星期二42/117顾客订购检查信用改变预订量扩展和包含之间的异

19、同 两种关系意味着从几个用例中抽取那些公共的行为并放入一个单独的用例中，而这个用例被其他用例扩展或包含。 包含和扩展的目的是不同的。 通常在描述一般行为的变化时采用扩展关系； 在两个或多个用例中出现重复描述又想避免这种重复时，可以采用包含关系。2022年6月7日星期二43/117泛化 从用例A到用例B之间的泛化关系表明：父用例表示通用的行为序列。通过插入额外的步骤或定义步骤，子用例特化父用例。 UML表示用例泛化的方法与类相同。 例：在线股票经纪人系统把通用用例“做交易”特化为子用例“交易债券”、“交易股票”和“交易期权”。父用例包含所有交易类型都会执行的步骤，如输入交易密码。每个子用例都包含

20、了针对某种交易类型特别安排的额外步骤，如输入期权的行权日期。 2022年6月7日星期二44/117做交易交易债券交易股票交易期权4. 用例图与事件表的比较模型的观点有细微的不同标识临时事件和状态事件时有差别定义一个用例支持多个商业事件2022年6月7日星期二45/117模型的观点有细微的不同 事件表通常注意商业过程。 它通过标识商业事件，以及这些事件的外部、初始化源的信息来关注商业过程。 外部的源是引起商业事件初始化的原因，并且它们能从自动系统中轻松的移除。 用例图强调了自动系统。因为它只与自动系统相连，所以参与者与自动系统有联系并且不一定是商业事件的发起者。2022年6月7日星期二46/11

21、7标识临时事件和状态事件时有差别 由于用例通常被外部参与者初始化，所以如果分析员不仔细标识每一个事件，那么临时事件和状态事件经常被忽略。 用例定义太窄将成为用例建模的一个缺陷。 如：在线系统菜单常包括用于表示事件表中临时事件的菜单选项，以便这样的事件能够被用户触发并且作为纯粹的临时事件。 建议：为每个临时事件和状态事件创建用例以确保这些需求不被忽略。2022年6月7日星期二47/117定义一个用例支持多个商业事件 满足3个标准，则定义一个用例： 本质上相同的处理发生在自动系统内部； 本质上相同的信息被更新； 本质上相同的信息从事件中输入和输出。 例：开发事件表过程中，添加新用户和更新用户两个事

22、件已被标识出来。从系统观点出发，两个商业事件的用例几乎一样，因为它们都包含更新用户文件。可定义一个单独的用例来支持这两个商业事件，该用例可命名为“维护客户账户信息”。2022年6月7日星期二48/117分析员会同时完成事件表和用例图，并不断更新。在商业事件对单一、简单的数据文件或表进行基本的文件维护时，这些条件常常能够满足。有时单一事件可触发非常复杂的处理需求，这将使系统活动分解为两个用例以更好地管理系统复杂性，使其变得更加有意义。 3.3 开发用例图1. 两个切入点 2. 两步迭代3. CRUD分析2022年6月7日星期二49/1171. 两个切入点 若创建了事件表，则用事件表标识用例 标识

23、使用系统的参与者和它们执行的功能2022年6月7日星期二50/117若创建了事件表，则用事件表标识用例 仔细分析事件表中的每个事件以确定系统为支持这些事件、发起这个事件的参与者，以及由于该事件而触发的其他用例所执行的处理。 当一个模型转向另一个更详细的模型时需要不断精炼，仔细分析事件和事件表非常重要。 开发人员可将一个单一的事件标识为用例，如所需的处理很相似，可把几个事件组合成一个单独的用例；或如果处理很复杂，也可标识多个用例。 多个用例的标识通常发生在它们有关系和两个用例从一个大用例分解得到时，或发生在一个附加用例按照通用子程序的方式被定义时。 2022年6月7日星期二51/117 该图显示

24、的客户支持子系统是使用该方法开发。图中定义的绝大多数用例直接来自事件表。 用例名称来自事件表的活动/用例栏中的描述。 例外:由于临时事件通常可手动发起,所以要为每个临时用例使用标识外部参与者选项。 “客户修改账户信息”事件。在该实例中，用例定义扩展到和所有维护客户信息相关的场景中。同样，该用例被命名为维护客户账户信息，指的是添加、更新和删除。 这些都是用例对事件表进行提炼更新的例子。 2022年6月7日星期二53/117RMO客户支持系统的完整事件表标识使用系统的参与者和它们执行的功能 若没创建事件表，则开发用例图的另一个切入点是标识使用系统的参与者和它们执行的功能。 记住两个前提条件： 为一

25、个自动系统创建自动化边界，这样标识的参与者就能和这个系统进行联系； 必须假定拥有完美的技术，确定用例是基于商业事件而不是像登录系统一样的技术活动。 只有给出上述前提，才可通过两步迭代来开发用例图。 2022年6月7日星期二54/1172. 两步迭代标识系统的参与者 开发这些角色的目标表2022年6月7日星期二55/117标识系统的参与者 参与者通常由用户扮演。不能把参与者列成如Bob先生这样的形式，而应该标识出这些人所处的特定的角色。 记住，在一个系统中同一个人可以有多个特定的角色。 理解和辨识系统所有可能使用的角色是重要的。其他的系统也可以成为系统的参与者。2022年6月7日星期二56/11

26、7开发这些角色的目标表 目标指参与者执行完成一些商业功能的任务。 目标通常是类似营销、接受用户反馈或者订单发货这样的任务。 目标是能够被标识和描述的工作单元。 在目标完成时，系统数据在一段时间内是不会改变的。 两个步骤常应用于项目组成员和用户的集体讨论中，并没什么捷径可以用来发现或标识用例。 2022年6月7日星期二57/1173. CRUD分析 将标识后的用例与域模型类图进行比较(复查)。 需要类图中每个类都有足够的用例来支持创建新对象实例、读取或者报告这些对象、更新这些对象并且在许多例子中删除对象实例。 检查在域模型类图中的每个类并确定在用例图中有用例来支持所有适合该应用的CRUD功能。2

27、022年6月7日星期二58/117RMO的一个活动数据矩阵 2022年6月7日星期二59/117CRUD分析需要类图中每个类都有足够的用例来支持创建新对象实例、读取或者报告这些对象、更新这些对象产且在许多例子中删除对象实例。 用例不应该命名为创建或者更新，但是潜在的处理可以添加新的实例或者更新已存在的实例。 例如，一个名为“记录支付情况”的用例并没有清楚地指出一个新的支付对象被创建，但是用例的详细描述却指出这个对象被创建了。用例“产生新订单”可以创建订单条目对象和更新库存条目对象。 在其他例子中，许多用例以维护两字开头命名，以覆盖常规的添加、更新、读取和删除操作。2022年6月7日星期二60/

28、117 为了做CRUD分析，只须看一下在域模型类图中的每个类并确定在用例图中有用例来支持所有适合该应用的CRUD功能。 切记：在集成系统中，一个系统可能负责创建对象，而另外的系统可以只更新它们。 CRUD分析方法提供了一种交叉检验方法(不是最终的解决方案)，并且提供了确认重要的系统集成需求的机会，这些需求如果不用该方法逆行分析可能就不明显了。2022年6月7日星期二61/1173.4 用例详细描述0. 场景或者用例实例 1. 简单描述2. 中间描述3. 完全展开描述4. 活动图描述2022年6月7日星期二62/1170. 场景或者用例实例 用例中步骤的一个特定顺序。一个用例可以有几个不同的场景

29、。 商业步骤的变化存在于单一用例中。不同的参与者调用用例，有不同的活动流。 为了完成商业过程，用例要包括完整的步骤顺序。每个活动流都是一个有效的顺序。 不同的活动流称为场景(也称用例实例)。 场景是对一个用例中的一套内部活动的识别和描述。它代表通过用例的惟一路径。 2022年6月7日星期二63/117 通常商业步骤的变化存在于单一用例中。 “产生新订单”用例，根据哪些参与者调用用例，将有不同的活动流。 订单职员通过电话来建立新订单的过程与用户通过Internet建立订单的过程是非常不同的。 可以按三个独立的详细描述等级进行用例描述。2022年6月7日星期二64/1171. 简单描述 用于非常简

30、单的用例，特别是当要开发的系统是一个很小并且易于理解的应用时。 一个简单的用例通常有单一的场景和即使有也很少的异常条件。 用于和活动图进行连接的简单描述为简单用例提供了可靠的描述。 2022年6月7日星期二65/117“产生新订单”用例的简单描述 当用户电话订购时，订单支援和系统会检验用户信息，创建一个新订单，将各条目加入订单中，检验支付款项，创建这个订单交易，最后完成订单。 通常，像“产生新订单”这样的用例是很复杂的，它们可以用中间或者完全展开描述进行描述。 2022年6月7日星期二66/1172. 中间描述 中间等级的用例描述扩展了简单描述，它包括了用例的内部活动流。 如果有多个场景，其中

31、每个活动流都被单独的进行描述。 如果它们需要，还可以记录下其他条件。 2022年6月7日星期二67/117产生新订单电话订购场景的中间描述 2022年6月7日星期二68/117注意：每个场景都描述了用户和系统所需要执行的处理，同时还列出了异常条件。每一步都进行了标号，以方便阅读。在许多方法中，描述都是结构化英语，它包括了顺序、分支和循环。 产生新订单Web订购场景的中间描述 3. 完全展开描述 完全展开描述是记录用例的最正式的方法。 它要花费较多的工作在这个层次上定义所有的组件，但它仍然是描述用例内部活动流的首选方法。 如果创建完全展开用例描述，更有可能完全理解商业过程和系统支持它们的方式。

32、2022年6月7日星期二70/117创建新订单的网上订购场景的完全展开图 2022年6月7日星期二71/117产生新订单电话订购场景的完全展开描述 2022年6月7日星期二72/1171、2行标识所记录用例的内部用例和场景。给用例添加带有扩展名的惟一标识符，以标识特定的场景。或制作该表格的人员姓名。标识发起该用例的触发器。从两个角度描述触发器： 标识触发处理的商业事件、用例已经开始运作的活动。用例和场景的简单描述。分析员只须复制他们先前建立的简单描述。标识一个或多个参与者。可以复制用例图本身所包含的一些信息。标识其他用例和它们与该用例相关联的方式，如关系标识相关人员，而不是特定的参与者。可以是

33、没调用但对用例结果感兴趣的用户 前提条件:在用例初始化之前必须为真的一组条件。后续条件:在用例执行完成时必须为真的一组条件。最后两行描述用例活动流的详细信息。*4. 活动图描述 使用活动图是记录用例场景的另外一种方式。 在实例中，活动图将作为一种有效的技术用于记录每个用例场景的活动流。 活动图可以用来支持任何等级的用例描述。 活动图和完全展开描述中的两列(参与者、系统)描述非常相似。 创建活动图的好处在于它更加形象，并且有助于用户和开发人员一起工作来完整地记录用例。 2022年6月7日星期二73/117活动图 以图形化方式描述一个业务过程或者一个用例的活动的顺序。 它也可以用于建模一个操作要执

34、行的动作，以及那些动作的结果。 活动图用于记录商业过程工作流。 2022年6月7日星期二74/117电话订购场景的活动图 图中，客户和订单职员交互，轮流使用系统。因用例的目的是说明参与者和系统间的相互作用，故图中包含订单职员和计算机系统的活动图矩形区。为帮助理解场景的所有活动流，触发这一步骤的客户也要包括进来。客户矩形区是可选的附加项，它有助于理解整个工作流。Web订购场景的活动图 图中用户是与计算机系统相互作用的参与者，所以只需要两个矩形区来描述场景中的步骤。4 确定输入和输出系统顺序图4.0 交互图 4.1 系统顺序图符号4.2 开发系统顺序图2022年6月7日星期二77/1174.0 交

35、互图 在OO方法中，信息流是通过向参与者或内部对象来回发送消息而形成的。 系统顺序图(SSD)用于描述进出自动系统的信息流，所以一个系统顺序流记录输入和输出并且标识了参与者和系统之间的交互。 系统顺序图是交互图的一种。 交互图：用于显示对象间的相互作用的协作图或顺序图。2022年6月7日星期二78/1174.1 系统顺序图符号1. 线条2. 带下划线的对象名称和矩形框3. 虚线4. 生命线之间箭头5. 系统顺序图的例子6. 消息2022年6月7日星期二79/117用例图与SSD 在用例图中，参与者“使用”系统。 在SSD中参与者如何通过输入数据和获得输出数据来和系统进行交互才是重点。 两个图有

36、着相同的思想，不同的描述等级。2022年6月7日星期二80/1171. 线条 代表和系统交互的参与者(人或角色)。2022年6月7日星期二81/1172. 带下划线的对象名称和矩形框 标记为:系统的方框是代表整个自动系统的对象。 在SSD和所有交互图中，分析员使用对象符号代替类符号。 对象符号表明方框指的是一个独立的对象而不是所有类似对象的类。 符号由带有下划线的对象名称和一个矩形框组成，其中冒号是可选的，是对象符号的一部分。 在交互图中消息通过独立对象(不是类)进行发送和接收。 在SSD中，只有代表整个系统的对象才会被包括进来。2022年6月7日星期二82/1173. 虚线 称为生命线。 在

37、整个SSD期间内，生命线或者对象生命线仅仅是这个对象(参与者或对象)的扩展。2022年6月7日星期二83/1174. 生命线之间箭头 代表参与者和系统的发送和接收。每个箭头都有一个起点和终点。 消息的起点是箭头尾部的生命线所指的发送它的参与者或对象。 消息的目标参与者或对象是由箭头所指向的生命线指示的。 生命线目的是指示参与者和对象发送和接收消息的顺序。2022年6月7日星期二84/1175. 系统顺序图的例子2022年6月7日星期二85/117和消息一起发送的输入数据被括在圆括号中，在该例中它是一种用来确定特定条目的数据。语法是带有用括号括起来的输入参数的消息名。该语法形式常附加在实线箭头上

38、。6. 消息 标有记号的消息用来描述消息的目的，以及被发送的任何输入数据。 在顺序图中，消息被认为是在目的对象上调用的一种活动，它更像一条命令语句。 箭头代表消息和输入数据。 实线箭头：其上附带有用括号括起来的输入参数的消息名。 虚线箭头：指明一个响应或应答，其返回消息(条目信息)，它们通常紧跟在启动消息的后面。 ：注释信息。 2022年6月7日星期二86/117消息的符号 消息的完整符号：*真/假条件返回值:=消息名(参数列表) 消息的任何部分都可省略。2022年6月7日星期二87/117消息符号的组成 星号(*)：表示消息的重复或者循环。 方括号：表示真/假条件。值为真，消息被发送。否则消

39、息不发送。 消息名：对所需服务的描述。在虚线返回消息时，它被省略，而仅显示返回的数据参数。 参数列表(带有圆括号表示启动消息；没有圆括号表示返回消息):显示消息传递的数据。 与消息处于同一线上(需要:=)的返回值:用于描述从目的对象返回到源对象的消息响应数据。2022年6月7日星期二88/117*真/假条件返回值:=消息名(参数列表)重复消息2022年6月7日星期二89/117消息和返回数据可显示在一个步骤中。返回数据作为返回值标识在赋值操作符(:=)的左边。 4.2 开发系统顺序图1. 开发SSD所需要的条件2. 基于活动图开发SSD步骤3. RMO例2022年6月7日星期二90/1171.

40、 开发SSD所需要的条件 SSD通常用来和用例描述相联系，以帮助记录用例中一个单独的用例或场景的详细信息。 开发SSD需要有用例的详细描述：完全展开形式、活动图。 使用活动图的优点：很容易确定输入或输出何时发生。 2022年6月7日星期二91/117电话订购场景的简化活动图 2.基于活动图开发SSD步骤 首先确定系统边界，即订单职员矩形区和计算机系统矩形区之间的竖线部分。 标识输入消息 描述从外部参与者到系统的消息 在输入消息上确定并添加特定条件 确定并添加输出返回消息2022年6月7日星期二93/117 顺序图的目的就是描述自动计算机系统的输入和输出，所以顺序图将只包括订单职员和计算机系统。

41、 在顺序图中将两个参与者都包含进来也是正确的，但只包含系统和其中发送输入和接收输出的参与者将使得重点更加突出。2022年6月7日星期二94/117标识输入消息 在例图中，有三个地方的工作流穿过订单职员和系统之间的边界线。 在每一个工作流穿过自动化边界的地方，都须输入数据，因此同样需要消息。2022年6月7日星期二95/117描述从外部参与者到系统的消息 消息名：要反映参与者向系统请求的服务。 参数列表：开发人员要确定数据参数通常需要数次的迭代，才能找到一个正确而又完整的列表。 确定数据参数的规则：根据类图来确定数据参数(类中一些恰当的属性可以用做参数列表)。2022年6月7日星期二96/117

42、“产生新建订单”用例电话订购场景的SSD startOrder：本用例的前提条件是用户应存在。后续条件是订单必须与一个客户相关联。 addItem：需要参数来标识目录中的条目，以及要购买的数量。 completeOrder：基于活动图，须输入支付数量。2022年6月7日星期二97/117在输入消息上确定并添加特定条件 本例中，有迭代框和与之相关的真/假条件(在方括号中)。2022年6月7日星期二98/117确定并添加输出返回消息 显示返回消息的两种选择：在消息上添加返回值用虚线箭头表示一个独立的返回消息。 活动图可提供关于返回消息的线索，但并没有一个标准的规则，当工作流中的转换箭头从系统出发到

43、达外部参与者的时候，不一定总会产生一个输出。 2022年6月7日星期二99/117 系统分析的目标是理解和发现，所以应该与用户一起工作，以便准确定义工作流是如何运作的，以及什么样的信息需要作为输出被传递和提供。 这是一个迭代过程，在这些图反映用户需要之前，需要多次地修改。2022年6月7日星期二100/1173. RMO例 产生新订单用例的Web订购场景的简化系统顺序图。2022年6月7日星期二101/117Web订购场景活动图SSD 5 问题域建模域模型类图 由于事物存在于真实的对象中，而对象是OO方法的基础，所以类图常被认为是所有UML模型中最重要的一个。 事实上，类图是OO开发中的一个焦

44、点。 每个其他的UML模型必须与类图一致。 域模型类图只是一个开始。 2022年6月7日星期二103/117 定义系统需求时开发人员只关注用户问题域类，定义这些系统需求而建立的类图称为域模型类图或简称为域模型，因为它显示的类是用户问题域中的一部分。域模型类图并不显示方法，相反它主要关注的是用户真实世界的对象。 2022年6月7日星期二104/117域模型类图或者域模型 描述类的基本结构和概念上的数据模型。 使用域模型类图的目的： 它描述必须由OO的编程方法运行的类的基本结构。 它被当做一种概念上的数据模型描述用于DB定义的类。 2022年6月7日星期二105/117学生域模型类图的例子 该图的

45、扩展，显示从学生到本科生和研究生的概括/具体类。如，在本科生中的每个对象同时也是学生。 具体类继承了概括类的所有属性和关联。 建立域模型时，标识主键字段很重要。 在UML中，属性的特征是用大括号括起来的，就像课程类中的课程号主键。 课程部分数量用下划线指明它是类级属性。 通常，每个对象的属性都有惟一值,而类级属性有一个应用于类的所有对象的数值。 在Java中，它作为一个静态属性被执行；在VB.NET中，它是一个共享属性。 系统需要存储一个用于表示所提供课程的部分数量的值。每次多选取一个课程部分，该数值加1。 2022年6月7日星期二108/117关联关系 连线指明类之间的相互关系。 连线的名字

46、随意。 本例中，相互关系有一个多对多的重数(基数)。 只要多对多的关联存在，则关联类就可能存在。2022年6月7日星期二109/117满足三个条件关联类存在关联关系必须有多对多的重数。关联关系必须有一个仅应用于本关联(而不是任何有联系的类)的属性(年级)。由于关联类中的每个对象代表了相互联系的类中两个对象之间的一个独立的关联连接，因此关联类对象的键值通常是相互联系类的键值的组合。 如果在键值中需要其他的属性，那么关联类就有可能被定义错误。2022年6月7日星期二110/117RMO域模型类图 2022年6月7日星期二111/1176 OO模型的集成 完整的用例图对理解新系统的总体规模很重要。但

47、包含在用例描述、活动图和系统顺序图中的支持细节只需为特定迭代中的用例完成。 域模型类图比较特殊，它更像完整的用例图。 系统的问题域类的数量为系统总体规模提供一个提示。类的精炼和实际执行将等到以后的迭代中进行，但域模型应该基本完成。 域模型对于确定新系统所需要的所有域类是必要的。 2022年6月7日星期二112/117至此应该明白 一个图的构造如何参照另一幅图所提供的信息来完成。 新图表的开发通常有助于精简和纠正先前的图。 详细图的开发对于充分理解用户需求是至关重要的。 2022年6月7日星期二113/117OO需求模型中的关系 说明OO开发中需求模型间的主要关系。 依赖性通常从顶部流到底部，双

48、向箭头表示在两个方向都产生影响。 2022年6月7日星期二114/117注意，用例图和类图是两个主要的模型，依靠他们其他的图可从中获取信息。应尽可能完整地开发这两种图表。 CRUD分析将有助于确保尽可能完整地开发这两种模型。以叙述格式的用例描述或者活动图，对系统顺序图的开发很重要。要点回顾 OO方法中有一整套的图表集合，一起用来记录用户的需要和定义系统需求。 域模型类图，用例图，用例详细模型、叙述形式、活动图，SSD。 用例图记录系统可用的各种方法。可独立开发或根据事件表进行开发，一个事件触发一个用例。 SSD提供用例处理需求更详细的说明。记录系统的I/O。每个SSD应用范围是一个用例或者用例的一个场景。由参与者和系统组成。 域模型类图得到进一步精简。 2022年6月7日星期二115/117学习本章后，你应具备的能力 OO的需求通过哪些模型表示； 如何使用OO的用例/场景视图描述系统活动； 如何使用SSD确定输入和输出； 问题域建模：域模型类图; OO模型的集成。2022年6月7日星期二116/117