UseCase是个啥概念？

Posted 2023-04-04

参考技术A 在软件工程中，用例是一种在开发新系统或者软件改造时捕获潜在需求的技术。每个用例提供了一个或多个场景，该场景揭示了系统是如何同最终用户或其它系统交互的，从而获得一个明确的业务目标。用例要避免技术术语，取而代之的是最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

在1986年，Ivar Jacobson，UML和统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。

用例迅速成为获取功能需求的最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。

用例范围和目标
每个用例集中描述如何获得一个业务目标或任务。从传统的软件工程视角来看，用例只是描述了系统的一个特征。所以对大部分软件项目来说，这就意味着需要很多（有可能是数十个）用例来完整的描述新系统。一个特殊软件项目的正规度和项目的不同阶段将会影响每一用例需要的详细程度。

一个用例定义了外部执行者和被考虑的系统之间的交互来实现一个业务目标。执行者是在系统外部和系统交互的人；一个执行者可以是一类用户，用户可以扮演的角色或者其它系统。

用例把系统看作"黑盒"，同系统的交互，包括系统的响应都是可以在系统外部感知的。它是一个deliberate policy，因为它简化了需求的描述，避免了对功能如何实现做出假设的陷阱。

用例应该:

描述了满足业务目标的业务活动
没有涉及特定的实现语言
要求合适的细节级别
足够短，使得在一次发布中能够被一个软件开发人员实现
[编辑]
用例图
Image:UMLUSE.PNG许多人通过UML认识了用例，UML定义为展现用例的图形符号。 UML并没有为描述用例定义书写格式的标准，因此许多人误认为这些图形符号就是用例本身；然而，图形符号只能给出最简单的一个或一组用例的概要。

UML是用例图形符号最流行的标准。但是，还有一些其它的可选择的标准。

[编辑]
书写用例
[编辑]
细度
Alistair Cockburn 在编写有效用例一书中确定了三种书写用例的细度。

[编辑]
摘要
摘要用例有很少的句子组成来总结的用例。它十分适合在电子表格中计划软件开发。一个摘要用例能够简单插入电子表格的单元格中并且用表格中的其它列记述业务优先级，技术复杂度，版本号等。

[编辑]
非正式
一个非正式的用例由文本段落组成，包括了上面提到的那些列，用总结或故事的形式详细的描述了用例。

[编辑]
完整正式
一个完整正式或者复杂的用例是一个以包含了不同部分的长模版为基础的正规的文档。该用例在下面的用例模版部分进行讨论。

[编辑]
适当使用
一些软件开发方法学只需要非正式的用例来定义需求。然而，开发方法学需要完整正式或详细的用例来定义需求。较大且较复杂的项目更需要使用完整正式的用例。

[编辑]
用例模版
没有一个意见一致的模版来编写详细的或fully dressed 用例。 There is no agreed template for documenting detailed or fully dressed use cases. There are a number of competing schemes and individuals are encouraged to use templates that work for them or the project they are on. Standardisation for each project is more important than the detail of a specific template. However, there is considerable agreement about the core sections; and so beneath different terminology and order there is an underlying similiarity between most use cases. (现在存在很多相互竞争的模板。同时，程序员们也被鼓励用那些适合于他们的工作或者他们所做项目的模板，相对于某个指定模板的细节来说，项目的标准化要重要的多，但是这些模板的关键部分都是大体相同的，所以，虽然在某些术语上或者其他一些方面上存在不同，但是这些用例从本质上来说，是大同小异的。)

典型部分包括:

用例名
迭代
综述
前置条件
触发器
基本事件流
备选路径
后置条件
业务规则
说明
作者和日期
不同的模版经常有其它部分，如，假设，异常，建议，技术要求。也会有行业细节部分。

[编辑]
用例名
用例名为用例提供了一个唯一标示。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。

[编辑]
迭代
迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。

[编辑]
综述
综述 部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。

[编辑]
前置条件
前置条件 部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。

[编辑]
触发器
触发器 部分描述了启动用例的起始条件。

[编辑]
基本事件流
最低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：

1) 系统提示用户登录。
2) 用户输入他的名字和密码。
3) 系统验证用户信息。
4) 系统使该用户登录入系统
...其他

[编辑]
备选路径
用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。

备选路径的例子:

1) 系统识别用户机器上的cookie
2) 到步骤4（主路径）
异常路径的例子:

3) 系统不能识别用户登录信息
4) 到步骤1（主路径）
[编辑]
后置条件
后置条件 部分总结了在场景结束后事务的状态。

[编辑]
业务规则
业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。

[编辑]
注释
经验告诉我们，不管采用何种模版，分析人员发现总有重要的信息不适合模版的结构。因此每一种模版通常包含了这种明显不能避免的信息的部分。

[编辑]
作者与日期
这部分列出创建用例的版本和谁书写的。还需要列出开发过程中从早期阶段开始的每个用例版本的日期。作者习惯在下面列出，因为它不被认为是重要的信息；用例是共同努力的结晶，并且它们被所有人拥有。

[编辑]
用例的效益
用例是一个较新的，比较敏捷的捕获软件需求的形式。用例经常和大的，统一的文档形成对比。这些大文档想要在新系统开始构成前，完整的表达出所有可能的需求，但这种做法通常都是失败的。

