软件架构实践86解析.ppt

评审实例——评审结论 原有的问题： 由于以前的系统采用了功能驱动单层模型的模式，所有的业务层和控制层也是采用的jsp页面的开发的，这样一来，复杂的控制逻辑和业务逻辑和显示搅在了一起，程序不便于阅读，而且不具有很好的可扩展性，没有xml配置文件，项目的可配置性也大打折扣，实现了视图，控制，业务层搅在一起，不助于我们扩展我们的系统，安全性较差，jsp页面里直接的sql语句的操作，使得操作数据库变得异常复杂，大大的加大了我们的开发的难度，框架中大量的xml配置文件在这里没有得到应有的应用，而每次都要编译程序。 评审实例——评审结论 改进： 继续采用功能驱动单层模型构架开发应该说是唯一的好处是功能实现“简单”，可以大大加快系统的开发进度。它把表现层和业务逻辑层柔和在一起，不利于以后的维护工作以及开发角色的分配，因此要实现质量属性其实非常困难。 使用ADD分层驱动模型重新开发在性能、可用性、安全性、可配置性、可修改性、可移植性方面满足质量需求。 评审实例——评审结论 点评： 整个方案的核心，就是采用了SSH架构，如果仅是这一点的话，完全没有必要进行架构评审。 奇怪的是，原方案作者自己也知道在原有的系统中，在JSP中加入SQL是不好的，为什么还把它作为新方案的战术之一呢？ 小结 ATAM是评估软件构架的健壮方法。在该方法中，项目决策者和风险承担者要以场景方式阐述一个准确的质量属性需求列表，说明实现高优先级场景的构架决策。然后，把这些决策确定为有风险和无风险场景，以找到构架中存在的问题。 但ATAM不是需求评估，不是代码评估，不包括对实际系统的测试，不是一个量化的手段。 评审实例——小型图书管理系统的软件构架表述 状态查询 视图选择 java控制器 定义应用程序行为 用户动作映射成模型更新 选择响应的视图 图书管理系统模型 封装应用程序状态 响应状态查询 应用程序功能 通知视图改变 图书管理系统视图 解释模型 模型更新请求 发送用户输入给控制器 允许控制器选择视图 通知改变 状态改变 用户请求 方法调用 事件 MVC框架说明 评审实例——小型图书管理系统的软件构架表述 Structs框架说明 Struts框架继承了MVC设计模式的特性，是J2EE体系架构的一种轻量级实现。Struts框架具有清晰性和灵活性，有利于图书管理系统的战术实现 评审实例——小型图书管理系统的软件构架表述 Hibernate框架说明 Hibernate位于应用程序的业务化和持久化层。根据O/R（对象/关系）映射技术思想，对JDBC进行了轻量级封装，提供面向对象的数据库服务中间件。使用Hibernate框架可以一种面向对象的方式来操纵和管理关系数据库。 评审实例——小型图书管理系统的软件构架表述 组件和组件间的关系 评审实例——小型图书管理系统的软件构架表述 （原案例在此没有说明文字） 点评： 看样子目标系统使用的是SSH架构，但从前几张图上，看不出针对本系统关键质量属性需求的任何设计对策，甚至“人为”的设计痕迹——完全是抄的MVC的原理图。 这几张图可以用在任何SSH架构的系统设计中。换句话说，这是张“废纸”。 那么，你们是在忽悠评审专家吗？ 评审实例——小型图书管理系统的软件构架表述 预约图书类图交互 评审实例——小型图书管理系统的软件构架表述 （原案例在此没有说明文字） 点评： 类图属于架构描述工具之一，但很多人把类图当成是架构图的全部，这就错了。如上图：仅仅通过这一张类图，如何让评审者理解从质量属性需求，到架构对策和设计，到哪怕是模拟的目标实现和测试，来验证架构设计可行性？ 你的性能、可用性、可修改性、可配置性、安全性体现在哪里？除非评审老师是假老师，否则，只会骂你——你是在说我们都是“傻瓜”吗? 你赶忙解释：战术描述还在后面。好，我们再看下去： 把用户的请求划分为3个优先级，优先响应较重要的请求，以保证重要数据不丢失。 系统对数据库进行备份。系统数据库崩溃后，系统能够进行数据库恢复，以使用户的数据不丢失。 可靠性 本系统用JAVA语言编写，可在WINDOWS,UNIX操作系统下运行。 在原有系统基础上，只需在页面中继续嵌入功能，开发难度低。 易实现性 jsp页面中加sql语句，减少了类的调用 性能 采用cookie技术,用户不须在每次登录时都输入用户名和密码，免除用户频繁输入密码的烦恼。 通过在原系统上添加功能达到易用 采用B/S结构，客户端不用安装任何软件，只需浏览器便可访问本系统。 易用性 战术 质量属性 评审实例——确定构架方式（质量属性与采用战术） 评审实例——确定构架方式（质量属性与采用战术） 本系统用JAVA语言编写，可在WINDOWS,UNIX操作系统下运行。 可移植性 将系统的所有提示语言都保存在Applicatio