UML及rose教程

       

在面向对象无孔不入的今天，利用对象的思想为软件系统建模，已经成为软件开发的主要工作，而传统的编码工作却“退居二线”了。一个系统的模型建的好，就为满足用户需求、保证系统的稳定性和质量、提高系统的扩展性打下了良好的基础。

UML和Rational ROSE,是一个面向对象建模的语言和工具。 UML，Unified Modeling Language，统一建模语言，是一种面向对象的建模语言，它的主要作用是帮助我们对软件系统进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。UML通过建立各种类、类之间的关联、类/对象怎样相互配合实现系统的动态行为等成分（这些都称为模型元素）来组建整个模型，刻画客观世界。UML提供了各种图形，比如Use Case图、类图、对象图、顺序图、协作图、状态图（共五类10种图）等，来把这些模型元素及其关系可视化，让人们可以清楚容易的理解模型。我们可以从多个视角来考察模型，从而更加全面的了解模型，这样同一个模型元素可能会出现在多个图中，对应多个图形元素。

和 Rational ROSE ,是一个面向对象建模的语言和工具。 UML ， Unified Modeling Language ，统一建模语言，是一种面向对象的建模语言，它的主要作用是帮助我们对软件系统进行面向对象的描述和建模，它可以描述这个软件开发过程从需求分析直到实现和测试的全过程。 UML 通过建立各种类、类之间的关联、类 / 对象怎样相互配合实现系统的动态行为等成分（这些都称为模型元素）来组建整个模型，刻画客观世界。 UML 提供了各种图形，比如 Use Case 图、类图、对象图、顺序图、协作图、状态图（共五类10种图）等，来把这些模型元素及其关系可视化，让人们可以清楚容易的理解模型。我们可以从多个视角来考察模型，从而更加全面的了解模型，这样同一个模型元素可能会出现在多个图中，对应多个图形元素。

ROSE是美国Rational公司的面向对象建模工具，利用这个工具，我们可以建立用UML描述的软件系统的模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。

是美国 Rational 公司的面向对象建模工具， 利用这个工具，我们可以建立用 UML 描述的软件系统的模型，而且可以自动生成和维护 C++ 、 Java 、 VB 、 Oracle 等语言和系统的代码。

ROSE的界面分为三个部分Browser窗口、Diagram窗口和Document窗口。Browser窗口用来浏览、创建、删除和修改模型中的模型元素；Diagram窗口用来显示和创作模型的各种图；而Document窗口则是用来显示和书写各个模型元素的文档注释。

如果你想要建造一个软件系统，首先必须先搞清楚用户需求，也就是你的软件系统的功能是什么。这是一切开发的基础。有了需求，接下来的工作就是分析系统的静态结构，看看要实现这些功能，我们的系统中必须要由哪些东西。系统的大体结构定下来之后，就要看这些系统成分是怎样相互配合实现系统功能（即系统的动态结构）的，同时还必须考虑与实现环境有关的细节，比如用什么语言啦，在什么操作系统上转啦，等等，这个工作，就是设计。设计工作细化到一定程度，就可以编码实现了。而最后的工作，毫无疑问，就是测试和维护。总之，这个顺序大体上就是“功能静态结构动态结构编码测试维护”。

我们通过一个简单的例子来浏览一下UML这种语言在软件系统建造的全过程中所起的作用，并初步了解一下ROSE的用法。

首先是用户需求，系统功能。

我们的例子其实很简单，它是一个ToDo（待办事宜）表的维护工具，可以为用户创建、删除和管理ToDo信息。ToDo表的信息存贮在文件系统中。

对于这样一个需求，应该怎样用UML来描述呢？

首先，我们需要识别系统的用户和相关的外部系统，在UML中，它们被称为Actor（角色）。识别Actor是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个Actor：ToDo User（系统的用户） 和 FileSystem（相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

的界面分为三个部分 Browser 窗口、 Diagram 窗口和 Document 窗口。 Browser 窗口用来浏览、创建、删除和修改模型中的模型元素； Diagram 窗口用来显示和创作模型的各种图；而 Document 窗口则是用来显示和书写各个模型元素的文档注释。

如果你想要建造一个软件系统，首先必须先搞清楚用户需求，也就是你的软件系统的功能是什么。这是一切开发的基础。有了需求，接下来的工作就是分析系统的静态结构，看看要实现这些功能，我们的系统中必须要由哪些东西。系统的大体结构定下来之后，就要看这些系统成分是怎样相互配合实现系统功能（即系统的动态结构）的，同时还必须考虑与实现环境有关的细节，比如用什么语言啦，在什么操作系统上转啦，等等，这个工作，就是设计。设计工作细化到一定程度，就可以编码实现了。而最后的工作，毫无疑问，就是测试和维护。总之，这个顺序大体上就是“功能静态结构动态结构编码测试维护”。

