需求的OO描述方法课件

需求的OO描述方法本章内容先导案例概述1

统一建模语言和对象管理组织2

OO的需求3

系统活动：OO的用例/场景视图4

确定输入和输出——系统顺序图5

问题域建模——域模型类图6

OO模型的集成要点回顾阅读章节要求06六月20232/117先导案例无限电子公司：供应链一体化06六月20233/117概述在OOA中需要使用事实发现技术。事实发现行为称做发现活动，发现必须先于理解。本章学习发现的下一个阶段：建立理解。事件发生在系统必须响应的商业环境中。事件被定义和记录在事件表中。新系统必须能够通过运行系统活动(用例)来响应商业事件。06六月20234/117系统的信息(包含在商业过程中的事物信息)存储需求或使用传统方法中的ERD进行记录，或用OO方法中的类图进行记录。学习：使用OO的分析模型和技术来理解和定义新系统的需求。OO的分析和OO设计之间的界限并不明显，因为系统的设计就是对分析阶段中用于定义需求的模型进行改进和扩展得到的。06六月20235/117面向对象分析(OOA)系统分析过程中使用对象建模的方法被称为面向对象分析(OOA)。06六月20236/117OOA技术用于研究现有对象，看它们是否能够被复用或者被调整用于新的用途；定义各种新对象和修改后的对象，它们将与现有对象一起组合成一个有用的企业计算应用系统。06六月20237/117对象建模(ObjectModeling)是一种用于辨识系统环境中的对象和这些对象之间关系的技术。对象建模方法要求使用完全不同于数据建模和过程建模的方法和图形记号。06六月20238/117术语对象:某种存在的，或者能被看到、触摸或以其他方式感觉到的事物，用户就该事物存储数据和相关行为。属性:表示关于一个对象相关特征的数据。对象实例:由描述特定的人、地点、事物或者事件的属性值构成。行为:指的是对象可以做的事情，以及在对象数据(或属性)上执行的功能。在OO环境中，对象的行为通常被称为方法、操作或者服务。封装：几项内容一起打包成一个单元(信息隐藏)。06六月20239/117考虑我们所处的环境教室中的所有人，我们中的每一个都代表人对象的一个实例;我们中的每一个都可以按照一些公共属性描述，例如：姓名、社会保险号、电话号码、地址等。06六月202310/117对象的行为当看到周围环境中的门对象时，可能仅仅看到一个不能思考的静止对象——几乎很少执行什么动作。在用于系统开发的OO方法中，门对象可以同假定能够在其上的行为相关联。例如，门可以打开，可以关闭，可以锁上，或者可以开锁。所有这些行为都与门对象相关，并且由门对象实现，而不是由其他对象实现。06六月202311/117以电话对象为例什么行为同一个电话相关联？随着技术的进步，我们实际上有了语音激活的电话，我们可以应答、拨号、挂断，还可以执行其他与电话相关的行为。因此，用于系统开发的OO方法要求我们调整通常看待对象的方式。06六月202312/117重要的OO原理对象单独地负责执行任何在其数据(或属性)上操作的功能或者行为。例如：只有你(一个对象)可以修改(行为)你的名字和家庭住址(你的属性)。引出对象的一个重要概念，即封装。对象的属性和行为都被封装到一起作为那个对象的一部分。访问或修改对象属性只能通过那个对象的行为来实现。06六月202313/1171统一建模语言和对象管理组织OMG是一个由800多个软件销售商、开发商和组织组成的共同体，他们致力于发展和传播OO系统。成立于1989年。使命：在分布式计算系统的开发中提高应用对象技术的理论和实践水平。目标：为基于广泛接口规格的OO的应用程序提供一个通用的体系框架。06六月202314/1172OO的需求系统开发过程开始于确定事件和事物。事件：新系统所必须考虑的商业过程；事物：包含在商业过程中的问题域对象。过程和对象通常一起定义(不断切换)。必须学会将所有不同的模型和它们组合在一起生成完整的系统功能需求图。本章主要讨论一个关于模型的集合，它根据OO方法中的用例来捕获系统需求四种模型——用例图、用例描述、活动图和系统顺序图，用来从不同的观点描述系统用例。06六月202315/117使用模型来记录需求最大的好处在于它能帮助系统开发员仔细和清楚地考虑处理的细节，以及系统相关人员的信息需求。06六月202316/117四种模型1.用例图2.系统顺序图3.消息4.状态图06六月202317/1171.用例图一种用以显示不同的用户角色和这些用户角色如何使用系统的图。以图形化的方式描述系统与外部系统和用户的交互。换言之，它们以图形化的方式描述谁将使用系统，以及用户期望以什么方式与系统交互。06六月202318/117目的：识别新系统的“用法”或用例，即识别如何使用系统。用例图本质上是事件表的延伸。用例图是用于记录系统必须支持的所有功能的一种简便方法。可以用一个综合的用例图来描述整个系统。活动图可以用来定义用例。06六月202319/1172.系统顺序图(SSD)在用例或场景中，用于显示外部参与者和系统之间的消息顺序的图。以图形化的方式描述在一个用例或操作的执行过程中对象如何通过消息互相交互，说明了消息如何在对象之间被发送和接收以及发送的顺序。用来定义一个用例的输入和输出，以及在用户和系统之间交互的顺序。用于联系用例详细描述或活动图。顺序图中，出入系统的信息流被称为消息。06六月202320/1173.消息用例内部对象之间的通信。当一个对象调用另一个对象的方法(行为)以请求信息或者某些动作时发生的通信。06六月202321/1174.状态图一种用以显示对象在各阶段中的生命和转换的情况的图。用于建模一个特定对象的动态行为，说明一个对象的生命周期——对象可以经历各种状态，以及引起对象从一个状态向另一个状态转换的事件。

