DR用例分析报告V040524.docx

DR用例分析报告V040524.docx

《DR用例分析报告V040524.docx》由会员分享，可在线阅读，更多相关《DR用例分析报告V040524.docx（64页珍藏版）》请在冰豆网上搜索。

DR用例分析报告V040524

智能电网用户侧接口业务应用

用例分析技术报告

（初稿V0.4）

DraftTechnicalReportofUseCasesofInterfaceApplication

forSmartGridUserSide

PC118WG2国内工作组

2013年05月

工作时间：

2012年03月～2013年05月

项目编号：

项目负责人：

张晶

工作人员：

张晶、杨胜春、闫华光、李扬、祁兵、宋杰、赵等君、张晶、王婷、马文晓、蒲俊、马元鑫

报告编写：

张晶、李扬、祁兵、王婷

1前言

Usecase，中文称用例，最早起源于软件工程学中对用户需求的描述。

在建设系统或开发系统应用软件时，开发商最需要了解的就是该领域用户对系统的需求。

但在实际工作中，开发商所了解的需求和用户期待的需求会有很大的差距，而且随着系统的开发，用户需求经常会发生变化。

这种需求的落差常常导致开发的系统不能被用户认可，软件架构需要重新设计，系统维护成本加剧。

因此，需要一种高效的需求提取方法让双方逐渐地磨合，进而达成共识。

自1992年Jacobson提出Usecase概念以来，就逐步成为软件工程中萃取需求、取得共识的最有效的方法。

智能电网是是下一代电网的发展方向。

传统电网通常只关注供给与需求的平衡，即发电、输电、配电和用电各环节的供需动态平衡。

而在可再生能源、电动汽车、用户储能等新型用电大量出现的今天，电网就必须充分了解各个环节的系统和设备动态信息，以经济性（能耗低）、可靠性（控制灵活、抗干扰性）、安全性（系统稳定和信息安全）、广泛性（用户参与）、可观测性（高级计量、电能质量）为目标进行优化，对电网进行管理和控制。

也可以说，智能电网是传统电网与信息通信技术完美结合的产物。

在智能电网用户领域，为了实现需求响应、计量与计费、用户能源管理、电动汽车充电、分布式电源等多元化的用户服务，电网运营管理中心、服务提供商、聚合代理商（aggregator）与用户系统/设备需要交互大量的实时和历史信息。

IEC和IEEE在智能电网标准体系研究中，一致认为智能电网标准本质上是电网领域（domain）之间的信息互操作标准。

NIST是由美国法令授权的智能电网标准体系研究的组织者和协调者，NIST发起成立的智能电网互操作委员会SGIP，主要关注的也是电网各个领域之间信息互操作。

目前国际标准组织的通常做法是，由领域专家提出业务需求，通过用户使用系统的途径（场景）方法，进行业务场景描述。

一个用例表达了用户对系统的一项需求，多个用例就构成了系统功能需求。

当然，这里还存在谁或在何环境（角色）使用系统。

每个角色（actor）代表具有相同目的的人或物。

IT专家将协助领域专家梳理不同角色之间需要交互的信息。

最后标准专家要确定需要互操作的领域信息内容，并最终完成信息建模、交互模型、通信协议等标准开发工作。

2011年，IEC成立智能电网用户侧接口委员会，致力于建立智能电网与用户侧设备或系统的信息交互桥梁。

IECPC118WG2于2012年-2013年-进行了2轮次的用例收集研究工作。

在2012年3月的用例研究过程中，整理了13个用例（详见附录），初步分析、研究了需求响应的主要实施过程和应用场景。

2013年3月，根据IECPC118第四次工作组会议的精神，WG2在第一轮工作的基础上，进行了进一步的用例研究工作，进行了明确的分工，统一了编写思路。

本报告在用例分析中，参考了PC118SGUITR各国提供的用例。

在附录中列举了WG2第一次收集的用例、EIS用例和NAESB用例。

