文章目录
1 部署图
1.1 基本概念
部署图展示了在系统的物理设计中的工件在节点上分布的情况。单张部署图代表了一种系统工作结构的视图。部署图在开发中用于说明节点的物理集合,这些节点是系统执行的平台。下面是一个示例(看看就行,后面会详细介绍):
部署图描述了一个运行时的硬件节点,以及在这些节点上运行的软件组件的静态视图。部署图显示了系统的硬件、安装在硬件上的软件、以及用于连接异构的机器之间的中间件。
创建部署图的目的:
- 探究系统投产的相关问题。
- 探究系统和生产环境中的其它系统的依赖关系,这些系统可能是已经存在的,或是将要引入的。
- 描述一个商业应用主要的部署结构。
- 设计一个嵌入系统的硬件和软件结构。
- 描述一个组织的硬件/网络基础结构。
1.2 组成元素
部署图有三个基本元素:工件、节点和它们的连接。
1.2.1 工件
工件(artifact)是物理上存在的一种东西,它实现了一部分的软件设计。它通常是可执行的软件代码,但也可能是一个源文件、一份文档或与软件代码相关的其他文件。工件之间可以有关系,如依赖或组合。下面是一个示例:
1.2.2 节点
节点是一种计算资源,通常包含存储和处理能力,工件部署在它上面执行。节点可以通过嵌套来包含其他节点。节点包含两种类型:设备和执行环境。下面是一个示例:
1.2.3 连接
节点之间通常会通过消息和信号进行通信,在图中用实线表示通信路径。一般通信是双向的,如果某个连接是单向的,可以加上箭头表示。每条通信路径可以包含一个可选的关键词标签,用于提供与连接有关的信息。下面是一个示例:
1.2.4 节点中的工件和执行环境
当某些工件驻留在某个节点中时,可以在该节点的内部描述这些工件。在部署图中,最有价值的是节点上的内容,即安装在节点中的工件,这些工件可直接写在节点中,也可以用工件表示,还可用UML2.0规范推荐的<<artifact>>
、<<database>>
、<<deploymentSpec>>
等构造型来表述工件,其中:
1、<<database>>
:用来表示一个实际的数据库。
2、<<deploymentSpec>>
:用来表示部署描述,通常对关键的配置文件进行建模,还可以在构造块中直接指出具体参数的值。
3、<<artifact>>
:用来表示文件、工件等制品。
下面是一个示例:
1.3 两个示例
下面是示例1:
下面是示例2——溶液植物园系统的环境控制系统的部署图:
1.4 建模分析
1.4.1 示例1
下面对某个网上扫描系统的部署图进行建模。其详细的需求如下所示:
- 【扫描仪】用来扫描产品信息。扫描仪通过内部的PCI总线连接到【网卡】。需要编写代码来控制扫描仪,代码驻留在扫描仪内部。
- 扫描仪通过【无线网卡】与插入到【Web服务器KONG】的无线hub通信,服务器通过HTTP协议向【客户PC机】提供Web页。
- Web服务器安装定制的Web服务器软件,通过专用数据访问组件与产品数据库交互。
- 在客户的PC机上将提供专用的浏览器软件,它运行产品查询插件,只与定制的Web服务器通信。
1、添加节点。根据系统需求添加节点:
2、添加连接:
①扫描仪通过内部的PCI总线连接到网卡。
②网卡通过无线电波与无线hub通信。
③无线hub通过USB连接到名为KONG的服务器实例。
④KONG Web服务器通过HTTP与客户组件通信。
如下:
3、添加组件。根据需求可以将下列组件用于图中:
①控制扫描仪的代码(名为ScanEngine组件)
②定制的Web服务器软件(名为WebSeverSoft组件)
③专用的数据访问组件(名为DataAccess组件)
④专用的浏览器软件(名为Browser组件)
⑤产品查询插件(名为ProductLookupAddln)
另外还有产品数据库,但它不必像上面一样也建模为软件组件,现在把产品数据库建模为一个类实例ProductDB。如下:
4、添加依赖关系。实现部署图的最后一步是添加组件和对象之间的依赖关系。它们具有下列依赖关系:
①WebServerSoft组件依赖于DataAccess组件。
②DataAccess组件依赖于ProductDB对象。
专用浏览器软件只通过运行查询插件与定制的Web服务器交互,它提供了下面的依赖关系:
①Browser组件依赖于WebServerSoft组件。
②ProductLookupAddln组件依赖于Browser组件。
最终的部署图如下:
1.4.2 示例2
IC卡考勤系统:
1、lC卡读卡器:提供给员工刷卡用,它收集刷卡的事件信息,传给应用系统,并存入数据库中。
2、应用服务器:用来负责从IC卡读卡器重收集信息,并对管理人员提供员工设置、考勤查询等功能。
3、数据库服务器:用来存储考勤数据,由于该系统比较小,因此在物理上可以与应用服务器合并。
4、客户端软件:提供给管理人员使用,连接应用服务器,完成相应操作。
5、客户端与服务器的连接显然应该是通过网络(假设是百兆以太网),而服务器与IC卡读写器则是通过串口(RS-232C)。
1、添加节点和连接:
2、添加约束和工件。假设该系统由C#和SQL SERVER开发:
- 客户端:需要使用Windows操作系统,安装客户端软件(假设名为KaoQin.exe)。
- 服务器:包含一个用C#开发的服务端软件(假设名为kqServer.exe),它需要与SQL Server数据库交互(假设名为KaoQin.mdb),并且需要通过IC卡读卡器的驱动程序(假设名为cardReader.dll)来实现与IC卡读卡器通信。
- IC卡读卡器:对于本系统而言,它是不执行构件的设备,但为了方便员工,安装了3个。
最终的部署图如下:
1.5 建模工具
创建部署图常用的工具有:
1、Microsoft Office Visio。
2、IBM Rational Rose。
3、Sparx Systems Enterprise Architect。
2 包图
2.1 包图的概念
包图(Package Diagram)是描述包及其关系的图,是维护和控制系统总体结构的重要建模工具。
包,可理解为命名空间、文件夹,用于组织图形的封装,可用于表达功能组、命名空间的组织层次。在OOSE中,类是构建整个系统的基本构造块,但是对于庞大的应用系统而言,其包含的类将是成百上千的,其之间的关系也更为复杂,而这超出了人们要处理的复杂度,因此引入了“包”分组事物的构造块。
包作为一个“容器”,用于组织模型中的相关元素,是将相关的各种类型的模型元素组织成group的通用机制。包的实例没有任何语义,一般在高层使用,仅在建模时有意义,不必迁移至可执行的系统中。
包的作用:
- 对语义上相关的元素进行分组
- 定义模型中的“语义边界”
- 提供配置管理单元
- 在设计时,提供并行工作的单元
- 提供封装的命名空间,其中所有名称必须唯一。
包中的元素包括:类、接口、组件、节点、协作、用例、图以及其它包。一个模型元素只能存在于一个包内。如果包被撤销,则其中的元素也会被撤销。
UML提供了5种构造型来描述包的新特征,分别为:
<<system>>
:包代表一个系统。
<<subsystem>>
:包代表某个子系统。<<facade>>
:包是由其他包构成的一个视图。<<stub>>
:包是一个代理包,该代理包为其他包提供公共服务。<<framework>>
:包代表一个框架。
2.2 包的表示
用文件夹符号来表示包,且每个包都必须有一个与其它包相区别的名称。几种表示方式如下:
嵌套包及其表示的一个示例如下:
与上图对应的包的外部表示法示例如下:
每个包必须有一个与其它包相区别的名称,下面是命名的两种形式,分别为简单名和路径名,示例如下:
包中可有各种其它元素,这属于组成关系。一个包意味着一个独立的命名空间,在两个不同的包中可以具有相同的元素名。在表示包中拥有的元素时,有两种方法:①在第二栏中列出所属元素名;②在第二栏中画出所属元素的图形表示。示例如下:
包内元素的可见性控制了包外部元素访问包内部元素的权限:
可见性 | 含义 | 前缀符号 |
---|---|---|
公有的Public | 此元素可以被任何引用该包的包中的元素访问。 | + |
受保护的Protected | 此元素可被继承该包的包中的元素访问。 | # |
私有的Private | 此元素只能被同一个包中的元素访问。 | - |
2.3 包图中的关系
不同的包之间可以有两种关系:
1、引用和访问依赖:在一个包中引入另一个包输出的元素。依赖分为:
- 使用关系
<<use>>
:说明客户包中的元素以某种方式使用提供包中的公共元素。 - 包含关系
<<import>>
:允许一个包的元素可以单向访问另一个包的元素;提供者包命名空间的公共元素被添加为客户名命名空间上的公共元素。 - 访问关系
<<access>>
:提供者包命名空间的公共元素被添加为客户名命名空间上的私有元素。
- 跟踪关系
<<trace>>
:一个元素历史地发展成为另一个进化版本。举个例子:分析模型是设计模型的元模型,元模型的元素进化为设计模型,这时指的是模型之间的关系,而不是元素之间的关系。
2、泛化:说明包的家族,与类之间的泛化关系相类似。如下:
2.4 阅读包图
阅读包图的方法如下:
1、了解每个包的语义及内部各元素的语义。
2、理解不同包之间的关系。
3、找到依赖复杂的包,然后从复杂的包到简单的包依次进行阅读。
请按上述方法阅读下面的包图:
2.5 创建包图
在考虑如何对类进行分组并放入不同的包时,主要依据类之间的依赖关系进行分组。包中的类应该是功能相关的,在建包时应把概念上和语义上相近的模型元素纳入一个包。如果两个包中的类之间存在依赖,那么这两个包之间就有了依赖关系,也就存在耦合关系。优秀的设计要求体现高内聚、低耦合的特性。
设计包的原则如下:
- 重用等价原则:把类放入包中,应考虑把包作为可重用的单元。
- 共同闭包原则:把那些需要同时改变的类放在同一个包中,如:①若一个类的行为或结构的改变,要求另一个类做相应的改变;②删除了一个类后,另一个类成多余的;③两个类之间有大量的消息发送。
- 共同重用原则:别把根本不会一起使用的类放在同一个包中。
- 非循环依赖原则:包之间的依赖关系不要形成循环。若形成了循环,则可以通过合并或者分解来进行修改,下面是一个示例:
绘制包图的基本步骤如下:
1、分析系统的模型元素(通常是对象类),把概念上或语义上相近的模型元素归入同一个包;
2、对于每一个包,标出其模型元素的可视性,确定包内每个元素的访问属性,是公有、保护或私有;
3、确定包与包之间的依赖联系,特别是“引入”关系;
4、确定包与包之间的泛化关系;
5、绘制包图;
6、对结果进行精化和细化。
2.5.1 示例1
示例:
- 通过Internet连接到股票信息服务器,获取实时的股票信息,并存入数据库中。
- 根据用户的输入和选择,从数据库中获取相应的信息,展现在屏幕中。
- 在数据的展现过程中,将需要绘制大量的图表。
步骤如下。
首先根据功能模块组织包:
包 | 分析与功能 | .NET支持包 |
---|---|---|
SocketClient | 负责连接Internet服务器,获取实时股票信息 | System.Net.Sockets |
DataAccess | 负责从数据库读写实时股票信息 | System.Data.Sqlclient |
UI | 负责响应用户输入和选择,并展现信息 | System.Windows.Forms |
GraphicGenerate | 负责根据数据库的信息生成相应的图表 | System.Drawing |
绘制初始的包图如下:
然后对成组元素建模:
- 每个包都应该由在概念、语义上相互接近的元素组成;
- 对每个包找出应标记为公共的元素,但应尽可能地少;
- 一般使用默认的
<<use>>
构造型,在映射到编程时考虑明确<<import>>
构造型; - 考虑采用泛化来对特殊包进行建模;
- 在表示这种模型时,注意只标明对每个包都起核心作用的元素;另外也可以标识每个包的文档标记值,以使其更加清晰。
之后对体系结构进行建模(程序分层),这是包图更有意义的一个用途。体系结构是一个软件系统的核心逻辑结构。常用的体系结构模式包括分层、MVC、管道、黑板、微内核等。
最终该示例的包图如下:
2.5.2 其他示例
下面是包图的另外一个示例:
下面是包图的另外一个示例:
END