软件架构简介及用例图、活动图、顺序图自上而下的设计

软件架构简介

可视化设计：

　　1. 使想象中的系统可视化
　　2. 能指定系统的结构和行为
　　3. 提供一个能够指导系统构建的模板
　　4. 记录所做的决策，形成文档

Microsoft的Visual Studio 从2010开始建模策略基于两种思想：域专用语言(Domain-Specific Languages, DSL), 模型驱动开发(Model-Driven Development, MDD)。

MDD力求获得建模的最大信息，尽可能提取从不同的模型一直到实现的各种信息。

DSL是一种满足特定标准的建模语言。DSL不仅能够使可视化模型用于生成设计文档，而且可以使其以一种准确的形式捕获一些易于处理的信息，同时，还提供了将模型编译为代码的广阔前景。

接口——组件接口定义的是组件和使用组件的客户所遵守的约定。这种约定不能被破坏，即对已有的操作，其参数不能增减。虽然有时允许添加新的操作，但操作的语义（或行为）应保持不变。

实现——组件的实现可根据所使用的底层数据库、算法（如排序）而随意改变，只要客户关心的行为不受影响即可，甚至可以采用不同的编程语言进行编写。

用例图是对使用应用程序的外部使用者以及他们所能作的事情的简要描述。用例图描述的是需求、用户和系统主要组件之间的关系。用例图显示的是用户（使用者）与系统或应用程序内的用例之间的关系。用例图使我们能全面了解系统的工作原理以及系统内的各种角色和发生的操作。

用例图可以向下分解为活动图。活动图通过一系列动作将软件处理过程描述为工作流。

顺序图显示了不同对象之间的交互。这种交互通常表现为不同对象之间的一系列消息。

组件图有助于可视化软件系统的高层结构。

类图描述的是应用程序系统中的对象。这种描述并不参考系统本身的任何特定实现。

层次图用于描述系统的逻辑架构。层次图将代码中的不同对象组织为不同的组（或层次），这些组用来描述对象执行的不同任务。

在Visual Studio 2013中，支持以上UML图：

使用Architecture Explorer工具有助于理解一段代码的现有架构。这个工具使我们可以深入到现有代码中，甚至可以深入到已编译的托管代码中，以帮助我们理解系统的工作原理。这一过程并不需要打开任何代码文件。比如查看WatiN框架代码的架构：

 

从Architecture Explorer还可以进入依赖图，它可以使我们更容易地理解一段新的或不熟悉的代码。依赖图使用DGML(Directed Graph Markup Language直接图形标记语言)以一种易于理解的图形方式显示了不同区域的代码之间的关系。

使用用例图、活动图和顺序图进行自上而下的设计

建模工具的强大之处在于能使我们设计出应用程序的架构。其中包括定义问题域有关的常见术语，并且保证团队每一个人都理解这些概念。

用例图可以以图形方式给出一个系统的功能概述，显示了使用该系统的使用者以及他们能执行的操作。了解任何一类图的最好方法是学习一个示例并认真对其进行分析。

一个参与者代表一个可以与该系统进行交互的用户、组织或外部系统。

一个用例代表一个或多个参与者所能完成的动作。

一个关联表明一个参与者可以参与所关联的用例。

一个子系统可以是正在运行中的应用程序，或者应用程序中的一部分。在个别用例图中，一个子系统既可能代表整个应用程序，也可能仅仅代表应用程序中的一个类。子系统支持的所有用例都绘制在子系统内。

最好的学习方法是从描述包含几个主要用例图的系统开始，每一个图都应该定义系统的一个主要目标。一旦定义了系统的目标之后，利用用例图工具箱中的一些其他对象就可以更加详细地定义系统了。

下面对用例Order Book进行进一步分解，使用Include关系分解：

使用带箭头的虚线表示的Include关系表明了一个用例使用被包含用例的所有行为。箭头通常应指向更详细的用例。每一个包含的用例是参与者完成主用例所要采取的一步操作。

用例图并没有说明该用例以什么样的顺序发生，或什么时候需要一个特定用例。要想清楚地描述这些信息，可以在一般的用例中附加一个Artifact对象，然后在Artifact元素与一般用例之间建立一种依赖关系。利用Artifact元素可以将一个独立的文档附加到用例中：

活动图可以通过一系列动作将一个商业或软件过程表示为一个工作流。这些动作可以由无数的对象完成，包括人、软件或计算机。活动图可以用于对一个特定用例的逻辑进行建模，或者对详细的商业逻辑进行建模。为了便于理解，可以将活动图想象为流程图。

活动图通常有一个起点、一系列活动和一个终点，该终点表明活动结束。

黑点称为起点，每个活动图都必须有起点，它用来指明活动的起始点。

圆角矩形称为动作，动作表示活动中的一个步骤，即用户或系统完成的一个动作。

最上面的菱形元素称为汇合点，用于汇合多个分支，这些分支通常用一个决策点分开。一个汇合点有两个或以上的输入和一个输出。

中间的菱形元素称为决策点，用于创建活动图中的分支流。决策点应该只有一个输入，但有多个输出。

Connector元素用于表示活动图中不同元素之间的流。

活动图也可以描述一组同时执行的动作，这组动作称为并发流：

有两种方法可以用来表示一个活动流入和流出的数据流。第一种方法是使用对象节点，这通常是描述活动之间的数据流最简单的方法。可以将一个对象节点想象为程序中的变量，它存储的值或多个值可以从一个动作传给下一个动作。第二种方法是使用input pin和output pin。

在使用input pin和output pin时，一定要对它们进行命名，从而表明产生或接收对象的角色（如参数名）。

在用例图部分的图中添加了一个Artifact元素，它可以通过Hyperlink属性建立这些元素与一张活动图之间的关联。

顺序图用于显示类、组件、子系统或参与者之间交互的顺序。顺序图自上而下指明了系统的时间流。本身从左至右显示的是从一个元素到下一元素的控制流。

图中三条竖直的虚线称为生命线，这些线代表的是所描述的交互行为中的参与者。时间沿生命线自上而下流动。生命线顶部的框如果是圆角的，说明它是用程序代码生成的。如果是常规的矩形，则说明是拖拉方法生成的。

左上角的黑点称为发现消息，表示未知的活不确定的参与者发送了一条异步消息到该顺序图中。

生命线上的矩形条成为执行发生，表示参与者执行一个操作时的一个阶段。执行通常在参与者接收到一条消息后开始，从执行块内可将消息发送给其他参与者甚至发送给自己。

异步消息是发送者不需要收到响应就可以继续的消息，只是表示一个发送者的调用。用于表示不同线程之间的通信或创建一个新的线程。对于同步消息而言，发送者必须收到响应之后工作流才能继续。

顺序图还可以向未知的活不确定的系统发送消息，此类消息称为lost消息。

此处的Payment System本身在另一个顺序图中定义，这里添加了一个引用。这种引用称为交互使用，用于封装定义在另一个图中的消息序列。