软件全程建模

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

软件建模方法有很多种，至今为止最广泛使用的是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所示。





2.3 用例实现

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



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

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

<img hand';"="" height="344" src="http://www.uml.org.cn/oobject/images/sm7.JPG" width="442" border="0" style="border: 0px; max-width: 100%; ">

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

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

2.4 整理分析类

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

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

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

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

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

<img hand';"="" height="150" src="http://www.uml.org.cn/oobject/images/sm8.JPG" width="186" border="0" style="border: 0px; max-width: 100%; ">

图8 分析类Project

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