UML系统用例及用例关系

CH4用例图系统用例图和用例图关系、统一建模语言、软件工程、知识回顾-需求获取、困难、重点、掌握用例图的位置、功能和定义、确定用例图和用例图之间的关系、教学目标、教学内容、需求是客户在项目启动时的长期愿景，客户需求将决定承包商在整个项目中需要做什么，即承包商的任务。承包商将在定义需求后开始随后的设计、开发、测试、部署和其他工作。在需求获取过程中，需要明确三个主要问题。一个是需求获取。二是明确需要获取的信息，获取信息的来源和渠道，以及如何获取需求。另一个是什么，在哪里，如何，两个用例图的相关概念的介绍。1.什么是用例图的动态视图，它由参与者、用例及其关系组成，用来描述系统的功能，称为用例图。2.用例图是需求分析的产物。它的主要功能是描述参与者和用例之间的关系，并帮助开发人员直观地理解系统的功能。用例图直观地表达了系统的需求，具有直观、标准化等优点，克服了纯文本描述的缺陷。用例方法是完全从外部定义系统功能，这将需求和设计完全分开。参与者，参与者关键字：边界参与者：系统外的任何事物，通过系统边界与系统有意义的交互，识别参与者1，指出系统外的参与者代表系统边界之外的真实事物，不是系统的组件，系统边界参与者通过系统边界直接与系统交互，并且参与者的确定代表任何与系统边界有意义的交互-人，外部系统，外部因素，时间，识别参与者2，识别参与者的思想， 谁使用系统的主要功能，谁改变系统的数据，谁从系统获得信息，谁需要系统的支持来完成日常工作任务，谁负责日常维护、管理和确保系统的正常运行，谁使用或删除系统中的信息，谁(或什么)对系统运行产生的结果(值)感兴趣，以及系统需要处理(处理)那些需要在预定时间与那些外部系统交互的硬设备系统。 是否有事件自动发生时间、温度等内外条件.参与者的类型和责任，主要参与者直接与系统交互的人，或执行系统主要功能的执行者，次要参与者使用系统次要功能的执行者，或作为系统一部分维护系统一般功能的执行者的外部硬件，运行应用程序的非计算机硬件，其工作需要与系统交互的外部系统，参与者之间的关系， 独立关系一般化关系中的参与者的抽象描述可以由一个或多个特定的参与者、客户、个人客户、商业客户共享，用例1，定义：用例用例代表系统的外部功能，它从用户的角度分析获得的需求。为了完成一个相对完整的功能，系统执行的一组动作是一个外部可见的系统功能，它代表了一个完整的功能，包括一系列动作、用例、用例2、捕获特定角色的可见需求的用例、实现用户角色使用的特定角色需求用例，以及为角色用例提供精确的输出，无论大小，但是，它必须是对特定角色目标实现的完整描述。用例的动态执行过程可以用UML的交互来说明，也可以用状态图、序列图、协作图或非正式的文本描述来表示。它可以识别用例和用例关键字：值定义用例实例是系统执行的一系列动作。这些操作将为特定参与者生成可观察到的结果值。用例简洁地定义了一组用例实例(场景):参与者使用系统来达到目标，识别用例的关键点，观察-用例停止在系统边界结果值-用例是有意义的目标系统执行-结果值由系统生成并由参与者观察-业务语言，用户观点，一组用例实例-用例的粒度被命名， 可观察的：用例停止在系统边界，描述交互，而不是内部系统活动，边界-边界，也称为系统边界，被用来定义系统功能的范围。 带有名称的矩形框用于放置描述系统功能的用例，而描述的与系统交互的角色放置在系统完整的系统或子系统之外。包含一个或多个用例的系统准确地定义了系统的边界(功能)。提前识别系统的基本功能集并不容易。在此基础上，定义了一个稳定的、精确定义的系统架构，然后系统功能不断扩展，逐步完善。结果值是有意义的目标、业务功能，而不是系统处理。系统执行：结果值由系统生成，需要系统处理的由系统生成。参与者观察：用户视图而不是系统视图，用户视图，系统视图，关键点：用例粒度，用例应该有路径，路径应该有步骤。然而，所有这些都是可以观察到的最常见的错误：过于精细的粒度和过于精细的功能分解粒度通常会导致对技术语言而不是业务语言的描述。用例粒度-1，用例步骤作为用例，系统活动作为用例，用例粒度-2，和“四轮马车”。所有的业务最终都会变成CRUD？CRUD能给演员带来价值吗？CRUD掩盖了业务，突然变成了关系数据库的建模：“系统是数据的添加、删除和检查”。它关心数据的存储和维护，但忽略了用户的目的。用例粒度-3，用例粒度-4。如果真的是CRUD呢？如果CRUD不涉及复杂的交互，一个用例“管理”可以被表达为一个用例，无论它是C，R，U，D，为了实现“管理”目标，甚至是各种基本的数据管理。用例粒度-5，对CRUD的灵活处理，可以分离包含复杂交互的路径以形成用例，用例命名，执行者视角：(状语)动词(定语)对象，用例关系，包括提取公共步骤有助于为相同的业务目的重用不同的扩展分离和扩展路径概括技术，包括关系1，关系2和关系。当一些步骤在多个用例中重复出现，并且有更多的步骤单独形成价值用例时，当用例完全知道何时调用它们时，可以使用Include来简化。基本用例需要包括用例封装的逻辑。在源代码中，它可以简单地被视为函数调用或操作调用，包括示例1、示例2、扩展关系1、扩展关系2。在一定条件下，根据相应的扩展点，将扩展用例的事件流插入到基本用例中。基本用例不需要知道扩展用例的任何细节，它只为它提供扩展点。扩展用例的行为是否被执行取决于主事件流中的决策点。扩展关系2，基本用例路径本身是完整的，它可能是一个扩展路径扩展路径步骤，在多扩展路径内可能有扩展点-扩展扩展路径是不确定的或者容易改变-分离到“冻结”基本用例基本用例可以单独存在，但是在某些条件下，他的行为可以被另一个用例用作扩展，扩展关系，扩展示例，扩展关系， 相同的业务目的是通过不同的技术实现的：一个用例可以推广到另一个更常见的用例(更常见的用例专用于一个特殊的用例)。 UML1.5:用例之间的一般化关系表明子用例包括父用例中定义的所有属性、行为序列和扩展点，并参与父用例中的所有关系。概括地说，销售人员可以终止任何交易，除了那些需要特殊销售人员(高级代理)终止超出特定限制的交易，包括用例和扩展用例之间的差异。与基本用例相比，扩展用例是可选的，而包含用例不是。(2)如果没有扩展用例，基本用例仍然是完整的，如果没有包含的用例，基本用例是不完整的。(3)扩展用例的执行需要满足一定的条件，但是包含用例不需要。(4)扩展用例的执行会改变基本用例的行为，但是包含用例不会。用例关系：扩展VS一般化，采用不同的关系，文档结构不同，总结，理解需求以用例为中心的组织需求使用基于用例的需求分析过程获取原始需求开发可理解的需求识别参与者识别用例确定关系，思考，基于用例的需求分析过程可以大致分为几个步骤？系统边界用例的概念是什么？用例关系参与者的定义和关系？思维1:确定参与者？寻呼系统：如果用户已经做了天气预报，系统将每天定期向他发送天气信息；如果当天气温高于35度，提醒使用者注意防暑降温。在这个故事中，谁是寻呼系统的参与者？用户？温度？时间？思考2:获取需求-工时记录卡应用程序，初始面试记录开发人员：谁将使用此应用程序？客户：使用它记录可计费和不可计费时数的所有员工.开发人员：当前的工时记录卡应用程序是什么样的？顾客：每半个月用一张Excel表格记录。每个员工都会填写他的表格，然后通过电子邮件发给我。这种形式非常标准：垂直是收费项目代码，水平是日期。员工可以在每个条目上填写说明。开发者：我在哪里可以得到这个账单代码？开发商：谁来管理收费项目代码？顾客：嗯，我会在必要的时候添加这个代码。每个经理总是告诉他的下属该填写什么。思考2:确定参与者：时间卡系统，开发人员：谁将使用该应用程序？客户：使用它记录可计费和不可计费时数的所有员工.开发人员：当前的工时记录卡应用程序是什么样的？顾客：每半个月用一张Excel表格记录。每个员工都会填写他的表格，然后通过电子邮件发给我。这种形式非常标准：垂直是收费项目代码，水平是日期。员工可以在每个条目上填写说明。开发者：我在哪里可以得到这个账单代码？开发商：谁来管理收费项目代码？顾客：嗯，我(业务经理)会在必要的时候添加这个代码。每个经理总是告诉他的下属该填写什么。思考2:识别用例：时间卡系统，开发人员：谁将使用该应用程序？客户：使用它记录可计费和不可计费时数的所有员工.开发人员：当前的工时记录卡应用程序是什么样的？顾客：每半个月用一张Excel表格记录。每个员工都会填写他的表格，然后通过电子邮件发给我。这种形式非常标准：垂直是收费项目代码，水平是日期。员工可以在每个条目上填写说明。开发者：我在哪里可以得到这个账单