可供PC118标准研究开发人员参考。

2目的意义

2.1用例分析的目的

用例分析主要用于软件或系统开发，其目标是描述客户需求和指导软件架构设计。

标准是对软件、系统的规范，在需求响应以及智能电网用户侧接口标准研究过程中，通过用例分析，能够抽取电网与用户信息交互实施过程中的核心功能，着眼于不同厂家系统、产品互操作的需求，确定信息模型的架构，从而为信息交互提供可能。

在软件工程中，用例的作用是不可替代的，有的软件开发方法论如RUP将用例作为整个软件开发流程的基础，全部流程都以用例驱动，以用例为输入工件（Artifact）。

例如，在测试阶段，就是以用例描述的各种场景为依据来测试系统的实用性。

但是用例也不是万能的，它只适合捕获功能性需求，而要捕获非功能性需求还要采用别的方法。

另外用例的开发最好有IT人员介入，实际上已经部分涉及设计阶段要考虑的问题。

2.2用例分析的作用

（1）用例分析是系统使用者与开发者沟通的工具。

采用用例来描述用户的需求，主要是该表达方式易于理解，可作为系统使用者与IT开发者沟通的手段。

在理清用户为什么使用系统时，其实就已经定义出用户对系统的需求了，用例能描述用户的外部行为及其与系统的交互情形，帮助开发者理解用户的需求。

（2）通过业务场景的用例分析，提取系统功能需求。

业务场景能抓住业务目标和流程，用例分析指出用户与系统交互的信息，结合业务场景与用例分析，能高效找出用户对于系统功能需求。

（3）根据功能需求，可以梳理角色间需要交互的信息。

一个用例就像几个角色联合执行一项任务，需要角色相互沟通和合作，为达到相同的功能，根据角色各自的特色，其相互交互的信息也可以找到。

（4）通过交互信息分类，为信息建模、信息交互等标准化工作提供支撑。

大量角色间交互的信息具有很大的共性，通过对其进行分类，可以考虑对通用的交互信息进行建模和标准化，为信息交互服务提供标准参考。

3用例分析方法

3.1用例的基本概念

3.1.1用例的定义

用例是提取功能需求的有效手段，通过用例分析，可以确定“谁”将“使用”系统，要求系统做“什么”或从系统得到什么“服务”。

从使用者“角色”的角度看系统，通过使用系统，即执行一个特定的用例，达到“角色”期待的目的。

3.1.2用例的构成

用例由使用者（Actor）、用例（UseCase）、使用对象（System）、相互关系（使用者的行为方式Association）等组成。

在用例中，使用者是在系统边界之外与系统交互的人或另一个系统，代表系统的使用者或使用环境。

不同的参与者关注的视角是不一样的，寻找并定位参与者是用例开发的关键。

一般来说，参与者主要来自于以下几个方面：

（1）谁将使用这个系统？

（2）系统从哪些人或其他系统获得数据？

（3）系统为哪些人或其他系统提供数据？

（4）系统与哪些其他系统相关联？

（5）系统由谁来维护和管理？

用例即系统对外提供的一个功能，代表一个具体的业务目标。

用例可以来自以下几个方面（针对每一个参与者）：

（1）参与者期待系统做什么？

（2）参与者如何创建、修改、删除、访问和存储数据？

（3）参与者是否需要将外部的某些事件通知给系统？

（4）系统是否需要将内部的某些事件通知给参与者？

要注意的是，有一个用例，就必然有一个参与者与之对应；如果有一个用例实在找不到参与者，则这个用例应当与其他用例合并。

反之，有一个参与者，也必须至少使用一个用例，否则应当删除。

参与者与用例之间的关系一般是“使用”，其他关系不常用。

一个系统往往由多个用例构成，一个用例应当只代表系统的一个业务目标，这就涉及用例的颗粒度问题。

