使用用例建模进行软件需求分析研究

靳佩瑶

摘要：需求分析和用例建模是软件需求工程研究的热点，通过讨论二者的作用及相互关系，得到如何使用用例分析技术为捕获的软件需求建立简洁明了的逻辑模型的一般方法。首先介绍用例、软件需求、需求建模等基本概念，然后探讨软件用例建模的一般过程，最后结合实例给出了使用用例进行需求建模的实现方法及采用用例建模的优势所在。

关键词：用例；需求分析；建模

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）29-6860-03

需求分析是指对要解决的问题进行详细的分析，弄清问题的要求。包括需要输入什么数据，要得到什么结果，最后应该输出什么。可以说，在软件工程当中的需求分析就是确定要软件实现的功能。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件不可能达到顾客的需要或者软件无法在规定的时间内完工。

用例建模是一想日益流行的基于面向对象思想的需求分析技术，它用过用例的参与者和用例一级用力之间的关系来描绘系统外在可见的需求，使用户和开发者共同剖析系统功能需求的起点。长期的实践证明，建立简介准确的表示模型是解决问题的关键。标准建模语言UML提供了无泪模型图，其中用例图特别适合与需求分析领域。

1 重要概念

1） 用例模型（use case model）：用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

2） 用例（use case）：用例就是对系统功能的描述，一个用例描述的是整个系统功能的一部分，这一部分一定要是在逻辑上有相对完整的功能流程。在使用UML的开发过程中，需求是用用例来表达的，界面是在用例的辅助下设计的，很多类是根据用例来发现的，测试实例是根据用例来生成的，包括整个开发的管理和任务分配，也是依据用例来组织的。

3） 参与者（Actor）：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。在处理参与者时，重要的是角色，并不关心人或人的职务等属性，其图形化表示是一个人。

4） 用例关系：用例关系用来表示用例间的关系。主要包括扩展（extend）、包含（include）和泛化（generalization）。为了表述用例之间的关系，使得系统设计有一个很好的框架，我们引入上述三种关系来表达系统的完整功能。

Extend 扩展：

基用例路径本身是完整的，可能是一条扩展路径。扩展路径步骤多；扩展路径内部还有扩展点-扩展之扩展；扩展路径未定或容易变化-分离以“冻结”基用例。

Include 包含：某些步骤在多个用例重复出现，且单独形成价值，当用例步骤较多时，可用Include简化。

Generalization 泛化：泛化是同一业务目的不同技术实现，一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例间的泛化关系中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

2 需求分析阶段的工作

2.1 需求获取

1） 刻画出软件的功能和性能；2） 指明软件与其他系统元素的接口；3） 建立软件必须满足的约束。

2.2 需求建模

需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和过程设计的模型。

2.3 需求规格说明

需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。

2.4 需求评审

1） 需求分析研究的对象是用户的要求。2） 必须全面理解用户的各项要求，准确表达被接受的用户要求。3） 只有经过确切描述的软件需求才能成为软件设计的基础。

3 用例建模实例分析

3.2 用例建模

与系统核心功能相关的主要有两种用户：招生人员与信息录入员。招生人员负责协调整个招生工作，可以参与到招生工作的各阶段中；而信息录入员则主要负责考生信息与考生成绩录入工作。在用例建模中这两种用户被定义为行为者。

下面主要细化已提出的两个用例：考生录取处理与专业考试处理。

1） 专业考试处理功能可分为：专业考试基础信息维护、考生基本信息处理 、考生专业成绩处理、专业考试合格证处理、招生计划信息处理。

2） 考生录取处理功能可分为：各省文化考试基础信息维护、考生文化成绩处理、考生志愿信息处理、预录取处理、最终录取处理。

