- 推荐序一:架构师真正要学会的事情
- 推荐序二
- 译者序 2.0
- 序
- 关于本书
- Part Ⅰ 什么是软件架构
- 第 1 章 什么是架构
- 第 2 章 架构的种类
- 第 3 章 软件架构是什么
- 第 4 章 敏捷软件架构是什么
- 第 5 章 架构对上设计
- 第 6 章 软件架构重要吗
- 第 7 章 问题
- Part Ⅱ 软件架构的角色
- 第 8 章 软件架构的角色
- 第 9 章 软件架构师应该编码吗
- 第 10 章 软件架构师应该是建造大师
- 第 11 章 从开发者到架构师
- 第 12 章 拓展 T
- 第 13 章 软技能
- 第 14 章 软件架构不是接力运动
- 第 15 章 软件架构要引入控制吗
- 第 16 章 小心鸿沟
- 第 17 章 未来的软件架构师在哪里
- 第 18 章 每个人都是架构师,除非他们有其他身份
- 第 19 章 软件架构咨询师
- 第 20 章 问题
- Part Ⅲ 设计软件
- 第 21 章 架构驱动力
- 第 22 章 质量属性(非功能需求)
- 第 23 章 处理非功能需求
- 第 24 章 约束
- 第 25 章 原则
- 第 26 章 技术不是实现细节
- 第 27 章 更多分层等于更高复杂度
- 第 28 章 协同设计是一把双刃剑
- 第 29 章 软件架构是对话的平台
- 第 30 章 SharePoint 项目也需要软件架构
- 第 31 章 问题
- Part Ⅳ 可视化软件
- 第 32 章 沟通障碍
- 第 33 章 对草图的需要
- 第 34 章 无效的草图
- 第 35 章 C4:语境、容器、组件和类
- 第 36 章 语境图
- 第 37 章 容器图
- 第 38 章 组件图
- 第 39 章 是否包含技术选择
- 第 40 章 你会那样编码吗
- 第 41 章 软件架构和编码
- 第 42 章 你不需要 UML 工具
- 第 43 章 有效的草图
- 第 44 章 C4 的常见问题
- 第 45 章 问题
- Part Ⅴ 为软件生成文档
- 第 46 章 代码不会讲述完整的故事
- 第 47 章 软件文档即指南
- 第 48 章 语境
- 第 49 章 功能性概览
- 第 50 章 质量属性
- 第 51 章 约束
- 第 52 章 原则
- 第 53 章 软件架构
- 第 54 章 外部接口
- 第 55 章 代码
- 第 56 章 数据
- 第 57 章 基础设施架构
- 第 58 章 部署
- 第 59 章 运营和支持
- 第 60 章 决策日志
- 第 61 章 问题
- Part Ⅵ 开发生命周期中的软件架构
- 第 62 章 敏捷和架构的冲突:神话还是现实
- 第 63 章 量化风险
- 第 64 章 风险风暴
- 第 65 章 恰如其分的预先设计
- 第 66 章 初识软件架构
- 第 67 章 问题
- Part Ⅶ 金融风险系统
- 第 68 章 金融风险系统
- Part Ⅷ 附录:技术部落 的软件指南
第 22 章 质量属性(非功能需求)
当你收集需求时,人们会很乐意给你一个愿望清单,写满了他们想要软件系统完成的事;也有完善的方法以用户故事、用例、传统的需求规格书、验收标准等形式来捕捉这一信息。那么,那些讨厌的“非功能性需求”呢?
非功能性需求通常被看作是“能力”,主要跟服务质量有关。按理说,比非功能性需求更好的说法是“系统特征”或“质量属性”,但不太常用。下面大致列出了常见的质量属性。
1. 性能
性能就是一个东西有多快,通常指响应时间或延迟。
响应时间:从发出请求到收到响应所用的时间,比如用户点击网页中的超链接或桌面应用程序中的按钮。
延迟:消息从A点到B点,通过你的系统所用的时间。
就算构建的不是“高性能”软件系统,性能也可应用于Web应用程序、桌面应用程序、面向服务架构、消息系统等几乎所有你要构建的软件系统。如果用户说你的软件“太慢”,你就明白为什么有一些性能的概念很重要。
2. 可伸缩性
可伸缩性基本上就是软件处理更多用户、请求、数据、消息等的能力。可伸缩性和并发机制密不可分,因此能在相同的时间内处理更多的东西(比如每秒的请求)。
3. 可用性
可用性是软件对服务请求的可操作和可见程度。你常会看到用“9”来衡量或指代可用性,如99.99%(“四个9”)或99.999%(“五个9”)。这些数字指的是正常运行时间的百分比。硬币的另一面是可以容忍的停机时间。99.9%(“三个9”)的正常运行时间意味着留给计划维护、升级和意外故障的时间每天只有1分多钟。
4. 安全性
安全性涵盖了从认证和授权到数据在运输和储存中的机密性的所有事情。和性能一样,安全性很有可能在一定程度上对你很重要。对于部署到互联网的Web应用程序,安全性应该被视为最基础的东西。开放Web应用程序安全项目(OWASP,Open Web Application Security Project)1是学习安全性的一个很好的出发点。
5. 灾难恢复
如果失去一个运行了你的软件的硬盘、服务器或数据中心,会发生什么?灾难恢复处理的就是这些。如果你的软件系统至关重要,就会经常听到人们谈论业务连续性过程,也就是发生灾难事件时,应该做什么才能保持持续运行的状态。
6. 可访问性
可访问性通常是指像W3C的可访问性标准2这样的东西,指的是如何让视觉障碍之类的残疾人也能使用你的软件。
2http://www.w3.org/standards/webdesign/accessibility
7. 监测
有些组织对于应该如何监测软件系统才能确保它们正常运行和满足服务请求,有特定的需求。这可能包括将软件与平台特定的监测功能(比如Java平台的JMX)集成,或发生故障时向集中监测仪表发送警报(比如通过SNMP)。
8. 管理
监测通常提供一个软件系统的只读视图,有时会有运行时管理需求。例如,有必要的话,暴露一些功能,使得操作人员能够修改系统运行时的拓扑结构或配置元素,刷新只读缓存等。
9. 审计
人们往往需要一个引起软件系统中数据或行为变化的事件的日志(即审计日志),特别是涉及钱的时候。通常这些日志需要捕获与变动由谁做出、什么时候做出以及为什么做出相关的信息。变动本身(即变动前后的值)往往也需要记录。
10. 灵活性
灵活性是一个有点滥用和含混的术语,指的是软件执行多个任务,或以不同方式执行单个任务的“灵活性”。一个很好的灵活性需求的例子是非技术人员修改软件内部使用的业务规则的能力。
11. 可扩展性
可扩展性也是滥用和模糊的,但它指的是扩展软件使其可以做一些现在还不能做的事的能力,也许是通过使用插件和API。一些市面上的产品(如微软Dynamics CRM)允许非技术用户扩展存储的数据和改变其他用户与数据交互的方式。
12. 可维护性
可维护性往往被认为是一个需求,但这到底是什么意思?作为软件开发者,我们通常会努力打造“可维护”的软件,但值得我们思考的是,代码库以后将由谁来维护。可维护性很难量化,所以我宁愿思考我们可以遵循的架构和开发原则,因为这些是编写可维护的代码的驱动力。
13. 法律法规
有些行业受到当地法律或监管机构的严格管理,导致了与数据保留或审计日志等相关的额外需求。举个例子,大多数金融机构(投资银行、零售银行、信托公司等)为了保持在市场中的运作能力,必须遵守一些规则(如反洗钱)。
14. 国际化(i18n)
很多软件系统,特别是部署在互联网上的,不再以单一的语言交付。国际化是指以多种语言交付软件中用户可见元素的能力。这看似简单,当你试图将其加入已有软件时,才会意识到有些语言是从右向左书写的。
15. 本地化(l10n)
和国际化相关的是本地化,是指以符合最终用户文化习俗的方式展现数字、货币、日期等内容。有时候,国际化和本地化也统称为“全球化”。
哪些对你重要
我们可以为自己的软件系统指定的质量属性有很多,但它们的重要性不尽相同。根据工作的环境和构建的软件系统的类型,有些质量属性比其他的更为适用。金融行业中基于Web的系统的质量属性可能就不同于电信行业使用的内部系统。我建议学习你的领域内常用的质量属性,在开始构建一个新系统或修改已有系统时,先关注这些常用的质量属性。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论