Fork me on GitHub

UML（4）

Posted on | Edited on | In | Views:

面向对象系统分析与设计（4）

引子

  • 为了让具有不同背景的角色（比如 user、customer 等）能够准确地获取需求，引入了类图、用例图、时序图、状态机图等等手段

UP建模

UP建模的四大阶段：

  1. 初始阶段：主要从此阶段拿到需求。搞定最关键部分的元素。占比10%。
  2. 详述阶段：填充细节，占比约80%。
  3. construction 阶段：补充剩下的。（不理会）
  4. transition 阶段：需求变更时进入此阶段。（不理会）

专有名词

  • domain model：针对一些全局的类和类之间的关系建模。静态的。关键词：数据。
  • use-case model：针对角色、用例和他们之间的关系建模。动态的。关键词：功能性。
  • domain specification：对 domain model 的描述。
  • use case specification：对 use-case model 的描述。
  • user-interface specification & prototyping：对 actors 和 system 之间的接口标准的描述。
  • actors：指的是 users，代表外部的主体。
  • glossary 术语表：分析员、开发者用的专业术语。
  • architecture description：对 use-cases 中的主干（核心，仅占 5~10%）的描述

身份

  1. system analyst：负责整个需求、精简系统、确定类、类间的联系、确定 actors 和用例。（任务最重，几乎什么都做）
  2. domain analyst：分析全局的特性。
  3. architect：以整体视角对用例模型进行描述。
  4. use-case 举例者：对用例进行详细阐述。
  5. user-interface 设计者：设计接口。

获取需求的正确步骤

  1. 拿到 user 的 needs：目标 + 约束（哪些能做、哪些不能做）
  2. 确定可行性：从经济、技术、可操作性、合法性等方面考虑
  3. 记录需求。
  4. 实现需求。

什么是有效的需求？

正确、完整、一致、无二义、真实。

Domain 建模

【important】拿到系统中最核心的 classes 和它们的 associations
要求：这种建模要尽可能的准确，保证后期不再修改、系统可以重用。

  • classes 有哪些？
    • 业务对象（比如订单、账户这种）；
    • 真实世界的对象（比如消费者、供应商）；
    • 事件（买卖）
  • classes 用名词表示，associations 用动词表示。
  • 阿辉注：如果题目列出一大段文字，那么我们要做的是：
    1. 首先将名词圈出来，这些名词都可能是 classes；
    2. 然后剔除多余、不相关的名词。
    3. 同时存在一些名词，很明显是附属于其他名词的（比如 name、age 等名词，明显归属于 Person 的名下），可以当做属性看待，不能作为独立的 classes。
    4. 剔除这些名词后，幸存下来的差不多就是合格的 classes 了。
    5. 之后将动词圈出来，这些动词很可能就是 associations；
    6. 按照前两步骤幸存下来的名词连线，将不合格的动词剔除。
    7. 剩下的动词大概就是合格的 associations 了。
    8. 以上步骤主要靠练习，没有特别有效的技巧。
  • 对于属性的命名，注重简短、有内涵等等。
  • generalization（泛化、父类/子类的关系）的层次选择 2~3 层最合适。

use-case 建模

【important】看重功能性 functionality。

  • 开始使用 use-case：
    1. 使用事件表；
    2. 确定 actors；
    3. 确定 functions；
  • 为不同的场景创建 Activities flow。
  • 一些内部用例可以重用。

actors

  • 定义：system 外界的一些直接接触者（实体），对系统输入，获得输出。
    • 举例：学生、教师、注册员、以及非人的事物（如第三方系统：账单系统）
  • 理解：actor 是一个 object，user 则是这个 object 的 instance。

use case

  • 定义：运用 system 的一种方式。代表一系列 events。
  • 理解：use case 是一个类的容器，scenario 是一个 instance。
  • use case 的命名应当是动宾短语，语态是现在时。
  • 举例：一个注册员 registrar，对应的用例有：维护学生信息、维护教师信息、维护课程信息、提供课程清单。

Scenario

  • 理解：以 actor 的视角，对 system 的描述。这种描述仅建立在部分功能的基础上，所以一定是不全面、带有偏见的。
  • 用处：多用在 error 和非主要流程的描述上。
  • scenario 的分类：
    • 既有场景：描述当下。
    • 预想的场景：描述将来。
    • evaluation：比如：acceptance tests（对功能进行检测）。
    • training：给新人培训。
  • use-case 建模的两种观点：
    1. top-down：从 use-case 开始，到 scenario 结束。
    2. bottom-up：从 scenario 开始，到 use-case 结束。

怎么算是一个好的用例

  • 主要体现功能性；
  • 传递一些有价值的东西交给 actor；
  • 范围要大，够清晰，最好列出细节。
  • 不仅显示正常的流程，还要考虑异常的流程。
  • 规格：
    1. name；
    2. actors；
    3. 一些先决条件：preconditions；
    4. 事件流：flow of events；
    5. 一些后决条件：postconditions；
    6. 其他需求（按需，可选）
    7. 分支、异常流程（按需，可选）

flow of events

  • 定义：一系列的事件序列。要求有序、有条理、事件明确。
  • 要求：尽可能简单、避免循环。

include

  • 将若干个 use-cases 中的相同功能剥离开，作为独立的 use-case，然后让这些 use-cases 都包含（include）它。
  • 在 use case 图中，通常是虚线箭头指向独立 use-case，而且附上<<include>>的记号。

extend

  • 新的 use-case 继承旧的 use-case。
  • 在 use case 图中，通常是子类用虚线箭头指向父类，而且附上<<extend>>的记号。

十种 use-case 建模的 errors

  1. 不写 usage scenario text。
  2. 只描述属性和方法不解释用法（usage）。（阿辉注：理解不能吧，我也看不懂，记住好了）
  3. use case 太简短。
  4. 遗漏 user interface。
  5. 给 use-case 取名太晦涩。
  6. 没有从 user 视角看待用例。
  7. 忽略 system 的响应。
  8. 忽略分支流程。
  9. 忽略前置、后置条件。
  10. 对采用 include 或 extends 难以抉择。

user-interface

逻辑上：需要确定哪些数据是 user 可以操作的，以及这些数据是用什么方式呈现给 user 的。
实际上：sketch -> prototype -> verify。
- [理解]先写个草稿、然后写个模板，最后套用并适当修改。

acceptance tests

  • 定义：通过测试的方式，告知消费者，system 的功能、限制等等有效可用。
  • 目标：确保功能性、接口可用、消息正确、以及界面正常。
  • 步骤：
    1. 检查之前的需求，剔除冗余；
    2. 收集 users 新增的需求；
    3. 为每个需求，构建一个独立的评价场景。
-------------The End-------------