系统质量属性

论软件体系结构设计中系统质量属性的实现软件质量的好坏，不仅要看系统是否能满足客户的功能性要求，也要看其是否能满足客户的非功能性要求，系统非功能性用质量性来描述，与软件体系结构设计相关的系统质量属性主要有可用性、可修改性、性能、安全性、可测试性和易用性，在软件体系结构的设计过程中，为了使系统的设计方案能保证某种特定的质量属性和实现，需要采用一些针对性的具体设计策略，例如，对可用性质量属性，为了阻止错误发展成为故障或者为了恢复错误，往往采取主动冗余或被动冗余的设计决策，对于可修改性质量属性，为了提高系统的可修改和扩展性，往往采取局部化修改的设计策略等等。请根据论题从以下三个方面进行论述：1、 概要叙述你参与管理和开发的软件项目以及你在其中担任的主要工作。2、 请对以上与软件体系结构设计相关的质量属性中至少4个质量属性的实现分析讨论，详细论述在软件体系结构的设计过程中，对于每个质量属性的实现，各自都有哪些针对性的具体的设计决策。3、 具体阐述你参与管理和开发的项目在体系结构设计时，都采用了那些针对性的设计决策以实现特定质量属性，最终实际效果如何？软件体系结构质量属性：成功的企业体系结构必须具备各种各样的质量属性。它可以帮助预先定义这些属性。这个属性集构成了一个蓝图，以指导分析、设计、编码、部署、维护、更新等阶段的工作。这种体系结构是对成型后的系统的预想。典型的质量属性包括（但并不局限于此）下列方面：1、可用性（Availability）：是指系统能够正常运行的时间比例。它常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。体系结构实现所定义的无故障运行时间级别的程度（例如，每年不超过5分钟的停机时间）独立异常发布程序负责确保将异常报告给系统中某个单一的位置。这种方法保证将系统中的所有异常都报告给体系结构中的某个要素，并因此提供更高的系统可用性级别。管理控制台实现健康状况和可用性监控生成三种模拟真实服务器问题的场景，了解健康状况和可用性监控功能如何解决这些问题，然后使用问题诊断功能诊断和修复这些问题。只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。2、 可修改性(Modifiability)：有了这种特性就可以很容易地对基础软件进行修改是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准。通过考察这些变更的代价来衡量可修改性。主要包括四方便可维护性：主要体现在问题的修复上，在错误发生后“修复”软件系统，为可维护性做好准备的软件体系结构往往能做局部性的修改并能是得对其它构件得负面影响最小化。可扩展性：关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构建并删除不需要或不必要的特性和构件，为了实现可扩展性，软件系统需要松散耦合的构建，其目标是实现一种体系结构，能使开发人员在不影响构建客户的情况下替换构件，同时支持把新构件集成倒现有的体系结构中也是必要的。结构重组：结构重组处理的使重新组织软件系统的构件及构件间的关系，例如通过将构件移动一个不同的子系统而改变它的位置，为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，他们允许开发人员在不影响实现主体部分的情况下灵活的配置构件。可移植性：使软件系统使用于多种硬件平台、用户界面、操作系统、编程语言或编译器，为了实现可移置，需要按照硬件无关的方式组织软件系统，然后提取出其它软件系统和环境。可移置性使系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合，在所有关于没个特定计算环境的假设都集中在一个构件中时，系统是可移置的。如果移置到新的系统需要做些修改则可移置性就是一种特殊的可修改性。3、 性能(Performance)：体系结构的可度量的服务级别从执行程序入手，很多现代程序的设计目标，是将应用程序的某些部分拆分成若十个能同时执行的任务，从而改善其性能。在不同的线程中执行这些任务往往有助于改善应用程序的性能和响应能力。执行程序模式描述这些任务与执行方法的分离过程。性能是指系统的响应能力，即要经多长时间才能对某个事件作出响应。或者在某段时间内系统所能处理的事件个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需要的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序(用以测量性能指标的特定事务或工作量环境)4、 安全性(Security)：是指系统在向合法用户提供服务的同时能够阻止非授权用户企图使用的或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。体系结构所定义的安全基准5、 可测试性(Testability)：6、 易用性(usability);7、 可伸缩性：体系结构能够在用户级别和所提供的服务方面的增长程度8、可重用性：将该体系结构中的部分或全部集成到一个新的体系结构中的能力对于《全国邮政储蓄统一版本系统》的设计，非功能性的设计重要性，要远远高于它的功能性设计，首先这套系统是服务于全国邮政银行系统的，它的稳定性，可用性，安全性是我们在设计系统初期首要考虑的因素。由于系统的过于庞大和增值业务层出不穷，他的可修改性（可扩展性）也是我们在系统设计初期在软件体系结构设计上，所需要考虑到的，目的就是为了满足银行系统用户层出不穷的需求和不断变化的推陈出新的业务。在非功能需求软件体系结构设计满足了以后，我们才会考虑到功能性的设计。当然这在我们系统整体设计中，只占很小一部分。有业务部门去了解银行的需求，然后分成模块化处理，有设计人员分别实现所需要完成的功能。以下我就对我们系统在软件体系结构设计中，相关质量属性实现，进行分析讨论，我们是怎样满足这些银行系统质量属性的要求的。质量属性虽然不是系统的功能需求，但是用户的这些要求达不到，最终会要求拒绝使用我们所提供的系统的。如何满足这样的非功能需求呢？上面所提到的各个属性都是相互制约的，都会对系统产生消极的影响，甚至相互是矛盾的，就要求我们怎么去取舍，在构架的设计中去折中处理。1可用性：从现实的系统出发，处理系统的HA，业界的方法也就是集群，在下个峰值到来之前，增加服务器的方式，或增加web容器，或增加DB；增加cache等等来实现的。我们则是……2、 可修改性：其实还是代码的质量问题，让架构对程序员写的代码做约束，限制程序员的随意性。我们邮政储蓄系统采用了客户机-服务器（C/S）的软件体系结构的设计。为了使系统具有可修改性和可伸缩性，系统被分成客户机和服务器两个部分；有（很大）一部分计算是在服务器部分执行的，服务器可以在不依赖客户机的情况下进行修改，并可为多个客户机提供服务。3、 性能：很多行业如电信行业对性能有着极高的要求。在银行系统中，更是要求甚高，我们为了提高系统的性能要求，采取了……的设计方案。4、 安全性，没有绝对的安全，我们系统首先采用ca,https,saml.amopoint等安全协议。我们系统采用了CFCA认证系统，它采用国际领先的PKI技术，总体为三层CA结构，第一层为根。人；第二层为政策CA，可向不同行业、领域扩展信用范围；第三层为运营CA，根据证书运作规范（CPS）发放证书。安全电子印章运营CA由CA系统和电子印章证书注册审批机构（RA）两大部分组成：CA系统：承担电子印章证书签发、审批、废止、查询、数字签名、电子印章证书/黑名单发布、密钥恢复与管理、电子印章证书认定和政策制定，CA系统设在CFCA本部，不直接面对用户；5、 易用是个问题，多和美工沟通一下吧6、 多和使用者进行沟通为什么非功能性需求很重要?在您设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，您的解决方案则很难取得实效。可用性如果用户不能够从他们可用的渠道（例如Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是：•您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？•系统是否根据模型-视图-控制器（Model-View-Controller）体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？•是否界面本来就有状态而功能无状态（反之亦然）？性能如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗？可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）？可测试性（Testability）：系统测试人员负责制定测试计划并依照测试计划进行测试。这些测试包括功能性的测试（黑盒测试）和非功能性的测试（白盒测试）。测试人员需要良好的测试工具来辅助完成测试任务，自动化的测试工具将大幅度提高测试人员的工作效率和质量。一个软件系统的特性表现在它的功能性和非功能性(如性能、可靠性、安全等)2个方面.在许多软件系统中，尤其是大型软件系统中,非功能甚至是强制的要求，例如电信系统中的性能和可靠性要求，电子商务中的安全性要求等.然而在许多实际系统的开发中却往往忽视了软件的非功能属性.在许多项目中，软件的非功能属性是在软件开发完成后再考虑的，但灾难由此发生:软件结构需要重新变化,大量代码需要重新编写，需要更多的时间、人力和物力.有些系统一开始考虑到一些非功能属性，但没有进行良好的设计、分析和验证,当产品完成后才发现并不能满足当初的需求.因忽视非功能需求而直接导致项目失败甚至造成重大经济损失的例子不胜枚举.一个著名的案例是"伦敦救护车系统(LAS)"[1]，这个系统在部署不久即陷入瘫痪，其中一个主要原因就是不能满足非功能需求(可靠性