在软件工程的全部实施过程中都采用模型的方式而非文字的表达方式来进行描述，这样的实现过程称之为全程建模。全 程建模的特点是：模型相互之间是有关联的，模型成为软件工程过程各阶段展现的主体而不是文字描述作为主体存在。通过建模的方式将原来纯文字加图形描述的各 种文档模型化，使得从需求到代码能够统一起来，实现需求的变动直接影响到代码的变化。提高代码对需求的有效性联系，同时，解决过去经常出现的：编码改动， 文档就失效的问题。

软件建模方法有很多种，至今为止最广泛使用的是UML。UML是 Unified Modeling Language，统一建模语言，主要由Booch、Rumbaugh及Jacobson三人提出，他们三人把自己分 别提出的建模方法Booch、OMT、OOSE融合为一种方法称为UML。Booch在 《The Unified Modeling Language User Guide》中对UML的定义是“UML是对软件密集型系统中的制品进行可视 化、详述、构造和文档化的语言”。可以简单的理解UML是软件建模的一种语言，它的特色是使用图形化的方法来进行软件建模。UML的特点如下：统一的标 准，UML已经被OMG接受为标准的建模语言，而且越来越多的开发人员使用ULM语言进行开发；UML是支持面向对象技术的建模语言；可视化、表示能力强 大；独立于过程，UML不依赖于特定的软件开发过程；概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用。

UML能够用来为系统进 行面向对象建模，但是并没有指定应用UML的过程，它仅仅是一种语言，它是独立于任何过程的。如果想要成功的应用UML一个好的过程是必要的。合理的过程 能够有效的测度工作进度，控制和改善工作效率。RUP是一个很好的软件过程，它的核心就是解决可操作性的问题，可以帮助开发人员完成使用UML全程建模的 问题。RUP虽好，但是RUP十分庞大对于一些小的项目实施起来比较困难。所以有很多人一直在探讨敏捷建模的方法。本人参考了RUP、青润的《软件工程
之 全程建模实现》及尤克滨的《UML应用建模实践过程》并结合自己的工作经验形成敏捷建模的过程，在此将它分享出来，希望对大家有所帮助，另外也希望大家多 提包括意见，让我成长。这个过程应用在以前我参与的一个软件项目开发过程中，为了方便表达将该系统称为A系统。下面的内容包括5节：需求模型、分析模型、 设计模型、物理架构模型、代码导出。由于内容太长将分几次上传。

1 需求模型

1.1 用例模型

1. 用例及用例图

用 例是一个角色使用系统的某项功能时交互过程的文字描述。用例的本质是系统中各个相关人员之间就系统的行为所达成的契约，是系统的功能性需求。用例从使用系 统的角度描述系统中的信息，即站在系统外部观看系统的功能，而不考虑系统内部对该功能的具体实现方式。用例描述了用户提出的一些可能需求，对应一个具体的 用户目标，用例可以促进与用户沟通、理解正确的需求，同时也可以用来划分系统与外部实体的界限，是面向对象系统设计的起点，是类、对象、操作的来源。用例 图主要用于描述拟建系统和外部环境的关系。用例图中主要包括用例、角色及用例间的关系。用例间的关系通常有包含、范化、扩展。

如何实现用例模型呢？用例图包括角色、系统边界、用例以及元素间的关联。首先识别出角色，根据角色再识别用例。建立用例模型的主要工作：找出角色；找出用例；描述用例；用例间的关系处理；验证模型，通过这样的一些步骤就可以建立用例模型。

2. 识别角色

角色不仅仅是使用系统的用户也可以是硬件、外部系统等等。角色应该和系统具有交互行为，即角色向用例发送消息或者接收用例反馈的消息。角色之间存在继承关系。通过回答以下6个问题来识别A系统的角色：

（1）谁使用系统的主要功能。 回答：质监人员。

（2）谁需要系统的支持以完成日常工作。 回答：质监人员。

（3）谁负责维护、管理并保持系统正常运行。 回答：质量监督结构的管理员。

（4）系统需要应付哪些设备。 回答：不需要。

（5）系统需要和哪些外部系统交互。 回答：无。

（6）谁或什么对系统运行结果感兴趣。 回答：质监人员。

综上所述我们分析出来的A系统角色有质监人员、管理员。