状态图表(状态图)描述了每个对象状态的集合。类图中所标识的一些对象有些状态情形需要跟踪，这些状态直接决定了对象的处理过程。06六月202322/117

客户订单有几个比较重要的状态条件，它们控制订单的处理过程，例如，订单只有在完成后才会发货。状态图标识这些状态条件并且标明允许的处理过程。同时，状态图也可用于设计过程，以确定系统本身的各种状态，以及能够处理的可允许的事件上。状态图既可以看做是分析工具，也可以看做是设计工具。06六月202323/1173系统活动：OO的用例/场景视图3.1

用例和参与者3.2

用例图3.3

开发用例图3.4

用例详细描述06六月202324/117用例分析的目标用来标识和定义系统必须支持的所有商业过程。分析员在综合等级和详细等级两个层次上定义用例。事件表和用例图为一个系统提供了所有用例的综合。关于每个用例的详细信息使用用例描述、活动图和系统顺序图，或者这些模型的组合进行说明。06六月202325/1173.1用例和参与者用例：系统运行的活动，通常由系统用户来响应需求。用例中蕴涵使用系统的人：参与者。参与者通常处于自动化系统边界之外，但是它也有可能是系统手动部分的成员。06六月202326/117参与者与事件的源的区别参与者的概念与在事件表中所定义的事件的“源”在内涵上略有不同。事件的源：指事件的发起者，例如一个用户，并且它通常在系统(包括手动系统)的外部。参与者实际上是亲自和计算机系统进行交互的人。06六月202327/117定义参与者①和系统进行交互的人定义为参与者。(自动化系统所必须响应的交互)②将能够接触自动系统的人定义为参与者。有些参与者可能是其他的系统或者从系统接受服务的设备。③把参与者看成一个角色。④考虑参与者和用例，认为用例是参与者想要完成的目标。06六月202328/117例：RMO中用例“产生新订单”的情况可能会涉及一个销售代表在电话里与一名客户进行交谈。如果这位客户直接在Internet上订货，那他也是个参与者。标志目标的方法：订单职员使用系统来生成新订单。

3.2用例图用例图：概括有关参与者和用例信息的一个图形化的模型。

1.自动化边界和组织

2.组织用例图的方法

3.用例之间的关系

