逻辑架构与UML包图详解
UML科普文，一篇文章掌握14种UML图
UML科普⽂，⼀篇⽂章掌握14种UML图前⾔上⼀篇⽂章写了⼀篇建造者模式，其中有⼏个UML类图，有的读者反馈看不懂了，我们今天就来解决⼀哈。
什么是UML？UML是Unified Model Language的缩写，中⽂是统⼀建模语⾔，是由⼀整套图表组成的标准化建模语⾔。
为什么要⽤UML？通过使⽤UML使得在软件开发之前，对整个软件设计有更好的可读性，可理解性，从⽽降低开发风险。
同时，也能⽅便各个开发⼈员之间的交流。
UML提供了极富表达能⼒的建模语⾔，可以让软件开发过程中的不同⼈员分别得到⾃⼰感兴趣的信息。
Page-Jones 在《Fundamental Object-Oriented Design in UML》⼀书中总结了UML的主要⽬的，如下：1. 为⽤户提供现成的、有表现⼒的可视化建模语⾔，以便他们开发和交换有意义的模型。
2. 为核⼼概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3. 独⽴于特定的编程语⾔和开发过程。
4. 为了解建模语⾔提供⼀个正式的基础。
5. ⿎励⾯向对象⼯具市场的发展。
6. ⽀持更⾼层次的开发概念，如协作，框架，模式和组件。
7. 整合最佳的⼯作⽅法 (Best Practices)。
UML图有哪些？UML图分为结构图和⾏为图。
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
⾏为图⼜分活动图、⽤例图、状态机图和交互图。
交互图⼜分为序列图、时序图、通讯图、交互概览图。
UML图概览什么是类图？【概念】类图是⼀切⾯向对象⽅法的核⼼建模⼯具。
类图描述了系统中对象的类型以及它们之间存在的各种静态关系。
【⽬的】⽤来表⽰类、接⼝以及它们之间的静态结构和关系。
在类图中，常见的有以下⼏种关系。
泛化（Generalization）【泛化关系】是⼀种继承关系，表⽰⼦类继承⽗类的所有特征和⾏为。
【箭头指向】带三⾓箭头的实线，箭头指向⽗类。
如何使用UML包图进行模块划分与表示
如何使用UML包图进行模块划分与表示使用UML包图进行模块划分与表示在软件开发过程中，模块化是一个重要的概念。
通过将系统划分为独立的模块，可以提高代码的可维护性和可复用性。
而UML（Unified Modeling Language）包图是一种常用的图形化工具，可以帮助开发人员进行模块划分与表示。
本文将介绍如何使用UML包图进行模块划分与表示。
1. 理解UML包图的基本概念UML包图是一种用于表示系统结构的图形化工具。
它可以将系统划分为不同的包，每个包代表一个模块或子系统。
包图中的包可以包含其他包或类，形成层次结构。
通过使用包图，开发人员可以清晰地了解系统的模块划分和关系。
2. 识别系统的功能模块在使用UML包图进行模块划分之前，首先需要识别系统的功能模块。
功能模块是系统中相互独立的部分，每个模块负责一项特定的功能。
通过分析系统的需求和功能，可以确定系统需要包含哪些功能模块。
3. 创建UML包图一旦确定了系统的功能模块，就可以开始创建UML包图。
在包图中，每个功能模块对应一个包。
可以使用UML建模工具或手绘图形来创建包图。
在包图中，每个包可以包含其他包或类，形成层次结构。
4. 定义包之间的关系在包图中，不同的包之间可以存在不同的关系。
常见的关系包括依赖关系、关联关系、聚合关系和继承关系等。
通过定义包之间的关系，可以清晰地表示模块之间的依赖和关联。
5. 表示模块的内部结构除了表示模块之间的关系，UML包图还可以用于表示模块的内部结构。
在包图中，可以将一个包进一步划分为更小的模块或类。
通过定义类之间的关系，可以清晰地表示模块内部的组成和功能。
6. 使用注释和标签在创建UML包图时，可以使用注释和标签来增加图形的可读性和理解性。
注释可以用于解释模块的功能或设计思路，标签可以用于标识模块的名称或属性。
通过使用注释和标签，可以使包图更加清晰和易于理解。
7. 更新和维护包图随着系统的开发和演化，模块的划分和关系可能会发生变化。
uml表达逻辑模型
uml表达逻辑模型
UML（统一建模语言）是一种可视化的面向对象建模语言，提供了丰富的图形化表示法，使得开发人员能够更加直观地理解和描述软件系统的结构和行为。
在UML中，逻辑模型主要通过以下几种方式来表达：
1. 类图（Class Diagram）：类图是UML中最基本的图之一，用于描述系统中的类、接口以及它们之间的关系。
类图可以展示类的静态结构，包括属性、方法和关系等，从而帮助开发人员理解系统的逻辑结构。
2. 对象图（Object Diagram）：对象图是类图的一个实例，它展示了在某一特定时间点上系统中对象的快照。
对象图可以帮助开发人员理解系统在运行时的状态和行为。
3. 包图（Package Diagram）：包图用于描述系统中的包以及包之间的关系。
包是一种组织类、接口和其他元素的方式，可以帮助开发人员将系统划分为更小、更易于管理的部分。
4. 组件图（Component Diagram）：组件图用于描述系统中的组件以及它们之间的关系。
组件是系统中的可替换部分，可以执行特定的功能。
组件图可以帮助开发人员理解系统的物理结构和部署方式。
除了以上几种图之外，UML还提供了其他类型的图，如
用例图、顺序图、活动图等，这些图也可以用于描述系统的逻辑模型，但侧重点可能有所不同。
例如，用例图主要用于描述系统的功能需求，而顺序图则用于描述系统中对象之间的交互行为。
总的来说，UML提供了多种图形化表示法来描述系统的逻辑模型，开发人员可以根据需要选择合适的图来描述系统的不同方面。
UML之包图
UML之包图包图的基本概念: 包图是⽤来描述模型中的包和所包含元素的组织⽅式的图，是维护和控制系统总体结构的重要内容。
包图能够组织许多UML中的元素，不过其最常⽤的⽤途是⽤来组织⽤例图和类图。
包图中包含包元素以及包之间的关系。
与其他图类似，包图中可以创建注解和约束。
包的概念: 包是⽤于把模型组织成层次结构的通⽤机制，它不能执⾏。
包名：包有简单名、路径名包中的元素：包中可以容纳各种⾼级的模型元素，如类和类的关系、状态机、⽤例图、交互、协作等，甚⾄是⼀个完整的UML图。
另外，包中还可以含有包，这被称为包的嵌套。
包元素的可见性：控制包外元素对包内元素的访问权限。
公有（+）：只要当前包被引⼊，包内的公共元素即对引⼊者可见。
保护（#）：仅对当前包的⼦包可见。
私有（-）：仅对该包可见，外部⽆法访问。
另外，如果某元素对于⼀个包是可见的，则它对于嵌套在这个包中的任何包都是可见的。
包的构造型：可以使⽤构造型来描述包的种类。
UML预定义了⼀些构造型，⽤户也可⾃⾏定义新的构造型。
⾼内聚，低耦合：在外部观察包时，可以将内部元素视作⼀个整体，⽅便将多个元素⼀同处理。
包内部的元素应该保证有相似、相同的语义，或者其元素有同时更改和变化的性质。
注：在实际应⽤中，包对包含的元素的作⽤相当于C++和C#中命名空间的概念或Java中的包概念。
和这些概念不同的是，UML包中的内容不限于类和接⼝，包中的元素种类要丰富的多。
元素的分包原则：1）元素不能“狡兔三窟”：树形结构的⼀个节点不能同时拥有两个⽗节点，⼀个元素也不允许在两个包中重复出现。
2）相同包内元素不能重名：包所具有的命名空间的作⽤要求⽤⼀个包中的同种类元素名称必须是唯⼀的。
3）包内元素要紧密联系：分在同⼀个包中的元素应该具有某些相同的性质，即包的⾼内聚性。
4）包与包尽可能保持独⽴：包和包之间需要尽可能减少耦合度，要求包内元素与外部元素有尽可能少的依赖关系。
包的依赖关系：包之间的依赖关系实际上是从⼀个更⾼的层次来描述包内某些元素之间的依赖关系。
UML概述ppt课件精选全文
注释体 用于对UML实体进行文字描述
注释连接
注释连接将注释体与要描述的实体相连。说 明该注释体是对该实体所进行2-
协作图（通讯图）
协作图表示一组对象间关系以及交互活动
协作图可以认为是对象图的扩展，它增加了一些符号用于表 示对象间的交互。协作图和顺序图具有同构性。
指向源同步 消息
表示对象间从目的对象向源对象发送同步消息
指向目的的 同步消息
表示对象间从源对象向目的对象发送同步消息
注释体
注释连接
-35-
示例：协作图
-36-
活动图
活动图：通过动作来组织，主要用于描述某一方法、机制或 用例的内部行为
主要使用场合：业务建模、用例分析
-37-
活动图元语-1
活动 组合活动
1997.1公布 UML 1.0 合作伙伴
业
公
意见
众 1996.6和1996.10 UML 0.9&0.91
化
反
馈 OOPSLA95 Unified Method 0.8
标
准
Booch93 OMT-2
化
Booch91 OOSE
OMT-1 其他方法 统
一
UML基本图
静态模型 (系类统图结 构) class diagrams
转移
用于说明两个对象间存在某种关系，如满足某 个条件并当某一事件发生时，对象将从一个状 态变迁到另一个状态并同时执行一些活动
注释体
注释连接
示例：状态图
顺序图
顺序图：主要用于显示对象间的交互活动，但没有明确的交 互环境和对象状态
主要使用场合：系统分析（用例分析）、设计
第5章UML包图
17
5.6.2 调整候选包
在已经识别一组候选包后，减少包间依赖，最小化每个包中public、 protected元素的个数，最大化每个包中private元素的个数。做法如 下。 (1) 在包间移动类。 (2) 添加包、分解包、合并包或删除包。 通常，在分析阶段，将类封装为包模型时，应该尽量使包模型简单。 起初，将类图转换为包图时，不需考虑包间的泛化和依赖关系，仅 当使用诸如包泛化和依赖关系能简化包模型时，才使用这些包整理 技术。 除了保持简单，还应该避免嵌套包。包的嵌套结构越深，模型变得 越难理解。我们曾见过非常深层的嵌套包，而每个包仅包含一个或 两个类。这些模型更像是标准的、自上而下的功能分解，而不是包 模型。 作为经验法则，希望每个包具有4~10个分析类。然而，对于所有的 经验法则，却存在例外，如果打破某个法则使得模型更加清晰，就 采用这个法则。有时，必须引入只带有一个或者两个类的包，因为 需要断开包模型中的循环依赖，在这种情况下是完全合理的。
14
5.5 包的传递性
当客户包与提供者包之间是<<access>>依赖 时，提供者包中的公共元素就成为客户包中的 私有元素，这些私有元素在包外是不可以访问 的。如图5-15所示，Z包中的公共元素成为Y包 的私有元素，而X包只能访问Y包中的公共元素， 因此，X包不能访问Z包中的公共元素。所以， X、Y、Z包间的<<access >>关系不存在传递 性。
22
5.8 小
结
本章首先解释了几种常见的包图表示法， 并通过了一个简单的例子来说明包的可见 性、依赖关系、泛化等概念。其次，概要 地说明了5种包的构造型。 最后说明如何寻找包、确定包之间的依赖 关系，从而绘制出一个表明软件体系结构 的包图，并简要介绍了用包图表示系统体 系结构的建模方法。
UML建模工具软件StarUML从入门到精通——如何应用StarUML创建UML包图的应用示例
（2）控制层包
（3）业务层包
（4）数据访问层包
（5）体现系统分层设计结果的包图
7、然后根据层次划分的要求分别添加各个不同的包所对应的子包（1）表示层包中的各个子包
2、包图的应用目的（1）能够体现出问题的层次关系 1）使用包图的目的是把模型元素组织成组，为其命名，以便作为整体处理。 2）对于一个大型系统，使用包来组织大量模型元素以便于
系统的理解和处理，使之有很好的层次关系。
（2）通过包可以形成一个高内聚、低耦合的类的集合。（3）在概要设计阶段，系统设计人员可以用包图来建立软件系统的体系架构（而在详细设计阶段，可以利用类图建立相应的体系结构）3、BBS论坛系统前台应用的包图示例
4、某个网上书店项目中的各个包的UML包图示例
5、创建一个名称为“BBS系统前台包图”的包图（1）右击“Design Model”节点，在弹出的快捷菜单中选择“Add Diagram”子菜单，然后再在其中选择下一级的子菜单项目“Package Diagram”，便可以创建出包图。
（2）命名该包图的名称为“BBS系统前台包图”
感谢阅读
感谢阅读
如何应用StarUML
创建UML包图的应用示例
do
something
1、UML中的包图（Package Diagram)（1）包图是保持系统整体结构简明、清晰的重要工具通过给出包可以列出各个包之间的关系。包图由包和包之间的联系构成，它是维护和控制系统总体结构的重要建模工具。
（2）在Rose中包图是通过类图来体现的
（2）控制层包中的各个子包
13种uml简介、工具及示例
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是UML中描述系统结构和静态关系的基本图表之一。
它用矩形表示类，用线连接类之间的关系，包括关联关系、聚合关系、继承关系等。
类图可以帮助开发人员更清晰地理解系统的对象结构和类之间的关系，从而支持系统的设计和重构。
示例：一个简单的学生信息管理系统的类图包括类“学生”、“课程”、“教师”等，以及它们之间的关系如“选修”、“授课”等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
准则：内聚职责；使关系分离同一层内的对象在职责上应该具有紧密关联，不 同层中对象的职责则不应该混淆 例如，UI层中的对象应该关注于UI工作，例如创 建窗口和小部件、捕获鼠标和键盘事件等。应用 逻辑或“领域”层中的对象应该关注应用逻辑， 例如计算销售总额或税金，或在棋盘上移动棋子； UI对象不应该处理应用逻辑！例如Java Swing Jframe（窗体）对象不应该包含计算税金或移动 棋子的逻辑。而应用逻辑类不应该捕获UI鼠标或 键盘事件。否则将违反关系分离和高内聚原则 （这是基本架构原则）
准则：使用层进行设计
使用层时：
将系统的大型逻辑结构组织为独立的、职 责相关的离散层，具有清晰、内聚的关注 分离。这样，“较低”的层是低级别和一 般性服务，较高的层则是与应用相关的。 协作和耦合是从较高层到较低层进行的， 要避免从较低层到较高层的耦合。
设计问题
使用层有助于解决如下问题：
源码的变更波及整个系统－大部分系统是高度耦 合的。 应用逻辑与用户界面交织在一起，因此无法复用 于其他不同界面或分布到其他处理节点之上 潜在的一般性技术服务或业务逻辑与更特定于应 用的逻辑交织在一起，因此无法被复用、分布到 其他节点或方便地使用不同实现替换 不同的关注领域之间的高度耦合。因此难以为不 同开发者清晰地界定和分配任务
软件架构师是做什么的？
软件架构师的职责是把需求转换为软件世界的模型。 4+1视图中以use case作为核心，其中功能性需 求以及部分非功能性需求会被软件架构师通过分析 和设计，映射为各种软件设计模型。从OOA/OOD 角度说，use case 在这个过程中是要转换为各种 UML，其中类图，序列图，状态图是最常用到的。 这个转换过程是需要智慧的，use case是目的， 各种OO的原则是指导，设计模式是经验，灵活运 用是能力。里面蕴涵了设计的美感，我觉得这个过 程是衡量一个软件架构师的最重要的指标。这个过 程是需要创造力和想象力的。可能很多人认为这个 地方正是软件架构师体现能力的地方。
Application (AKA Workflow, Process, Mediation, App Controller)
使用层的好处
关系分离、高级服务与低级服务分离、特定于应用 的服务与一般性服务分离。层可以减少耦合和依赖 性、增加内聚性、提高潜在的复用性并且使概念更 加清晰 封装和分解了相关的复杂性 某些层能够使用新的实现替换。对于较低级的技 术服务层或基础层来说不大可能（例如java.util） 但是对UI、应用层和领域层来说是可能的。 较低层包含可复用功能 某些层（主要是领域层和技术服务层）可以是分布 式的。 通过逻辑划分，有助于团队开发。
将代码组织映射为层和UML包
//---UI包 Java中称为包package com.mycompany.nextgen.ui.swing C#和C++中称为命名空间 com.mycompany.nextgen.ui.web //---领域层 namespace //---特定于NextGen项目的包 com.mycompany.nextgen.domain.sales com.mycompany.nextgen..domain.payments //---技术服务层 //---我们自己的持久（数据库）访问层 com.mycompany.service.persistence //第三方 org.apache.log4j org.apache.soap.rpc //---基础层 //---我们小组自己创建的基础包 pany.util
Glossary
The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Design Model package diagrams of the logical architecture (a static view) UI Domain Tech Services
UML包图
UML包图通常用于描述系统的逻辑架构
层 子系统 包（就Java）而言等
层可以建模为UML包。例如，UI层可 以建模为名为UI的包
UML包图
UML包图提供了组织元素的方式（类，其他包， 用例，…） 嵌套包十分常见 UML包是比Java包和.NET命名空间更为通用的概 念 如果包内部显示了其成员，则在标签上标识包名； 否则，可以在包体内标识包名称 人们通常希望显示包之间的依赖性(耦合），以 便开发者能够看到系统内大型事物之间的耦合。 UML的依赖线即可用于此目的，依赖线是有箭头 的虚线，箭头指向被依赖的包 完全限定的名称 例如Java::util::Date
· ·
(relatively) high-level technical services and frameworks Persistence, Security
Technical Services (AKA Technical Infrastructure, High-level Technical Services)
· ·
low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O
Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure)
· · ·
handles application layer requests implementation of domain rules domain services (POS, Inventory) - services may be used by just one application, but there is also the possibility of multi-application services
width implies range of applicability
dependency
· · · · ·
handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation
第13章 逻辑架构和UML包图
目标
介绍使用层的逻辑架构 阐述使用UML包图的逻辑架构
简介
现在，我们就从面向分析的工作过渡到 软件设计 典型OO系统设计的基础是若干架构层， 例如UI层、应用逻辑（或“领域”） 层等。
UP制品相互影响
业务建模
领域模型
需求
用例模型 设想 补充性规格说明 词汇表
: Register Design interaction diagrams (a dynamic view) enterItem (itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
Register class diagrams (a static view) ... makeNewSale() enterItem(...) ... 1 1 ...
典型的层
信 息 系 统 逻 辑 架 构 中 常 见 的 层
· · · ·
GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ...
UI (AKA Presentation, View)
more app specific
层（Layer）
层是对类、包或子系统的甚为粗粒度的 分组，具有对系统主要方面加以内聚的 职责。 层按照“较高”层（例如UI层）可以调 用“较低”层的服务 OO系统中通常包括的层有：
用户界面 应用逻辑和领域对象 技术服务（例如数据库接口或错误日志） 独立于应用的，也可在多个系统中复用的 服务。
架构分层
在严格的分层架构中，层只能调用与其相邻 的下层的服务。这种设计在网络协议栈中比 较常见，而在信息系统中不太常见。在信息 系统中通常使用宽松的分层架构，其中较高 层可以调用其下任何层的服务 例如，UI层可以调用与其相邻的应用逻辑层， 也可以调用更下面的技术服务层中的元素， 完成日志记录等工作 逻辑架构并非一定要组织为层。但这种方式 极为常用
ProductCatalog
getProductSpec(...) ...
UP制品相互影响
强调的是逻辑架构（LA) 主要的输入是补充性规格说明中记录的 架构方面的约束和要点 LA定义了包，包中有关于软件类的定 义
UI
示 例
Swing
not the Java Swing libraries, but our GUI classes based on Swing
Web
Domain
Sales
Payments
Taxes
Technical Services
Persistence
Logging
RulesEngine
逻辑架构（logical architecture）
逻辑架构是软件类的宏观组织结构，它 将软件类组织为包(或命名空间）、子 系统和层等。 为何称其为逻辑架构？ 因为并未决定如何在不同的操作系统进 程或网络中物理的计算机上对这些元素 进行部署（后一种决定是部署架构的一 部分）。