用例建模的过程，除了图之外，还必须给出必要的解释。否则，建模是不完整的。图2，“专业考试处理”用例包含（include）了“专业考试基础信息维护”等5个子用例。其中信息录入员因为权限的关系，仅参与“考生基本信息处理”和“考生专业成绩处理”两个用例，而且在这两个子用例中间也只有录入信息和核对信息的功能，不能做信息的修改。而招生人员具备所有用例中的处理功能（除录入员的录入功能外）。5个子用例之间也有一定的关联，首先，“考生基本信息处理”子用例依赖于“专业考试基础信息维护”子用例，这是因为，“考生基本信息处理”中间的部分内容（如考生的考试课目），是由该考生的报考的专业决定的，而专业的情况，是“专业考试基础信息维护”的功能。类似的，“考生专业成绩处理”子用例依赖于“专业考试基础信息维护”和“考生基本信息处理”子用例，这是因为，要进行考生专业成绩的录入，维护等工作，必须在考生的基本信息和考生所报考专业的考试信息都完整的情况下进行。“专业考试合格证处理”子用例依赖于“招生计划信息处理”和“考生专业成绩处理”子用例，这是因为发放专业考试合格证的前提是考生专业成绩和招生计划都处理完毕。

图3，“考生录取处理”包含（include）了“各省文化考试基础信息维护”等5个子用例。信息录入员参与了“考生文化成绩处理”和“考生志愿信息处理”2个子用例，并且仅有录入信息和核对信息的权限，不具有修改和维护的权限。招生人员具备所有用例的处理功能（除录入员的录入功能外）。5个子用例之间也具备一定依赖关系。“考生文化成绩处理”子用例依赖于“各省文化考试基础信息维护”子用例，因为要录入并维护考生的文化成绩，前提是该考生所在省份所考类别的文化课课目的信息是完整准确的。“预录取处理”子用例依赖于“考生志愿信息处理”和“考生文化成绩处理”两个子用例，因为考生志愿、文化成绩、专业成绩、招生计划（后两者需要依赖“专业课考试处理”用例，图3.3无法表示，可从图3.1中看到）决定了预录取的结果。“最终录取处理”是一个审批和微调的过程，需要依赖于“预录取处理”的结果。

4 用例建模的优点

1） 用例建模完全是从外部站在用户的角度上来描述系统功能的，把用户需求和设计完全分离开来。用例模型主要描述系统的功能性需求。系统的设计由对象模型来描述。2） 用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务而不是分离的功能。3） 用例方法比传统的方法更易于被用户理解，用例方法是用户和开发人员有效地沟通手段。

5 结束语

用例建模向人们展示用户如何使用系统以及系统的工作流程。通过用例建模来观察系统，有助于了解系统中最重要的部分，避免不必要的细节，来满足用户的需求和期望。用例建模技术以面向对象思想为指导，注重参与者和用例一级用力之间的关系，对用户需求有着极强的表述能力。总之 ，用例分析技术很好的解决了传统面向过程需求分析技术对用户需求描述不清、难以处理需求变化的问题。正确使用用例建模这项技术，会对软件的设计、开发以及后期维护都带来巨大的方便。

参考文献：

[1] 张龙祥.UML与系统分析与设计[M].北京：人民邮电出版社，2001.

[2] Martin F.UML精粹[M].徐家福，译.2版.北京：清华大学出版社，2002.

[3] 吴际，金茂忠.UML面向对象分析[M].北京：北京航空航天大学出版社，2002.endprint

摘要：需求分析和用例建模是软件需求工程研究的热点，通过讨论二者的作用及相互关系，得到如何使用用例分析技术为捕获的软件需求建立简洁明了的逻辑模型的一般方法。首先介绍用例、软件需求、需求建模等基本概念，然后探讨软件用例建模的一般过程，最后结合实例给出了使用用例进行需求建模的实现方法及采用用例建模的优势所在。

关键词：用例；需求分析；建模

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）29-6860-03

需求分析是指对要解决的问题进行详细的分析，弄清问题的要求。包括需要输入什么数据，要得到什么结果，最后应该输出什么。可以说，在软件工程当中的需求分析就是确定要软件实现的功能。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件不可能达到顾客的需要或者软件无法在规定的时间内完工。

用例建模是一想日益流行的基于面向对象思想的需求分析技术，它用过用例的参与者和用例一级用力之间的关系来描绘系统外在可见的需求，使用户和开发者共同剖析系统功能需求的起点。长期的实践证明，建立简介准确的表示模型是解决问题的关键。标准建模语言UML提供了无泪模型图，其中用例图特别适合与需求分析领域。

1 重要概念

1） 用例模型（use case model）：用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

2） 用例（use case）：用例就是对系统功能的描述，一个用例描述的是整个系统功能的一部分，这一部分一定要是在逻辑上有相对完整的功能流程。在使用UML的开发过程中，需求是用用例来表达的，界面是在用例的辅助下设计的，很多类是根据用例来发现的，测试实例是根据用例来生成的，包括整个开发的管理和任务分配，也是依据用例来组织的。

