构件图
构件图概述
构件图描述了软件的各种构件和它们之间的依赖关系。
构件图的作用
在构件图中,系统中的每个物理构件都使用构件符号来表示,通常,构件图看起来像是构件图标的集合,这些图标代表系统中的物理部件,构件图的基本目的是:使系统人员和开发人员能够从整体上了解系统的所有物理部件,同时,也使我们知道如何对构件进行打包,以便交付给最终客户,最后,构件图显示了被开发系统所包含的构件之间的依赖关系。
构件图从软件架构的角度来描述一个系统的主要功能,如系统分成几个子系统,每个子系统包括哪些类、包和构件,它们之间的关系以及它们分配到哪些节点上等。
使用构件图可以清楚地看出系统的结构和功能。方便项目组的成员制定工作目标和了解工作情况,同时,最重要的一点是有利于软件的复用。
从宏观的角度上,构件图把软件看作多个独立构件组装而成的集合,每个构件可以被实现相同接口的其它构件替换。
构件图的组成
- 构件图三元素
- 构件(Component)
- 接口(Interface)
- 依赖关系(Dependency)
- 构件图由构件、接口、关系、端口和连接器组成,它的表达方式为:
构件图=构件+接口+关系+端口+连接器
构件
- 构件的定义
构件是定义了良好接口的物理实现单元,是系统中可替换的物理部件。一般情况下,构件表示将类、接口等逻辑元素打包而成的物理模块。 - 构件与类
从构件的定义上看,构件和类十分相似,事实也是如此:二者都有名称,都可以实现一组接口,都可以参与依赖、泛化和关联关系,都可以被嵌套,都可以有实例,都可以参与交互。但也存在着一些明显的不同,下面是构件与类的区别:
(1)类表示是对实体的抽象,而构件是对存在于计算机中的物理部件的抽象。也就是说,构件是可以部署的,而类不能部署。
(2)构件属于软件模块,而非逻辑模块,与类相比,它们处于不同的抽象级别。甚至可以说,构件就是由一组类通过协作完成的。
(3)类可以直接拥有操作和属性,而构件仅拥有可以通过其接口访问的操作。 - 构件的名称
每个构件必须有一个不同于其他构件的名称。构件的名称和类的名称的命名法则很是相似,有简单名和路径名之分。构件的名称是一个字符串,位于构件图标的内部。在实际应用中,构件名称通常是从现实词汇中抽取出来的短名词或名词短语。 - 构件的表示
供接口用棒棒糖式的图形表示,由一个封闭的圆形与一条直线组成;需接口用插座式的图形表示,由一个半圆与一条直线组成
- 构件间的关系
为了表达构件与其他构件间的关系,供接口与需接口之间用一个表示依赖的箭头(即虚线加一个开箭头)连接起来,该箭头从需接口引出,指向服务供应者提供的供接口
用一个装配连接器(Assembly Connectors)来表示构件之间的关系
更简单的,你可以忽略构件间的供接口和需接口,而直接在构件间画上依赖关系
外部接口----端口
组合构件的外部接口用一个尾部加一个小方块的正常的接口组成,这个小矩形框被称为端口(Port)
端口是UML2.0引入的一个概念,端口提供种方法,显示建模构件所提供或要求的接口如何与它里面的部分相关联
连接器
为了展现功能的实现,连接器(Connectors将一个组件提供的接口与另一个组件必需的接口绑定到一起
- UML2.0提供了两种类型的连接器:
代理连接器(Delegation Connectors):连接外部接口的端口和内部接口
组装连接器(Assembly Connectors):组装连接器表示构件之间的关系,它连接构件内部的类,将一个构件的供接口和一个构件的需接口捆绑在一起
怎么画构件图?
- 确定划分的子系统的对外接口。
程序子系统和系统外实际要进行联系的边界处理。 - 确定子构件和接口。
在子系统中把功能不同的模块划分成构件,同时确定构件跟构件之间的接口。 - 确定构件之间的关系。
分析构件之间存在的逻辑设计关系,画出依赖图。
案例:绘制出汽车租赁系统的构件图
- 汽车租赁系统的需求分析简述如下:
(1)客户可以通过不同的方式(电话、网上和前台)预订租借车辆。
(2)能够保存客户的预定信息。
(3)能够保存客户的历史记录。
(4)工作人员可以处理客户申请。
(5)技术人员可以保存对车辆检修的结果。 - 汽车租赁系统是建立在一个含有过去租赁记录、汽车信息、服务记录以及客户和员工信息的中央数据库上
- 包括租赁程序、员工记录、客户信息、服务记录、工作记录汽车记录6个构件
部署图
部署图显示了系统的硬件、在这些硬件上安装的软件以及用于连接异构的机器之间的中
间件
从部署图中,可以了解到软件构件、硬件是如何部署到系统的物理架构中的,使用部署图可以显示运行时系统的结构,同时传达构成应用程序的硬件和软件元素的配置和部署方式
部署图的表达方式为:
部署图=制品+节点+通信路径
制品
- 制品是与软件开发过程相关联的实际存在的信息
- 制品是被软件开发过程所利用或通过软件开发过程所生产的一段信息
- 制品可以是一个模型、描述或软件,它通常以文件的形式存在,可以是可执行的,比如.exe文件、二进制文件、DDLs或者JAR文件等,或者是一个数据文件、一个配置文件、一个用户手册或者一个HTML文档
- 在UML2.0中,制品可以用于表示任何可打包的元素,这些元素涵盖了UML中的所有部分
- 在UML中,制品用右上角带一个狗耳朵标记的矩形框表示
- 制品可以有属性和操作,最常见的是用属性和操作表示制品的配置选项
- 属性和操作可以放在制品的第二栏中
- 制品拥有制品实例,用制品名加下划线的方式来表示一个制品实例
- 一个制品可能是另一个UML元素的显示(Manifestation)
- 比如Logging.jar是LoggingSubsystem构j件的显示
- 在UL1.X中,这种显示关系被建模为实施(Implementation)
- 在UML2.0中用标记<< manifest>>的虚线箭头表示这种实施关系
节点
- 节点Nodes)是一个能够执行制品的实体,可以是硬件,但有时也可以是为其他软件的执行提供执行环境的软件
- 有两种类型的节点
- 执行环境(Execution Environments)节点
- 设备(Device)节点
- UML2.0用一个3D风格的盒子表示书点,在节点的内部注明节点名
执行环境节点
在部署图内部用构造型<< ExecutionEnvironment>>和所选用的执行环境名称来表示执行环境节点
执行环境通常是中间件或操作系统
设备节点
设备节点用于表示具体的计算设备,一般是个单独的硬件设备
部署
- 部署图最重要的部分就是将制品部署在将执行它的节点上
- UML2.0提供了三种方法来表示把制品部署到节点中
1、通过将制品绘制在节点中实现对制品的部署
- 可以用带构造型<< deploy>>标签的虚线箭头表示将制品部署在节点中,注意,箭头指向节点
- 更简单的,可以将制品直接记录在节点中表示部署关系
部署规约
- 为了使部署在节点上的制品能够执行,大多数情况下我们需要说明一些配置参数
- 这些参数被称为部署规约(DeploymentSpecification)
- 它是一个属性的集合,是一类特殊的制品,说明了其他制品是如何部署到节点中的
- 它提供了其他制品如何成功的在节点上运行的信息
- 部署规约用构造型<< deployment spec>>表示
- 可以用指向制品的依赖箭头将部署规约与制品绑定
- 可以将部署规约用虚线连接在制品和节点间的部署箭头上
通信路径
通信路径表示节点间的通信,用实心线表示
第八章小结