第7讲ch13逻辑架构与uml包图.pptVIP

架构的混合视图 模型－视图分离原则 其他包应该对UI层具有何种可见性？ 非窗口类应该如何与窗口通信？ 模型－视图分离原则 原则： 不要将非UI对象直接与UI对象连接或耦合。 不要在UI对象方法中加入应用逻辑 模型←→领域层对象（如Sale、Payment） 视图←→UI对象（如：窗口、web页、applet和reports报表） 模型－视图分离原则 模型－视图分离原则规定，模型（领域）对象不应该直接与视图（UI）对象连接，对于视图对象也是如此。 MVC： M：Model模型指领域层（数据对象） V：View视图指UI层（GUI小部件，web页） C：Control控制器指应用层的工作流对象。（鼠标、键盘事件控制器（句柄）） 模型－视图分离原则 动机： 支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。 允许对模型和用户界面层分别进行开发。 使界面的需求变更对领域层的影响最小化。 允许新视图能够被方便地连接到现有的领域层之上，而不会对领域层产生影响。 允许对同一模型对象同时使用多个视图，例如销售信息同时具有表格和业务图表视图。 允许模型层的运行不依赖于用户界面层，例如，消息处理或批处理模式的系统。 允许模型层能够简便地移植到另一个用户接口框架下。 SSD、系统操作、层 SSD描述了系统操作，但是隐藏了特定的UI对象。 系统UI层对象捕获系统操作请求，一般是富客户端GUI或Web页面。 * * * * * * * * * * * * * * * * * * * * * * * * 第13章 逻辑架构和UML包图 计算机系软件工程教研室 姜春艳 目标 介绍使用层的逻辑架构 阐述使用UML包图的逻辑架构 简介 现在，我们就从面向分析的工作过渡到软件设计 典型OO系统设计的基础是若干架构层，例如UI层、应用逻辑（或“领域”）层等。 UP制品相互影响 业务建模 领域模型 需求 用例模型 设想 补充性规格说明 词汇表 设计 逻辑架构的包图(静态视图） 交互图(动态视图） 类图（静态视图) UP制品相互影响 强调的是逻辑架构（LA) 主要的输入是补充性规格说明中记录的架构方面的约束和要点 LA定义了包，包中有关于软件类的定义 示例 逻辑架构（logical architecture） 逻辑架构是软件类的宏观组织结构，它将软件类组织为包(或命名空间）、子系统和层等。 为何称其为逻辑架构？ 因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署架构的一部分）。 层（Layer） 层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。 层按照“较高”层（例如UI层）可以调用“较低”层的服务 OO系统中通常包括的层有： 用户界面 应用逻辑和领域对象 技术服务（例如数据库接口或错误日志）独立于应用的，也可在多个系统中复用的服务。 架构分层 在严格的分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。在信息系统中通常使用宽松的分层架构，其中较高层可以调用其下任何层的服务 例如，UI层可以调用与其相邻的应用逻辑层，也可以调用更下面的技术服务层中的元素，完成日志记录等工作 逻辑架构并非一定要组织为层。但这种方式极为常用 案例研究中应该关注的层 尽管OO技术可以用于所有级别，但本课程对OOA/D的介绍着重于核心应用逻辑（或“领域”）层，其次才是对其他层的讨论。 软件架构 软件架构（宏观） 架构是一种重要决策，其中涉及软件系统的组织 对结构元素及其组成系统所籍接口的选择 这些元素特定于其相互协作的行为 这些结构和行为元素到规模更大的子系统的组成 以及指导该组织结构的架构风格－ 这些元素及其接口、协作、和组成 软件架构师是做什么的？ 软件架构师的职责是把需求转换为软件世界的模型。4+1视图中以use case作为核心，其中功能性需求以及部分非功能性需求会被软件架构师通过分析和设计，映射为各种软件设计模型。从OOA/OOD角度说，use case 在这个过程中是要转换为各种UML，其中类图，序列图，状态图是最常用到的。这个转换过程是需要智慧的，use case是目的，各种OO的原则是指导，设计模式是经验，灵活运用是能力。里面蕴涵了设计的美感，我觉得这个过程是衡量一个软件架构师的最重要的指标。这个过程是需要创造力和想象力的。可能很多人认为这个地方正是软件架构师体现能力的地方。 UML包图 UML包图通常用于描述系统的逻辑架构 层 子系统 包（就Java）而言等 层可以建模为UML包。例如，UI层可以建模为名为UI的包 UML包图