4+1系统架构模型

本文转自CSDN

前言

本文参考IBM官方的软件架构模式，并参考UML视图建模，将软件架构视图—4+1模式进行了小结。关于每种视图的参考实例，会在随后继续补充进去。

架构模型

一、软件架构

软件架构概念：将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。用来处理软件高层次结构的设计和实施。

软件架构 ＝{元素，形式，关系/约束}

软件架构涉及到抽象、分解和组合、风格和美学。用由多个视图或视角组成的模型来描述软件架构，该方法称为多重视图方法。

使用多重视图的目的：

基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。

1、使用多重视图允许独立地处理各"风险承担人"：最终用户、开发人员、系统工程师、项目经理等所关注的问题，

2、并且能够独立地处理功能性和非功能性需求。

 

多重视图方法从根本上说是需求种类的复杂性所致。

 

二、需求背景

1、需求的三个层次

软件需求包括3个不同的层次――业务需求、用户需求和功能需求。

业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。

用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。 注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，