软件体系架构-六中质量属性小论文

一、可用性战术

可用性是指系统正常运行时间的比例。可用性侧重如何检测系统故障、系统故障发生的频度、出现故障时会发生什么情况、允许系统有多长时间非正常运行、什么时候可以安全地出现故障、如何防止故障的发生以及故障时要求哪种通知。可用性战术是阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使系统恢复成为可能。实例为加载网页的过程中，由于网速过慢，经过一段时间之后，网页依旧没有弹出内容，那么浏览器就会弹出相关的错误提示；在银行APP上进行余额查询时会与数据库进行交流，如果出现问题会进行相应反馈；为预防错误发生，系统重新启动组件，以防止内存泄露导致故障的发生等。可用性战术在代码层面上Java将所有的非正常情况分为两种：Error(错误)和Exception(异常)，错误是无法恢复或不可能捕获的，而我们能处理的是Exception类下的错误。Exception则分为两大类，RuntimeException(运行时异常)和其他异常(Checked异常)，其他异常(Checked异常)是各种形式的编译错误，是我们必须显示处理才可以通过变异的；而运行时错误顾名思义就是程序已经通过了编译，在运行时出现的错误，若是对这些异常置之不理会导致程序停止运行、占用资源无法释放甚至导致系统崩溃。

二、可修改性战术

可修改性是指系统或软件的能够快速地以较高的性价比对系统进行变更的能力。可修改性战术分析1——局部化变更。局部化意味着实现“模块化”思想，也就是设计模式中的“单一职责原则”的设计原则。可修改性战术分析2——防止连锁反应。连锁反应定义：我们平时编程，无论是写函数还是写类，都需要被其他类还是函数调用，修改此函数或类就会影响到调用他的函数，这就是连锁反应。可修改性战术分析3——推迟绑定时间。推迟绑定时间。将有可能的修改，尽量用配置文件，或者其他后期让非开发人员可调整的方式实现。

三、性能战术

性能战术的目标是对一定的时间限制内到达系统的事件生成一个响应，这些事件可以是消息到达、定时器到时，系统状态的变化。性能战术包括3个分类：资源需求——分析影响性能的资源因素，提高计算效率，减少计算开销，管理事件率，控制采样频率；资源管理——提高资源的应用效率，引用并发，维持多个副本，增加可用资源；资源仲裁——解决资源的争用，调度策略先进/先出，固定优先级，动态优先级，静态调度。

四、安全性战术

安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户企图使用的或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。

就淘宝而言，其拥有良好的安全体系结构设计：

身份认证：淘宝的身份证认证体系，个人认证，商家认证，均需提供个人身份信息，从虚拟网络映射到显示，实现可监察。

五、可测试性战术

可测试性战术的目标是允许在完成软件开发的一个增量后，轻松地对软件进行测试。将捕获跨接口的信息，并将其作为测试专用软件的输入。将接口与实现分离允许实现的代替。占位实现允许在缺少被占位组件时，对系统的剩余部分进行测试。有了标准的接口，进行有效的隔离，能够极大程度的减少测试员的工作量，模块化测试，单元测试极大地减少了测试过程中用例的原则。特化访问路线/接口。内部监视器：组件可以维持状态、性能负载、容量、安全性或其他可通过接口访问的信息。当监视状态被激活时可以记录事件。

六、易用性战术

易用性就是用户使用系统提供的服务的难易程度。在管理员或者用户操作查询的过程中，提供页数跳转，选择每页显示多少条数据，并且在添加了一条数据之后会自动跳到最后一页，方便用户查看自己刚添加的数据，在修改数据的时候也会在当前页数停留方便查看刚修改的那条数据。

 

时    间：2021.3.11，下午15:50-17:25

地    点：科技厅会议室

参加人员：孔梵冰，闫彦霖，郝子嘉

会议议题：关于软件质量之性能的讨论

纪要内容：

孔梵冰：我查找的性能官方解释为性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。由于感受软件性能的主体是人，不同的人对于同样的软件能有不同的主观感受，而且不同的人对于软件性能关心的视角也不同。由于网络应用非常普遍，因此下面将介绍网络应用软件性能的指标和软件性能的视角。

闫彦霖：性能的测试指标我做了分类

1.响应时间

响应时间是指系统对请求作出响应的时间。

2.系统响应时间和应用延迟时间

系统响应时间”进一步分解为“网络传输时间”和“应用延迟时间”，其中前者是指数据（包括请求数据和响应数据）在客户端和服务器端进行传输的时间，而后者是指网站软件实际处理请求所需的时间。类似的，软件性能测试也更关心“应用延迟时间”。

3.吞吐量

吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。

4.并发用户数

并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。

5.资源利用率

资源利用率反映的是在一段时间内资源平均被占用的情况。

   郝子嘉：我们还应该分视角讨论

1.用户视角

对用户而言，性能就是响应时间。用户甚至不关心响应时间中哪些是软件造成的，哪些是硬件造成的。但用户感受到的响应时间既有客观成分，也有主观成分，甚至是心理因素 。

2.管理员视角

管理员需要使用软件提供的管理功能等手段来方便普通用户使用。这类用户首先关注普通用户感受到的软件性能。其次，管理员需要进一步关注如何利用管理功能进行性能调优。

3.开发人员视角

开发人员的视角与管理员的视角基本一致，但开发人员需要更深入地关注软件性能。在开发过程中，开发人员希望能够尽可能地开发出高性能的软件。

目前急需解决的问题：

1. 对于具体软件还要有更加详细的分析

2. 找出存在的漏洞，防止被别人指出无法回答