|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
①依赖（dependency）是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，偶尔在其上还有一个标记，如下图所示。
|
|
|
|
|
|
|
|
②关联（association）是一种结构关系，它描述了一组链，链是对象之间的连接。聚合是一种特殊类型的关联，它描述了整体和部分间的结构关系。在图形上，把一个关联画成一条实线，它可能有方向，偶尔在其上还有一个标记，而且它经常还含有诸如多重性和角色名这样的修饰，如下图所示。
|
|
|
|
|
|
|
|
③泛化（generalization）是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如下图所示。
|
|
|
|
|
|
|
|
④实现（realization）是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。在两种地方要遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，它是泛化和依赖关系两种图形的结合，如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
检验（检查）包括测量、检查和测试等活动，目的是确定项目成果是否与要求相一致。检验可以在任何管理层次中开展，例如，一个单项活动的结果和整个项目的最后成果都可以检验。检验有各种名称，如复查、产品复查、审查及评审等。
|
|
|
|
检查表（核对表）是常用的检验技术，检查表通常是由详细的条目组成的，用于检查和核对一系列必须采取的步骤是否已经实施的结构化工具，其具体内容因应用的不同而不同。检查表是一种有条理的工具，可简单可烦琐，语言表达形式可以是命令式，也可以是询问式。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OOA的基本任务是运用面向对象方法，对问题域和系统责任进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域及系统责任所需的类和对象，定义它们的属性和服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能直接反映问题域和系统责任的OOA模型及其详细说明。
|
|
|
|
用例分析方法的创始人Ivar Jacobson给用例的定义是：“用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例则定义一组用例实例。”从这个定义中，我们可以得知用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景；其次，可以知道，用例应该给参与者带来可见的价值，这点很关键；最后还可以得知，用例是在系统中的。
|
|
|
|
用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。构建用例模型需要经历识别参与者、合并需求获得用例、细化用例描述三个阶段。
|
|
|
|
（1）识别参与者。参与者（actor）是系统之外与系统进行交互的任何事物，参与者可以是使用系统的用户，也可以是其他外部系统、外部设备等外部实体。在UML中采用小人符号来表示参与者。参与者有主要参与者和次要参与者之分，开发用例的重点是要找到主要参与者。
|
|
|
|
（2）合并需求获得用例。将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。而其中的依据主要可以来源于已经获取得到的特征表。首先，将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。在确定用例的过程中，不能混淆用例和用例所包含的步骤，要注意区分业务用例和系统用例。
|
|
|
|
（3）细化用例描述。用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流、扩展事件流）、后置条件等，其他的还可以包括非功能需求、用例优先级等。
|
|
|
|
：一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时可以对用例进行分组。UML使用用例主题划分用例图，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
两个用例之间的关系可以概括为两种情况。一种是用于重用的包含关系，用构造型<>或<
|
|
|
|
（1）包含关系：当可以从两个或两个以上的原始用例中提取公共行为，或者发现能够使用一个构件来实现某一个用例很重要的部分功能时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例。
|
|
|
|
例如，软考在线图书订单处理系统中，“创建新订单”和“更新订单”两个用例都需要检查客户的账号是否正确，为此定义一个抽象用例“核查客户账户”。用例“创建新订单”和“更新订单”与用例“核查客户账户”之间的关系就是包含关系。
|
|
|
|
（2）扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
|
|
|
|
例如，软考在线图书管理系统中，读者归还图书时，需要判断当前日期是否已经超过了图书借阅的周期。如果超过了借阅周期，则必须罚款。“归还图书”和“罚款”用例之间的关系就是扩展关系。
|
|
|
|
用例之间还存在一种泛化关系。用例可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。例如，购买飞机票时，既可以通过电话订票，也可以通过网上订票，则订票用例就是电话订票和网上订票的泛化。
|
|
|
|
|
|
|
|
|
|
|
|
|