4.用例图与事件表的比较06六月202329/117例：有一个参与者的简单用例。*1.自动化边界和组织在全套的用例上画一条边界线。该边界是自动化边界。它表示环境(参与者的居住地)和自动系统的内部功能之间的边界。06六月202330/117员对前面的图进行了扩展，增加了参与者和用例。在该实例中，订单员和用户都可直接访问系统。正像有关系线连接表示的那样，每个参与者可以操作所有的用例。2.组织用例图的方法⑴使用子系统⑵包含涉及一个特定参与者的所有用例06六月202331/117⑴使用子系统订单输入子系统用例图，显示系统边界06六月202332/117员RMO客户支持系统用例图(子系统)06六月202333/117*⑵包含涉及一个特定参与者的所有用例06六月202334/117图表示了与一个客户参与者相关的所有用例。该图在表明所有通过Internet访问的活动时非常有用。分析员可以选择绘制基于项目团队需要的用例图。如果计划与市场部门经理会面讨论所有涉及直接客户交互的用例，则图中的用例图会很有用。3.用例之间的关系⑴扩展⑵包含⑶泛化06六月202335/117<<包含>>关系通常在用例图的开发过程中，一个用例需要用到通用子程序所提供的服务。例如，“订单输入子系统”的两个用例是“产生新订单”、“更新订单”，这两个用例均须检查客户的账号是否正确。因此，可以定义一个通用的子程序来完成这个功能，并且它变成了一个附加用例。06六月202336/117有<<包含>>关系用例的订单输入子系统关系可读做“产生新订单<<包含>>验证用户账号”。<<包含>>关系也称<<包括>>关系或者<<使用>>关系。06六月202337/117名为“验证用户账号”的用例，它被“产生新订单”、“更新订单”两个用例调用。用例之间的关系由带箭头的连接线表示。“检查条目可用性”可能是<<包含>>关系的一部分。分析员可定义两种类型的<<包含>>关系：一种是通用内部子程序，如“验证用户账号”，它不被外部参与者直接引用；另一种是能被外部参与者直接引用，如“检查条目可用性”。⑴扩展当某个基本用例由于需要附加一个用例来扩展或延伸其原有功能时，附加的扩展用例与原有的基本用例之间的关系就体现为扩展关系。在UML中可使用带有<<extend>>说明的依赖关系表示“扩展关系”。例：网上购物系统中有“支付”用例，而“网上支付”用例是“支付”用例的扩展用例。06六月202338/117支付网上支付<<extend>>基本用例扩展用例*从基本用例A到扩展用例B的扩展关系表明：按基本用例A中指定的条件，把扩展用例B的行为插入到由A中的扩展点定义的位置。也就是说基本用例A可以单独存在，但在一定的条件下，它的行为可被另一个用例B的行为扩展。一个用例可以扩展多个用例，一个用例也可以被多个用例扩展。扩展用例不能作为动作序列单独出现，但基本用例在缺少任何扩展用例的情况下也必须是独立的用例。06六月202339/117⑵包含

如果在若干个用例中有某些相同的动作，则可把这些相同的动作提取出来单独构成一个用例(称抽象用例)。(将多个用例中的公共部分抽取出来作一个单独用例)。当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例中的所有动作。UML中使用带有<<include>>说明的依赖关系表示“包含关系”。例：网上购物系统中有一个“订购”用例，而“查询”用例是“订购”用例的包含用例。06六月202340/117*订购查询<<include

>>包含用例

如果从用例A到用例B存在包含关系，则用例A在它内部说明的某一位置上显式地使用用例B的行为的结果。被包含的用例B作为包含它的用例A的功能的一部分出现。可以把包含关系想像为基本用例调用供应者用例，基本用例仅仅依赖供应者用例执行的结果，而不依赖供应者用例的内部结构。一个用例可以包含多个用例，一个用例也可以被多个用例包含。06六月202341/117例：网上订购商品软件系统需要对顾客的信用进行检查，检查输入的信用卡号是否有效，信用卡是否有足够的资金支持本次订购。由于该功能在“订购”过程中使用，因此是包含关系。在执行“改变订购量”用例时，只有预定量改变时才执行“检查信用”用例，如果预订量不改变，则不执行“检查信用”用例。由于“检查信用”用例是可选执行的，因此，用例之间存在扩展关系。箭头从可选运行的用例“检查信用”指向被扩展的用例。06六月202342/117顾客订购检查信用<<include

>>改变预订量<<extend