3. 识别用例

识别用例时由于角色已经识别出来，所以我们主要根据角色来识别用例，识别用例的人为因素很大，不同的人针对同一个需求识别出的用例不一定是相同的，用例识别和经验关系很大。我们以角色“管理员”为例，根据这个角色来识别相关的用例。

（1）某个角色要求系统为其提供什么功能？该角色需要做哪些工作？ 回答：管理员登录软件以后主要进行用户管理。另外系统的新建数据库、连接数据库这些工作也主要由管理员来做。

（2）角色需要阅读、创建、销毁、更新或存储系统中某些信息吗？ 回答：管理员需要创建、删除、修改用户信息，进行用户管理。

将这个角色涉及到的用例进行分析得到和这个角色相关的用例：管理用户、选择数据库、建立数据库、登录。采用类似的方法还可以分析出系统的其他用例。

4. 用例图

通过上面的分析我们获得初步的用例图。我们还需要对用例进行拆分或合并。根据以上分析的结果绘制该软件的用例图。软件的用例图如图1所示。

图1 用例图

1.2 用例描述

用 例描述是通过文字语言描述用户的实际需求，用例采用自然语言描述角色和系统进行交互时双方的行为，不追求形式化的语言。用例描述没有一个统一的标准，但一 般应该包括以下的内容：用例的目的；用例是怎样启动的；角色和用例之间的消息是如何传送的；用例中除了主要路径外，其他路径是什么；用例结束后系统的状 态；其他需要描述的内容。表1是一个用例描述的示例。

表1 “选择建设项目”用例描述

用例名称：
    
选择建设项目

综述：

所有建设项目的数据保存在同一个数据库中，当用户登录后需要选择某个建设项目或者新建建设项目。

前置条件：
    
登录成功，打算对某个项目进行操作

后置条件：
    
进入软件主界面

基本操作流：
    
1、 系统提供已有建设项目供用户选择。

2、 用户从系统提供的项目列表中选中某个建设项目。

3、 系统对当前选中的建设项目进行标识，进入主界面。

可选操作流：

可选流1：

1、系统提供查询条件，查询条件包括公里等级、项目名称。

2、用户输入查询条件

3、系统提供满足条件的项目，如果用户没有输入系统提示，并不进行查询操作。

4、 用户选中建设项目。

5、 系统对当前选中的建设项目进行标识，进入主界面。

可选流2：

1、 用户选择建设项目的界面上提供新建建设项目功能。

2、 系统提供新建建设项目页面

3、 用户输入建设项目信息

3、系统导航到新建建设项目界面

1.3界面建模

在 青润的《软件工程之全程建模实现》一文中提出将界面设计作为需要分析阶段的一项工作。我以前也曾在需求分析阶段进行了界面建模，并用界面模型和用户进行交 流，取得了良好的效果。界面建模是需求工作中重要的步骤，同时又属于设计工作的内容，所有很多人在争论界面建模应该在什么时间开始。我很赞同做将界面建模 放在需求分析阶段，一方面软件界面的需求也是用户需求的一部分，另一方面使用界面模型和用户交流系统的功能需求直观、明确，用户很容易理解。界面就结合自 己以前开发的一个项目谈谈软件界面建模的事情。

1、界面设计的基本要求

    * 界面设计要完整的体现出用户需求的表现形式。
    * 界面设计要美观大方，一般来说界面设计的结果要符合用户群的习惯、感官、感觉。
    * 界面设计中的交互操作过程要符合用户习惯性的工作过程。

2、界面建模的主要工作

首先确定界面元素，通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等等。对用户工作 效率有明显影响的元素包括：输入输出方式、交互方式、功能分布。界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。 本项目的这个部分的工作由界面设计人员和美工协同完成，并且以界面设计规范的形式确定下来。

再次要通过对软件的背景，使用的行业特点、用 户的使用水平、喜好等方面的了解提出针对用户的一些设计。考虑到本系统的用户为公路行业，计算机应用水平比较低，所以很多部分力求简洁、明了，尽量提供用 户操作、使用上的方便，很多地方尽量模拟用户的手工操作，符合他们的使用习惯。比如在功能布局上以工作流的方式来进行功能布局，这样用户很清楚做完了这个 工作下一步应该怎样做。另外我们专门设计数据录入界面完全和用户实际工作中的表格相同。

