RUP简介以及常用模型
RUP
有时候用户需求难以捉摸，甚至连用户自己都理不清，RUP就提供了一系列模板方便我们快速地获取用户的需求。用户只需要像填写表格一样把公式化的内容填上，再套用对应的模板，建立一系列模型，就能快速地系统地开发。
为此RUP还定义了一些术语来通用的建模和描述业务。
1.1 什么叫迭代增量式iteration incrementation开发
将整个开发工作组织成一系列小的项目，被称为一系列迭代。根据用户反馈每个阶段可以再细化分解，并开始新的迭代。每个阶段都会经历完整的周期。
- 优点
- 可以应对不断变化的需求，降低风险
- 得到早期用户的反馈
- 每个阶段都有阶段性的中心
1.2 什么叫use case driven开发
通过测试来推动整个过程的开发，通过测试用例对功能和接口进行设计。
- 两个概念：
- use case (用例)，一个系统执行的一系列动作，它为一个特定的actor产生一个可观察的结果
- actor (参与者)，与系统外部和系统交互的人或物
考虑一个系统，actor表示与系统交互的对象，use case则表示这些交互的行为。
要实现的功能可以用一些用例来表示，例如，银行客户可以使用自动柜员机(ATM)取款、转账或检查帐户余额。这些功能可以用一组用例来表示。
收集的用例构成了系统所有可能的方法。用例的名称通常传达提供给参与者的值。
以ATM系统中取款为例
- 首先客户要插卡到ATM，系统会读取卡中的信息
- 系统提示用户输入密码以验证个人信息
- 系统给出操作选项，用户选择”取款”
- 系统选择取款金额，等待用户输入
- 系统连接网络，验证用户信息(密码、余额等)
- 系统询问是否需要打印收据
- 系统出款
- 如果要求打印收据，则还要打印收据
- 系统提示取出磁卡
当尝试用一套完整的流程描述系统的行为时，你就能快速意识到系统可能遇到的的许多情况
可以具体化需求，去除模棱两可的需求
1.3 什么叫4+1 view
RUP提出4+1 view模型用来描述整体架构。
每个视图只关心系统的一个方面，结合起来才能反应体系结构的全部内容。
- 逻辑视图logical view
- 设计的对象模型
- 着重描述系统的功能性需求，即这个系统能为它的最终用户做些什么。 逻辑视图是设计模型的抽象，确定了重要的设计包、子系统和类。
- 过程视图process view
- 捕捉设计的并发和同步特征
- 表述了系统在运行时的并发性——任务、线程、过程及它们之间的交互作用。 过程视图讨论了并发性和并行性、系统启动和关机、容错性和对象分布等问题，处理了如死锁、应答时间、吞吐量以及功能和故障的隔绝问题等。它主要关心系统的可升级性。
- 物理视图physical view
- 描述了软件到硬件的映射，反映了分布式特性
- 展示了不同的可执行程序和其他运行时间构件是如何映射到底层平台或计算节点上的。 它讨论了如实施、安装系统和系统性能等问题。
- 配置视图development view
- 描述了在开发环境中软件的静态组织结构
- 从打包、分层、配置管理(所有权、版本等)的角度描述了处于开发环境中的静态软件模型(源代码、数据文件、构件、可执行程序和其他伴随的制品)的组织结构。 着重讨论了如何使开发工作更简易，以及如何管理软件资产、重用、转包合同和现成的构件。
- 用例use case view
- 用于联系/说明以上4个视图
- 包含几个关键情景或者用例。这个视图在初始和细化阶段用来驱动构架的挖掘和设计，之后将被用于验证不同的视图。 这几个为数不多的情景在软件构架文档中用来阐明其他视图是如何工作的。
1.4 什么叫architecture centric开发
以架构为中心开发
模型是对现实的简化，能够帮我们掌握一个复杂系统，能帮助我们理解和提出问题和解决方案。一个模型未必能覆盖系统的方方面面，因此我们需要不同模型来解决不同的问题。
架构是可以描述一个系统工作的最简模型，所谓最简就是不能在剔除任何东西。
我们需要搭建一个架构来在有限的时间空间内描述一个系统，以便你的同事：如设计师、开发者、管理员、甲方等能够快速了解系统的功能、工作原理、可复用性等。
- 两个基本的RUP工件
- The software architecture description (SAD)。描述项目的架构
- 架构原型，用于验证架构并作为其他部分的基线
- 以上述两个工件为基础的三个扩展
- 设计指南要取决于架构的选择并反映一些模式和习惯用法
- 开发环境中的产品结构要基于实现视图(implementation view)
- 团队要结构要基于实现
所谓实现视图，就是从不同角度对一个系统的描述。就像拍照从各个方向拍才能完整全面的展示一个事物。实现视图的一般组织形式为一个个文件夹，每个文件夹都是对一个方面
架构设计不单由架构师一人完成，许多团队成员都参与架构的定义和实现，尤其是在精化阶段。可做如下分工
- 设计人员重点关注类和机制，而不是类的细节
- 集成者(Integrators)集成主要的软件，实现他们的注意功能，验证接口
- 分块开发的东西重要有人来合成吧
- 测试人员测试架构的性能和健壮性
在构建阶段，重点转移到向架构骨架添加内容上。活动反映出对架构的持续关注:调优它、细化它，并确保没有引入新的设计决策削弱或破坏它
为什么要以架构为中心，首先是一个项目多人开发，要合理的分配工作首先要能很好地将系统个各个部门描述。使用架构为中心的方式，就能在有限的时间空间内描述整个系统。
其次，一个大系统会存在很多依赖关系，如果不理清依赖关系，到后期才发现对不上号将会造成巨大的损伤。以架构为中心能把帮助我们理清整体地依赖关系。