面向对象-表示法

表示法

画图的动作并不是分析或设计的要点。一张图示只是记录了系统行为的一种说明或一种架构的愿景与细节。如果遵循任何一种工程师的工作方式（软件、土木、机械、化工、建筑或其他），你很快就会意识到系统构想形成的唯一场所就是设计者的头脑。当这种设计随时间展开时，它常常被记录在一些高科技的媒质上，如同被记录在白板、餐巾纸或信封的背面一样的。

1.统一建模语言

拥有一种定义良好的、富有 表现力的表示法，对于软件开发过程是很重要的。首先标准的表示法让分析师或开发者能够描述一个场景，阐明一种架构，然后无二义地将这些决定高速别人。画一张电路图，其晶体管的符号应基本上可以被世界上任何一个电子工程师看懂。类似地，如果一个在纽约的建筑师画出了一栋房屋的草图，在旧金山的建筑工人基本上能够毫无困难地理解哪里房门、哪里放窗、哪里放电器，只要图纸包含这些细节。其次正如怀特海在他的数学名著中所说的，“好的标识法消除了大脑的不必要工作，让大脑能够集中中考虑更高级的问题。第三，一种富有表现力的表示法能够利用自动化的工具，消除关于这些决定的许多繁琐的一致性和正确性检查。美国国防科学委员会的一份报告指出：”软件开发现在是，而且永远是一种劳动密集型的基数.....虽然机器能够做一些辛苦而乏味的工作，并让我们能够记录下心中的构想，但概念开发仍是典型的人类活动....软件开发中永远不会消失的部分就是打造概念结构，可以消失的部分是表达这些概念结构所需的工作量。

2.模型与多重视图

许多其他行业（如电子、化工、建筑、音乐等）都有特有的表示法，表示人们创造出的制品。同样，人们用UML对构建的系统进行建模（即表示 ）。总的来说，所够贱的UML模型以一定的保真度展现要构建的真实系统。但是，不可能在一张大图上记录一个复杂软件系统的所有细节。UML有几种不同类型的图，每一种都提供了系统的某种视图。Kleyn和Gingrich指出：“开发者必须理解对象所涉及的结构和功能。开发者必须理解类对象的分类结构、使用的继承机制、对象独立的行为以及整体系统的动态行为。这个问题有点类似观看网球后足球这样的体育赛事--每个摄像机都结实了动作的一个方面，这不能由一个摄像机独立完成。

3.图分类

UML图可以分成两大类：结构图和行为图。

结构图：

包图

类图

组件图

部署图

对象图

组合结构图

概念模型、逻辑模型和物理模型

随着系统开发的推进和程序，你的系统模式可能代表了不同的细节层次。概念模型记录了系统中存在的领域实体以及它们与系统中其他领域实体的关系。概念层的建模是利用业务领域的术语来完成的，应该是技术无关的。系统的逻辑视图利用了概念模型中创造的概念，建立起关键抽象和机制的意义，并确定系统的架构和整体设计。系统的物理模型描述了系统实现的具体软件和硬件构成。显然，物理模型是技术相关的。

对于某个项目来说，随着时间的推移，系统的设计将从概念成熟发展到逻辑成熟，最后到物理成熟。在开发声明周期的不同阶段，会使用不同的图。某些图只在项目开发声明周期的早期使用。根据创建的系统的类型，用法也会不一样。例如，一个券商的投资交易系统会使用更多地状态机图和时间图，而简单的支票本应用就不会这样。

对于某个项目来说，分析和设计的产物是通过这些模型来标识的。总的来说，这些不同模型的语义是丰富的：它们的表达能力足够强，让开发者能够记录系统分析和架构阐述时所有感兴趣的战略和战术决策；它们也足够完整，可以作为大多数面向对象语言实现的蓝图。

我们将以下面的次序来介绍这些图：

包图

组件图

部署图

用例图

活动图

类图

序列图

交互概述图

组合结构图

状态机图

时间图

对象图

通信图

包图

在进行面向对象分析和设计时，需要组织开发过程的工件，从而清晰地展现出问题域的分析和相关的设计。具体的原因会有同，但主要集中在可视模型本身的物理结构上，后希望通过多重视图，清晰地展现模型元素。组织OOAD攻坚的好处有以下几点：

在复杂系统开发中提供清晰性和可理解性；

支持多用户使用的并发模型；

支持版本控制；

在多个层次上提供抽象--从系统到组件中的类；

提供封装和包容，支持模块化。

如果因为有一些元素存在，或者因为我们的关注，需要显示向量的元素，可以使用合适的表示法在包内显示这些组成部分。图5-3也显示了HydroponicsGardeningSystem包，但它还包含了另外两个包。在左边的表示方法中，我们将Planning和Greenhouse包作为被物理包包含的包，在HydroponicsGrardeningSystem包之内显示。右边显示了另一种包容关系的表示法

包的可见性

基本概念：依赖关系

