Rational Rose是支持UML建模的强大的可视化工具。Rational Rose是个菜单驱动应用程序，它支持8种不同类型的UML框图：用例图、类图、时序图、协作图、状态图、活动图、组件图、分布图。Rose对不同框图都提供了不同的工具栏。
Rose界面的五大部分是浏览器、文档窗口、工具栏、框架窗口和日志：
①浏览器：用于在模型中迅速漫游。
②文档窗口：用于查看或更新模型元素的文档。
③工具栏：用于迅速访问常用命令。
④框架窗口：用户显示和编辑一个或几个UML框图。
⑤日志：用于查看错误消息和报告各个命令的结果。
在Rose的浏览器中有4个视图：UseCase视图、Logical视图、Component视图和Deployment视图。
1）UseCase视图
UseCase视图包括系统中所有的角色、用例图和用例模型图，还可能包括一些时序图和协作图。
UseCase视图是系统中与实现无关的视图，它关注于系统功能的高层形状，而不关注于系统的具体实现。
2）Logical视图
Logical视图关注系统如何实现用例中提出的功能，包括特定的类、类图、时序图、协作图、状态图等。
3）Component视图在Rose中，组件和组件图在Component视图中显示。
4）Deployment视图在Rose中，分布图在Deployment视图中显示。
1.3软件过程
1.3.1软件过程改进的目标
软件过程管理的核心是持续的软件过程改进（Software Process Improvement）。在建立了持续的过程改进环境的软件组织中，其软件开发过程是可控制的、可预测的、可度量的。在这样的软件组织中，定义好的软件过程被制度化、规范化，软件过程中的行为被文档化。这样的理想状态就是通过软件过程管理要实现的目标。
1.3.2软件过程管理的主要内容
软件过程管理的核心是持续的软件过程改进（Software Process Improvement）。而软件过程改进的第一步就是过程基础结构的建立（Establish Process Infrastructure）。这一步骤主要完成企业过程管理的基础性工作，包括获取管理者的支持，获取资金，创建软件过程工程小组（Software Engineering Process Group，SEPG）或者创建过程改进组（Process Improvement Team，PIT），进行任务职责的分配等工作。Sami Zahran指出软件过程改进的基础架构包含两部分主要内容：一是组织与管理方面的架构，也就前面所提到的软件过程改进过程中各类角色的定义及其职责的分配；二是技术方面的架构，主要是过程改进中各类工具的建立。
软件过程改进计划，也就是Planning of Process Implementation and Change。这一步包括过程管理的几个重要内容：过程定义（Process Definition）、过程度量（Process Measurement）和过程定性分析（Process Qualitative Analysis）。
过程定义（Process Definition），显然是整个过程改进的基础。整个组织的过程改进必须基于明确的过程定义，以方便员工的交流、过程改进的实施。过程可以在两个层次上加以定义：一个是在抽象层次上，从软件的开发过程的技术角度来定义，可以得到生命周期框架模型（Life Cycle Framework Model），也就是通常所说的软件生命周期。此外，在具体层次上，综合考虑软件工程管理方面的内容，可以得到各种软件生命周期过程模型（Software Life Cycle Process Model）。
在正式实施一个定义好的软件过程之前，企业或组织必须对现有的软件过程加以评估或者度量，以明确现有软件过程的优势及缺陷，并以此为基础定义新的软件过程。对于现有软件过程的定量数据的收集、整理、分析的过程就是这里的过程度量。对于现有软件过程的定性分析就是上面提到的过程定性分析。
当新的过程定义好之后，就进入了过程改进的实施阶段。也就是Process Implementation and Change阶段。在这一阶段，通常需要选择一些成熟的软件过程改进框架，作为企业过程改进的指南。SEI的能力成熟度模型CMM和国际化标准组织的ISO/IEC15504都是这样的过程改进模型。
过程度量（Process Measurement）是指当过程改进顺利完成之后，为了实现持续的过程改进，还有必要对现有的软件过程加以评估（Evaluation），以明确当前的软件过程的实际效果。CMM和ISO/IEC15504均提供了相应的评估模型。
1.4软件生命周期模型
软件生命周期模型，也就是前面说到的Life Cycle Framework Model。它是在较为抽象的级别对软件过程从技术角度加以定义的一种软件过程模型。这也就意味着真实的软件过程模型可能并非都能符合如此理想模型，很有可能是下面提到的典型软件生命周期的改进或者一定程度上的互相叠加。
下面介绍几种典型的软件生命周期模型。
1.4.1线性顺序模型（Linear Sequential Model）
线性顺序模型就是瀑布模型（Waterfall Model）。线性模型至少包括需求分析、软件设计、软件构造、软件测试、软件维护等阶段。它是最早提出的一种软件生命周期模型。这一模型的最根本特征就是严格线型。这里的线型有两层含义：一是相对螺旋模型而言的。螺旋模型本质上是一种迭代式的开发，而非线性开发。另一层含义是相对有反馈的线性模型而言。在有反馈的线性模型中，后续阶段中发现的问题都会直接反馈给前续阶段，以及时调整整个软件的分析设计，避免缺陷放大。这也就是说，严格的线性模型后继阶段无法把在其阶段的信息反馈给前续阶段。因而严格的线性模型要想得到有效地实施，必须基于确定的需求，详细而准确的设计，而且分析设计的结果必须严格文档化。所以有时又称其为基于文档（Document Based）的软件生命周期模型。
但现实中的软件过程不可能严格遵守线性化，或多或少我们会在分析、设计阶段犯下错误，而且随着企业环境的日益复杂，需求变更已经变成了一种常见现象，软件工程领域正在发起一场“Embrace Change”的革命。这就意味着，传统的线性模型是不符合实际的。因而用得比较多的可能是经过改进的线性模型，它是带反馈的，或者说是可回溯的线性模型，有时又称其为V模型。
V模型中，有两点值得注意。
①它将测试阶段细化，并将各测试阶段的结果直接反馈给前面的相应阶段。从该模型可以看出真实测试过程的开始与需求分析的结束，需求分析的结果就是用户验收测试或者系统测试的依据。
②它体现了V&；V策略。从分析到编程，每一个阶段结束后，都进行相应的检查（Review）。这里的Review就是Validation和Verification的过程。
1.4.2原型（Prototype）实现模型
在开发软件时，客户提的需求往往是比较抽象的商业目标，而不能确定具体的、详细的输入、处理、输出细节。对于一些非功能性的需求，如系统的响应时间、系统的可靠性要求，用户更是难以提出。由此，导致很多软件的开发风险极大。为此人们提出了原型，原型可能是最终系统的一个简单的实现，这种实现便于客户理解开发者实现的内容。通过这样一个原型，客户可以与开发者充分交流，以消除双方的误解。因此很大程度上原型是客户和开发者沟通的界面。
在理解了基础需求的基础上，就可以在较短的时间内快速设计，并实现一个简单的原型，然后对原型加以评价、提炼，最终将这一阶段的原型提交给客户确认。如果客户觉得还需要修改，则再次进入原型实现周期，也就是原型的迭代周期。否则，用户就得到比较满意的最终的产品。原型法有一个原型循环迭代周期，因而与线性模型相比，原型法一个典型的特征就是迭代。
1.4.3螺旋模型（Spiral Model）
螺旋模型是Boehm于1988年提出的。将原型实现的迭代特征与线性模型中的线性控制这两个方面结合起来，使得基于迭代的快速开发成为现实。螺旋模型从中心部分的环开始，每个环代表了一个迭代周期。在每个迭代周期，进行以下几类活动。
①Planning：在这一活动中，系统分析师分析项目所要实现的目标以及开发项目的一些限制性约束。
②RiskAnalysis：就是对整个项目进行风险分析，标识出最有风险的部分，并为之寻求相应的解决方案。在每个迭代的开始都进行风险分析，优先考虑风险最大的部分。这样做的目的显然是为了降低项目开发的风险，这也是Boehm提出螺旋模型的初衷。风险分析是螺旋模型最为典型的特征。
③Engineering：该阶段用于用户评估的原型的分析、设计、验证与实现。在不同的迭代周期，这一步骤的具体内容可能有所不同。越靠近里面的环，这部分的内容越靠近线性模型中前面的部分。越是靠近外面的环，这部分的内容越靠近线性模型中后面的部分。
④Customer Evaluation：是指客户对该迭代周期产生的产品的评价。用户对现有原型的意见又构成下一次迭代计划的依据，这样周而复始，就可以得到越来越贴近目标系统的原型，最后一次迭代的产品就是最终的产品。
1.5常见的软件工程过程模型
1.5.1CMM
软件能力成熟度模型（Capability Maturity Model For Software，SW—CMM），是由美国卡内基梅隆大学软件工程研究所（CMUSEI）研究出的一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。
虽然本书将CMM归为软件工程过程模型的一种，但CMM的含义却远远超出软件过程管理的内容。首先，CMM除了给出基于项目的软件过程的改进指导，更给出了对于组织整体的过程改进框架。其次，CMM是以动态的观点考察组织持续的软件过程改进，而并非只是针对某个项目。再次，CMM的实施过程不仅是过程管理技术的应用过程，更是优秀企业文化的建立过程。正是因为上述原因，在一个软件组织中实施以CMM为指导的过程改进，对该软件组织而言，可以说是一件全局的、艰巨的任务。所以很多时候又称CMM是一种重载软件过程模型（Heavy—weight Software Process Model）。
