UML系统用例及用例关系

1、CH4用例图系统掌握用例与用例的关系、统一建模语言、11软件工程、知识评论的需要获得、难点、重点、用例图的地位和定义、确定用例与用例的关系、教育目标、教育内容、 需求是客户在项目立案时拥有的愿景，客户的需求是承包人在整个项目中具体做什么，即决定承包人的任务。 承包人在明确需求后，开始后期的设计、开发、测试、引进等工作。 在需求获得、Click to add title in here、4、需求获得的过程中，主要需要明确三个问题：需求获得：要获得的信息，明确获得的信息的来源和途径，需求获得：What、Where、How、用例图相关的概念介绍1 .用例图将用于描述由参与者(Actor )、用例(U

2、se Case )和它们的关系组成的系统功能的动态视图称为用例图。 2 .用例图的作用，用例图是需求分析中的产物，主要角色是描述参与者和用例之间的关系，帮助开发者可视化的系统功能。 在图例中，具有直观、规范等优点，可以直观地表现系统的需求，克服了纯文字说明的不足。 用例方法完全从外部定义系统功能，将需求和设计完全分离。 参加者，Actor关键字：边界参加者：在系统之外，通过系统边界与系统进行有意义的交互，识别参加者1，重要的系统外参加者表示系统边界之外的真实内容， 非系统组成部分的系统边界参与者经由系统边界直接与系统交互的参与者的确定代表对系统边界的确定有意义的任何相互作用的事物的人、外部系统

3、、外部因素、时间，识别参与者， 使用识别参加者的想法系统的主要功能改变人系统的数据从人系统获得信息需要人系统的支持人完成日常业务的人日常的维护、管理、保证系统的正常动作使用人系统的信息的人和系统的动作结果(值)很关心需要处理(处理)这些硬盘系统的事件自动发生的时间、气温等内部外部条件、参加者的类型和责任、主要参加者直接与系统交互的人、执行系统主要功能的执行者的次要参加者使用系统的次要功能的执行者， 或者维持系统一般功能的执行者的外部硬件是系统的一部分，执行应用程序的计算机以外的硬件的其他系统在其工作中需要与系统对话的外部系统参加者间的关系、独立关系泛化关系参加者的抽象记述， 可以由一个或多个特

4、定的参与者共享，客户、个人客户、商业客户、用例1，定义： Use Case用例描述系统的外部功能，它分析从用户的角度得出的需求。为了完成相对完整的功能，系统执行的一系列操作的集合表示可视系统功能具有一系列操作。 然而，用例、用例2和用例可以捕获看起来像是特定角色的要求，在该用户的角色中使用实现特定角色要求的用例，并向角色用例提供适当的输出。 它可以用UML的交互来说明针对特定角色目标实现的完整描述例的动态执行过程，可以用状态图、序列图、协作图或非正式的文本描述来表现，识别例子，识别例子关键字。 这些动作(价值定义实例是系统执行的一系列动作)简化了一组用例实例(场景) :参与者使用系统实现目标，

5、认识用例的要点，生成特定参与者可以观测到的结果值。 可以观测的用例是系统边界结果值的用例有意义的目标系统执行结果值是通过参加者观测业务语言，从用户的角度生成一组用例的粒度用例来命名，可以观测：用例在系统边界停止， 作为边界的边界(而不是描述交互组件的内部系统活动)也被称为系统边界，并且使用命名矩形框来定义系统功能的范围。 部署了描述系统功能的用例与所描述的系统交互的角色都位于其他系统完全系统或子系统的系统中，一个或多个用例准确地定义系统的边界(功能)不是件容易的事。 事先认识系统的基本功能集，在此基础上定义稳定准确的系统体系结构，不断扩展系统功能，逐步改进，结果值：有意义的目标、业务功能，系统

6、处理，而系统执行：结果值由系统执行。 系统需要处理的由系统生成，参加者是用户的观点、用户的观点、系统的观点、要点：用例的粒度、用例需要路径，路径需要步骤，这是所有可以观测到的最常见的错误不是业务语言，而是用例粒度-1，以步骤为用例，以系统活动为用例。 用例粒度-2，“四轮马车”c (create ) r (read ) u (update ) d (delete )所有业务都成为CRUD吗？ CRUD能为Actor提供价值吗？ CRUD隐藏业务，成为关系数据库的建模。 “系统数据增减调查”对数据的存储和维护很感兴趣，但是无视用户的目的，用例粒度-3、用例粒度-4，如果是CRUD的话？ 如果CR