用例的几点优势:

用例已经证实更容易被业务用户理解，因此它也是开发人员和最终用户的很好的沟通桥梁。
用例对于确定范围很有用。用例使分阶段交付从而一步步完成项目变得容易； 它们能够在优先度变化时相对较容易的添加或从软件项目移去。
用例可跟踪。
用例能够作为估计，制定进度和验证成果的基础。
用例防止了不成熟的设计
用例不使用特定语言
用例允许我们去讲故事。能够容易的采用将需求转换为故事或场景这一具体的方法来描述用例。
用例在项目中可复用。 用例在每一次迭代中都能进一步演化，用例可以用于捕获需求，成为程序员的开发依据，发展为测试用例，到最后成为用户手册。
用例与用户和系统交互相关。它们使软件开发者在开发之前或当中就能够开始用户接口设计。
用例将需求置于上下文中，它们能够清楚地描述业务活动间的关系。
[编辑]
用例的局限性
用例不是没有局限性:

用例在捕获系统功能需求上表现很优秀，但是它们并不适合方便的捕获非功能需求。尽管一些用例支持者过于热心的主张，还是需要其它的方法去捕获非功能需求。
用例模版不能自动保证清晰。清晰要依靠书写者的技巧。
用例并不像支持者说的那样易于理解。 There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.(如何正确地向最终用户和程序员解释这些用例是一个需要花费时间学习的事情。)
极限编程的说明者通常认为用例是没用的文档，他们更喜欢用较简单的用户故事这一方法。
可用性设计人员批评用例在开发过程中过早的引入了用户接口设计。他们指出用例描述用户和系统之间的交互，很显然它和用户接口设计重叠了。不好的用例描述将过细的，专断的用户接口设计包含于交互的描述中，即使用例的一个原则是不要加入实现的细节。

听起来很高大上的“大数据技术”到底是个啥？

不知道大家有没有经常听到人说“大数据”这个词，反正小编我是有的。好像“大数据”这个概念已经火了很久了，但是你要我解释一下它的概念，小编又觉得好像不是很容易说清楚，不过在小编查阅了相关书籍以后，今天打算来和大家正经的解释一下。

先简单的来个结论，大数据技术其实就是一套完成的“数据+业务+需求”的解决方案。但是它其实是一个很宽泛的概念，主要涉及业务分析、数据分析、数据挖掘、机器学习、人工智能这5个方面。从业务分析到人工智能，是越来越需要技术背景的；而从人工智能到业务分析，是越来越贴近具体业务的。

其实，除了像搜索引擎这样需要依靠数据技术而产生的产品以外，大部分的互联网产品在生存期，即一个产品从“0”到“1”的阶段，并不是特别需要大数据技术的。但是在产品的发展期，也就是从“1”到“无穷”，“大数据技术”对产品的影响作用才渐渐有所体现。

主要是因为初期产品的功能和服务比较少，也没有积累的用户数据用于模型研发，所以我们常常听说“构建大数据的壁垒”，其实“数据及时”只是小壁垒，而“大数据”本身才是大壁垒。

那么，这里我们先从“大数据”开始说起。

什么是大数据？

“大数据”从字面意思上理解，就是很大的数据，那这个很大的数据到底有多大呢？这里举一个比较有趣的例子，早在很多年前，百度首页导航每天都需要提供的数据超过1.5PB（1PB=1024TB），这些数据如果打印出来将是5千亿张A4纸。5千亿张A4纸是什么概念？小编也难以想象……

如果大家觉得以上的举例也难以理解，那小编再用大白话来解释一下，大数据其实就是巨量的数据集合，因为大数据来源于大量用户的一次次的行为数据，所以将其称为数据集合；但是大数据的战略意义不在于掌握大量的数据信息，而在于对这些含有意义的数据进行专业化的处理。

说到对于数据进行专业化的处理，那就不得不提到“大数据技术”了。

什么是大数据技术？

对于一个从事大数据行业的人来说，一切的数据都是有意义的。因为通过数据采集、数据存储、数据管理、数据分析与挖掘、数据展现等，我们可以发现有很多有用的或者有意思的规律和结论。

例如，如果广州公交一卡通每天产生3千万条刷卡记录，那么通过分析这些刷卡记录，可以清楚的了解广州市民的出行规律，依据规律分析结果来有效改善城市交通。

但是这3千万条刷卡记录不是说能用就能用的，需要通过“存储”、“计算”、“智能”来对数据进行加工和支撑，以此来实现数据的增值。

然而在这当中，关键不在于数据技术本身，而在于是否实现了以下这两个标准：第一，这3千万条记录是不是足够多，是不是具有价值；第二，是否找到合适的数据技术的业务应用。

说了这么多，不知道小编有没有将“大数据技术”解释清楚，如果没有的话，那就简单粗暴的给大家百度个定义，大数据技术就是指大数据的应用技术，涵盖各类大数据平台、大数据指数体系等大数据应用技术。

以上就是关于“大数据技术”的相关知识分享，如果大家想要了解更多的话就去Smartbi官网看看吧！如果想看更多的行业知识分享，也请继续关注我们！