>>扩展和包含之间的异同两种关系意味着从几个用例中抽取那些公共的行为并放入一个单独的用例中，而这个用例被其他用例扩展或包含。包含和扩展的目的是不同的。通常在描述一般行为的变化时采用扩展关系；在两个或多个用例中出现重复描述又想避免这种重复时，可以采用包含关系。06六月202343/117⑶泛化从用例A到用例B之间的泛化关系表明：父用例表示通用的行为序列。通过插入额外的步骤或定义步骤，子用例特化父用例。UML表示用例泛化的方法与类相同。例：在线股票经纪人系统把通用用例“做交易”特化为子用例“交易债券”、“交易股票”和“交易期权”。父用例包含所有交易类型都会执行的步骤，如输入交易密码。每个子用例都包含了针对某种交易类型特别安排的额外步骤，如输入期权的行权日期。06六月202344/117做交易交易债券交易股票交易期权4.用例图与事件表的比较①模型的观点有细微的不同②标识临时事件和状态事件时有差别③定义一个用例支持多个商业事件06六月202345/117①模型的观点有细微的不同事件表通常注意商业过程。它通过标识商业事件，以及这些事件的外部、初始化源的信息来关注商业过程。外部的源是引起商业事件初始化的原因，并且它们能从自动系统中轻松的移除。用例图强调了自动系统。因为它只与自动系统相连，所以参与者与自动系统有联系并且不一定是商业事件的发起者。06六月202346/117②标识临时事件和状态事件时有差别由于用例通常被外部参与者初始化，所以如果分析员不仔细标识每一个事件，那么临时事件和状态事件经常被忽略。用例定义太窄将成为用例建模的一个缺陷。如：在线系统菜单常包括用于表示事件表中临时事件的菜单选项，以便这样的事件能够被用户触发并且作为纯粹的临时事件。建议：为每个临时事件和状态事件创建用例以确保这些需求不被忽略。06六月202347/117③定义一个用例支持多个商业事件满足3个标准，则定义一个用例：本质上相同的处理发生在自动系统内部；本质上相同的信息被更新；本质上相同的信息从事件中输入和输出。例：开发事件表过程中，添加新用户和更新用户两个事件已被标识出来。从系统观点出发，两个商业事件的用例几乎一样，因为它们都包含更新用户文件。可定义一个单独的用例来支持这两个商业事件，该用例可命名为“维护客户账户信息”。06六月202348/117分析员会同时完成事件表和用例图，并不断更新。在商业事件对单一、简单的数据文件或表进行基本的文件维护时，这些条件常常能够满足。有时单一事件可触发非常复杂的处理需求，这将使系统活动分解为两个用例以更好地管理系统复杂性，使其变得更加有意义。3.3开发用例图1.两个切入点2.两步迭代3.CRUD分析06六月202349/1171.两个切入点⑴若创建了事件表，则用事件表标识用例⑵标识使用系统的参与者和它们执行的功能06六月202350/117⑴若创建了事件表，则用事件表标识用例仔细分析事件表中的每个事件以确定系统为支持这些事件、发起这个事件的参与者，以及由于该事件而触发的其他用例所执行的处理。当一个模型转向另一个更详细的模型时需要不断精炼，仔细分析事件和事件表非常重要。开发人员可将一个单一的事件标识为用例，如所需的处理很相似，可把几个事件组合成一个单独的用例；或如果处理很复杂，也可标识多个用例。多个用例的标识通常发生在它们有<<包含>>关系和两个用例从一个大用例分解得到时，或发生在一个附加用例按照通用子程序的方式被定义时。06六月202351/117该图显示的客户支持子系统是使用该方法开发。图中定义的绝大多数用例直接来自事件表。用例名称来自事件表的活动/用例栏中的描述。例外:①由于临时事件通常可手动发起,所以要为每个临时用例使用标识外部参与者选项。