3） 参与者（Actor）：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。在处理参与者时，重要的是角色，并不关心人或人的职务等属性，其图形化表示是一个人。

4） 用例关系：用例关系用来表示用例间的关系。主要包括扩展（extend）、包含（include）和泛化（generalization）。为了表述用例之间的关系，使得系统设计有一个很好的框架，我们引入上述三种关系来表达系统的完整功能。

Extend 扩展：

基用例路径本身是完整的，可能是一条扩展路径。扩展路径步骤多；扩展路径内部还有扩展点-扩展之扩展；扩展路径未定或容易变化-分离以“冻结”基用例。

Include 包含：某些步骤在多个用例重复出现，且单独形成价值，当用例步骤较多时，可用Include简化。

Generalization 泛化：泛化是同一业务目的不同技术实现，一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例间的泛化关系中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

2 需求分析阶段的工作

2.1 需求获取

1） 刻画出软件的功能和性能；2） 指明软件与其他系统元素的接口；3） 建立软件必须满足的约束。

2.2 需求建模

需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和过程设计的模型。

2.3 需求规格说明

需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。

2.4 需求评审

1） 需求分析研究的对象是用户的要求。2） 必须全面理解用户的各项要求，准确表达被接受的用户要求。3） 只有经过确切描述的软件需求才能成为软件设计的基础。

3 用例建模实例分析

3.2 用例建模

与系统核心功能相关的主要有两种用户：招生人员与信息录入员。招生人员负责协调整个招生工作，可以参与到招生工作的各阶段中；而信息录入员则主要负责考生信息与考生成绩录入工作。在用例建模中这两种用户被定义为行为者。

下面主要细化已提出的两个用例：考生录取处理与专业考试处理。

1） 专业考试处理功能可分为：专业考试基础信息维护、考生基本信息处理 、考生专业成绩处理、专业考试合格证处理、招生计划信息处理。

2） 考生录取处理功能可分为：各省文化考试基础信息维护、考生文化成绩处理、考生志愿信息处理、预录取处理、最终录取处理。

用例建模的过程，除了图之外，还必须给出必要的解释。否则，建模是不完整的。图2，“专业考试处理”用例包含（include）了“专业考试基础信息维护”等5个子用例。其中信息录入员因为权限的关系，仅参与“考生基本信息处理”和“考生专业成绩处理”两个用例，而且在这两个子用例中间也只有录入信息和核对信息的功能，不能做信息的修改。而招生人员具备所有用例中的处理功能（除录入员的录入功能外）。5个子用例之间也有一定的关联，首先，“考生基本信息处理”子用例依赖于“专业考试基础信息维护”子用例，这是因为，“考生基本信息处理”中间的部分内容（如考生的考试课目），是由该考生的报考的专业决定的，而专业的情况，是“专业考试基础信息维护”的功能。类似的，“考生专业成绩处理”子用例依赖于“专业考试基础信息维护”和“考生基本信息处理”子用例，这是因为，要进行考生专业成绩的录入，维护等工作，必须在考生的基本信息和考生所报考专业的考试信息都完整的情况下进行。“专业考试合格证处理”子用例依赖于“招生计划信息处理”和“考生专业成绩处理”子用例，这是因为发放专业考试合格证的前提是考生专业成绩和招生计划都处理完毕。

图3，“考生录取处理”包含（include）了“各省文化考试基础信息维护”等5个子用例。信息录入员参与了“考生文化成绩处理”和“考生志愿信息处理”2个子用例，并且仅有录入信息和核对信息的权限，不具有修改和维护的权限。招生人员具备所有用例的处理功能（除录入员的录入功能外）。5个子用例之间也具备一定依赖关系。“考生文化成绩处理”子用例依赖于“各省文化考试基础信息维护”子用例，因为要录入并维护考生的文化成绩，前提是该考生所在省份所考类别的文化课课目的信息是完整准确的。“预录取处理”子用例依赖于“考生志愿信息处理”和“考生文化成绩处理”两个子用例，因为考生志愿、文化成绩、专业成绩、招生计划（后两者需要依赖“专业课考试处理”用例，图3.3无法表示，可从图3.1中看到）决定了预录取的结果。“最终录取处理”是一个审批和微调的过程，需要依赖于“预录取处理”的结果。

