【Jsp精品源码栏目提醒】:网学会员--在 Jsp精品源码编辑为广大网友搜集整理了:【精品】第13章-逻辑架构和UML包图 - 大学课件绩等信息,祝愿广大网友取得需要的信息,参考学习。
第13章 逻辑架构和UML包图Logical Architecture and UML Package Diagrams 1 UP制品关系示例 领域模型业务建模 用例模型 补充性规格说明 愿景 词汇表 需求 补充性规格说明中捕获的约束和 非功能需求影响了逻辑架构 设计模型 UI 逻辑架构的包图 静态视图 Domain Tech Services : Register : ProductCatalog 设计 enterItem 交互图动态视图 itemID quantity spec getProductSpec itemID Register ProductCatalog ... 1 1 类图静态视图 ... makeNewSale getProductSpec... enterItem... ... ... 2 图13-1 UP制品相互影响的示例 什么是逻辑架构和层 逻辑架构是软件类的宏观组织结构,它将软件类 组织为包(或命令空间)、子系统和层等。
之所以称其为逻辑架构,是因为并未决定如何在 不同的操作系统进程或网络中物理的计算机上对 这些元素进行部署。
层是对类、包或子系统的甚为粗粒度的分组一, 具有对系统主要方面加以内聚的职责。
层按照“较高”层(例如UI层)可以调用“较低” 层的服务,而反之则不然的方式组织。
示例(图13-2) 3 UI 并非Java的Swing Swing Web 库,而是基于Swing 的GUI类 Domain Sales Payments Taxes Technical ServicesPersistence Logging RulesEngine 4 图13-2 UML包图所表示的层 应用UML:包图 UML包图通常用于描述系统的逻辑架构——层、 子系统、包(就Java而言) UML包能够组织任何事件:类、其他包、用例等 嵌套包十分常见。
UML包是比Java包或.NET命名空间更为通常的概 念,当然UML包也可以表示这些事物,而且表示 更为广泛的事物。
UML中包的完全限定名表示法:java::util::date UML嵌套包的表示法如图13-3所示 5UI Domain Swing Web Sales UI UI::Swing UI::Web Swing Web Domain::Sales Domain Sales 图13-3 表示嵌套包的另一种UML表示法,使用嵌入包、 6 UML完全限定的名称以及十字圆形符号 UML工具:从代码逆向工程产生包图 开发早期,会画出UML包图的草图,然后 根据草图来组织代码。
此后,可以使用UML工具对源代码进行逆 向工程,从而自动生成包图。
7 准则:使用层进行设计 使用层的本质思想 – 将系统的大型逻辑结构组织为独立的、职责相关的离散 层,具有清晰、内聚的关注分离。
– 协作和耦合是从较高层到较低层进行的,要避免从较低 层到较高层的耦合。
使用层有助于解决下列问题 –
源码的变更波及整个系统——大部分系统是高度耦合的 – 应用逻辑与用户界面交织在一起。
难以复用和分布 – 技术服务或业务逻辑与更特定于应用的逻辑交织在一起。
难以复用、分布和替换 – 不同的关注领域之间高度耦合。
难以为不同开发者清晰 地界定和分配任务 信息系统逻辑架构中常见的层,如图13-4所示 8 GUI 窗口 报表 UI 语音接口 AKA Presentation View HTML XML XSLT
JSP Javascript ... 更特定 处理表示层请求 于应用 工作流 Application 会话状态 AKA Workflow Process 窗口/页面转换 Mediation App Controller 依赖性 合并/转换不同的表示数据 处理应用层请求 实现领域规则 Domain 领域服务POS、库存 AKA Business 服务可能只用于一个应用,但是也存在多 Application Logic Model应用服务的可能性 用于多种业务领域的十分普遍的低层业务服 Business Infrastructure 务 AKA Low-level Business Services 现金转换器 相对高层技术服务和框架 Technical Services 持久性、安全性 AKA Technical Infrastructure High-level Technical Services 低层技术服务、工具和框架 Foundation 数据结构、线程、数学、文件、DB和网络 AKA Core Services Base Services I/O等 Low-level Technical Services/Infrastructure 宽度表示可应用的范围 9 图13-4 信息系统逻辑架构中常见的层 准则:内聚职责;使关系分离 同一层内的对象在职责上应该具有紧密关 联,不同层中对象的职责不应该混淆。
– UI层应该关注于UI工作,如:创建窗口、捕获 鼠标和键盘事件等。
不应处理业务逻辑 – 应用逻辑或“领域”层中的对象应该关注应用 逻辑,如:计算销售总额或税金。
应用逻辑不 应捕获UI鼠标或键盘事件。
10 代码:将代码组织映射为层和UML包 如P151代码所示 11定义:领域层与应用逻辑层;领域对象 不提倡将所有方法转入一个类中。
应该:创建软件对象,使用其名称和信息 类似于真实世界的领域,并且为其分配应 用逻辑职责。
以这种方式设计对象,则可以将应用逻辑 层更准确地称为架构的领域层,即包含领 域对象,处理应用逻辑的层。
领域层与领域模型之间的关系,如图13-5 所示。
12 UP领域模型 涉众对领域内重要概念的看法. Sale Payment 1 1 Pays-for date amount领域模型中的Payment是概念,但 time在设计模型中的Payment是软件类。
它们不是一回事,但前者启 启发了对发了后者的名称和定义 象和名称这减少了表示差异这是对象技术的主要思想之一 Sale Payment 1 1 date: Date Pays-for amount: Money startTime: Time getBalance: Money getTotal: Money ... UP设计模型中架构的领域层 面向对象开发者在创建软件类时从真实世界领域中获得启发 因此,涉众所设想的领域与其在软件的表示之间的表示差异被降 低 图13-5 领域层和领域模型的关系 13 定义:层和分区 Domain POS Inventory Tax垂直分层 Technical Services Persistence Security Logging 水平分区 图13-6 层和分区 14 不要将逻辑视图和部件(物理实现构件)视图混淆较差: 较好:混合了逻辑视图和部署视图 逻辑视图 Domains 与这些子领域相关的所需 Domains 数据和服务的逻辑表示, POS Inventory 抽象了对诸如数据库等的 实现决策 Technical Services Technical Services Foundation Naming and Web Persistence Directory Services AppFramework component Novell MySQL LDAP Foundation Inventory UML表示法:UML构件,或物理系统的可替换、模块化部分 UML表示法:UML中的物理数据库 图13-7 架构的混合视图 15 准则:模型-视图分离原则 1 不要将非UI对象直接与UI对象连接或耦合。
– 如:不要让Sale软件对象引用Java Swing窗口 对象 2 不要在UI对象方法中加入应用逻辑 – 如:税金计算 在该语境下,模型是领域层对象的同义词。
视图是UI对象的同义词 16 SSD、系统操作和层之间的联系 UI Swing makeNewSale :System enterItem: Cashier ProcessSale endSale ... Frame makeNewSale : Cashier enterItemid quantity makeNewSale description total enterItem endSale Domain endSale ... Register makeNewSale enterItem ... 在SSD中由系统处理的系统操作表示 从UI层到应用或领域层的操作调用 图13-8 SSD和就层而言的系统操作 17