虽然写这个博客主要目的是为了给我自己做一个思路记忆录，但是如果你恰好点了进来，那么先对你说一声欢迎。我并不是什么大触，只是一个菜菜的学生，如果您发现了什么错误或者您对于某些地方有更好的意见，非常欢迎您的斧正！
目录
✔ 类模型描述系统中的对象及其关系，状态模型描述对象的生存期，交互模型描述对象如何交互。
7.1用例模型
7.1.1参与者
✔参与者（actor）：系统的直接外部用户——直接与系统通信的一个对象或一组对象，但并不是系统的一部分。
▶每个参与者都表示以某种方式对系统起作用的那些对象。
▶参与者可以是人、设备和其它系统——任何与系统直接交互的事物。
▶例如：客户和维修技师 是 自动售货机 的不同参与者。
▶如果对象的行为有不同侧面的话，它就可以被绑定到多个参与者上。（例如，某个人既可以是自动收获机的客户，也可以是维修技师）
▶参与者有一个明确的用途。相反，对象和类经常是许多不同用途兼而有之的。（比如参与者可以是学生、老师，他们有自己不同的用途，但是当他们都身为参与者的时候，他们的用途都是购买）
▶参与者直接与系统相连——间接相连的对象不是参与者，不应该被包含而作为系统模型的一部分。与间接相连的对象的任何交互都必须通过参与者。（比如调度维修的调度员就不是参与者）
7.1.2用例
✔用例（use case）：系统通过与参与者的交互可以提供的一段连贯的功能。
▶每个用例都会涉及一个或多个参与者以及系统本身。（比如：用例“购买一瓶饮料”涉及客户参与者）
▶用例涉及系统和其参与者之间的消息序列。（比如用例“购买一瓶饮料”的时候，要先交钱才能得到饮料）
▶错误条件也是用例的一部分。（例如选择一瓶已经卖完的饮料，就要显示警告信息）
▶用例把一部分系统功能相关的所有行为组合在一起。这包括普通主线行为、普通行为的变体、异常条件、错误条件和请求取消。
▶在完整的模型中，用例分割系统的功能。
7.1.3用例图
| ▶系统包括一组用例和一组参与者。 ▶每个用例表示系统提供的一段功能。 ▶用例集合以某种细节层次显示了系统完整的功能。 ▶参与者集合表示系统服务的完整的对象集合。 |
 |
7.1.4用例模型的准则
✔ 用例标志系统的功能，并根据用户的观点组织这些功能。
✔ 构建用例模型的指南：
▶确定系统边界。
▶确保关注参与者。
♦每个参与者都应该有单一的、一致的目的。
♦如果某个现实世界的对象体现了多种目的，就要分别用单个参与者来捕获它们。
♦参与者要根据系统来定义，而不是作为自主的概念来定义。
▶每个用例必须给用户提供价值。
▶关联用例和参与者。
♦每个用例都至少要有一个参与者，每个参与者会参与至少一项用例。
♦用例可能会包括几个参与者，一个参与者也会参与多个用例。
▶用例是非形式化的。
▶用例可以结构化。
7.2顺序模型
✔ 顺序模型详细描述用例的主题。分为场景和顺序图。
✔ 顺序图具有更加结构化的形式。
7.2.1场景
✔ 场景（scenario）：系统在某个特定的执行期内所发生的一系列事件，例如用例。
▶场景可以显示为一列文本语句。
▶场景包含对象之间的消息以及对象所执行的活动。
▶文本格式便于编写，但它无法清晰地显示每条消息的发送者和接收者。
7.2.2顺序图
✔ 顺序图（sequence diagram）：显示了交互的参与者以及参与者之间的消息顺序。也显示了系统为了执行全部或部分用例而与其参与者的交互。
▶每个参与者以及系统都用一条垂直的生命线（lifeline）表示。
▶图中只显示消息的顺序，而不是它们的准确时序。
▶每个用例需要一张或多张顺序图来描述其行为。
▶我们应该为用例系统内部的每种异常条件绘制一张顺序图。
7.2.3顺序模型的准则
①至少为每个用例编写一种场景。场景中的步骤应该是逻辑命令，问不是单次的按钮点击。
②把场景抽象成顺序图。顺序图清晰地显示了每个参与者的贡献。
③划分复杂的交互。把大型交互划分成各个组成的任务，并为每一项任务绘制一张顺序图。
④为每种错误条件绘制一张顺序图。显示系统对于错误条件的响应。
7.3活动模型
✔活动图（activity diagram）：显示了组成复杂过程的步骤序列，例如算法或工作流。
▶与顺序图类似，活动图可以显示控制流，但专注于操作而不是对象。
▶活动图在设计算法和工作的早期阶段最为有用。
7.3.1活动
✔ 活动图的各个步骤都是操作。
✔ 活动图的目标：显示复杂过程内部的各个步骤以及它们之间的顺序约束。
✔ 活动可以分解成更细的活动。
7.3.5可执行活动图
✔ 活动令牌（activity token）：可以放在某个活动符号上，表示它正在执行。
7.3.6活动模型的准则
✔ 不要误用活动图。
✔ 让图保持平衡。图中的活动应该具有一致的细节层次。
✔ 注意分支和条件。
✔ 注意并发活动。
✔ 考虑使用可执行的活动图。可执行的活动图可以帮助开发者更好地理解系统。