一般来说，用例不能过粗，一个用例应当只需要一个IT人员去实现；但也不能过细，否则将增加系统的复杂度。

在项目的不同阶段，用例的颗粒度是不同的。

对于同一个系统，不同的人来进行用例开发，结果可能是不一样的（不仅仅是命名规则不一样）。

这时候，就需要一个有经验的系统分析员来进行比较，最终选择其中最合理的一个。

3.1.3用例的场景和类

用户使用系统的途径就是个实例，称为场景，虽然每个人使用系统的场景会有些差异，但是若用户的目标是相同的，则其场景常会极为相似，这些类似的业务场景的集合就是类，这种类称为usecase，即用例。

3.1.4用例图和用例描述

一个用例就是用户使用系统时，期望系统提供的一项功能或服务。

用例图表达了从用户角度看用例，用户能够从系统处所能获取的服务。

现在，人们往往用建模工具来画用例图，并且按UML标准来输出用例图。

不过，不是所有的功能需求都适合用用例模型来描述，UML也不是描述用例的唯一标准，在有的领域，BNF、SDL更适合。

要说明的是，用例图并不是用例本身，而只是一组符号，只能对系统有一个总体的概述。

要描述用例，仅仅输出用例图是不够的。

人们惯用文字模型来记录用例的执行细节，补足用例图无法详述之处，这样的文字描述就称为用例描述。

用例描述宜描述用户使用系统的途径以及用例应有的配合行为。

由于用例的目的在于分析系统的需求，将用例视为黑箱，所以在用例描述里，只描述用例的外部行为，及其与用户的交互即可，并不描述用例幕后的内部行为。

3.2简单用例

3.2.1ATM机

（1）用例图

ATM机用例图如图3-1所示：

图3-1ATM机用例图

（2）用例描述

ATM机用例：

查询

用例名称：

ATM查询

描述：

客户持银行卡（本行或其他行）从ATM查询余额

actors:

客户和银行主机

前置条件：

无

基本流：

1.客户插入银行卡。

2.ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。

3.客户输入密码。

4.ATM验证帐号和密码。

5.ATM显示包括查询在内的服务功能，客户选择“查询”。

6.ATM返回查询结果。

7.ATM询问客户是否继续服务。

8.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。

[用例结束]

ATM机用例：

取款

用例名称：

ATM取款

描述：

客户持银行卡（本行或其他行）从ATM提取现金

actors:

客户和银行主机

前置条件：

客户已经成功验证其银行卡信息并登录系统

基本流：

1.ATM显示包括取款在内的服务功能，客户选择“取款”。

2.输入取款额：

客户输入数量为50元的倍数的取款额。

3.ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。

4.ATM打印并吐出凭条。

5.ATM清点并吐出现金，记录取款成功。

6.ATM询问客户是否继续服务。

7.客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。

[用例结束]

接着可以继续编写其他用例描述，如“ATM机用例：

存款”、“ATM机用例：

转账”等。

3.2.2负荷管理系统

（1）用例图

负荷管理系统的用例图如图3-2所示：

图3-2负荷管理系统用例图

（2）用例描述

负荷管理系统用例：

对时

用例名称：

对时

描述：

电网侧对用户系统进行对时，方便终端负荷控制

actors:

电网、负荷管理系统、用户

前置条件：

电网与用户签订供用电合同

基本流：

9.电网侧下达对时指令；

10.负荷管理系统启动对时；

11.负荷管理系统执行对时，核对用户系统时间，如有误，进行修改；

12.结束。

负荷管理系统用例：

采集实时负荷数据

用例名称：

采集实时负荷数据

描述：

系统对实时负荷数据进行采集

actors:

电网、负荷管理系统、用户

前置条件：

无

基本流：

1.电网侧下达采集实时负荷数据；

2.负荷管理系统请求数据采集；

3.用户接收指令，返回实时负荷数据；

4.负荷管理系统储存返回数据；

5.负荷管理系统返回实时负荷数据给电网；

