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