②“客户修改账户信息”事件。在该实例中，用例定义扩展到和所有维护客户信息相关的场景中。同样，该用例被命名为维护客户账户信息，指的是添加、更新和删除。这些都是用例对事件表进行提炼更新的例子。06六月202353/117RMO客户支持系统的完整事件表⑵标识使用系统的参与者和它们执行的功能若没创建事件表，则开发用例图的另一个切入点是标识使用系统的参与者和它们执行的功能。记住两个前提条件：为一个自动系统创建自动化边界，这样标识的参与者就能和这个系统进行联系；必须假定拥有完美的技术，确定用例是基于商业事件而不是像登录系统一样的技术活动。只有给出上述前提，才可通过两步迭代来开发用例图。06六月202354/1172.两步迭代⑴标识系统的参与者⑵开发这些角色的目标表06六月202355/117⑴标识系统的参与者参与者通常由用户扮演。不能把参与者列成如Bob先生这样的形式，而应该标识出这些人所处的特定的角色。记住，在一个系统中同一个人可以有多个特定的角色。理解和辨识系统所有可能使用的角色是重要的。其他的系统也可以成为系统的参与者。06六月202356/117⑵开发这些角色的目标表目标指参与者执行完成一些商业功能的任务。目标通常是类似营销、接受用户反馈或者订单发货这样的任务。目标是能够被标识和描述的工作单元。在目标完成时，系统数据在一段时间内是不会改变的。两个步骤常应用于项目组成员和用户的集体讨论中，并没什么捷径可以用来发现或标识用例。06六月202357/1173.CRUD分析将标识后的用例与域模型类图进行比较(复查)。需要类图中每个类都有足够的用例来支持创建新对象实例、读取或者报告这些对象、更新这些对象并且在许多例子中删除对象实例。检查在域模型类图中的每个类并确定在用例图中有用例来支持所有适合该应用的CRUD功能。06六月202358/117RMO的一个活动数据矩阵06六月202359/117CRUD分析需要类图中每个类都有足够的用例来支持创建新对象实例、读取或者报告这些对象、更新这些对象产且在许多例子中删除对象实例。用例不应该命名为创建或者更新，但是潜在的处理可以添加新的实例或者更新已存在的实例。例如，一个名为“记录支付情况”的用例并没有清楚地指出一个新的支付对象被创建，但是用例的详细描述却指出这个对象被创建了。用例“产生新订单”可以创建订单条目对象和更新库存条目对象。在其他例子中，许多用例以维护两字开头命名，以覆盖常规的添加、更新、读取和删除操作。06六月202360/117为了做CRUD分析，只须看一下在域模型类图中的每个类并确定在用例图中有用例来支持所有适合该应用的CRUD功能。切记：在集成系统中，一个系统可能负责创建对象，而另外的系统可以只更新它们。CRUD分析方法提供了一种交叉检验方法(不是最终的解决方案)，并且提供了确认重要的系统集成需求的机会，这些需求如果不用该方法逆行分析可能就不明显了。06六月202361/1173.4用例详细描述0.场景或者用例实例1.简单描述2.中间描述3.完全展开描述4.活动图描述06六月202362/1170.场景或者用例实例用例中步骤的一个特定顺序。一个用例可以有几个不同的场景。商业步骤的变化存在于单一用例中。不同的参与者调用用例，有不同的活动流。为了完成商业过程，用例要包括完整的步骤顺序。每个活动流都是一个有效的顺序。不同的活动流称为场景(也称用例实例)。场景是对一个用例中的一套内部活动的识别和描述。它代表通过用例的惟一路径。06六月202363/117通常商业步骤的变化存在于单一用例中。“产生新订单”用例，根据哪些参与者调用用例，将有不同的活动流。订单职员通过电话来建立新订单的过程与用户通过Internet建立订单的过程是非常不同的。可以按三个独立的详细描述等级进行用例描述。06六月202364/1171.简单描述用于非常简单的用例，特别是当要开发的系统是一个很小并且易于理解的应用时。一个简单的用例通常有单一的场景和即使有也很少的异常条件。用于和活动图进行连接的简单描述为简单用例提供了可靠的描述。06六月202365/117“产生新订单”用例的简单描述当用户电话订购时，订单支援和系统会检验用户信息，创建一个新订单，将各条目加入订单中，检验支付款项，创建这个订单交易，最后完成订单。通常，像“产生新订单”这样的用例是很复杂的，它们可以用中间或者完全展开描述进行描述。06六月202366/1172.中间描述中间等级的用例描述扩展了简单描述，它包括了用例的内部活动流。如果有多个场景，其中每个活动流都被单独的进行描述。如果它们需要，还可以记录下其他条件。06六月202367/117产生新订单电话订购场景的中间描述06六月202368/117注意：每个场景都描述了用户和系统所需要执行的处理，同时还列出了异常条件。每一步都进行了标号，以方便阅读。在许多方法中，描述都是结构化英语，它包括了顺序、分支和循环。产生新订单Web订购场景的中间描述3.完全展开描述完全展开描述是记录用例的最正式的方法。它要花费较多的工作在这个层次上定义所有的组件，但它仍然是描述用例内部活动流的首选方法。如果创建完全展开用例描述，更有可能完全理解商业过程和系统支持它们的方式。06六月202370/117创建新订单的网上订购场景的完全展开图06六月202371/117产生新订单电话订购场景的完全展开描述06六月202372/1171、2行标识所记录用例的内部用例和场景。给用例添加带有扩展名的惟一标识符，以标识特定的场景。或制作该表格的人员姓名。标识发起该用例的触发器。从两个角度描述触发器：标识触发处理的商业事件、用例已经开始运作的活动。用例和场景的简单描述。分析员只须复制他们先前建立的简单描述。标识一个或多个参与者。可以复制用例图本身所包含的一些信息。标识其他用例和它们与该用例相关联的方式，如<<包含>>关系标识相关人员，而不是特定的参与者。可以是没调用但对用例结果感兴趣的用户