4 用例建模的优点

1） 用例建模完全是从外部站在用户的角度上来描述系统功能的，把用户需求和设计完全分离开来。用例模型主要描述系统的功能性需求。系统的设计由对象模型来描述。2） 用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务而不是分离的功能。3） 用例方法比传统的方法更易于被用户理解，用例方法是用户和开发人员有效地沟通手段。

5 结束语

用例建模向人们展示用户如何使用系统以及系统的工作流程。通过用例建模来观察系统，有助于了解系统中最重要的部分，避免不必要的细节，来满足用户的需求和期望。用例建模技术以面向对象思想为指导，注重参与者和用例一级用力之间的关系，对用户需求有着极强的表述能力。总之 ，用例分析技术很好的解决了传统面向过程需求分析技术对用户需求描述不清、难以处理需求变化的问题。正确使用用例建模这项技术，会对软件的设计、开发以及后期维护都带来巨大的方便。

参考文献：

[1] 张龙祥.UML与系统分析与设计[M].北京：人民邮电出版社，2001.

[2] Martin F.UML精粹[M].徐家福，译.2版.北京：清华大学出版社，2002.

[3] 吴际，金茂忠.UML面向对象分析[M].北京：北京航空航天大学出版社，2002.endprint

摘要：需求分析和用例建模是软件需求工程研究的热点，通过讨论二者的作用及相互关系，得到如何使用用例分析技术为捕获的软件需求建立简洁明了的逻辑模型的一般方法。首先介绍用例、软件需求、需求建模等基本概念，然后探讨软件用例建模的一般过程，最后结合实例给出了使用用例进行需求建模的实现方法及采用用例建模的优势所在。

关键词：用例；需求分析；建模

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）29-6860-03

需求分析是指对要解决的问题进行详细的分析，弄清问题的要求。包括需要输入什么数据，要得到什么结果，最后应该输出什么。可以说，在软件工程当中的需求分析就是确定要软件实现的功能。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件不可能达到顾客的需要或者软件无法在规定的时间内完工。

用例建模是一想日益流行的基于面向对象思想的需求分析技术，它用过用例的参与者和用例一级用力之间的关系来描绘系统外在可见的需求，使用户和开发者共同剖析系统功能需求的起点。长期的实践证明，建立简介准确的表示模型是解决问题的关键。标准建模语言UML提供了无泪模型图，其中用例图特别适合与需求分析领域。

1 重要概念

1） 用例模型（use case model）：用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

2） 用例（use case）：用例就是对系统功能的描述，一个用例描述的是整个系统功能的一部分，这一部分一定要是在逻辑上有相对完整的功能流程。在使用UML的开发过程中，需求是用用例来表达的，界面是在用例的辅助下设计的，很多类是根据用例来发现的，测试实例是根据用例来生成的，包括整个开发的管理和任务分配，也是依据用例来组织的。

3） 参与者（Actor）：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。在处理参与者时，重要的是角色，并不关心人或人的职务等属性，其图形化表示是一个人。

4） 用例关系：用例关系用来表示用例间的关系。主要包括扩展（extend）、包含（include）和泛化（generalization）。为了表述用例之间的关系，使得系统设计有一个很好的框架，我们引入上述三种关系来表达系统的完整功能。

Extend 扩展：

基用例路径本身是完整的，可能是一条扩展路径。扩展路径步骤多；扩展路径内部还有扩展点-扩展之扩展；扩展路径未定或容易变化-分离以“冻结”基用例。

Include 包含：某些步骤在多个用例重复出现，且单独形成价值，当用例步骤较多时，可用Include简化。

Generalization 泛化：泛化是同一业务目的不同技术实现，一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例）。UML 1.5： 用例间的泛化关系中，子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

2 需求分析阶段的工作

2.1 需求获取

1） 刻画出软件的功能和性能；2） 指明软件与其他系统元素的接口；3） 建立软件必须满足的约束。

2.2 需求建模

需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、体系结构、接口和过程设计的模型。

2.3 需求规格说明

需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。

2.4 需求评审

1） 需求分析研究的对象是用户的要求。2） 必须全面理解用户的各项要求，准确表达被接受的用户要求。3） 只有经过确切描述的软件需求才能成为软件设计的基础。