6.结束。

负荷管理系统用例：

采集历史负荷数据

用例名称：

采集历史负荷数据

描述：

系统对历史负荷数据进行采集

actors:

电网、负荷管理系统、用户

前置条件：

无

基本流：

7.电网侧下达采集历史负荷数据；

8.负荷管理系统请求历史负荷数据采集；

9.用户接收指令，返回历史负荷数据；

10.负荷管理系统储存返回数据；

11.负荷管理系统返回历史负荷数据给电网；

12.结束。

接着可以继续编写其他用例描述，如“负荷管理系统用例：

遥控用户负荷”、“负荷管理系统用例：

本地控制用户负荷”等，其余用例描述在4.2.5有详细介绍。

3.3高级用例

3.3.1用例关联

有的情况下，多个用例可能包含同样的动作。

这种情况下，就可以将公共部分提取出来，形成一个单独的用例，再让其他用例对公共用例进行包含（Include）、扩展（Extend）和泛化（Generalization），这样就能改善用例模型的可维护性和一致性，减少重复的工作量。

例如，在ATM系统中，查询、取款和存款这3个用例都要打印回单给客户，为了减少重复，可以将打印回单功能提取出来，抽象为一个单独的用例，并使原来的查询、取款和存款三个用例包含这个用例，这样就避免了重复描述同样的功能，避免了不一致性。

以后如果要对打印部分的功能需求进行修改，只需要改动一个用例。

包含关系如图3-3所示。

图3-3包含关系示意图

采用了包含关系后，描述事件流时只需要引用被包含用例即可。

以“查询”用例为例：

（1）用户插入银行卡；

（2）输入密码；

（3）选择查询功能；

（4）查看帐号余额；

（5）包含用例“打印回单”；

（6）退出系统，取出银行卡。

用例与用例之间还有一种扩展（Extend）关系，即在一个基础用例上定义一个或几个扩展点，再用另一个或几个用例扩展基础用例的功能。

例如，在电话业务中，基本通话功能是一个基础用例，如果需要，可以扩展出一些增值业务，例如呼叫等待、呼叫转移等。

扩展关系如图3-4所示。

图3-4扩展关系示意图

在包含关系中，被包含的用例是一定要用到的，它的事件流必须插入到基础用例中，插入点只有一个。

而在扩展关系中，需要根据一定的条件下来判断是否将扩展用例的事件流插入到基础用例的事件流，插入点可以有多个。

如上图，“呼叫等待”用例的事件流只有在应答方正忙时才插入到基础用例的事件流中，“呼叫转移”用例的事件流只有在应答方无应答时才插入到基础用例的事件流中。

其实，扩展用例的事件流也可以作为基础用例的备选流，但是，如果基础用例已经很复杂，最好还是用扩展关系来表达。

如果多个用例都具有某些相似的行为，就可以将共性部分“泛化”为父用例，再从父用例派生出子用例。

例如一个审批系统，可以先写一个一般审批的用例，再派生出一个请假审批的用例和一个报销审批的用例。

注意，子用例不能重叠。

在实际应用中，很少用到泛化关系，因为子用例的特殊行为都可以作为父用例中的备选流存在。

3.3.2规范的开发方法（IECPAS62559）

描述用例有多种方法，可以是一句话，可以是一段文字，但最好按照IECPAS62559建议的模板来描述用例。

当然，实际开发用例时，可以适当地裁剪。

一般认为，描述用例可以包括以下要素：

用例名、作者、简要描述、详细描述、参与者、前置条件、基本事件流与备选流（可选）、非功能性需求（可选）、版本迭代（可选）、用例图等。

（1）用例名。

用例名是用例的唯一标识，必须是动宾词组，要明确地表达出用例的业务目标。

（2）作者。

描述作者姓名以及所属机构。

（3）简要描述。

简要描述用例的作用和目的。

（4）详细描述。