我们通过一个简单的例子来浏览一下UML这种语言在软件系统建造的全过程中所起的作用，并初步了解一下ROSE的用法。

首先是用户需求，系统功能。

我们的例子其实很简单，它是一个ToDo（待办事宜）表的维护工具，可以为用户创建、删除和管理ToDo信息。ToDo表的信息存贮在文件系统中。

对于这样一个需求，应该怎样用UML来描述呢？

首先，我们需要识别系统的用户和相关的外部系统，在UML中，它们被称为Actor（角色）。识别Actor是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个Actor：ToDo User（系统的用户） 和 FileSystem（相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

UML 这种语言在软件系统建造的全过程中所起的作用，并初步了解一下 ROSE 的用法。

首先是用户需求，系统功能。

我们的例子其实很简单，它是一个ToDo（待办事宜）表的维护工具，可以为用户创建、删除和管理ToDo信息。ToDo表的信息存贮在文件系统中。

对于这样一个需求，应该怎样用UML来描述呢？

首先，我们需要识别系统的用户和相关的外部系统，在UML中，它们被称为Actor（角色）。识别Actor是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个Actor：ToDo User（系统的用户） 和 FileSystem（相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

ToDo （待办事宜）表的维护工具，可以为用户创建、删除和管理 ToDo 信息。 ToDo 表的信息存贮在文件系统中。

对于这样一个需求，应该怎样用UML来描述呢？

首先，我们需要识别系统的用户和相关的外部系统，在UML中，它们被称为Actor（角色）。识别Actor是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个Actor：ToDo User（系统的用户） 和 FileSystem（相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

UML 来描述呢？

首先，我们需要识别系统的用户和相关的外部系统，在UML中，它们被称为Actor（角色）。识别Actor是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个Actor：ToDo User（系统的用户） 和 FileSystem（相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

UML 中，它们被称为 Actor （角色）。识别 Actor 是很重要的，它可以帮助我们界定软件系统的边界，引导我们发掘用户的需求，辅助我们设计用户界面等等，是需求分析阶段的第一步。对于我们这个简单例子，有两个 Actor ： ToDo User （系统的用户） 和 FileSystem （相关外部系统）。

接下来，针对每个Actor，我们开始分析系统的Use Case。Use Case是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

Actor ，我们开始分析系统的 Use Case 。 Use Case 是一个 UML 中非常重要的概念，在使用 UML 的整个软件开发过程中， Use Case 处于一个中心地位。

那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

Use Case 呢？在 UML 的文档中， Use Case 的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实 Use Case 就是对系统功能的描述而已，不过一个 Use Case 描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。

在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

UML 的开发过程中，需求是用 Use Case 来表达的，界面是在 Use Case 的辅助下设计的，很多类是根据 Use Case 来发现的，测试实例是根据 Use Case 来生成的，包括整个开发的管理和任务分配，也是依据 Use Case 来组织的。啊， Use Case ，简直太重要了！

对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭头来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

Actor 来说，他都要使用系统的某项功能，所以我们识别和分析 Use Case 是，要对于每个 Actor 来逐个进行。对于 ToDo User ，我们可以轻易的识别出两个 Use Case ： Add Task 和 Remove Task 。 ToDo User 主动使用这两个 Use Case 所描述的系统功能，所以在我们的 Use Case 图上， ToDo User 和这两个 Use Case 的关系是用从 ToDo User 发出的箭头来表示的。对于 FileSystem ，我们识别出的也是同样的两个 Use Case ，不过这次箭头从 Use Case 指向 FileSystem ，表示 FileSystem 是被动的。

Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（？？？），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）。

静态结构分析

通过分析Use Case和问题域，我们得到了类。现在我们要分析这些类的属性、操作和它们之间的关系，即系统的静态结构。属性就是对象必须要存贮的信息，而类的操作，则可以通过顺序图中向对象发送的消息来识别。我们重点看一看类之间的关联。系统的静态结构主要用类图来表示。在类图中，类用一个方框来表示，这个方框用横线分为三个部分，第一部分是类的名字，第二部分是类的属性，第三部分是类的操作。类之间的关联用一条连接类方框的横线来表示。一端有箭头的的横线表示单向关联，没有箭头的表示双向关联。对类之间关联的良好分析对以后的实现和扩充都有非常大的帮助。

逻辑上相关的类可以被封装成包，这为我们组织和管理所开发的系统以及开发过程提供了一个很好的手段。大家在我们这个例子的类图上可以看到几个包。

