在软件工程的全部实施过程中都采用模型的方式而非文字的表达方式来进行描述，这样的实现过程称之为全程建模。全程建模的特点是：模型相互之间是有关联的，模型成为软件工程过程各阶段展现的主体而不是文字描述作为主体存在。通过建模的方式将原来纯文字加图形描述的各种文档模型化，使得从需求到代码能够统一起来，实现需求的变动直接影响到代码的变化。提高代码对需求的有效性联系，同时，解决过去经常出现的：编码改动，文档就失效的问题。
软件建模方法有很多种，至今为止最广泛使用的是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界面建模
见http://www.cnblogs.com/hobe/archive/2006/10/08/523861.html
未完待续......