运用RUP 4+1视图方法进行软件架构设计(zz)

https://www.ibm.com/developerworks/cn/rational/06/r-wenyu/index.html

https://www.ibm.com/developerworks/cn/rational/r-4p1-view/

 

呼唤架构设计的多重视图方法

灵感一闪，就想出了把大象放进冰箱的办法，这自然好。但希望每个架构设计策略都依靠灵感是不现实的--我们需要系统方法的指导。

需要架构设计的多重视图方法，从根本上来说是因为需求种类的复杂性所致。以工程领域的例子开道吧。比如设计一座跨江大桥：我们会考虑"连接南北的公路交通"这个"功能需求"，从而初步设计出理想化的桥墩支撑的公路桥方案；然后还要考虑造桥要面临的"约束条件"，这个约束条件可能是"不能影响万吨轮从桥下通过"，于是细化设计方案，规定桥墩的高度和桥墩之间的间距；另外还要顾及"大桥的使用期质量属性"，比如为了"能在湍急的江流中保持稳固"，可以把大桥桥墩深深地建在岩石层之上，和大地浑然一体；其实，"建造期间的质量属性"也很值得考虑，比如在大桥的设计过程中考虑"施工方便性"的一些措施。

和工程领域的功能需求、约束条件、使用期质量属性、建造期间的质量属性等类似，软件系统的需求种类也相当复杂，具体分类如图1所示。

图1 软件需求分类的复杂性

 

超市系统案例：理解需求种类的复杂性

例子是最好的老师。为了更好地理解软件需求种类的复杂性，我们来分析一个实际的例子。在表1中，我们列举了一个典型的超市系统的需求子集，从这个例子中可以清晰地看到需求可以分为两大类：功能需求和非功能需求。

表1 超市系统案例：理解需求种类的复杂性

简单而言，功能需求就是"软件有什么用，软件需要做什么"。同时，注意把握功能需求的层次性是软件需求的最佳实践。以该超市系统为例：

• 超市老板希望通过软件来"提高收银效率"。
• 那么，你可能需要为收银员提供一系列功能来促成这个目的，比如供收银员使用的"任意商品项可单独取消"功能有利于提供收银效率（笔者曾在超市有过被迫整单取消然后一车商品重新扫描收费的痛苦经历）。
• 而具体到这个超市系统，系统分析员可能会决定要提供的具体功能为：通过收银终端的按键组合，可以使收银过程从"逐项录入状态"进入"选择取消状态"，从而取消某项商品。

从上面的例子中我们还惊讶地发现，非功能需求--人们最经常忽视的一大类需求--包括的内容非常