面向对象软件工程的一个很大的好处就是在分析和设计之间没有什么明显的区别，更不会有传统软件工程中在分析和设计之间的语义上的鸿沟。在分析进行到一定程度时，把具体实现环境的因素考虑进来，就自然过渡到了设计阶段。由于我们的小例子使用文件系统存贮ToDo表的信息，所以我们需要一个CFile类来封装文件系统的功能和操作。

至此，我们的小例子的静态结构分析和设计已经有了初步的成果。接下来，可以根据这些成果分析和设计系统的动态结构。这包括细化和修改Use Case的描述，比如把类的操作和对象之间的消息相对应、充填参数等等，还有为比较复杂的类设计状态图等工作。

因为这个例子比较简单，没有什么比较复杂的类，所以没有必要设计状态图，只需要细化一下Use Case的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（？？？），也可以用各种图示。在 UML 中，通常用两种图来描述 Use Case ，它们就是顺序图（ Sequence Diagram ）和协作图（ Collaboration Diagram ）。

静态结构分析

通过分析Use Case和问题域，我们得到了类。现在我们要分析这些类的属性、操作和它们之间的关系，即系统的静态结构。属性就是对象必须要存贮的信息，而类的操作，则可以通过顺序图中向对象发送的消息来识别。我们重点看一看类之间的关联。系统的静态结构主要用类图来表示。在类图中，类用一个方框来表示，这个方框用横线分为三个部分，第一部分是类的名字，第二部分是类的属性，第三部分是类的操作。类之间的关联用一条连接类方框的横线来表示。一端有箭头的的横线表示单向关联，没有箭头的表示双向关联。对类之间关联的良好分析对以后的实现和扩充都有非常大的帮助。

逻辑上相关的类可以被封装成包，这为我们组织和管理所开发的系统以及开发过程提供了一个很好的手段。大家在我们这个例子的类图上可以看到几个包。

面向对象软件工程的一个很大的好处就是在分析和设计之间没有什么明显的区别，更不会有传统软件工程中在分析和设计之间的语义上的鸿沟。在分析进行到一定程度时，把具体实现环境的因素考虑进来，就自然过渡到了设计阶段。由于我们的小例子使用文件系统存贮ToDo表的信息，所以我们需要一个CFile类来封装文件系统的功能和操作。

至此，我们的小例子的静态结构分析和设计已经有了初步的成果。接下来，可以根据这些成果分析和设计系统的动态结构。这包括细化和修改Use Case的描述，比如把类的操作和对象之间的消息相对应、充填参数等等，还有为比较复杂的类设计状态图等工作。

因为这个例子比较简单，没有什么比较复杂的类，所以没有必要设计状态图，只需要细化一下Use Case的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Use Case 和问题域，我们得到了类。现在我们要分析这些类的属性、操作和它们之间的关系，即系统的静态结构。属性就是对象必须要存贮的信息，而类的操作，则可以通过顺序图中向对象发送的消息来识别。我们重点看一看类之间的关联。系统的静态结构主要用类图来表示。在类图中，类用一个方框来表示，这个方框用横线分为三个部分，第一部分是类的名字，第二部分是类的属性，第三部分是类的操作。类之间的关联用一条连接类方框的横线来表示。一端有箭头的的横线表示单向关联，没有箭头的表示双向关联。对类之间关联的良好分析对以后的实现和扩充都有非常大的帮助。

逻辑上相关的类可以被封装成包，这为我们组织和管理所开发的系统以及开发过程提供了一个很好的手段。大家在我们这个例子的类图上可以看到几个包。

面向对象软件工程的一个很大的好处就是在分析和设计之间没有什么明显的区别，更不会有传统软件工程中在分析和设计之间的语义上的鸿沟。在分析进行到一定程度时，把具体实现环境的因素考虑进来，就自然过渡到了设计阶段。由于我们的小例子使用文件系统存贮ToDo表的信息，所以我们需要一个CFile类来封装文件系统的功能和操作。

至此，我们的小例子的静态结构分析和设计已经有了初步的成果。接下来，可以根据这些成果分析和设计系统的动态结构。这包括细化和修改Use Case的描述，比如把类的操作和对象之间的消息相对应、充填参数等等，还有为比较复杂的类设计状态图等工作。

因为这个例子比较简单，没有什么比较复杂的类，所以没有必要设计状态图，只需要细化一下Use Case的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

ToDo 表的信息，所以我们需要一个 CFile 类来封装文件系统的功能和操作。

至此，我们的小例子的静态结构分析和设计已经有了初步的成果。接下来，可以根据这些成果分析和设计系统的动态结构。这包括细化和修改Use Case的描述，比如把类的操作和对象之间的消息相对应、充填参数等等，还有为比较复杂的类设计状态图等工作。

因为这个例子比较简单，没有什么比较复杂的类，所以没有必要设计状态图，只需要细化一下Use Case的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Use Case 的描述，比如把类的操作和对象之间的消息相对应、充填参数等等，还有为比较复杂的类设计状态图等工作。

