10第十章：统一建模语言解析.ppt

10.4.2 构件图 ◇ 二进制构件：典型情况下，二进制构件是对象代码，它是源构件的编译结果。它可以是一个对象代码文件、一个静态库文件或一个动态库文件。二进制构件仅在链接时有意义，如果二进制构件是动态库文件，则在运行时有意义（动态库只在运行时由可执行的构件装入）。 10.4.2 构件图 ◇ 可执行构件：可执行构件是一个可执行的程序文件，它是链接所有二进制构件所得到的结果。一个可执行构件代表在处理器（计算机）上运行的可执行单元。 构件是类型，但是仅仅可执行构件才可能有实例（当它们代表的程序在处理器上执行时）。构件图只把构件显示成类型，为显示构件的实例必须使用部署图。 10.4.2 构件图 10.4 描述物理架构的机制 10.4.1 逻辑架构和物理架构 10.4.2 构件图 10.4.3 部署图 10.4.3 部署图 部署图描述处理器、硬件设备和软件构件在运行时的架构，它显示系统硬件的物理拓扑结构及在此结构上执行的软件。使用部署图可以显示硬件节点的拓扑结构和通信路径、节点上运行的软件构件、软件构件包含的逻辑单元（对象、类）等。图10.12所示为部署图示例，部署图常用于帮助人理解分布式系统。 10.4.3 部署图 10.4.3 部署图 1．节点和连接 节点（node）代表一个物理设备及在其上运行的软件系统，例如，一台UNIX主机、一个PC终端、一台打印机、一台通信设备等。在图10.12中，“客户端PC”和“保险后台服务器”就是两个节点。在UML中，节点用一个立方体来表示，节点名放在立方体的左上角。 10.4.3 部署图 2．构件和接口 在部署图中，构件代表可执行的物理代码模块（可执行构件的实例），在逻辑上它可以与类图中的包或类对应，因此，部署图显示运行时各个包或类在节点中的分布情况。在图10.12中，“保险后台服务器”节点中包含“保险系统”、“保险对象数据库”和“保险系统配置”3个构件。 10.4.3 部署图 3．对象 在一个面向对象的软件系统中运行着许多个对象。由于可以把构件看做是与包或类对应的物理代码模块，因此，构件中应该包含一些运行的对象。部署图中的对象与对象图中的对象表示方法相同。在图10.12中，“保险系统配置”构件包含“配置保险政策”和“配置用户”两个对象。 10.5 使用和扩展UML 10.5.1 使用UML的准则 10.5.2 扩展UML的机制 10.5.1 使用UML的准则 1．不要试图使用所有的图形和符号 应该根据项目的特点，选用最适用的图形和符号。一般来说，应该优先选用简单的图形和符号，如用例、类、关联、属性、继承等概念是最常用的。在UML中，有些符号仅用于特殊的场合和方法中，仅当确实需要时才应使用它们。 10.5.1 使用UML的准则 2．不要为每个事物都画一个模型 任何模型都应该具有一个明确的目标，抓住事物本质建模是保证模型符合目标的关键。一般来说，能够满足用户需求，抓住了事物的本质且容易与之交互的模型，才是好模型。通常，建模的方法是，抽取事物的本质（内核），然后围绕内核建模，最后实现内核的具体表示。 10.5.1 使用UML的准则 3．应该分层次地画模型图 根据项目进展的不同阶段，用正确的观点画模型图。如果处于分析阶段，应该画概念层模型图；当开始着手进行软件设计时，应该画说明层模型图；当考察某个特定的实现方案时，则应画实现层模型图。 10.5.1 使用UML的准则 4．模型应该具有协调性 模型协调性的第1个方面是集成。集成的含义是，把对同一个事物从各种不同角度（静态、动态和架构）描述的模型合成为一个整体，而且在合成时不会出现不一致的问题。 10.5.1 使用UML的准则 模型协调性的第2个方面是建立在不同抽象层次上的各个模型之间的关系，能够用UML中的细化关系表示出来，有了这种细化关系才可能成功地追踪系统的工作状态。总之，模型必须在每个抽象层次内和不同的抽象层次之间协调。 10.5.1 使用UML的准则 5．模型和模型元素的大小应该适中 过于复杂的模型和模型元素难于理解也难于使用，这样的模型和模型元素很难生存下去。如果要建模的问题相当复杂，则可以把该问题分解成若干个子问题，分别为每个子问题建模，每个子模型构成原模型中的一个包，以降低建模的难度和模型的复杂性。 10.5 使用和扩展UML 10.5.1 使用UML的准则 10.5.2 扩展UML的机制 10.5.2 扩展UML的机制 为避免使UML变得过于复杂，UML并没有吸收所有面向对象的建模技术和机制，而是设计了适当的扩展机制，使得它能很容易地适应某些特定的方法、机构或用户的需要。利用扩展机制，用户可以定义和使用自己的模型元素。 10.5.2 扩展UML的机制 1．标签值 标