如图，UML元素（包括包）之间的依赖关系使用一个虚线的开放箭头来标识的。箭头的尾部位于具有依赖性的元素，箭头位于支持这种依赖的元素。依赖关系可以标上标签，通过在符号中包含依赖关系的类型，强调元素间依赖关系的类型。包特有的依赖关系包括导入、访问和合并，由于包容的元素之间的关系儿导致的包间依赖关系包括跟踪、派生、细化、允许和使用

组件图

组件是一种结构化的分类器，组件间的协作和内部结构可以利用组件图来标识。组件与组件之间通过定义良好的接口进行协作，从而提供系统的功能。组件也可以由一些协作的组件组成，提供它自己的功能。

在开发中，我们利用组件图来表达架构的逻辑封城和划分方式。组件图中展现了组件间的相互依赖关系，也就是它们通过定义良好的接口进行协作，从而提供系统的功能。下图展示了EnvironmentalControlSystem的组件图。这个百合视图中张世乐提供组件功能的四个封装的组件Environmental-Controller/LightingController/HeatingController和CoolingController

基本概念：组件接口

如果需要更详细地显示组件的接口，可以提供接口规格说明，如图所示。在我们的例子中规格说明只关注了EnvironmentalController的7个接口中的两个：CoolControl和AmbientTemp

EnvironmentalController实现了CoolControl接口，这意味着它提供了该接口规定的功能。这个功能是让所有使用这个接口的组件能工启动、停止、设置温度和设置风扇速度，它所包含的操作说明了这一点。如果需要，这些操作可以进一步地包含参数和返回值类型。CoolingController组件要求这个接口的功能。

还展示了EnvironmentalController组件在AmbientTemp接口上的依赖关系。通过这个接口，EnvironmentalController获得它所需要的环境温度，实现它在EnvironmentalControllerSystem组件内的职责。

下图中展示了EnvironmentalController的接口的另一种表示法。这里可以看到，标题《provided interfaces》下面列出了是哪个提供的接口。对于指定的CoolControl接口，我们提供了相关的操作。类似地，标题《required interfaces？下面列出了要求的接口

组件实现

图5-13指出，EnvironmentalController组件是由Plan、Controller和SensorInput类来实现的。这是三个类提供了组件接口宣城的所有功能。但是，要做到这一点，需要组件要求的接口所指定的功能。

图5-14展示了EnvironmentalController组件以及Plan、Controller和SensorInput类之间的这种实现关系。这里，我们看到从每个类指向EnvironmentalController的实现依赖关系。同样是这一信息，也可以通过包含关系来表示。

组件的内部结构

具体来说，EnvironmentalControSystem要求GardeningPlan，后者规定了溶液种植园系统的环境需求（光照、加热和冷却）。这种对要求的接口的需要被代理隔了一个未命名的端口，它与GardeningPlan接口相连。通过这种方式可以知道，如果我们想使用EnvironmentalControlSystem组件的服务，就必修向它提供培育计划。我们也知道，必须为它提供AmbientLight、AmbientTemp和TempRamp服务。

EnvironmentalControlSystem的连接器提供了它与环境之间的通信联系，也为它的部件提供了内部通信的方式。

部署图

部署图用于展示在系统的物理设计中，工件在节点上分布的情况。单张部署视图代表了一种系统攻讦结构的视图。在开发中，我们使用部署图来说明节点的物理集合，这些节点是系统执行的平台。

部署图有三个基本元素：工件、节点和它们的连接。

工件表示法

节点表示法

下图中，PC和ApplicationgServer节点之间的通信是双向的。通信路径通常表示某种直接的硬件耦合，如USB电缆、以太网连接甚至是共享内存。但是，路径也可以表示不太直接的耦合，如卫星和地面后移动电话通信。在我们的例子中，它标识利用TCP/IP的双向连接。我们规定一个或多个PC节点可以连接到ApplicationServer节点上。

用例图

多年的证据证明，软件项目失败最常见的原因都集中在关键涉众之间沟通不佳或缺少沟通。当开发组织和业务机构之间缺乏联盟时，这一点特别关键。

我们非常需要一种系统开发方法，让开发组织能够理解业务的目标，同时又不会玛法业务人员。用例图提供了这种能力。我们通过用例图展示待建系统的上下文范围以及它提供的功能。它们描述了谁与系统交互，外部世界希望系统做些什么。

基本概念：执行者

执行者是与系统交互的实体，他们可以是人或其他系统。执行者位于他们使用的系统之外，用棍状的小人来表示。

在考慮执行者时，一种方法是思考执行者所扮演的角色。在真实世界中，人们（系统）可能承担许多不同的角色。例如，一个人可以是一名销售人员、一名经理、一位父亲、一位艺术家等。

基本概念：用例

用例代表了执行者希望熊为他们做什么。下图展示了溶液种植园系统的一些用例，用一些椭圆表示。用例不仅仅是系统可以提供的功能，从“执行者的观点“来看，用例必须是一个”完整“的活动流程，它为执行者提供了”价值“。

基本概念：用例图