前提条件:在用例初始化之前必须为真的一组条件。后续条件:在用例执行完成时必须为真的一组条件。最后两行描述用例活动流的详细信息。*4.活动图描述使用活动图是记录用例场景的另外一种方式。在实例中，活动图将作为一种有效的技术用于记录每个用例场景的活动流。活动图可以用来支持任何等级的用例描述。活动图和完全展开描述中的两列(参与者、系统)描述非常相似。创建活动图的好处在于它更加形象，并且有助于用户和开发人员一起工作来完整地记录用例。06六月202373/117活动图以图形化方式描述一个业务过程或者一个用例的活动的顺序。它也可以用于建模一个操作要执行的动作，以及那些动作的结果。活动图用于记录商业过程工作流。06六月202374/117电话订购场景的活动图图中，客户和订单职员交互，轮流使用系统。因用例的目的是说明参与者和系统间的相互作用，故图中包含订单职员和计算机系统的活动图矩形区。为帮助理解场景的所有活动流，触发这一步骤的客户也要包括进来。客户矩形区是可选的附加项，它有助于理解整个工作流。Web订购场景的活动图图中用户是与计算机系统相互作用的参与者，所以只需要两个矩形区来描述场景中的步骤。4确定输入和输出——系统顺序图4.0

交互图4.1

系统顺序图符号4.2

开发系统顺序图06六月202377/1174.0交互图在OO方法中，信息流是通过向参与者或内部对象来回发送消息而形成的。系统顺序图(SSD)用于描述进出自动系统的信息流，所以一个系统顺序流记录输入和输出并且标识了参与者和系统之间的交互。系统顺序图是交互图的一种。交互图：用于显示对象间的相互作用的协作图或顺序图。06六月202378/1174.1系统顺序图符号1.线条2.带下划线的对象名称和矩形框3.虚线4.生命线之间箭头5.系统顺序图的例子6.消息06六月202379/117用例图与SSD在用例图中，参与者“使用”系统。在SSD中参与者如何通过输入数据和获得输出数据来和系统进行交互才是重点。两个图有着相同的思想，不同的描述等级。06六月202380/1171.线条代表和系统交互的参与者(人或角色)。06六月202381/1172.带下划线的对象名称和矩形框标记为:系统的方框是代表整个自动系统的对象。在SSD和所有交互图中，分析员使用对象符号代替类符号。对象符号表明方框指的是一个独立的对象而不是所有类似对象的类。符号由带有下划线的对象名称和一个矩形框组成，其中冒号是可选的，是对象符号的一部分。在交互图中消息通过独立对象(不是类)进行发送和接收。在SSD中，只有代表整个系统的对象才会被包括进来。06六月202382/1173.虚线称为生命线。在整个SSD期间内，生命线或者对象生命线仅仅是这个对象(参与者或对象)的扩展。06六月202383/1174.生命线之间箭头代表参与者和系统的发送和接收。每个箭头都有一个起点和终点。消息的起点是箭头尾部的生命线所指的发送它的参与者或对象。消息的目标参与者或对象是由箭头所指向的生命线指示的。生命线目的是指示参与者和对象发送和接收消息的顺序。06六月202384/1175.系统顺序图的例子06六月202385/117和消息一起发送的输入数据被括在圆括号中，在该例中它是一种用来确定特定条目的数据。语法是带有用括号括起来的输入参数的消息名。该语法形式常附加在实线箭头上。6.消息标有记号的消息用来描述消息的目的，以及被发送的任何输入数据。在顺序图中，消息被认为是在目的对象上调用的一种活动，它更像一条命令语句。箭头代表消息和输入数据。实线箭头：其上附带有用括号括起来的输入参数的消息名。虚线箭头：指明一个响应或应答，其返回消息(条目信息)，它们通常紧跟在启动消息的后面。：注释信息。06六月202386/117消息的符号消息的完整符号：*[真/假条件]返回值:=消息名(参数列表)消息的任何部分都可省略。06六月202387/117消息符号的组成星号(*)：表示消息的重复或者循环。方括号[]：表示真/假条件。值为真，消息被发送。否则消息不发送。消息名：对所需服务的描述。在虚线返回消息时，它被省略，而仅显示返回的数据参数。参数列表(带有圆括号表示启动消息；没有圆括号表示返回消息):显示消息传递的数据。与消息处于同一线上(需要:=)的返回值:用于描述从目的对象返回到源对象的消息响应数据。06六月202388/117*[真/假条件]返回值:=消息名(参数列表)重复消息06六月202389/117消息和返回数据可显示在一个步骤中。返回数据作为返回值标识在赋值操作符(:=)的左边。

