uml精粹——8.部署图 & 9.用例

8.部署图deployment diagram
  部署图展示了一个系统的物理布局，展示软件里哪些部分在硬件哪些部分上跑。

  见图8.1

  其中主要项是通过交流路径communication paths连接的节点nodes。一个节点node是可以放一些软件的东西，它以两种形式出现。一个设备device是硬件，可能是一台电脑或是一个更简单的被连接到这个系统的软件块。一个执行环境execution environment是软件自己主持hosts或者包含其他软件，例子是一个操作系统或一个容器进程container process。
  节点包含人工制品artifacts——软件的物理表现manifestation（经常是文件）。这些文件可以是可执行的（比如exe、二进制、dll、jar、脚本），或者数据文件、配置文件、html文档等。在一个节点里列出一个产物表示这个产物在运行系统中被部署deploy到了这个节点。
  你可以在节点里 像类盒子或只是列出名字来显示产物artifact。如果你使用类盒子，你可以添加一个文档图标或者使用<<artifact>>关键字。你可以用标记值 标记节点或者产物来展示该节点的各种信息，比如操作系统、位置等。
  你经常会有多个物理节点来执行相同的逻辑任务。你可以显示多个节点盒子或用一个标记值来说明数量。
  产物artifact经常是一个组件component的实现。你可在产物盒里用一个标记值来显示。
  节点间的交流路径展示了事物如何联系。你可以给这些路径用 所使用的协议信息来命名。


9.用例use case
  用例是一个捕获一个系统功能需求的技术。用例的工作是通过描述系统的使用者和系统本身间典型的交互typical interaction，提供一个系统是怎样被使用的描述。
  先描述下情景scenario。一个场景是一系列描述用户和系统间交互的步骤。如下的场景：
the customer browses the catalog and adds desired items to the shopping basket.
when the customer wishes to pay, the customer describes the shipping and credit card
information and confirms the sale.
the system checks the authorization on the credit card and confirms the sale both
immediately and with a follow-up e-mail
  这是一个可能方式的情景。但信用卡认证可能失败，这会是一个分开的情景。另外你可能有一个常客，
你不需要获取信用卡信息，这是第3个情景。
  这些情景不同但相似。这里3个情景相似的地方是用户有相同的目标：买东西。虽然不总是成功，但其目标没变。这个用户的目标是用例的关键：一个用例是一个 有一个共同用户目标的情景的集合a set of scenarios tied together 


by a common user goal。
  在用例里，用户指actor演员。一个演员是用户在系统中扮演的角色。演员可能包含顾客、卖主和产品分析。演员实现用例，一个演员可能完成多个用例，一个用例可能有多个演员完成。一个人可以扮演多个角色。
  演员并不是正确的说法，角色role应该更好。


【用例的内容】content

  见图9.1

  你开始选一个作为主要成功的情景main success scenario。你开始用例的身体，通过写出主成功场景的一系列数字步骤。你然后写其他的场景作为扩展extensions，描述他跟主成功情景的不同，可以是成功的或者失败的。
  每个用例都有一个主要的角色primary actor，来请求系统提交一个服务。这个主角有这个用例尝试满足的目标，且经常是这用例的发起者。在实现用例时，也会有其他角色来跟系统交流，这些叫配角。
  用例中的每一步是角色和系统间的交互的一个元素。每步应该是一个简单的描述，并可清楚的显示是谁在执行这一步。所以你不用在用例里描述用户接口user interface。的确，写用例经常是在设计ui之前。
  用例的扩展指定了在主要成果情景MSS中不同的交互的结果的条件condition，并说明那些区别。扩展的开始是为检测到条件的那一步命名，并提供该条件的简短描述。然后是后面的一些步骤，结束是通过描述你要返回的MSS的哪一步。
  用例的结构是一个很好的方式来集体讨论brainstorm主成功场景的不同选择。一般最后最开始就集体讨论好所有的扩展条件，这样能想到更多的条件，后面也会占用更少的时间。
  用例里一个复杂的步骤可以是另一个用例。uml中可以说第一个用例包含include第二个。在文本里没有标准的方式来显示一个被包含的用例，但我发现下划线暗示超链接，很有效。
  对于一个复杂的步骤（会混乱主场景或在几个用例中重复用到），使用被包含included用例很有用。但不用尝试去将用例分成很多子用例，这样浪费时间。
  像场景里的步骤一样，你可以添加一些其他的公共信息到用例去。
·前置条件pre-condition：描述了在系统允许用例开始前，系统应该确保true的东西。这告诉了程序员在他们的代码里不用考虑哪些条件
·保证guarantee：描述了系统在用例的最后会确保什么。Success guarantees hold after a successful scenario; minimal guarantees hold after any scenario
·触发器trigger：指出让用例开始的事件
  当你考虑添加元素时，请概括。最后不要做太多事情，保持用例简洁易读。
  用例里你需要的细节的数量取决于用例里风险risk的数量。经常早期的时候你需要一些关键用例的细节，其他的在你开始实现的时候可以被很快的具体化fleshed out。你不需要写下所有的细节，口头交流也很有效，特别是在一个迭代循环里通过运行代码需求就被满足meet了。
  
【用例图】
  uml也提供了图，但不是必须的。在你用例工作中，不要花费太多精力到这个图上，而是集中注意力到用例的文字内容去。

  见图9.2

  理解用例图最好的方式是把他当做用例集合的内容的一个图形表。用例图显示了角色，用例，和他们之间的关系：
·哪个角色实现了哪个用例
·哪个用例包含了其他用例


【用例的等级】  
  经常你听到人们讨论系统用例和业务用例。一般一个系统用例表示软件的一个交互，而业务用例讨论一个业务business怎样回应一个客户customer或一个事件event。
  核心的用例是在sea-level，sea-level一般代表主角和系统间离散的discrete交互。这些用例会传递一些值到主角，并经常需要花费主角一定时间去完成。而在那里只是因为被sea-level用例包含的用例叫做fish level。更高的，kite-level用例显示了sea-level用例如何适应更宽的业务交互。kite-level用例经常是业务用例，而sea和fish级是系统用例。你应该让你大部分用例都在海洋级sea level。我喜欢在用例的顶部说明等级。


【用例和特性feature】或者说故事
  尽管你可以直接貌似特性，但很多人发现更有帮助的是先开发用例，然后生成特性列表list of features。一个特性可能是一整个用例，用例里的一个场景，用例里的一个步骤或者各种行为。


【何时用】
  用例帮助理解一个系统的功能需求。需要记住用例代表一个系统的外部视图external view。