1.确定用例细节

那么，如何指定用例提供的功能细节？如何指定这个完整序列的事件？较好的方法是利用其他UML模型（如活动图）和文本规格说明。在UML文献中，用例规格说明有许多不同的形式。大多数都包括一下信息：用例的名称、关于它的目的的一段剪短描述、乐观流程、一个或多个更实际的流程。

2.用例规格说明实例

下面来看看“维护储水箱”用例的例子。

用例规格说明

用例名称：维护储水箱

用例的目的：本用例提供了维护储水箱中储水量的功能。本用例让执行者维护一组水箱和营养液相。

乐观流程：

A.执行者检查储水箱的当前容量。

B.执行者决定水箱需要加注。

C.水箱正常的溶液种植园系统操作被执行者挂起。

D.操作者选择水箱并设置加注量。

对于每个选定的水箱，执行步骤E~G。

E如果水箱正在加热，系统停止加热器。

加热器达到安全温度。

F。系统加注水箱

G.当水箱加注完成后，如果水箱是在加热的，系统启动加热器。

水箱达到操作温度。

H.执行者继续正常的溶液种植园系统操作。

实际流程：

条件触发的可选流程如下。

条件1：原料不够，不足以将水箱加注到执行者指定的容量。

D1.提醒执行者原料不够，不能达到设置的值。显示可用的原料。

D2.提示用户选择终止维护或重新设置加注容量。

D3.如果重新设置，执行步骤D.

D3.如果选择终止，执行步骤H。

D5.否则，执行步骤D2.

条件2：。。。

高级概念：<<include>>和<<extend>>关系

1.include关系

在溶液种植园系统的例子中，我们有一个名为“UPdate Crop Encyclopedia(更新作物百科全书）”的用例。在分析过程中，我们确定使用这个用例的执行者Nutritionist将先看到作物百科全书的内容，再更新它。这就是Nutritiongist可以调用“View Reports（查看报告）”用例的原因。执行者Gardener在每次调用Maintain Stroage Tanks时也是这样。两种执行者都不应该盲目地执行用例。因此，View Report用例是其他两个用例需要的共同功能。这可以利用<<include>>关系在用例模型中描述。

2.extend关系

在开发用例时，可能发现某些活动可以作为用例的一部分执行，但并不一定要运行它，用例也能成功。在我们的例子中，当执行者Gardenger执行Manage Garden用例时，他可能想看一下某些报告，这可以通过View Reports用例来实现。但在执行Manage Garden时，View Reports并不是必须的，Manange Garden本身是完整的。所以我们修改用例图，

高级概念：泛华

活动图

活动图提供了活动流程发的可视化描述，可以是在系统、业务、工作流或其他过程中。这些图关注被执行人的活动以及谁负责执行这些活动。

活动图的元素包括动作节点、控制节点、和对象节点。有三种类型的控制节点：初始和终止、判断和合并、分叉和结合。

基本概念：动作

基本概念：开始和停止

既然活动图展示了一个处理流程，那么流程就必须有开始和结束的地方。活动流程的开始出被表示为一个实心圆点，借书处被表示为一个牛眼的样子

基本概念：判断节点和合并节点

分區

高级概念：分叉、结合和并发

分叉节点和结合节点分别与判断节点和合并节点类似，关键的不同之处在于并发。分叉节点具有一个进入流程和多个离开流程，判断节点也是如此。不容之处在于，判断节点会选择一个离开流程，而进入分叉节点的一个流程会导致多个离开流程。所有离开流程是并发的。如图，来自Set Fill Levels动作的一个刘策划稿进入分叉节点，即第一条粗横线。伺候，NutrientTank流程和WaterTank流程是并行发生的。

结合节点具有多个进入流程和一个离开流程，与合并节点类似。但是对于结合节点来说，必须完成所有进入流程之后，才能够进入离开流程。如图，第二条粗航线就是一个结合节点。必须在两个进入流程NutrientTank和WaterTank完成之后，离开流程才能继续Resume Operationgs动作。

高级概念：对象流

类图

在系统的逻辑视图中，类图用于表示类和它们之间的关系。单张类图表示了系统的一个视图。在分析时，我们利用类图来说明实体共同的角色和责任，这些实体提供系统的行为。在设计时，我们利用类图来记录类的结构，这些类构成了系统的架构。

序列图

交互概念图

组合结构图

状态机图

状态机在用到实时处理的行业中是周所周知的。状态机被用来射界和理解时间关键的系统，在这种系统中，时间不正确的后果是严重的。

状态机图将行为表示为一系列的状态转换，由事件触发，并与坑能发生的动作相关联。这样的状态机也被称为行为状态机。状态机图通常用于描述单个对象的行为。但是，它们也可以用于描述系统中更大元素的行为。状态机图和活动图有亲戚关系。但是状态图关注的是状态以及状态之间的转换，而不是活动的流程。

状态机图的两个基本元素是状态和状态转换。

基本概念：初始状态、最终状态和简单状态