第13章-逻辑架构和UML包图.pptVIP

第13章 逻辑架构和UML包图Logical Architecture and UML Package Diagrams 什么是逻辑架构和层 逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命令空间）、子系统和层等。 之所以称其为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署。 层是对类、包或子系统的甚为粗粒度的分组一，具有对系统主要方面加以内聚的职责。 层按照“较高”层（例如UI层）可以调用“较低”层的服务，而反之则不然的方式组织。 示例（图13-2） 应用UML：包图 UML包图通常用于描述系统的逻辑架构——层、子系统、包（就Java而言） UML包能够组织任何事件：类、其他包、用例等 嵌套包十分常见。 UML包是比Java包或.NET命名空间更为通常的概念，当然UML包也可以表示这些事物，而且表示更为广泛的事物。 UML中包的完全限定名表示法：java::util::date UML嵌套包的表示法如图13-3所示 UML工具：从代码逆向工程产生包图 开发早期，会画出UML包图的草图，然后根据草图来组织代码。 此后，可以使用UML工具对源代码进行逆向工程，从而自动生成包图。 准则：使用层进行设计 使用层的本质思想 将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。 协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。 使用层有助于解决下列问题 源码的变更波及整个系统——大部分系统是高度耦合的 应用逻辑与用户界面交织在一起。难以复用和分布 技术服务或业务逻辑与更特定于应用的逻辑交织在一起。难以复用、分布和替换 不同的关注领域之间高度耦合。难以为不同开发者清晰地界定和分配任务 信息系统逻辑架构中常见的层，如图13-4所示 准则：内聚职责；使关系分离 同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责不应该混淆。 UI层应该关注于UI工作，如：创建窗口、捕获鼠标和键盘事件等。不应处理业务逻辑 应用逻辑或“领域”层中的对象应该关注应用逻辑，如：计算销售总额或税金。应用逻辑不应捕获UI鼠标或键盘事件。 代码：将代码组织映射为层和UML包 如P151代码所示 定义：领域层与应用逻辑层；领域对象 不提倡将所有方法转入一个类中。 应该：创建软件对象，使用其名称和信息类似于真实世界的领域，并且为其分配应用逻辑职责。 以这种方式设计对象，则可以将应用逻辑层更准确地称为架构的领域层，即包含领域对象，处理应用逻辑的层。 领域层与领域模型之间的关系，如图13-5所示。 定义：层和分区 不要将逻辑视图和部件（物理实现构件）视图混淆 准则：模型-视图分离原则 1 不要将非UI对象直接与UI对象连接或耦合。 如：不要让Sale软件对象引用Java Swing窗口对象 2 不要在UI对象方法中加入应用逻辑 如：税金计算 在该语境下，模型是领域层对象的同义词。视图是UI对象的同义词 SSD、系统操作和层之间的联系 * 图13-1 UP制品相互影响的示例 图13-2 UML包图所表示的层 图13-3 表示嵌套包的另一种UML表示法，使用嵌入包、 UML完全限定的名称以及十字圆形符号 图13-4 信息系统逻辑架构中常见的层 图13-5 领域层和领域模型的关系 图13-6 层和分区 图13-7 架构的混合视图