详细描述用例的业务目标和实现过程，要明确列出用例的各种场景（Scenario）。

（5）参与者。

一般是一个表格，列出每一个参与者的名称、类型（人、系统、设备）、描述。

（6）前置条件。

描述执行用例时必须具备的基础和前提，包括政策、市场、技术、人员等，也可以是需要用到的其他用例。

（7）基本事件流和备选流。

用例描述的是参与者与系统之间的对话，但用例图并没有描述出对话的细节，这就需要用事件流来补充描述。

一个用例必须至少有一个基本事件流（BasicFlow），一般对应于主场景。

而对应于其他场景，则要用备选事件流（AlternativeFlow）来描述。

通过基本流与备选流的组合，就可以将用例可能遇到的各种场景全部描述清楚。

一个好的用例，应当无遗漏地列出所有场景。

（8）非功能性需求。

描述与用例相关的非功能性需求和设计约束，包括性能、可靠性、可用性、可扩展性、兼容性以及环境。

（9）版本迭代。

描述用例版本的适用阶段，因为在不同的阶段，用例可能是不同的。

（10）用例图。

不同的参与者关注的视角是不同的，但它们之间存在一些共同的用例。

要将所有的参与者和用例合并成一个用例图来表示。

用例名是用例的唯一标识，必须是动宾词组，要明确地表达出用例的业务目标。

4用例分析

4.1用例分类

用例分类的目的是为了反映不同的业务应用和技术领域。

用例分类有助于按照层次展开用例分析。

通过业务流程，从用户角度提取功能性需求，确定不同的域之间需要交互的信息。

目前按照业务和对象，暂时分了7类，包括公共基础类、需求响应类、能效评估类、分布式能源类、电动汽车充电类、负荷管理类、和其他类。

以后随着SGUI应用的增加，还应该会增加新的用例类。

中国用例分类如表4-1所示。

表4-1中国用例分类

分类号

用例类名称

Nameofcasecategory

CN01

公共基础类（14个）

General

CN02

需求响应类（15个）

DemandResponse

CN03

能效评估类（12个）

EnergyEfficiency

CN04

分布式能源类（11个）

DistributedEnergyResource

CN05

电动汽车类（9个）

ElectricVehicleCharging

CN06

负荷管理类（12个）

LoadManagement

CN07

其它类

Others

4.1.1公共基础类用例

公共基础类是把所有业务领域都有，或都涉及的用例进行汇总。

这将有利于提取SGUI的用例，并和其他业务用例区别开来。

在本文档中，对于电网侧系统、用户侧系统和设备而言，对某些用例的支持是通用的，如下表所示，必须被所有系统和设备所支持。

公共基础类用例如表4-2所示。

表4-2公共基础类用例

序号

用例名称

描述

其他国家涉及用例

CN0101

采集用户基本信息

电网侧采集用户基本信息，包括：

用户地址、用户名、银行帐号、用户设备的相关信息（设备的额定/最大电压、电流、频率，最大可削减负荷比例等）等。

IN01

CN0102

采集用户实时信息

电网侧采集用户实时用电信息，包括：

用户侧设备和系统的当前用电量、实时电压、实时电流、实时频率等。

US06、IN03、IN01

CN0103

采集用户历史信息

电网侧采集用户的历史用电信息，包括：

历史用电量、消费记录、历史电价、故障报修记录、负荷曲线等。

US06、IN03、IN01

CN0104

传递用户未来信息

用户近期、中期、远期的用电信息。

US06、IN03

CN0105

发布能源价格信息

电网侧向电力用户发布相关能源价格信息，如：

当前时段的电价信息和费率结构等。

US01、FR02、KR04、IN02、JP08、US06

CN0106

传递能源交易信息

电网侧向电力用户传递除能源价格外的其他能源交易相关信息。

US02

CN0107

传递能源消费控制信息

电网侧向电力用户传递能源消费控制信息。

JP03-06

CN0108

设置电表参数

