|
产生背景：需求分析是软件开发的第一步，如果走的不好，那后果不堪设想，但要做好这一步，其实是很难得，因为需求分析往往是两个互不相干领域的人沟通的产物，由于领域不同，他们很少有“共同语言”。对于开发人员来说，如何清晰的获取用户的需求，从而避免以后的返工（和加班），是个难题。同时，对于大的项目来说，定义各期的开发边界，从而避免开发费用纠纷，也是个难题。对于用户来说，按时获得自己想要的东西也是个难题。 这些难题的根本原因是：开发人员和最终用户处于两种“语系”中，他们无法很好的沟通，开发人员总是会先想到如何去实现，实现是否困难；而最终用户往往先想到的是我想要什么东西，要花多少钱，可见，他们的沟通往往是没有什么基础可循的，牛头不对马嘴，这就为以后的加班和费用纠纷埋下了伏笔。 为了解决这些问题，用例图应运而生，它生来就是开发人员和最终用户的“共同语言”，双方都能够用它来表达意愿，而且对方都可以很容易的理解。 发展历程： 1986年，Ivar Jacobson博士在一篇文章中提到了用例的概念，之后Alistair Cockburn写了一本书：《编写有效用例》，该书是定义用例和书写用例最重要、最有影响力也是最全面的书籍。 概念： 用例图是这样一种视图，它清晰的描述了用户的各种需求，向用户展示了其所需要的系统的整体结构及其边界。 要素说明： 用例图包含三个要素：活动者、用例、关系。 活动者： 活动者是指向软件系统发出请求，或享受系统服务的事物。 活动者可以是人，也可以是外部系统。 活动者的标记：
用例： 用例是指系统的一个功能模块。 用例的命名一般用动宾结构的词。 用例的标记是：
关系： 用例图中的关系有四种：关联、泛化、包含、扩展 关联： 关联用于描述活动者与用例之间的交互。 关联的标记如下：
例如：
泛化： 泛化用于表达父类与子类的关系，与编程中的继承含义一致。 泛化的标记如下：
例如：
包含： 包含是指一个用例的执行必须要用到另一个用例。 包含的标号如下：
例如：
扩展： 扩展用于描述功能的可选功能。 扩展的标记如下：
例如：
画用例图的一般步骤： 1. 确定系统边界，找出所有的活动者。 2. 从抽象到具体，对系统进行细化，确定各个功能点 3. 对功能点进行优化，提前共通功能点和扩展功能点， 4. 确认活动者与功能点的关系。 作用： 1. 便于用户与开发人员沟通 2. 便于对系统复杂度、开发周期等的评估。 3. 便于新员工对系统整体结构的了解。 4. 便于测试人员开展ST。 注意事项： 用例图中要尽量避免使用编程相关的技术术语，而应该使用最终用户或领域专家的语言。 用例图应该有最终用户和开发人员共同完成。（或者至少需要经过双方确认。） |
|
|