因为这个例子比较简单，没有什么比较复杂的类，所以没有必要设计状态图，只需要细化一下Use Case的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Use Case 的顺序图就可以了。

这些分析和设计的工作经常是相互影响和促进的。你常常会在分析动态结构的时候，发现漏掉了一个类、一个属性，或者需要加上一个操作；而随着对静态结构的进一步深入刻画，对类之间的关联、消息传递的设计也会不断发生变化。所以我们要不断的对设计方案进行深化和细化，直到达到一个稳定的状态，这时我们就可以考虑系统的实现了。

实现模型

在实现模型中，我们定义一些组成软件系统的部件，比如DLL库啦，EXE文件啦，Java Applet啦，ActiveX Control啦，Web页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的EXE文件ToDoList。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

DLL 库啦， EXE 文件啦， Java Applet 啦， ActiveX Control 啦， Web 页面啦等等。定义这些部件和它们之间的关系，对代码的自动生成、软件系统的配置、测试管理、软件的打包发行等等都有很大的好处。对于我们这个小例子，只有一个部件最终的 EXE 文件 ToDoList 。

在ROSE中的Component View包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

ROSE 中的 Component View 包中，我们创建这个部件。然后可以将各个类拖动到这个部件上，这表示这些类最终是用这个部件实现的。

做完了所有这些活，我们就可以自动生成代码了！ROSE可以自动生成C++、Java、CORBA IDL、Visual Basic、Visual C++、Oracle Schema等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

ROSE 可以自动生成 C++ 、 Java 、 CORBA IDL 、 Visual Basic 、 Visual C++ 、 Oracle Schema 等等不同语言和系统的代码，并且可以进行“双向工程”模型和代码之间的双向转换，大大减轻了代码书写的工作。可是代码生成内容很多，已经不是我们这个简单的教程所能包容的了。

顺序图和协作图

从面向对象的角度来看，系统的功能是由一组对象通过相互发送消息来完成的，顺序图和协作图就是通过描述这样的对象和消息来描述系统的动态行为的。我们先用一个顺序图来描述Use Case AddTask。AddTask的功能是向ToDo表中加入一个Task项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Use Case AddTask 。 AddTask 的功能是向 ToDo 表中加入一个 Task 项，它的步骤应该是：

打开加入Task项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Task 项的窗口；

输入相应信息；

生成一个Task对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Task 对象；

把这个Task加入到Task表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Task 加入到 Task 表中。

那么，我们的顺序图就可以画成：

图中，方块表示一个对象，方块中的文字中冒号之前的部分是对象的名字，冒号之后的是对象所属的类的名字。方块下面的竖直虚线是对象的生命线，表示对象按照从上到下的时间轴的在某段时间内存在。对象间的箭头表示对象之间的消息通讯。而那些狭长的长方块表示某个操作方法执行的时间和调用关系。

顺序图有一个孪生兄弟协作图，AddTask的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

AddTask 的协作图是这样的。这两种图描述的其实是同一种东西，即实现某种系统功能的一组对象和它们之间的消息传递。不过在顺序图中，时间是作为一个显式的因素出现的，这是的顺序图在构造实时系统时特别有用。而在协作图中，没有显式的时间因素，但是对象之间的关联是一目了然的，这对我们在一组相互关联的对象的语境中考察它们的消息传递是很有帮助的。顺序图和协作图是对同一事物的不同角度的考察。

我们从Use Case自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个Task对象，相应的就得有一个Task类，类似的，Tasks这个用来管理和组织Task的集合对象也是必须的。Great!现在你看到Use Case和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了Use Case的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析Use Case，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析Use Case，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。

Use Case 自然语言的描述得到了它的顺序图，从顺序图中我们可以发现许多类。你瞧，我们有一个窗口，所以需要有一个对应的窗口类；我们有一个 Task 对象，相应的就得有一个 Task 类，类似的， Tasks 这个用来管理和组织 Task 的集合对象也是必须的。 Great! 现在你看到 Use Case 和顺序图对识别和发现类的作用了吧！在传统的面向对象分析中，类的识别是靠分析人员的经验和灵感来进行的，这太难以把握了。现在有了 Use Case 的概念，就可以为对象和类的识别提供一个有力的线索和支点。通过分析 Use Case ，构造它的顺序图描述，再加上传统的对问题域中的对象和类的考察，可以发现大多数和系统相关的类。面向对象分析中最重要也是最困难的识别和分析类的工作再也不是一种神秘的法术了，现在人人都可以胜任这个活儿了。经过识别和分析 Use Case ，我们的需求分析工作可以告一段落了。现在我们着手分析系统的静态结构就是类的分析和设计。