电网公司对电表进行设置，包括：

电表的电压参数、电流参数、电源频率、耗电计量参数等；也应包括对电表的重启、清零等操作。

CN0109

请求服务信息

用户向电网侧发送请求服务信息。

CN0110

监测电能质量

电网公司对用户的电能质量进行监测。

US08

CN0111

传递电能质量信息

电网公司将监测到的电能质量信息传递给用户。

IN04、US07

CN0112

同步时间信号

电网侧和电力用户同步设备和系统的时间。

CN0113

发布系统版本信息

电网侧通知各用户当前运行系统的版本信息。

CN0114

用户注册/登录

在电网侧，用户进行注册/登录。

4.1.2需求响应类用例

需求响应由政府主导制定国家层面的智能电网战略规划与DR行动计划，并将智能电网技术与DR有机整合到智能电网发展愿景中。

同时，健全相关的政策法规，引入合理的激励机制降低投资风险，引导用户优化用电方式，提高终端用电效率。

用经济、技术和行政手段来控制电力系统负荷的增长速度及调整电力系统的负荷曲线，取得最佳经济效益。

需求响应类用例如表4-3所示。

表4-3需求响应类用例

序号

用例名称

描述

其他国家涉及用例

CN0201

创建DR项目

电网公司创建DR项目。

CN0202

更新DR项目信息

电网公司更新DR项目信息。

CN0203

删除DR项目

电网公司删除DR项目。

CN0204

创建DR用户

依据项目，DR用户进行注册/登录。

资源可以认为是具有交互能力的楼宇

CN0205

更新DR用户

依据项目，更新DR用户信息。

CN0206

删除DR用户

依据项目，删除DR用户信息。

CN0207

注册DR设备

在用户下，注册DR设备。

CN0208

更新DR设备信息

在用户下，更新DR设备信息。

CN0209

删除DR设备

在用户下，删除DR设备。

CN0210

提交DR投标要约

用户发出DR投标要约（购买和出售）。

CN0211

请求DR参与信息

电网公司请求用户参与DR项目信息。

US03

CN0212

监控DR信息

电网公司监控用户DR项目执行状况。

US04

CN0213

传递DR辅助服务信息

电网公司传递对DR项目进行辅助服务的相关信息。

US05

CN0214

传递峰值需求信息

用户向电网侧传递峰值需求信息。

FR03

CN0215

确认DR合约

电网侧发送用户参与DR合约，用户签字确认后回复电网侧。

4.1.3能效评估类用例

能效评估服务可分为针对企业单个/主要用电设备的设备能效评估以及针对企业整体能效的综合能效评估。

供电公司对用户的用电数据进行实时/定时采集，与常用设备或系统的能效评估模型进行对比，完成用电数据的能效分析，并将结果及优化方案反馈给用户，实现设备能耗管理的数字化，指导用户合理用电，降低用电成本。

能效评估类用例如表4-4所示。

表4-4能效评估类用例

序号

用例名称

描述

其他国家涉及用例

CN0301

请求EE评估

用户侧请求能效评估商评估EE。

CN0302

创建EE项目

服务商创建EE项目。

CN0303

更新EE项目信息

服务商更新EE项目。

CN0304

删除EE项目

服务商删除EE项目。

CN0305

EE用户注册/登录

依据项目，EE用户进行注册/登录。

CN0306

更新EE用户信息

依据项目，更新EE用户信息。

CN0307

删除EE用户

依据项目，删除EE用户信息。

CN0308

注册EE设备

用户注册EE设备。

CN0309

更新EE设备信息

用户更新EE设备信息。

CN0310

删除EE设备

用户删除EE设备。

CN0311

采集设备能效数据

服务商采集EE用户设备能效信息。

CN0312

评估设备能效信息

服务商评估EE用户设备能效。

4.1.4分布式能源类用例

分布式能源通过微网接入电力系统，实现分布式能源的“即插即用”、远程监视