UML2 构架设计基础

构架设计基础-2-主要内容8.1过渡到设计8.2构架设计基础8.3确定设计元素重点：确定设计元素难点：确定设计元素课时：2课时-3-学习路线图OOUMLOOPDP…Case-Study…学习路线图::……………………12345678910-4-软件设计的定义IEEE1990：设计是构架、接口、构件、以及系统其它特征定义的过程-5-更精确定义软件设计（的结果）必须描述系统的构架（architecture）系统如何分解（decompose）和组织（organize）构件描述构件间的接口（interface）描述构件（component）：必须详细到可进一步构造的程度-6-软件设计知识域(SWEBOK)D-设计（Decompositiondesign）将系统映射为构件片（componentpieces）FP-设计（FamilyPatterndesign）目标是探求一定范围的通用性I-设计（Inventiondesign）基于概念化原型作系统分析，定义系统以满足所发现的需要和需求-7-1从分析到设计分析是设计的输入，设计是分析的细化方法相同，但关注点不同分析：做什么(What)分析有效地确定了将要构建的内容分析重点关注业务(business)问题设计：怎么做(How)设计定义如何构建目标系统：采用何种技术、何种平台来实现分析模型设计关注于系统的技术(technical)和实现(implementation)细节-8-分析VS.设计分析关注问题的理解理想化设计行为系统结构功能需求一个小的模型设计关注解决方案的理解接近实际的代码操作和属性性能对象的生命周期性能、可维护性非功能需求一个大的模型-9-并不是自下而上或自上而下的抽象具体化-10-从分析模型到设计模型设计是对分析的进一步细化，其根本思想是：对分析模型中的分析类进行进一步的设计，添加实现细节，这些分析类最终转变成设计元素面向对象的方法中，设计是分析的自然延续，在分析模型中添加特定的实现机制，得到可以实现的设计元素设计过程会直接覆盖分析模型的成果，随着设计的深入，分析模型将消失-11-保留分析模型迭代开发中，保留分析模型是必要的分析模型可以保持从需求、分析到设计的可跟踪性下一迭代的分析也需要前一迭代的分析模型分析模型提供了系统核心业务场景，对于理解大规模系统的核心机制有非常重要的意义需要采取一些手段来保留系统的分析模型在某个点冻结分析模型，保留一份历史拷贝；但这可能存在模型不一致性问题同时维护两个独立的分析模型和设计模型；但增加维护模型的成本-12-内容安排过渡到设计构架设计基础确定设计元素-13-2构架设计基础2.1构架(Architecture)设计即在系统的全局范围内，以分析活动的结果为出发点：将现有的“分析类”映射成设计模型中的“设计元素”明确适用于系统的“设计机制”调整内容逐渐充实为系统“构架”-14-2.1构架设计构架设计内容确定核心元素：在构架的中高层，以“分析类”为出发点，确定相应的“核心设计元素”引入外围元素：在构架的中低层，以“分析机制”为出发点，确定满足分析类要求的“设计机制”，并将相关的内容引入设计模型优化组织结构：按照高内聚、低耦合的基本原则，整理并逐渐充实构架的层次和内容定义设计后的组织结构：构架设计还应该考虑设计完成后系统实现、运行以及部署等阶段的组织结构分析类分析机制说明申请控制类分布前台服务员可以通过本地客户机访问服务器上的旅游团和路线信息导出财务信息控制类遗留接口导出的财务信息需要导入到遗留的财务系统旅游团、路线持久性旅游团和路线信息需存储在数据库中申请持久性申请相关信息需存储在数据库中支付明细持久性、安全性、遗留接口支付明细信息需存储在数据库中，并不允许随意修改，同时要与外部财务系统保持一致参加人、联系人持久性参加人和联系人等信息需存储在数据库中在数据库中访问需引入新的包（类）把接口分离出边界类包-16-UML和构架设计构架的全部内容就是复杂性管理：将解决方案划分成多个小的组成部分，再将这些小的部分结合起来，构成更大的、更加一致的结构UML中提供了相关的模型支持构架层的建模包图(Packagediagram)包(Package)、依赖关系(Dependency)子系统(Subsystem)层(Layer)-17-2.2包-package2.2.1包包是一种将模型元素分组的机制包主要用于组织模型元素配置管理单元分包的原则职责相似：将一组职责相似、但以不同方式实现的类归为一组有意义的包；如java类库中的javax.swing.border协作关系：包含了各种不同类型的类，它们之间通过相互协作实现一个意义重大的职责-18-2.2.2依赖关系包之间存在着依赖关系如果Client包依赖于Supplier包：Supplier包的改变将影响到Client包Client包不能够独立的重用，因为它依赖于Supplier包ClientPackageSupplierPackage-19-定义依赖关系-包元素的可见性Public可见性Private可见性2.2.3包设计原则：基本策略：职责相似职责相似：将一组职责相似、但以不同方式实现的类归为一组有意义的包；如java类库中的javax.swing.border协作关系：包含了各种不同类型的类，它们之间通过相互协作实现一个意义重大的职责其它的包设计原则：复用发布等价原则共同复用原则共同封闭原则无循环依赖原则稳定依赖原则稳定抽象原则-21-2.2.3包设计原则：避免循环依赖ABABCA'ABC循环依赖使得任何一个包都不能独立的重用，修改任何一个包都会引起所有的包的变化高级依赖关系合并关系（merge）定义一个包的内容如何被另一个包扩展包导入关系允许一个包可以不需要通过包名直接访问被导入包中的元素公有导入（导入关系（import））导入后的元素在当前包内的可见性不变私有导入（访问关系（access））导入后的元素是私有的，对外不可见等同于Java中的import关键词-22-示例：高级依赖关系-23-8.2.4利用包图设计架构基于分析的基本包基础上开展设计追加分析阶段所没有考虑到与实现环境相关的细节，从而添加新的设计包利用现有的第三方中间件或平台提供的功能来实现的包，将被替换为接口和相应的子系统针对系统中的变化点，运用相应的设计原则和策略进行抽象，从而构成新的抽象包（接口/子系统）考虑部署环境时，如果需要将某个包的内容部署到多个不同的节点，则将与部署环境相匹配，将包分割成若干子包在包与包之间发现了通用的部分，从而将通用部分单独作为包来封装。-24--25-内容安排过渡到设计构架设计基础确定设计元素应用设计机制定义运行时构架描述分布-26-3设计元素设计元素(DesignElements)是指能够直接用于实现(编码)的模型要素设计类(DesignClasses)子系统(Subsystem)接口(Interface)主动类确定设计元素的目的是改进(调整)分析类，使之成为适当的设计模型元素-27-3.1从分析类到设计元素controlentityboundaryboundaryAnalysisClassesDesignElements分析类与设计类是多对多的关系-28-1初始设计类一个分析类，可能一个简单的设计类一个设计类的一部分一个聚合类同一个类继承而来的一组类一组功能相关的类(如，一个包)一个子系统一个关系分析类间的一个关系可能成为设计中的一个类(关联类)一个分析类(或部分)可以被硬件(或已有构件)所实现，则根本不需要“设计”3.组织设计类-29-2利用包将设计类分组在分析阶段利用B-C-E的备选构架对分析类进行分组，而设计时，由于大量设计元素的引入，因此需要定义更合理的分组(封装)机制封装标准可以基于多种不同的因素：配置单元开发团队中的资源分配反映用户类型表示已有产品和服务PackageCPackageBPackageA-30-封装技巧：边界类(1)如果系统边界(用户界面、系统接口)可能进行相当大的更改边界类应被放置在几个单独的包-31-封装技巧：边界类(2)如果系统边界(用户界面、系统接口)不太可能进行大的更改将边界类和在功能上与它们相关的类打包到一起-32-封装技巧：功能相关的类(1)确定类在功能上是否相关的标准：如果某个边界类的功能是显示一个特定的实体类，它就可能在功能上与该实体类相关如果两个类与同一个参与者进行交互，或受到对同一个参与者更改的影响一个类的行为和（或）结构的变化使得另一个类也必须相应地变化一个类的删除影响其它类两个对象进行大量的消息交互，或者以一种复杂的方式相互通信两个类之间存在某些关系一个类创建另一个类的实例-33-封装技巧：功能相关的类(2)下列情况一般不应将两个类放在同一个包中与不同参与者相关的两个类不应放在同一个包中一个可选类和一个必选类不应放在同一个包中-34-实例：旅游申请系统分包考虑考虑的几个要素考虑用户界面的不确定性，将用户界面单独打包(UserInterface)系统核心业务为申请旅游团，与申请相关的业务打包为ApplicationServices包，负责前端与申请相关的业务处理与参与者相关业务可以考虑和其它系统的复用(如与CRM系统)，与路线管理相关的业务也存在一定的复用性，这些均可放在单独的包中，作为旅游业务相关的基础业务服务单元(TourArtifaces)-35-实例：旅游申请系统分包结果-36-3.3子系统和接口1.接口(Interface)是类、子系统或构件提供的操作的集合接口允许用户以公开的方式定义多态，并且和实现没有直接联系接口支持“即插即用”的结构实现(Realization)关系-37-2.子系统(Subsystem)是一种介于包和类之间的一种设计机制，它实现一个或多个接口所定义的行为具有包的语义：能够包含其它模型元素具有类的语义：具有行为-38-子系统的作用完全封装了行为利用清晰的接口代表所拥有的能力(便于复用)可以定义不同的实现-39-子系统VS.包子系统：提供行为完全封装实现细节容易替换包：不提供行为不完全封装实现细节难以替换ClientClassSubsystemAsubsystemPackageBClassB1ClassB2关键在于封装-40-子系统的主要用途子系统可以将系统划分成独立的部分，将被实现为独立的构件，这些构件在保持结构不变的情况下，可以独立地开发和部署，适应变更，而不影响到其它系统子系统也可用于将系统划分成若干单元表示设计中的既存产品或外部系统-41-候选子系统可能发展为子系统的分析类提供复杂服务和(或)通用功能的类边界类(用户界面和外部系统接口)设计中既存产品或外部系统通信软件数据库访问支持类型和数据结构通用程序专业应用软件产品-42-确定子系统如果分析类相当复杂，以致它所包含的行为无法由单个类(或几个类的简单组合)来独自负责执行，此时应该考虑将该分析类映射到设计子系统使用设计子系统来封装协作子系统客户在完全不知道内部设计的情况下可以很方便的使用它提供的服务子系统内部的实现细节则延迟到子系统设计阶段-43-确定子系统示意图SupermanClass-44-确定子系统的接口目的基于子系统的职责确定其接口步骤为每个子系统确定一个备选接口集寻找接口之间的相似点定义接口依赖关系将接口映射到子系统定义接口所指定的行为将接口打包-45-指南：确定接口接口名反映在系统中的作用接口描述表达职责操作定义名称应反映出操作的结果说明操作做什么，以及所有参数和结果接口文档交互图、状态图、测试计划…-46-实例：确定子系统