当代架构师和架构
项目干系人
项目干系人的定义是所有对创建系统感兴趣或关注的人,包括系统的创建者(架构师、开发人员和测试人员)以及产品接受方、最终用户、
分析师、审计人员和首席信息官(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图表甚至是可以使用原型系统等。