最后建立用户界面模型，并且同用户进行交互。这个 工作对于界面建模是很重要的，因为用户对于功能的需求相对是比较明确的，对于界面方面的需求却比较模糊，但是当一个系统展现在他们面前的时候，他们却有很 多的要求和想法，通过这个工作可以将用户对界面的需求挖掘出来，而且也比较容易暴露设计中的缺陷。我们在设计完界面模型之后请用户参与了我们的评审会，之 后根据用户的意见进行了界面模型的修改。

3、建模工具

我选择Visio作为界面建模工具。Visio是微软的一个图表绘 制软件。Visio的模具中提供了Windows界面元素和各种标注元素，能够使我们很方便地建立Windows用户界面模型。另外，Visio还提供了 比较好的发布功能允许我们将Visio文档发布为网页格式。由于UML对界面建模支持的不好，所以使用UML建模工具进行界面建模比较难。

4、界面模型示例

这 个系统使用Visio来表达界面元素的布局、功能分布、交互方式等，对于不能在该模型中表达的某些内容（比如字体的大小等）用界面设计规范来表达。我们使 用该模型在前期阶段和用户进行交流，帮助测试人员了解系统功能。在后期阶段将界面层对业务层的调用叠加在界面模型中，也就是在界面模型上指明在什么情况下 调用哪个对象的什么方法来实现用户的请求，从而指导开发人员构筑系统。这样做，在某些方面和UML的动态建模机制有异曲同工之妙，而且更加直观有效。

2 分析模型

分析是一个十分关键的过程，它是把需求转化为代码实现的中间阶段。软件分析是将自然语言表达的软件需求进一步进行解析的过程。软件设计就是从分析到软件实现的过程。

2.1 架构设计

1. 分层架构

架构设计决定了各子系统如何组织以及如何协调工作。架构设计的好坏影响到软件的好坏，系统越大越是这样。在分解复杂的软件系统时，经常使用的一种架构技术就 是分层。分层架构中最困难的问题就是决定建立哪些层以及每层的职责。分层结构的好处主要有：不需要去了解层的实现细节；可以使用另一种技术来改变基础的 层，而不会影响上层的应用；可以减少不同层之间的依赖；容易制定出层标准；底下的层可以用来建立顶上层的多项服务；分层有利于标准化工作的执行。分层只是 将系统各种逻辑进行更有效的组织。分层架构的缺陷也不容忽视，层次不能封装所有东西，有时候会带来级联修改；过多的层间数据传递会影响性能。

2. 两层结构与三层结构

在分层结构中比较常用的有两层结构和以三层结构为代表的多层结构。基于二层架构的应用通常称为Client/Server应用。很多情况下服务器提供的服务 仅仅是数据库服务。在这种模式中客户端负责访问数据，完成业务逻辑处理、接收用户的输入及将结果向用户展示。二层体系结构的主要不利之处是其业务逻辑没有 从表示逻辑中分离开来，程序员很难在二层结构的应用中清楚地将业务逻辑从表示逻辑中分割出来，这样就很难维护、改进，可扩展性差，也很难重用。

三层体系结构以传统客户服务器模式为基础，将客户程序和数据库服务器的功能进一步分解，客户程序仅根据需要提出数据请求，数据库服务器也仅负责与数据存储、 完整性控制等有关的任务，而数据加工、处理等业务逻辑，交于另一个独立的部分来完成，这样不仅减轻了服务器的负担，也使前台客户程序更加独立，仅注重于与 操作人员的交互和数据的单一处理，形成了表示层、业务层、以及数据层三层结构，其中业务层也称为中间层，执行中间层任务的计算机称为应用程序服务器。

与传统的两层结构相比，三层最大的特征是将业务层独立了出来，从而提高了业务层的可复用性。在两层结构中，用户界面和业务处理流程放在一起，因此无法直接复 用业务处理的相关功能，也无法将业务处理功能进行灵活的部署。在三层结构中，表示层只处理用户界面相关的功能，主要处理用户和软件的交互，表示层主要有 Windows图形界面和基于Web的界面，主要职责就是为用户提供信息，以及把用户的指令传送给业务层。业务层复杂处理业务流程，是三层结构中最重要的 一层，可以对业务层进行灵活的部署，开发时也便于业务处理的开发和用户界面的开发同时进行。针对于信息系，数据层的最大的逻辑就是存储持久数据。

