软件架构实践86要点课件.ppt

软件架构实践SOFTWARE ARCHITECTURE IN PRACTICE软件系统设计与体系结构,软件架构实践第 8章基于关键需求的架构设计、验证测试与评审,8.1 理解架构设计中的关键需求8.2 基于关键需求的架构设计对策8.3 影响架构设计的关键机制8.4 架构设计的验证8.5 架构的集成测试8.6 架构设计与评审8.7 电梯控制系统的架构设计实现与评审8.8 本章小结与习题,第8章基于关键需求的架构设计、验证测试与评审,分析软件构架的原因 因为软件构架非常重要，它是风险承担者之间的交流平台，是早期设计决策的体现，可传递、可重用的模型；而且软件质量不可能在软件开发的最后阶段追加上去，必须在设计之初就考虑到。,8.6 架构设计与评审,8.6 架构设计与评审,架构验证的两个目的是：验证架构设计的可行性和验证架构设计纪律的遵守程度。上二节的架构验证，解决的是第二个目标。本节讨论的话题，则是前者。那么，所谓架构设计的可行性验证，应该回答：在特定架构需求、设计策略和设计方案确定后，如果按此方案实现的话，是否可以满足架构需求。与先两节所讨论的架构验证不同，可行性验证往往是在系统还没有实现之前进行的。因为架构设计具有全局性、整体性和前瞻性，当系统已经完全开发完成，再发现架构设计的错误，将会付出加大的代价，是不能接受的。,8.6.1 针对架构设计基本要素的架构评审,1、架构设计的基本要素与架构评审：这里所谓的架构设计的“基本要素”，主要是指架构设计的“物理、逻辑、开发、运行、数据”五个方面考虑因素。即指架构设计在这五个方面限制条件下，是否满足其特定的需求。显然，这五个要素，是架构设计的最基本考虑因素。2、针对基本要素的架构评审：针对五个基本素的架构设计评审，架构师应包括分别报告并接受审查以下一些内容：目标系统在这五个方面的具体需求和限制是什么？针对需求和限制的设计决策是什么？实现设计决策的方法是什么？通过一定的形式，例如：原型法、模拟运行环境、形式化方法等，对采用上述设计方法可能达到的实现效果，进行展示和预期，并接受老师的评审。,8.6.1 针对架构设计基本要素的架构评审,3、效果展示与评审方法：在实现方法的效果评审中，应考虑采用按五个方面，进行分解的方法。如：根据需求的OMT方法，把用例图转化为静态的类图、动态的行为（状态图、时序图、协作图、活动图），以及反映系统架构的组件图和部署图时，应分别报告：系统设计和实现，是如何分别满足五个方面的特定需求和限制的。4、评审的关注点：评审老师应特别关注：作为系统架构设计的第一步和关键一步，系统一步步被分解为子系统、包、接口、实现类、对象和方法等，其分解的依据是什么？各逻辑单元的抽取与定义是如何体现对系统架构元素（模块、组件、包、子系统）进行划分和分离的？分离点在哪里？理由是什么？这些分离后的架构元素本身，是否满足：抽象是否与系统目标相一致；是否与作为类的责任相一致；是否满足高内聚、松耦合的原则要求；是否可以委托给其他类；等等。,评审方法与技巧,构架评审技巧可以分为两大类，应用不同的技巧需要付出不同的代价，也能够得到不同的信息。 定性分析方法提问的技巧 1. 场景描述风险承担者和系统之间的具体交互 2.评审清单对同一领域的若干系统进行评估后提出的一组详细的问题 3.问卷适用于所有构架的若干问题的清单 定量分析的方法量化的技巧 1. 指标对构架可观察到的参数的量化度量与解释 2. 模拟、原型与实验,评审技巧的选用定性分析：场景-评审清单-问卷调查定量分析：利用系统原型或模拟系统来解答与性能相关的问题,评审方法与技巧,评审的一般过程,评审环境与条件的准备评审环境预先规划项目代表风险承担者，组件负责人评审小组 评审小组的人员公证、客观、受尊重 成员必须专门从事评审工作 有对构架相关问题熟悉的人，其领导具有设计、评价经验 至少有一位该系统所属领域的专家 有专人负责文档、后勤，办公地点离评审对象近,组织的期望用合同明确 构架评审结束时应向谁报告什么内容 评审的标准是什么 向评审小组提供那些资源及人力 对评审小组和项目组以后的工作有什么期望 预计评审持续的最长时间 设定期望的目的是让所有人都理解评审结果的本质是判断可行性，而不是提供任何保证。评审的准备制定评审日程 系统需求文档 构架描述及介绍构架决策思想的材料 将系统的质量属性和功能要求按重要程度排序出前面3-5个,评审实施 强调那些与构架相符或相悖的重要问题。 必须记载评审中所提的每个问题。 按问题的重要性进行分类。 评审结果 对评审中的各个问题都要做出正式的阐述，同时也要对赖以确定这些问题的数据做出相应的说明。,评审的一般过程,构架评审的主要指导原则如下：把由独立部门实施的正规的构架评审作为项目开发周期规划的一部分。选择评审的最佳时间，尽早预审一次。选择恰当的评审技巧。签署评审合同。限制所要评审的质量属性的个数。要保证评审小组中有构架方面的专家、领域专家、资料员及后勤员。一定要有系统设计师。收集各种场景数据，并在此基础上形成评审清单。,评审的一般过程,8.6.2 针对关键质量属性需求的架构设计评审,ATAM（Architecture Tradeoff Analysis Method）是SEI提出的一种软件构架评估方法。ATAM评估方法的主要目的就是：1、提炼出软件质量属性需求的精确描述；2、提炼出构架设计决策的精确描述；3、评估这些构架设计决策，并判定其是否令人满意的实现了这些质量需求。,ATAM： 一种进行构架评估的综合方法,ATAM评估方法并非把每个可以量化的质量属性都进行详尽的分析，而是使众多的风险承担者（包括经理、开发人员、测试人员、用户、客户等等）都参与进来，由此而达到上述目标的。ATAM是一种挖掘潜在风险，降低或者缓和现有风险的软件构架评估方法。因此，以下三点是评估中要特别注重的：1、风险；2、敏感点；3、权衡点。,ATAM的参与人员,ATAM(Architecture Tradeoff Analysis Method)一种构架权衡分析法。ATAM方法的特点是不仅可以揭示出构架满足特定质量目标的情况，而且可以使我们更清楚地认识到质量目标之间的联系。ATAM的中心问题是对用于构架评估的有限时间进行管理。ATAM要求以下3个小组的参与和合作： 评估小组 通常由3-5人组成，每个人要扮演多个角色，包括：场景和进展的提问者、记录者和决策者。,软件构架评估的输入与输出输入用场景集合捕获的质量要求输出评价，可能包括： 一个简洁的构架表述 表述清楚的业务目标 构架决策到质量需求的映射 所确定的敏感点和权衡点集合 有风险决策和无风险决策 风险主题的集合,ATAM的输入和结果,ATAM的阶段,ATAM中的活动被分为四个阶段： 评估小组和项目决策者共同确定评估细节。 评估小组收集信息和分析。 风险承担者参与评估。 评估小组自我检查和改进，提交书面报告。,评估阶段的步骤,ATAM的分析评估阶段由9步组成：1、ATAM描述（方法、人员、步骤）；2、商业动机表述；3、软件构架表述；4、确定构架方式；5、生成效用树；6、分析构架方式；7、确定场景及其优先级；8、进一步分析构架方式；9、得出结论。,8.6.3 一个架构评审案例的点评,以下的架构评审案例来自网络，抄录在此并加以点评，只为教学所需，如对原作者或有不敬之处，请谅解。按照上节介绍的评审步骤（步骤一省略），在此一一简述如下，斜体字为方案原文：,二、商业动机表述（1）系统功能表述根据需求分析，系统功能被确定为：本系统是为中小型图书馆设计的基于网络的图书管理系统，应包括图书管理系统的所有基本功能。功能设置如下：系统设置、图书编目、借书卡管理、查询、图书借还管理、统计、图书续借和预约、数据备份。点评：可能由于篇幅所限，也可能原案例也是教学案例（学生的问题根子还是在老师），因此，需求分析的结果，才只有几个字，好在这个系统是大家都熟悉的、且业务操作核心（业务实体）就是数据库的读写查，即使有理解的偏差，也偏不到哪里去。但是，从后面的分析可以看到，即使是这样简单的系统，仍然有需求目标不确定的情况，且导致问题多多。,评审实例小型图书管理系统的商业动机表述,评审实例小型图书管理系统的商业动机表述,2.1 商业表述介于技术力量与开发时间考虑，要求该系统能够继续改进完善。由于具体客户尚未开发，要求系统能满足多个不同客户的要求。本系统是为小型图书馆设计的基于网络的图书管理系统，系统容易使用。 系统希望能快速响应。根据表述的结果，质量属性被确定为如下划分：高优先级质量属性：可修改性、易用性、可配置性、性能重要但优先级低的属性。可用性、安全性、数据完整性、可测试性,评审实例小型图书管理系统的商业动机表述,点评：从上述描述可以看出，被评审系统的开发目标，可能是只需要开发部分功能（原型），且没有真正的用户，目标数据库也很小。在这个目标下，提出来的质量属性目标，不是“为赋新诗强说愁”也没人相信。例如：仅以高优先和重要但优先级低的选排，看不出有什么依据。难道可用、安全、数据完整和可测试这些应用系统交付前期应达到的最基本目标，比可修改（交付后）、易用（运行期）、可配置（交付时）、性能（运行期）指标，优先级要低吗？所以，暂时理解为：我说低就低啦，反正高也好，低也好，也没有什么影响啦，就算它低吧。,评审实例小型图书管理系统的商业动机表述,2.2 质量属性的具体表述2.2.1 性能1 动态数值要求在正常工作条件下，一定时间周期内要处理的数据需求峰值为200个。即平均处理的数据为200。并行处理200个用户申请2精度要求在数据库中提取数据时，要求数据记录定位准确；向数据库中添加数据时，要求输入准确。3时间特性要求响应时间较快，灵活性强。响应时间在人能忍受的等待范围内，设为5秒。,评审实例小型图书管理系统的商业动机表述,点评：上例所列性能指标虽都可通过实际模拟测试获得验证，但上述需求表述，均存在目标要求模糊不清，指标要求缺乏依据等情况。例如：动态数值要求的“并行处理数据需求峰值”，是指同时“在线用户数”，还是有效用户进程数（进程生命周期）、还是“完整交易过程数”？精度要求的数据记录“定位准确”、“输入准确”要求，不知道是针对编码工程师，还是使用系统的用户。难道真的出现这样的问题，也是架构设计的问题？,评审实例小型图书管理系统的商业动机表述,点评：时间要求的“响应时间较快、灵活性强、人能忍受”等，作为技术指标，如同要求衣着“美观、大方、得体”一样，是见仁见智，无法实际测试的。唯有“5秒”这个指标，也反映了原作者可能没有什么实际系统开发经验。用户能够接受不论什么操作，只要5秒之内就可以验收吗？甚至，延时时间是以秒为单位的吗？具体不同操作，延时要求不同，一般以ms（毫秒）为单位，有些要细化到ns（纳秒）或多少个指令机器时间周期。可能用户并不能提出具体的目标描述，但作为提交系统架构设计评审的评审目标，不是用户写的，不可以这么模糊的，否则，如何测试验证和评审？,评审实例小型图书管理系统的商业动机表述,2.2.2 可用性能迅速检测到图书管理系统存在的错误及疏忽，系统遇到各种问题，能较快返回出错的原因，以及提供系统管理员检测办法，及恢复办法，该系统平均修复时间经系统测试为60分钟，使得故障率降到最低。2.2.3 可修改性图书管理系统提供了更多扩展功能的空间，系统为模块化设计，能很好的与扩展功能相结合，使得以后的升级工作更为轻松，从而使得图书管理系统能获得更强生命力。,评审实例小型图书管理系统的商业动机表述,点评：其他属性的问题也是明显的，例如：使故障降到最低哪里是最低，没有更低了？还有吧？使以后的升级工作更轻松那就等以后升级的时候再测我是否轻松吧；证明系统无重大BUG你证明给我看？什么时候能证明了，什么时候通过测试；使得系统被广大用户接受广大是多大？扩大使用人群面积你也帮我们来兼做市场吧，买不出去，我也不付你们软件开发的钱。,评审实例小型图书管理系统的商业动机表述,2.2.4 可配置性系统能够满足不同用户群的要求，对不同语言，底层数据库等能很好的支持，同时界面能根据不同客户要求来设计。2.2.5 安全性考虑到不同用户的权限不同，第一次进入该系统时应该向管理员申请注册一个用户名和密码，并完整的填写相关信息，同时存入数据库表中。这样管理员就可赋予不同用户不同的权限。每位用户根据自己的身份不同，进入不同的用户界面。管理员有权力行使所有的管理功能，普通用户只能进行一般的查询。,评审实例小型图书管理系统的商业动机表述,2.2.6 完整性需求根据图书管理系统的要求，为保持数据的完整性，采用了数据库的事务机制，防止出现操作故障2.2.7 可测试性系统经过软件设计人员、 图书馆以及普通用户多种测试，证明系统无重大BUG。2.2.8 易用性系统操作简单，界面人性化，能为普通用户迅速掌握使用方法，快速的使用本系统所提供简单明了的查询功能，从而使得系统能被广大用户接受，扩大使用人群面积。,评审实例小型图书管理系统的软件构架表述,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操作系统下运行。,可移植性,将系统的所有提示语言都保存在ApplicationResource.properties中，这样只要替换这个文件，就可方便实现国际化（中、英文版面互换）,将数据库访问信息保存在xml配置文件中要更换数据库时，只需修改配置文件，不需修改任何代码，更不需重新编译。,可配置性,采用cookie技术,用户不须在每次登录时都输入用户名和密码，免除用户频繁输入密码的烦恼。,采用B/S结构，客户端不用安装任何软件，只需浏览器便可访问本系统。,易用性,采用MVC三层结构，程序逻辑结构清晰，便于扩充修改。同时将与系统有关的信息放在配置文件中，便于系统更新,可修改性,采用战术,质量属性,评审实例确定构架方式（质量属性与采用战术）,将web server与数据库分别放在两台服务器上，以提高其总体性能。,读者用户若超过5分钟不活动就强制其退出系统以响应其他用户请求。,把用户的请求划分为3个优先级，超级管理员优先级最高，图书管理员次之，其它用户优先级最低，当服务器繁忙时，服务器优先相应优先级高的用户请求。,限制最大访问数为200，当访问数大于200时对请求不予以响应。（超级管理员和图书管理员请求除外）,性能,采用战术,质量属性,评审实例确定构架方式（质量属性与采用战术）,将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面；而想要访问页面，必须经过action的处理和转发,由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录,用户的ID和密码采用RSA方法加密后再进行传输，保证这些信息在网络传输过程中的安全。,只有通过授权的用户才能登录本系统，不同的用户在系统中有不同的权限。,安全性,采用战术,质量属性,评审实例确定构架方式（质量属性与采用战术）,点评：易用性：与功能多少有直接关系吗?如果只有很简单的、单一的功能（如第六章的最简单的媒体播放器），难道一定就是难于使用？这是混淆了功能与易用性的关系，没有搞清楚什么是易用性。简单的对策如本章8.2.5；性能：在JSP页面加SQL语句，作者看到这个方法时，简直怀疑是否是在看与软件架构有关的文字。在JSP程序代码中直接用SQL语句？在SSH架构中?那不是从第一层，直接打穿到数据库层？中间的所有SSH都穿越了？这样的性能是什么性能？系统的每个功能都这样来提高？匪夷所思！都已经使用SSH了，怎么还用SQL语句呢？玩“复古”吗？,评审实例确定构架方式（质量属性与采用战术）,可修改性：这里的系统信息不知道是指那些，而配置文件是否是指Struts的配置文件。这个配置文件只定义Struts的JSP与ActionFrom/Action之间的对应关系，并不涉及其他什么系统信息，所以，所谓的系统更新，应该跟这个配置文件关系不大。（此后还有不少涉及SSH架构的内容，都给人一种“似是而非”的感觉）；可配置性：在SSH架构中，虽然Hibernate提供了面向对象与数据库的无关性，但到具体更换数据库的时候，也绝不是简单修改Hibernate配置文件可以那么简单。即使更换后的数据库库表与原数据库表的定义完全一致（这几乎不可能），那么，至少也还需要重新做逆向工程，修改DAO类等。,评审实例确定构架方式（质量属性与采用战术）,可移植性：JAVA语言代码在Windows和UNIX系统之间移植是个“神话”，只听说过，没有见过。即使开发者不惜一切代价，具有超凡能力，用户也不信。安全性：JSP文件放在哪个目录下与安全性几乎毫无关系，通过控制用户是否有该目录的访问权限来进行的安全控制，简直是“小儿科”，不值一评。上述方案好像是一个经常“翘课”的学生，交来的“应付”作业。下面就可以看到这个“学生”如何“出洋相”了。老师本不应该这样看学生，但当看到那些不认真听课的学生交作业时候的狼狈相，也是很好笑的，老师也是人嘛。,评审实例生成效用树（定性评价质量属性的效果）,生成质量属性效用树效用树的作用是使质量属性需求具体化，从而迫使设计师和客户代表准确地定义出他们的质量需求。“效用”是效用树的根结点，表示系统的总体适宜性。中间结点是质量属性及其求精。叶结点是与质量属性对应的场景。,评审实例生成效用树（定性评价质量属性的效果）,在访问量不超过系统负载的情况下，服务器的死机次数要小于2次/周,正常操作,采用MVC结构设计，逻辑结构清晰，便于修改。,更改系统,可修改性,把用户的请求划分为3个优先级，优先响应较重要的请求，以保证重要数据不丢失。,服务器繁忙,系统数据库崩溃后，系统应能够进行数据库恢复，以使用户的数据不丢失。,突发事件,可靠性,采用cookie技术,用户不须在每次登录时都输入用户名和密码，免除用户频繁输入密码的烦恼。,正常操作,具备基本计算机知识的借书用户在20分钟就可以了解和使用本系统的主要功能。,正常操作,在图书馆工作一个月以上而且具备基本上网的计算机知识的图书馆员在3天的培训后就可使用本系统。,熟练度培训,易用性,场景,属性求精,质量属性,评审实例生成效用树（定性评价质量属性的效果）,本系统用JAVA语言编写，可在WINDOWS,UNIX操作系统下运行。,操作系统可移植性,可移植性,将web server与数据库分别放在两台PC机上，以提高其总体性能。,正常运行,读者用户若超过5分钟不活动就强制其退出系统以响应其他用户请求。,正常运行,把用户的请求划分为3个优先级，超级管理员优先级最高，图书管理员次之，其它用户优先级最低，当服务器繁忙时，服务器优先相应优先级高的用户请求，保证高优先级用户获得较好的性能。,服务器繁忙,限制最大访问数为200，当访问数大于200时对请求不予以响应。（超级管理员和图书管理员请求除外）,服务器繁忙,性能,场景,属性求精,质量属性,评审实例生成效用树（定性评价质量属性的效果）,将所有的jsp页面都放入文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意访问页面；而想要访问页面，必须经过action的处理和转发,更改系统,由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端后超级管理员才能登录,更改系统,用户的ID和密码采用RSA方法加密后再进行传输，保证这些信息在网络传输过程中的安全。,更改系统,只有通过授权的用户才能登录本系统，不同的用户在系统中有不同的权限。,更改系统,安全性,将系统的所有提示语言都保存在Application Resource Properties中，这样只要替换这个文件，就可方便实现国际化（中、英文版面互换）,更改系统,将数据库访问信息保存在heibernet.cfg.xml文件中，要更换数据库时，只需修改配置文件，不需修改任何代码，更不需重新编译。,更改系统,可配置性,场景,属性求精,质量属性,评审实例生成效用树（定性评价质量属性的效果）,点评：我们主要是从效果看是否满足需求（可满足），以及效果是否有可能达到（可行性）。首先，由于需求目标本身就模糊不清（见质量属性表述点评），所以，方案中要给出明确的效果描述，同样也是十分困难。例如：“学习3天后就能使用本系统”、“20分钟就能了解功能”、“死机次数要小于2次/每周”这种几乎“广告用语”般的承诺，就是效果。如果说不出什么效果的话，那只好拿方法当效果了。好像只要做了，就是效果，且不论这些方法是否可行。所以，直接抄“战术”部分吧。无语！,评审实例质量场景分析,分析与场景相关的质量属性质量属性不是处于隔离状态，只有在一定的上下文环境中才能做出有意义的评判。某一场景是一类场景的代表，系统将以完全相同的方式对这些场景做出反应。,评审实例质量场景分析,*,将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面,A2,由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录,无风险决策,有风险决策,权衡点,敏感点,构架决策,成功抵抗攻击概率大于99.9%,响应,黑客试图盗取密码，攻击系统,刺激,系统运行时,环 境,安全性,属性,场景：抵抗恶意攻击,场景号：A1,评审实例质量场景分析,1. 超级管理员拥有系统的最高权限，因此保护超级管理员用户的安全显得格外重要。由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录，这样即使黑客盗取了用户名和密码，他也不能在浏览器端访问系统。这样虽降低了系统的可用性，但经权衡，还是利大于弊。2. 将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面而想要访问页面，必须经过action的处理和转发，这样保证了系统文件不能随意访问和修改。,推 理,无风险决策,有风险决策,权衡点,敏感点,构架决策,成功抵抗攻击概率大于99.9%,响应,黑客试图盗取密码，攻击系统,刺激,系统运行时,环 境,安全性,属性,场景：抵抗恶意攻击,场景号：A1,评审实例质量场景分析,*,将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面,A2,由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录,无风险决策,有风险决策,权衡点,敏感点,构架决策,系统尽快响应客户请求，特别是响应重要的请求,响应,大量用户（200）访问系统,刺激,系统运行时,环 境,性能,属性,场景：提高系统的性能,场景号：A2,评审实例质量场景分析,1. 超级管理员拥有系统的最高权限，因此保护超级管理员用户的安全显得格外重要。由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录，这样即使黑客盗取了用户名和密码，他也不能在浏览器端访问系统。这样虽降低了系统的可用性，但经权衡，还是利大于弊。2. 将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面而想要访问页面，必须经过action的处理和转发，这样保证了系统文件不能随意访问和修改。,推 理,评审实例质量场景分析,A4,把用户的请求划分为3个优先级，超级管理员优先级最高，图书管理员次之，其它用户优先级最低，当服务器繁忙时，服务器优先相应优先级高的用户请求。,A5,A4,限制最大访问数为200，当访问数大于200时对请求不予以响应。（超级管理员和图书管理员请求除外）,无风险决策,有风险决策,权衡点,敏感点,构架决策,系统尽快响应客户请求，特别是响应重要的请求,响应,大量用户（200）访问系统,刺激,系统运行时,环 境,性能,属性,场景：提高系统的性能,场景号：A4,评审实例质量场景分析,1. 限制最大访问数为200,以免过多的连接导致服务器性能急剧降低，甚至死机。2. 图书管理员、超级管理员的请求往往对系统是较为重要的，保证这两种用户的性能，防止重要信息的丢失有助于提高整个系统的性能与可靠性。3.若用户长时间不活动，强制其退出以响应其它用户请求，这样可以更有效地利用系统资源。但当然这样可能会引起某些用户对本系统的不满。,推 理,*,A4,读者用户若超过5分钟不活动就强制其退出系统以响应其他用户请求。,无风险决策,有风险决策,权衡点,敏感点,构架决策,评审实例质量场景分析,用户不须在每次登录时都输入用户名和密码，免除用户频繁输入密码的烦恼，但降低了系统的安全性。,推 理,A1,采用cookie技术,无风险决策,有风险决策,权衡点,敏感点,构架决策,采用cookie技术，用户再次登录不需要输入密码。,响应,用户首次登录本系统后再次登录本系统,刺激,系统运行时,环 境,易用性,属性,场景：提高系统的易用性,场景号：A4,评审实例质量场景分析,点评：,评审实例结果表述（有风险决策及敏感点）,只有通过授权的用户才能登录本系统，不同的用户在系统中有不同的权限。,将web server与数据库分别放在两台PC机上，以提高其总体性能。,降低了可用性，但保证了系统的整体性能,降低了可用性，有可能引起某些用户的不满,读者用户若超过5分钟不活动就强制其退出系统以响应其他用户请求。,降低了某些用户的可用性，但保证了整个系统的可靠性和性能。,把用户的请求划分为3个优先级，超级管理员优先级最高，图书管理员次之，其它用户优先级最低，当服务器繁忙时，服务器优先相应优先级高的用户请求。,限制最大访问数为200，当访问数大于200时对请求不予以响应。（超级管理员和图书管理员请求除外）,权衡点,有风险决策,采用战术,评审实例结果表述（有风险决策及敏感点）,提高了可用性，降低了安全性,存在安全隐患,采用B/S结构，客户端不用安装任何软件，只需浏览器便可访问本系统。,系统数据库崩溃后，系统应能够进行数据库恢复，以使用户的数据不丢失。,将所有的jsp页面都放入WEB-INF文件夹中，这样最终用户就不能随意的通过在地址栏中输入地址来随意的访问页面；而想要访问页面，必须经过action的处理和转发,提高了安全性，降低了可用性,由于B/S模式存在安全隐患，超级管理员模块单独采用C/S模式，只有安装客户端软件后超级管理员才能登录,提高了安全性，性能方面有损失。,用户的ID和密码采用RSA方法加密后再进行传输，保证这些信息在网络传输过程中的安全。,权衡点,有风险决策,采用战术,评审实例结果表述（有风险决策及敏感点）,本系统用JAVA语言编写，可在WINDOWS,UNIX操作系统下运行。,将系统的所有提示语言都保存在ApplicationResource.properties中，这样只要替换这个文件，就可方便实现国际化（中、英文版面互换）,将数据库访问信息保存在文件中要更换数据库时，只需修改配置文件，不需修改任何代码，更不需重新编译。,采用MVC三层结构设计，程序逻辑结构清晰，便于修改,提高了可用性，降低了安全性,存在安全隐患,采用cookie技术,用户不须在每次登录时都输入用户名和密码，免除用户频繁输入密码的烦恼。,权衡点,有风险决策,采用战术,评审实例结果表述（有风险决策及敏感点）,点评：,评审实例评审结论,原有的问题：由于以前的系统采用了功能驱动单层模型的模式，所有的业务层和控制层也是采用的jsp页面的开发的，这样一来，复杂的控制逻辑和业务逻辑和显示搅在了一起，程序不便于阅读，而且不具有很好的可扩展性，没有xml配置文件，项目的可配置性也大打折扣，实现了视图，控制，业务层搅在一起，不助于我们扩展我们的系统，安全性较差，jsp页面里直接的sql语句的操作，使得操作数据库变得异常复杂，大大的加大了我们的开发的难度，框架中大量的xml配置文件在这里没有得到应有的应用，而每次都要编译程序。,评审实例评审结论,改进：继续采用功能驱动单层模型构架开发应该说是唯一的好处是功能实现“简单”，可以大大加快系统的开发进度。它把表现层和业务逻辑层柔和在一起，不利于以后的维护工作以及开发角色的分配，因此要实现质量属性其实非常困难。使用ADD分层驱动模型重新开发在性能、可用性、安全性、可配置性、可修改性、可移植性方面满足质量需求。,评审实例评审结论,点评：整个方案的核心，就是采用了SSH架构，如果仅是这一点的话，完全没有必要进行架构评审。奇怪的是，原方案作者自己也知道在原有的系统中，在JSP中加入SQL是不好的，为什么还把它作为新方案的战术之一呢？,小结,ATAM是评估软件构架的健壮方法。在该方法中，项目决策者和风险承担者要以场景方式阐述一个准确的质量属性需求列表，说明实现高优先级场景的构架决策。然后，把这些决策确定为有风险和无风险场景，以找到构架中存在的问题。但ATAM不是需求评估，不是代码评估，不包括对实际系统的测试，不是一个量化的手段。,