图 9. 将项目产品组织到定义完善的抽象层次中的 RUP 配置
• |
域。域层次捕获项目的业务环境。 | ||||||||||||
• |
项目洞察力。项目洞察力对系统将会有的对企业的业务影响进行通讯。它以投资回报分析量化了这个影响。项目洞察力表示该项目的最高抽象层次。 | ||||||||||||
• |
业务处理。系统层次为公司内的业务处理建模。对于极其复杂的单位来说,这个层次可以再细分到子层次:部门、部门间以及部门内。 | ||||||||||||
• |
UI 规范。UI 规范设计了实现业务处理的用户界面。它是由 UI 设计文档和功能 UI 原型组成的。 | ||||||||||||
• |
详细要求。详细要求指定了系统要求的最低层次抽象。它包括诸如数据类型格式和详细业务规则等详细信息。它还包括专业性要求,例如,性能、可用性、安全性、国际化、配置、可扩展性和灵活性要求等。 | ||||||||||||
• |
体系结构。系统的体系结构被组织到六个视图中:
|
优点
将系统产品组织到离散的抽象层次有若干优点:
• |
它将系统要求分离到三个不同的抽象层次:业务处理、UI 规范和详细要求。我们不会再用令企业用户感到不知所措的单个整体功能规范了。取而代之,我们在三个改进的详细层次中对系统要求进行通讯。 |
• |
分析师和架构师可以将复杂性控制在一个单一的、集成的系统模型中。 |
• |
架构师可以专注于系统的单个方面,并将那些决策集成到整个解决方案中。 |
• |
抽象层次形成了系统产品的结构。举例来说,软件体系结构文档为每个视图专设了一个小节。 |
• |
抽象层次提供从要求到设计再到实现的直接可跟踪能力。可跟踪能力使小组能够在评测更改请求时执行精确的影响评估。 |
• |
在使用同一框架开发几个系统之后,会在每个抽象层次形成模式。单位可以编录这些模式和每个抽象层次内的其他最佳实践。这个最佳实践的目录会作为过程改进计划的基础。 |
小结
为了处理复杂性,所有工程学科都应用正式抽象层次。软件也不例外。为了实现抽象层次的优点,项目必须:
• |
正式标识层次,每个层次都有定义完善的范围。 |
• |
将一个层次内的复杂性分开到多个视图。 |
• |
在层次间保持一致性。 |
通过一个简单的示例,本文演示了如何应用抽象层次,然后将该方法扩展到支持企业 IT 解决方案。它提供了一个 RUP 配置框架,该框架将系统产品组织到定义完善的抽象层次。
自我评估
• |
您当前的项目是否应用了抽象层次? |
• |
层次是否定义完善? |
• |
项目团队是否很好地理解了这些层次? |
• |
如果复杂性在一个层次中变得过大,团队是否将其分离到视图中呢? |
• |
团队是否在层次间保持一致性? |
• |
您的项目会从抽象层次中获益吗? |
伟大的架构师本能地遵循这些原则。我们其余的人就必须有意识地应用抽象层次,并运用规则在整个项目生命周期中保持这些层次。
文章来源于领测软件测试网 https://www.ltesting.net/