软件需求分析与设计－架构分析与gof模式

软件需求分析与设计架构分析与GOF模式,2018/1/30,2,细化迭代3,架构分析逻辑架构的精化包的设计使用GoF模式完成更多对象设计,2018/1/30,3,架构分析,目标创建架构因素表创建能够记录架构决策的技术备忘录,2018/1/30,4,架构分析,架构分析的本质是要识别影响架构的因素，理解这些因素的可变性和优先级，并且解决这些问题优秀架构师的价值在于他们具有知道问什么问题的经验，并且能够熟练选择各种方法来解决这些因素架构分析的重要性降低在系统设计中丢失某些重要因素的风险避免在低优先级的问题上花费过多的精力有助于产品与业务目标的一致,2018/1/30,5,架构分析,架构分析是在功能性需求的语境中，识别和处理系统非功能需求的活动，其包括识别变化点和最具可能性的进化点变化点当前现有系统或需求中的变化之处进化点现有需求中不存在，但可在将来发生，推测性的变化点需要解决的问题可靠性和容错性需求如何影响设计采购子构件的许可费用如何影响收益率可适应性和可配置性需求如何影响设计商标名称的选择如何影响架构,2018/1/30,6,架构分析的常用步骤,识别和分析对架构有影响的非功能需求对于这些在架构方面具有重要影响的需求，需求分析可供选择的办法并创建解决这些影响的解决方案，这就是架构决策决策的范围包括删除需求、定制解决方案、终止该项目、雇佣一个专家等,2018/1/30,7,UC1:处理销售,主成功场景：1. 特殊需求：在90%的情形下，信用卡授权应在30秒内响应无论如何，当访问诸如库存系统等远程服务失败时，系统应该以某种方式提供强健的恢复机制技术和数据变化列表：2a.用激光条码扫描器或键盘输入销售项目的标识。未解决的问题：税收法律可能有什么变化？研究远程服务恢复问题。,2018/1/30,8,NextGen架构分析的部分因素,2018/1/30,9,NextGen架构分析的部分因素,2018/1/30,10,NextGen架构分析的部分因素,2018/1/30,11,技术备忘录,问题可靠性从远程服务失败中恢复解决方案要点利用服务查找实现位置透明性，使用本地服务的部分复制，实现从远程到本地的容错因素从远程服务失败中健壮的恢复从远程产品数据库访问中健壮地恢复解决方案使用在ServicesFactory中创建的Adapter对象，实现对服务位置的防止异变。如果可能，提供远程服务的本地实现，通常本地服务只有简化的和受限的行为解决方案的适应性可参见“对第三方服务的适应性”技术备忘录为了满足尽快重新连接远程服务的质量场景，对这些服务使用智能代理对象，在每次服务调用时都要测试远程激活，并且在远程服务激活时进行重新定向,2018/1/30,12,技术备忘录,动机零售商永远不想停止销售！因此如果nextGen POS提供了这个水平的可靠性和可恢复性，它将会是极具吸引力的产品未解决的问题无其他可供选择的方案可以向远程信用卡授权服务机构购买“金牌”服务以改进可靠性,2018/1/30,13,引导架构决策的优先级,强制性约束，包括强制性的安全和法律规定业务目标18月后交易会上展示提供具有吸引力的质量和特性所有其他目标这些目标通常能够被追溯为被直接声明的业务目标，但其本身并不是被直接声明的,2018/1/30,14,基本的架构设计原则,低耦合高内聚防止变异（接口、间接性、服务查找等）关注分离以及局部化影响关注分离可以应用于小尺度的对象，但在架构分析中效果最明显横切面关注（cross-cutting concern）是指在系统中具有广泛应用或影响的事物关注分离的设计将持久化支持和安全性支持分离到单独的“事物”中关注分离是在架构级别上考虑低耦合、高内聚目标的大尺度方式,2018/1/30,15,实现关注分离的大尺度原则,将有关事物模块化，封装到单独的构件中，并且调用其服务使用装饰者EJB技术使用后编译器（post-compiler）和面向方面编程（aspect-oriented）,2018/1/30,16,逻辑架构的精化,目标进一步研究逻辑架构中的问题和层模式，包括层之间的协作展示案例研究在本次迭代的逻辑架构在分层架构的语境中应用外观、观察者和控制模式,2018/1/30,17,nextGen应用的部分逻辑层视图,在这些包中还有其他类型；仅显示一小部分是为了说明重要的方面在本图中没有显示基础层到目前为止，没有使用单独的应用层,2018/1/30,18,包之间的部分耦合,用依赖线表达包或者包内类型之间的耦合,2018/1/30,19,层之间和包之间的交互场景：部分包耦合,2018/1/30,20,强调跨边界连接的具有重要架构意义的交互图,2018/1/30,21,使用层模式的协作,架构性的层模式用来指导定义大尺度的分块，同时诸如外观、控制器和观察者这样的微观架构设计模式则用来设计层和包之间的连接简单包与子系统某些包和层不仅仅是概念上的一组事物，事实上它们是具有行为和接口的子系统,2018/1/30,22,子系统构造型,2018/1/30,23,使用层模式的协作,外观对于表示子系统的包，GoF外观模式是最常用的访问方式。一个公共的外观对象定义了子系统的服务，客户端不与子系统内部的构件交互，而是通过与外观对象协作来访问子系统外观一般不应该暴露太多底层操作，相反，它只应该暴露少数高层操作外观不会直接执行任务，而是隐藏在外观下的子系统对象来完成工作，外观是这些对象的统一或中介如果应用只有“少量”系统操作，则应用层或领域层通常只向上一层暴露一个对象,2018/1/30,24,向上一层暴露的接口数量,2018/1/30,25,会话外观和应用层,2018/1/30,26,控制器的选择,2018/1/30,27,在SSD中和就层而言的系统操作,2018/1/30,28,“向上”与UI层通信的观察者,2018/1/30,29,松散分层耦合关系,所有较高层都依赖于技术服务层和基础层领域层依赖于业务基础设施层UI层调用应用服务层的服务，应用层又调用领域层的服务对于单进程的“桌面”应用，领域层的软件对象对于UI层、应用层可见，或者在上述各层之间转换另一方面，在分布式系统中，通常将领域模型层对象的序列化副本或数据持有者传递给UI层,2018/1/30,30,层模式的其他问题,架构的逻辑、进程和部署视图架构的分层结构是它的逻辑视图，而不是元素到进程或处理节点的部署视图。根据不同的平台，所有的层可以部署在同一个进程中，也可以如同大规模应用一样，跨越多台计算机和多个进程UP中的部署模型将这种逻辑架构映射到进程和节点，并且很受软件和硬件平台以及相关应用框架的选择的影响有许多为部署而切分的逻辑层次结构的方法,2018/1/30,31,层模式的其他问题,应用层是可选的吗如果存在应用层，则其作为UI层和领域层之间的中介，容纳负责获知客户对话状态的对象，并且负责控制工作的流程应用层的效用系统使用多个用户接口，应用层可以充当负责收集和合并不同用户接口数据的适配器，同时承当隐藏对领域层访问的外观在分布式系统中，应用层与UI层部署在不同的节点，有多个客户端访问，此情况下，通常需要追踪会话状态，应用层的对象可以用来承担此职责通过限定窗口或Web页面的顺序定义了工作流，并且必须表示这一工作流,2018/1/30,32,层模式的其他问题,不同层的模糊集合成员层的障碍和禁忌增加层将导致性能问题层模式是少数几个核心框架模式之一，但不是对所有问题都适用已知的应用虚拟机和操作系统信息系统：经典的三层架构,2018/1/30,33,三层架构的经典视图,2018/1/30,34,三层结构的逻辑划分部署在两层物理架构上,2018/1/30,35,模型视图分离和“向上”通讯,UI层的UIFacade偶尔用于从下面推的设计,2018/1/30,36,包的设计,目标合理组织包来减少变化带来的影响熟悉可供选择的UML包结构表示法,2018/1/30,37,组织包结构的准则,包在水平和处置划分上的功能性内聚基于功能性内聚的模快化，将参与共同目的、服务、协作、策略和功能的强相关类型（类和接口）组织在一起除依据功能进行的非正式的猜测以外，也可以依据类型之间的耦合程度进行分组包内部的耦合程度或关系内聚，可以被定量地度量RC=内部关系的数量/类型的数量非常小的RC意味者包中包含相互无关的事物，彼此没有离开包中包含相互无关的事务，设计者故意这样安排（java.util）包含几个高内聚的子集，但整体内聚程度不高,2018/1/30,38,组织包结构的准则,由一族接口组成的包将一组功能相关的接口放入单独的包，与其实现类分离用于正式工作的包和用于聚集不稳定类的包减少不稳定包的广泛依赖职责越多的包越需要稳定增强包的稳定性的方法包中仅包含或者主要包含接口和抽象类不依赖于其他的包，或者仅依赖非常稳定的包，或者封装了依赖关系以使其不受影响包含相对稳定的代码，这些代码在发布之前经过充分的测试和精化强制规定具有缓慢的变化周期,2018/1/30,39,职责越多的包应该越稳定,2018/1/30,40,组织包结构的准则,将不相关的类型分离出去将能够独立使用或运行于不同语境的类型组织到单独的包中,分离不相关的类,2018/1/30,41,组织包结构的准则,使用工厂模式减少对具体包的依赖减少对其他包中的具体类的依赖是提高包的稳定性的一个途径,为了创建而直接与具体包耦合,2018/1/30,42,通过工厂对象来减少与具体包的耦合,2018/1/30,43,组织包结构的准则,包之间没有循环依赖如果包之间有循环依赖，解决的方法将参与循环的类型分解出来形成较小的新包使用接口来打破循环使用接口打破循环的步骤重新定义在一个包中被依赖的类，使其实现新的接口在一个新包中定义新的接口重新定义依赖于原来类的类型，使其依赖于新包的接口，而不是原来的类,2018/1/30,44,打破循环依赖,2018/1/30,45,使用GoF模式完成更多对象设计,目标在用例实现的设计中应用GoF和GRASP模式,2018/1/30,46,本地服务容错:使用本地缓存提高性能,问题当远程服务访问失败时，得到某种程度的恢复在试图访问远程服务之前，应该总是首先在本地缓冲中查找,2018/1/30,47,对产品信息的适配器,2018/1/30,48,对于产品信息服务的初始化,2018/1/30,49,开始与产品信息服务的协作,2018/1/30,50,继续与产品信息服务的协作,如果产品不在本地产品服务的缓存中，则本地产品服务与外部服务的适配器进行协作,2018/1/30,51,新的外部服务不影响设计,如果实际的外部服务从数据库改为新的WEB Service， 则只需改动远程服务工厂的配置,2018/1/30,52,与持久型子系统的协作,2018/1/30,53,UML中的线程和异步消息,2018/1/30,54,主动类表示法,2018/1/30,55,处理故障,本地缓冲中未命中且访问外产品服务时，如何处理？假设涉众要求我们在此情形时用信号通知收银员人工输入价格和描述或者取消该产品项缺陷（fault)：错误行为的起因程序员拼写错了数据库名称错误（Error）：缺陷在运行系统中的表现当（使用拼写错误的名称）调用名称服务获取数据库引用时，它将发出一个错误信号故障（Failure）:由错误引起的服务拒绝产品子系统和NextGen POS无法提供产品信息服务,2018/1/30,56,处理故障,抛出异常异常最适合于处理资源（例如硬盘、内存、网络和访问数据库和其他外部服务）故障的情形模式：转换异常在一个子系统中，避免直接抛出来自低层子系统或服务的异常应该将较低层的异常转换成本层次子系统中有意义的异常较高层的异常包裹较低层次的异常并添加一些信息，使的该异常在较高层次的子系统语境中有意义模式：对问题而不是抛出者命名这样作能够使程序员更容易理解问题,2018/1/30,57,由类抛出和捕获的异常,2018/1/30,58,交互图中的异常,2018/1/30,59,处理错误,模式：集中错误日志使用单实例类访问的集中错误日志对象，所有的异常都向他报告，如果在分布式系统中，那么每个本地单实例类日志对象将与集中的错误日志对象协作，其优点一致的报告方式灵活定义输出流和格式,2018/1/30,60,处理错误,模式：错误对话使用标准的单实例类访问的、应用程序无关的、非用户界面的对象用户通知错误。它包裹了一个或者多个UI“对话”对象，并且将通知错误的职责委派给UI对象。这样错误即可以输出到GUI对话框也可以输出到语音生成器，它也可以将异常报告给集中的错误日志对象。用工厂读取系统参数，并且创建相应的UI对象，优点对输出机制的变化实现了防止变异一致的错误报告风格；集中控制公共的错误通知策略性能也有改近,2018/1/30,61,处理异常,2018/1/30,62,通过代理使用本地服务进行容错,语境/问题不希望或不可能直接访问真正的主题对象时，应该怎么办解决方案通过代理对象增加层层间接性，代理对象实现与主题对象相同的接口，并且负责控制和增强对主题对象的访问,2018/1/30,63,代理模式的一般性结构,2018/1/30,64,NextGen使用了重定向代理,2018/1/30,65,使用适配器访问外部物理设备,标准JavaPOS接口,2018/1/30,66,对一组相关的对象使用抽象工作模式,语境/问题如何创建实现相同接口的一族相关的类型解决方案定义一个工厂接口