三层结构的优点如下：减少客户机的维护量，因为前台程序比较简单；把企业逻辑封装在通用的中间件应用服务器中，不同的客户都可以共享同一个中间层，而不必每 个客户都单独实现企业规则，避免了重复开发和维护的麻烦。由于客户程序相当瘦，无论是开发还是发布，都变得简单了。便于升级，当中间件升级的时候，客户程 序可能不需要变化；实现了分布式数据处理，把一个应用程序分布在几台机器上运行，可以提高应用程序的性能，也可以把敏感部分封装在中间件，为不同的用户设 置不同的访问权限，增强了安全性。

3. 本软件架构设计

在上述的二层结构和三层结构中，三层结构具有明显的优势，能很好 的实现业务与界面的分离，在一定程度上实现了重用和松耦合。本软件的结构在三层架构的基础上继续改进，如图2所示。表示层采用Windows界面，主要是 结合用户的使用习惯及本项目开发人员的技能综合考虑。数据库采用微软的SQL Server2000及MSDE，对于用户网络环境受限，本软件只能单机安 装的情况采用MSDE数据库，其他情况采用SQL Server2000。 在基于数据库系统的三层结构中，业务逻辑层不仅负责业务逻辑，而且直接访问数 据库，提供对业务数据的保存、更新、删除和查询操作。系统框架起到容器的作用向业务逻辑层提供服务，它还能够被很好的重用，将一些基础的公共的功能放在系 统框架层，这样就没有必要每个项目都从头做起，可以重用以前的成果提高效率。目前该系统框架提供的服务主要有连接池、缓存、日志、安全性、异常、访问配置 信息等。

2.2 获取分析类

类图的获取是一个不断细化的过程，一般我们先从分析类开始。分析类是概念层面上的类，是进行类设计的基础，获取分析类是系统分析中一项很重要的工作。获取分析类的是一个需要大量技巧的工作，我们主要根据用例描述来确定分析类。表2中列出的问题可以帮助我们识别用例中的类。

表 2 识别用例中类的问题

用例描述中出现了那些实体？

用例的完成需要哪些实体合作？

用例执行过程中会产生并存储哪些信息？

用例要求与之关联的每个角色的输入是什么？

用例反馈与之关联的每个角色的输出是什么？

用例需要操作哪些硬设备？

比 如在“选择建设项目”用例描述中对基本流的描述如下：“系统提供已有建设项目供用户选择。用户从系统提供的项目列表中选中某个建设项目。系统对当前选中的 建设项目进行标识，进入主界面” 。通过对用例描述的分析可以确定出分析类“建设项目”。通过类似的方式对每个用例描述进行分析，可以获得系统的分析类。 如图3所示，就是我们对用例进行分析后获得的系统的分析类。

2.3 用例实现

获 得分析类以后，我们就可以借助分析类通过交互模型对用例如何实现进行描述。用例实现是一个由需求转移到分析、设计的过程。用例描述了用户的功能性需求，用 例实现借助分析类以及他们之间的交互来描述用例被如何实现。可以看出使用UML从需求到分析、设计的过渡是很平滑的。在描述用例实现时我们可以使用活动 图、顺序图、协作图等方式。活动图和协作图可以互换，一般我们仅选择其中的一种就可以了。由于篇幅的限制项目继续以用例“选择建设项目”为例说明。

为 了使这个用例能够更加清晰，使用了图4所示的“选择建设项目”的活动图对该用例加以描述。进入该用例后，系统提供所有建设项目及新建建设项目功能。此时用 户可以浏览已经列出的建设项目进行选择，或者使用查询功能进行查询，或者新建一个并不存在的建设项目，这些操作对应了基本流和可选流。由于用户处理的建设 项目不多，所以将所有的建设项目都列出来。通过这样的活动图我们对用例“选择建设项目”将有一个更清晰的认识。

下面的对用例实现的描述主 要采用了顺序图来描述，当然也可以同时使用协作图进行描述。顺序图和协作图都属于交互图，都是用于描述系统中对象之间的动态关系。两者可以相互转换，但是 两者强调的重点不同，顺序图强调的是消息的时间顺序，而协作图强调的是参与交互的对象的组织。如果我们使用建模工具，创建了顺序图之后，工具可以帮我们自 动生成协作图。