4.2开发系统顺序图1.开发SSD所需要的条件2.基于活动图开发SSD步骤3.RMO例06六月202390/1171.开发SSD所需要的条件SSD通常用来和用例描述相联系，以帮助记录用例中一个单独的用例或场景的详细信息。开发SSD需要有用例的详细描述：完全展开形式、活动图。使用活动图的优点：很容易确定输入或输出何时发生。06六月202391/117电话订购场景的简化活动图

2.基于活动图开发SSD步骤首先确定系统边界，即订单职员矩形区和计算机系统矩形区之间的竖线部分。

⑴标识输入消息

⑵描述从外部参与者到系统的消息

⑶在输入消息上确定并添加特定条件

⑷确定并添加输出返回消息06六月202393/117

顺序图的目的就是描述自动计算机系统的输入和输出，所以顺序图将只包括订单职员和计算机系统。在顺序图中将两个参与者都包含进来也是正确的，但只包含系统和其中发送输入和接收输出的参与者将使得重点更加突出。06六月202394/117⑴标识输入消息在例图中，有三个地方的工作流穿过订单职员和系统之间的边界线。在每一个工作流穿过自动化边界的地方，都须输入数据，因此同样需要消息。06六月202395/117⑵描述从外部参与者到系统的消息消息名：要反映参与者向系统请求的服务。参数列表：开发人员要确定数据参数通常需要数次的迭代，才能找到一个正确而又完整的列表。确定数据参数的规则：根据类图来确定数据参数(类中一些恰当的属性可以用做参数列表)。06六月202396/117“产生新建订单”用例电话订购场景的SSDstartOrder：本用例的前提条件是用户应存在。后续条件是订单必须与一个客户相关联。addItem：需要参数来标识目录中的条目，以及要购买的数量。completeOrder：基于活动图，须输入支付数量。06六月202397/117⑶在输入消息上确定并添加特定条件本例中，有迭代框和与之相关的真/假条件(在方括号中)。06六月202398/117⑷确定并添加输出返回消息显示返回消息的两种选择：①在消息上添加返回值②用虚线箭头表示一个独立的返回消息。活动图可提供关于返回消息的线索，但并没有一个标准的规则，当工作流中的转换箭头从系统出发到达外部参与者的时候，不一定总会产生一个输出。06六月202399/117系统分析的目标是理解和发现，所以应该与用户一起工作，以便准确定义工作流是如何运作的，以及什么样的信息需要作为输出被传递和提供。这是一个迭代过程，在这些图反映用户需要之前，需要多次地修改。06六月2023100/1173.RMO例产生新订单用例的Web订购场景的简化系统顺序图。06六月2023101/117Web订购场景活动图SSD5问题域建模——域模型类图由于事物存在于真实的对象中，而对象是OO方法的基础，所以类图常被认为是所有UML模型中最重要的一个。事实上，类图是OO开发中的一个焦点。每个其他的UML模型必须与类图一致。域模型类图只是一个开始。06六月2023103/117定义系统需求时开发人员只关注用户问题域类，定义这些系统需求而建立的类图称为域模型类图或简称为域模型，因为它显示的类是用户问题域中的一部分。域模型类图并不显示方法，相反它主要关注的是用户真实世界的对象。06六月2023104/117域模型类