7、UD不涉及复杂的交互，则一个用例“管理”无论c、r、u、d如何，都可以用一个用例表示多种基本数据管理，以实现“管理”目标，灵活处理用例粒度-5，CRUD，包含复杂交互的路径用例命名、执行者的观点： (状态语)动词(定语)宾语、用例关系包含提取共同步骤容易实现Extend分离扩展路径通用化的同一业务目的不同的技术，关系1、关系2、包含关系的步骤、多个用例重复， 单独形成价值用例的步骤很多时，基本用例中必须包含用用例封装的逻辑。的。 可以轻松地考虑源代码的函数调用和操作调用。 包含例1、例2、扩展关系1、扩展关系2，在一定条件下在对应的扩展点插入扩展用例的事件流。 基本用例不需要知道扩展用例的详细

8、信息，提供扩展点的扩展用例的行为是否执行取决于主事件流的决定点。扩展关系2、基本用例路径本身可能完全的扩展路径扩展路径步骤多扩展路径内部有扩展点扩展的扩展路径，或者容易变化的分离可以单独存在于“冻结”基本用例基础用例中，但在一种条件下，他的行为可以在其他用例中扩展相同业务目的不同技术的实现，可以是泛化关系：一个用例可以泛化为另一个更一般的用例(更一般的用例专用于特殊用例)的UML 1.5:用例之间的泛化关系在子用例中由父用例定义泛化，销售人员可以结束任何交易。 除了特殊销售人员(高级代理)必须终止的超过一定限制的交易以外，对于基本用例，扩展用例是可选的，包括用例和扩展用例的差异，而不是包括用例

9、。 如果没有扩展用例，则基本用例是完整的；如果没有包含用例，则基本用例是不完整的。 扩展用例的执行必须满足某种条件，但不需要包含用例。 扩展用例的执行会更改基本用例的行为，但不能包含用例。 用例关系：扩展VS .泛化，采用不同的关系，文件结构不同，总结，以理解需求的用例为中心组织需求，获得基于用例的需求分析过程，理解的需求识别参加者开发确定用例的关系，思考、基于用例的需求分析过程大致系统边界用例的概念用例的关系所谓参加者的定义和关系是：1:考虑识别参加者，呼叫台系统：如果用户计划天气预报，系统每天向他发送天气信息的当天气温超过35度，提醒用户注意防热气温是多少？ 时间？ 思考2 :获取需求-工

10、作卡应用程序，初次采访记录开发者：谁使用此应用程序？ 客户：用于记录可计费时间和不可计费时间的所有员工开发人员：现在工作卡应用程序是什么？ 顾客：每半个月用Excel表格记录一次。 所有员工都填写他的表格，然后用电子邮件发给我。 这张表有相当多的标准。 纵向是收费项目代码，横向是日期。 员工可以为每个条目输入说明。 开发者：从哪里可以得到这个收费项目代码？ 开发者：谁管理计费项目代码？ 客人：是的，根据需要添加这个代码。 各经理总是告诉部下应该填写什么。 思考2 :识别参加者：工作卡系统，开发者：谁使用这个应用程序？ 客户：用于记录可计费时间和不可计费时间的所有员工开发人员：现在工作卡应用程序

11、是什么？ 顾客：每半个月用Excel表格记录一次。 所有员工都填写他的表格，然后用电子邮件发给我。 这张表有相当多的标准。 纵向是收费项目代码，横向是日期。 员工可以为每个条目输入说明。 开发者：从哪里可以得到这个收费项目代码？ 开发者：谁管理计费项目代码？ 客户：是的，我(销售经理)会根据需要添加这个代码。 各经理总是告诉部下应该填写什么。 思考2 :识别用例：工作卡系统，开发者：谁使用这个应用程序？ 客户：用于记录可计费时间和不可计费时间的所有员工开发人员：现在工作卡应用程序是什么？ 顾客：每半个月用Excel表格记录一次。 所有员工都填写他的表格，然后用电子邮件发给我。 这张表有相当多的标准。 纵向是收费项目代码，横向是日期。 员工可以为每个条目输入说明