用例描述中描述的基本流、可选流可以通过顺序图来进行更加详细的描述。对于用例“选择建设项目”使用一个活动图和三个顺序图来实现它的动态模型。“选择建设项目”的用例描述中有一个基本流，两个可选流。我们将选用3个顺序图分别描述这三个场景。

图5 “选择建设项目”基本流的顺序图

图5 所示的顺序图，是“选择建设项目”用例的基本流中对象之间的交互序列。在此顺序图中的对象有质监机构的工作人员、选择建设项目窗体的一个实例、 TProject类的一个对象。用户激活选择建设项目窗体的一个实例。该窗体创建TProject类的一个对象。接着窗体调用对象方法，获得的所有建设项 目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选择。用户选择了一个建设项目，窗体调用对象的方法将用户选择的建设项目标识为当前 的建设项目，以后所有的操作将在这个建设项目上进行。

图6　“选择建设项目”可选流1的顺序图

图6 所示的顺序图是选择建设项目用例的“可选流1”中对象之间的交互序列。也就是用户不使用系统列出的建设项目，而是查询建设项目从中选择。在此顺序图中的对 象有某个质监机构的工作人员、选择建设项目窗体的一个实例、TProject类的一个对象。某个质监机构的工作人员激活选择建设项目窗体的一个实例。该窗 体创建TProject类的一个对象。接着窗体调用对象方法，获得的所有建设项目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选 择。某个质监机构的工作人员将查询信息提供给窗体进行查询，窗体调用对象的查询方法获得建设项目。窗体调用自身的加载方法，将查询得到的建设项目加载到窗 体上，供质监机构的工作人员选择。质监机构的工作人员选择某个建设项目之后，窗体调用对象的方法将用户选择的建设项目标识为当前的建设项目，以后所有的操 作将在这个建设项目上进行。

图7　“选择建设项目”可选流2的顺序图

图7 所示的顺序图是“选择建设项目”用例的可选流2中对象之间的交互序列。也就是不选择建设项目而新建一个建设项目。在此顺序图中的对象有某个质监机构的工作 人员、选择建设项目窗体的一个实例、TProject类的一个对象。某个质监机构的工作人员激活选择建设项目窗体的一个实例。该窗体创建TProject 类的一个对象。接着窗体对象的方法，获得所有的建设项目，并且调用自身的方法将这些建设项目进行加载，供质监机构的工作人员选择。某个质监机构的工作人员 不进行选择，新建建设项目，窗体调用对象的新建建设项目的功能。该功能在新建建设项目用例中描述。

2.4 整理分析类

整理分析类主要是依据用例实现部分的一系列的交互图。我们已经获得了分析类，在用例实现中我们在交互图中使用了这些类。但是这些类还没有属性、职责。我们需要对他们进行整理，完成分析类的属性、职责以及类之间的关系，并在类图中将他们展示出来。

职责是分析类响应消息并完成特定功能的能力，包括对外提供服务和维护自身的信息。由于消息和职责存在着对应关系，根据消息就可以确定职责。在交互模型中对象之间的交互通过消息进行。将交互图中将和该类有关的消息进行整理确定类的职责。

类之间并不是孤立的，利用类之间的关系就可以找到另一个类。利用协作图中对象之间的连接就是分析类之间的关联方式之一。分析类之间完整的关联关系要根据所有事件序列中对象间的连接加以归纳。

属性是分析类的基本内容。属性的基本来源是用例的事件流描述。如果对分析类及方法的描述比较明确，属性就比较容易获取。要分析属性也要结合分析类的方法，因为职责会使用属性去完成功能。

在整理分析类的过程中一定要注意分析类不仅仅参与了一个用例，它可能参与了很多的用例，因此在分析属性、职责及类之间关联的时候要考虑每个用例的情况，进行归纳总结。通过整理分析类绘制的类图仅仅是分析阶段的类图还需要在后续阶段继续完善和细化。

图8 分析类Project

图8就是整理出的一个分析类Project类的示例，当然这个类不仅仅是从选择建设项目这个用例获取的信息，它是综合了所有相关的用例分析的结果。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号