软件逻辑架构和UML包图

Posted 2021-07-09 系斯模科技

The Large-Scale

在这个层次上，典型OO系统的设计是基于几个架构层的，比如UI层、应用程序逻辑（或“域”）层、技术服务层。

层/Layers

•层是类、包或子系统的粗粒度分组，这些类、包或子系统对系统的一个主要方面具有内聚（强相关）责任。

–例如，应用程序逻辑和域对象表示满足应用程序需求的域概念（例如，软件类：销售）的软件对象，例如计算销售总额。

•应用层是用例的焦点。

•较高层（如UI层）调用较低层的服务，但通常不是相反。

•在严格的分层体系结构中，层只调用其正下方层的服务。

–在网络协议中常见

•在信息系统中不常见，信息系统具有宽松的分层体系结构，其中较高的一层调用几个较低的层。

–例如，UI层可以调用其直接下属的应用程序逻辑层，也可以调用较低技术服务层的元素来进行日志记录等等。

软件架构/Software Architecture

软件架构是

–关于软件系统组织的一组重要决策，

–组成系统的结构元素及其接口的选择，

–以及它们在这些元素之间的协作中指定的行为，以及

–这些结构和行为元素逐渐变成更大的子系统。

UML包图

同一事物的替代符号表示

不使用层时的问题

• 应用程序逻辑与用户界面交织在一起，因此 

– 它不能与不同的界面重用或分发到另一个处理节点。

•通用技术服务与特定于应用程序的逻辑交织在一起，因此它们

–无法重用，

–分发到另一个节点，或者

–很容易被不同的实现替换。

• 不同关注领域之间存在高度耦合。

– 因此很难为不同的开发人员按照清晰的界限划分工作。

将代码组织映射到层和 UML 包

util 为了支持跨项目重用，除非必要，否则我们避免在包名称中使用特定的应用限定符（“nextgen”）。  UI 包与 NextGenPOS 应用相关，因此它们被限定为应用程序名称 …nextgen.ui.*。但是应用可以在许多项目之间共享，因此包 com.mycompany.utils，而不是 com.mycompany.nextgen.utils.

领域层与领域模型的关系

面向对象的开发人员在创建软件类时从现实世界的领域中汲取了灵感。因此，利益相关者如何构想领域与其在软件中的表现之间的表现差距已经缩小。

层和分区/Layers and Partitions

架构的层代表垂直切片，而分区代表层的相对平行的子系统的水平划分。

– 例如，Technical Serviceslayer 可以划分为 Security 和 Reporting 等分区。

模型-视图分离原则/Model-View Separation Principle

•模型是对象领域层的同义词（它是20世纪70年代末的一个旧OO术语）。

•视图是UI对象的同义词，如windows、Web页面、applet和报表。

原则：

•模型（域）对象不应该直接了解视图（UI）对象。

–例如，Registeror Saleobjects不应直接向GUI窗口objectProcessSaleFrame发送消息，要求它显示某些内容、更改颜色、关闭等等。

历史：

•模式模型视图控制器（MVC）最初是一个小规模的Smalltalk-80模式。

•模型是域层，视图是UI层，控制器是应用层中的工作流对象。

原则的另一部分

•域类封装了与应用程序逻辑相关的信息和行为。

•窗口类比较少；它们负责

–输入和输出，以及

–捕获GUI事件。

•窗口类不维护应用程序数据或直接提供应用程序逻辑。例如，

–JavaJFramewindow或webjsp页面不应具有进行具体计算的方法。

•这些UI元素应该委托给非UI元素来承担这些职责。

Legitimate relaxation

•观察者模式，其中域对象可以向UI对象发送消息，而UI对象只能根据接口（如PropertyListener）查看（这种情况下的常见Java接口）。

•然后，域对象不知道UI对象是一个UI对象，也不知道它的具体窗口类。它只知道对象是实现PropertyListenerInterface的对象。

M-V/模型-视图分离动机

•允许单独开发模型和用户界面层。

•将接口中的需求变化对域层的影响降至最低。

•允许新（多个同时）视图轻松连接到现有域层，而不影响域层。

•允许独立于用户界面层执行模型层，例如在批处理模式系统中。

SSD和层之间的连接

•ssd演示系统操作，但隐藏特定的UI对象。

•捕获这些系统操作请求的将是系统UI层中的对象。

–然后UI层对象将从UI层转发或委托请求到域层进行处理。