@Author: Basil Guo
@Date: Feb. 10, 2021
@Description: Software/Game Architecture 这是CISC 322课程的内容，讲述Software/Game architecture。
1. Introduction, Syllabus, and Admin
现在的软件规模很大，而且有越来越大的倾向。比如Linux内核在过去的12年里增大了7.5倍。那么关键问题就来了：
- 如何保持对这样一个系统的概览？
- 如何发现bug或添加新功能？
- 如何调试系统？
- 如何跟踪系统开发进展？
- 如何理解基础的代码？
- 如何保证软件知量？
- 如何部署这样的系统？
这就涉及到系统架构的分析。
系统架构分析（Architecture Analysis该阶段生成系统架构文档） 承接问题空间需求分析（该阶段生成Software Requirements Specification），启下系统设计和实现（产出源代码），最后会测试和维护系统。这是因为软件架构是管理复杂度和风险的关键部分。
软件的架构根据IEEE的定义，Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. 架构是一个系统最基本的组织结构，它内嵌于系统组件、组件彼此关系以及上下文环境和设计和演进的指导原则。
系统的架构即系统的结构，类似于城市规划一样的存在。包括要使用的计算机、网络、数据库等。概念上的软件架构是抽象的结构，是存在于设计图纸上的。而真实的软件架构则是具体的实现出来的系统的架构。架构不同于设计。架构是系统的结构，包括其组成部分，是一个高层次的并且很难改变的东西，最好开始时就搞正确了。架构关系到技术选型以及非技术问题。是项目生命周期非常靠前的一部分。而设计则是系统具体组件内部的结构，位于一个相对较低的层次，更关注技术性的问题。在项目声明周期中后部的位置。
2. Non Functional Requirements (NFR) – Quality Attributes
2.1 需求分析
这是项目的第一步。后期的各个步骤都是依赖于这一步的。
需求是客户和利益相关者的需求。但是客户或者利益相关者可能无法正确描述他们的需求，这一步需要需求分析师或者需求工程师帮助他们梳理出需求，分析需求的一致性、可行性和完整性，并形成需求文档，验证梳理出来的需求是否符合客户或者利益相关者的真正需求。看似简单的问题，然而实际操作起来却是经典的如下图所示，不同的视角，产生了矛盾。
这是在收集需求的时候产生了问题。
- 分不清是业务需要还是客户需求；
- 分不清是优化还是必需；
- 分不清是系统目标还是合约需求；
- 技术选型摇摆不定。
需求分为了功能性需求和非功能性需求。功能性需求设定了系统能够完成的功能，通过一个映射函数表示F(input, system state) -> (output, new state)。非功能性需求往往是系统的约束。非功能性需求包括质量需求、管理需求以及环境上下文需求。质量需求表明系统是否功能实现完好，性能、可用性、后期维护、可靠性、可移植性。管理上的需求是项目何时验收发布、如果出错了如何处理。环境需求决定了系统可以运行的范围，系统的边界。
系统视图用于描述系统的边界、用户以及接口。
一个良好的需求文档需要：
- 正确：每个需求映射一个关注点；
- 完整：包含所有必需需求；
- 无歧义：所有人都同意；
- 一致：匹配所有部分，例如E/R以及事件列表；
- 重要性和稳定性排序：给每个需求进行优先级排序；
- 可修改：容易变更且统一维护；
- 可验证：验证是否满足需求；
- 可追踪：为目标设计，为意图编码；
- 必要性以及可行性。
2.2 NFRs也即“quality attributes”
NFR即Non Functional Requirement，非功能性需求决定了系统能够很好地执行它的功能，比如是否响应要多快？使用要多容易？安全性要求？便于维护的要求？
功能性需求就像verbs，非功能性需求就像动词的属性。例如系统应该提供安全登录是属于功能性需求，而系统应该提供高安全级别的登录功能就属于非功能性需求。功能性需求必须满足，是强制性的，而非功能性需求可以是强制性的，也可以是非强制性的。非功能性需求属于锦上添花，而功能性需求属于雪中送碳，只有当市场上所有产品都具备了功能性需求之后，客户才开始考虑非功能性需求。
功能性需求经常以Use-Case用例图的形式表现出来。而非功能性需求不能使用用例图的形式表现出来，因为他们可能不可见。但是非功能性需求却是非常重要的，大约占据总需求的20%，而且很难理解和指定。只是单单列出来所有的NFRs是不足够的，需求应该是清晰、准确且是可测量的。定义良好的非功能性需求，不仅需要客户的参与，还需要开发者的参与。
在软件架构设计中，NFRs需要特殊的考虑，因为它们通常不是映射到一个子系统，这涉及到很多子系统层面的协同，一旦过了这个架构设计阶段，就很难去改变了。例如使得现在的互联网更加安全基本都很难实现。
Quality Attributes，也即是多个后缀为ilities的单词：Reliablitiy、Availability、Portability、Scalability、Performance。是系统NFRs的一部分。
3. Architecture Styles
所谓系统架构就是系统结构，包括软件的组件、组件外部可见属性、组件之间的联系。