Microsoft.NET 企业级应用架构设计-当代架构师和架构
当代架构师和架构
项目干系人
项目干系人的定义是所有对创建系统感兴趣或关注的人，包括系统的创建者（架构师、开发人员和测试人员）以及产品接受方、最终用户、
分析师、审计人员和首席信息官（CIO）等
软件架构的关键点是软件应该符合干系人的期待，该期待可以分为功能性需求和非功能需求性两种，以及诸如安全性、可测试性、性能、可靠性和可扩展性等其他方面。
上图中每个连接表示一个动作，并影响到连接结束的目标。
例如系统（System）将满足一个或多个任务（Mission）；环境（Environment，即上下文）将影响整个系统；一个关注点（Concern）对一个或多个项目干系人（Stakeholder）来说很重要；系统有一个架构（Architecture）。
架构描述
UML也是一种被认可的国际标准，即2005年发布的ISO/IEC 19501。UML类图可以用来表示类之间的关系；用例图可以用来表示使用场景；组件图可以用来说明系统中可以重用的部件（即组件），并更易于看出它与二进制文件之间的对应关系。对于某些情况，也可以使用顺序图来表示一些核心场景的工作流程。
通过对UML的一系列使用，即可对架构进行不同角度的描述，并抓住其核心部分。
另一种比较好的描述方法是IBM/Rational专有的4+1视图模型。这个模型定义了4种主要视图（类似于UML图表）
- 逻辑视图，用来描述组件。
- 流程视图，用来描述映射和依赖。
- 开发视图，用来描述类型。
- 物理视图，用来描述将系统映射至硬件的方法
第五个视图是场景视图，专门用于用例。
验证架构
怎么样来验证架构，也没有什么好的方法，唯一的方法就是测试--多种测试多个级别的测试。
因此可以用单元测试来验证单一的功能，用集成测试评估系统与其他系统/应用程序的兼容性。最终的验收测试则可以看出用户到底对程序的感觉如何，程序是否提供了必要的功能。
软件的需求和质量
系统的最终目标就是由一系列需求描述的，这些需求最终决定了系统的架构。
需求就是系统的一系列特质，既可以是功能性的，也可以是非功能性的。
功能性需求是指某种系统必须提供的行为，以便满足某个特定的场景，非功能性需求是指项目干系人明确要求的系统的某种属性。
ISO/IEC 9126标准给出了6大类质量特质，其中包含了21种详细特质。最主要的6大类特质包括
| 属性 | 描述 |
| 功能（Functionality） | 表示软件符合需求所必需的条件。功能基于诸如适用性、准确性、安全性、胡操作性等需求，并能满足必需的标准和规则。 |
| 可靠性（Reliability） | 表示软件在某些特定情况下满足指定级别性能的能力。可靠性诸如完备性、容错性和可恢复性等需求。 |
| 可用性（Usability) | 表示软件能够别用户理解、使用并吸引用户的能力。它要求软件必需满足可用性标准和规则。 |
| 有效性（Efficiency） | 表示软件提供特定级别性能的能力，需要考虑响应时间和资源占用等方面。 |
| 可维护性（Maintainability） | 表示软件支持修改（如更正、改进、改写)的能力。可维护性基于诸如可测试性、稳定性、可被分析、可被修改等需求。 |
| 可移植性（Portability） | 表示软件能够从一个平台迁移到另一个平台，以及在同一环境中与其他软件共存并共享资源的能力。 |
功能性需求
功能性需求是指系统需要做的事情，即系统需要为完成特定的任务和达到用户的目的提供哪些功能。通常而言，一个功能包括输入、行为和输出。需求必须要求做到
“清晰、正确、避免二义、明确可被检验的”。功能需求通常以用户故事或用例的形式描述。
非功能性需求
非功能性需求是指那些最终系统整体上的需求，但这些需求并不属于功能方面。
详细说明书
详细说明书可以有多种形式，例如，UML草图、word文档、Microsoft Visio图表甚至是可以使用原型系统等。