3 用例建模实例分析

3.2 用例建模

与系统核心功能相关的主要有两种用户：招生人员与信息录入员。招生人员负责协调整个招生工作，可以参与到招生工作的各阶段中；而信息录入员则主要负责考生信息与考生成绩录入工作。在用例建模中这两种用户被定义为行为者。

下面主要细化已提出的两个用例：考生录取处理与专业考试处理。

1） 专业考试处理功能可分为：专业考试基础信息维护、考生基本信息处理 、考生专业成绩处理、专业考试合格证处理、招生计划信息处理。

2） 考生录取处理功能可分为：各省文化考试基础信息维护、考生文化成绩处理、考生志愿信息处理、预录取处理、最终录取处理。

用例建模的过程，除了图之外，还必须给出必要的解释。否则，建模是不完整的。图2，“专业考试处理”用例包含（include）了“专业考试基础信息维护”等5个子用例。其中信息录入员因为权限的关系，仅参与“考生基本信息处理”和“考生专业成绩处理”两个用例，而且在这两个子用例中间也只有录入信息和核对信息的功能，不能做信息的修改。而招生人员具备所有用例中的处理功能（除录入员的录入功能外）。5个子用例之间也有一定的关联，首先，“考生基本信息处理”子用例依赖于“专业考试基础信息维护”子用例，这是因为，“考生基本信息处理”中间的部分内容（如考生的考试课目），是由该考生的报考的专业决定的，而专业的情况，是“专业考试基础信息维护”的功能。类似的，“考生专业成绩处理”子用例依赖于“专业考试基础信息维护”和“考生基本信息处理”子用例，这是因为，要进行考生专业成绩的录入，维护等工作，必须在考生的基本信息和考生所报考专业的考试信息都完整的情况下进行。“专业考试合格证处理”子用例依赖于“招生计划信息处理”和“考生专业成绩处理”子用例，这是因为发放专业考试合格证的前提是考生专业成绩和招生计划都处理完毕。

图3，“考生录取处理”包含（include）了“各省文化考试基础信息维护”等5个子用例。信息录入员参与了“考生文化成绩处理”和“考生志愿信息处理”2个子用例，并且仅有录入信息和核对信息的权限，不具有修改和维护的权限。招生人员具备所有用例的处理功能（除录入员的录入功能外）。5个子用例之间也具备一定依赖关系。“考生文化成绩处理”子用例依赖于“各省文化考试基础信息维护”子用例，因为要录入并维护考生的文化成绩，前提是该考生所在省份所考类别的文化课课目的信息是完整准确的。“预录取处理”子用例依赖于“考生志愿信息处理”和“考生文化成绩处理”两个子用例，因为考生志愿、文化成绩、专业成绩、招生计划（后两者需要依赖“专业课考试处理”用例，图3.3无法表示，可从图3.1中看到）决定了预录取的结果。“最终录取处理”是一个审批和微调的过程，需要依赖于“预录取处理”的结果。

4 用例建模的优点

1） 用例建模完全是从外部站在用户的角度上来描述系统功能的，把用户需求和设计完全分离开来。用例模型主要描述系统的功能性需求。系统的设计由对象模型来描述。2） 用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务而不是分离的功能。3） 用例方法比传统的方法更易于被用户理解，用例方法是用户和开发人员有效地沟通手段。

5 结束语

用例建模向人们展示用户如何使用系统以及系统的工作流程。通过用例建模来观察系统，有助于了解系统中最重要的部分，避免不必要的细节，来满足用户的需求和期望。用例建模技术以面向对象思想为指导，注重参与者和用例一级用力之间的关系，对用户需求有着极强的表述能力。总之 ，用例分析技术很好的解决了传统面向过程需求分析技术对用户需求描述不清、难以处理需求变化的问题。正确使用用例建模这项技术，会对软件的设计、开发以及后期维护都带来巨大的方便。

参考文献：

[1] 张龙祥.UML与系统分析与设计[M].北京：人民邮电出版社，2001.

[2] Martin F.UML精粹[M].徐家福，译.2版.北京：清华大学出版社，2002.

[3] 吴际，金茂忠.UML面向对象分析[M].北京：北京航空航天大学出版社，2002.endprint