电力营销系统的案例-需求分析课件.ppt

1、统一建模语言UML电力营销系统案例电力营销系统案例需求分析需求分析关键概念分析关键概念分析l需求确定后，接下来进行系统的分析和设计工需求确定后，接下来进行系统的分析和设计工作。作。l面对复杂的需求，需要对其中的面对复杂的需求，需要对其中的关键概念关键概念进行进行分析。分析。l支撑起客户整个业务架构的主线。支撑起客户整个业务架构的主线。l这些主线由一些关键业务（关键用例）构成。这些主线由一些关键业务（关键用例）构成。需求分析的任务需求分析的任务l找到关键的业务用例，并对它们进行分析，建找到关键的业务用例，并对它们进行分析，建立概念模型，立概念模型，l依据概念模型搭建业务架构，依据概念模型搭建业务

2、架构，l为验证这个架构或者进行技术可行性分析开发为验证这个架构或者进行技术可行性分析开发系统原型。系统原型。建立概念模型建立概念模型建立概念模型建立概念模型l概念模型始于业务用例，从业务模型中抽象出概念模型始于业务用例，从业务模型中抽象出一些概念用例，针对概念用例进行分析，得到一些概念用例，针对概念用例进行分析，得到一些分析类和分析场景。一些分析类和分析场景。l注意：注意：l概念模型针对需求中的关键业务，业务核心来概念模型针对需求中的关键业务，业务核心来建立，非全面覆盖。建立，非全面覆盖。l概念模型由需求人员、系统分析员、软件架构概念模型由需求人员、系统分析员、软件架构员、系统设计人员共同参与

3、。员、系统设计人员共同参与。获取概念用例获取概念用例l回顾电力营销系统，对于供电企业来说，最核回顾电力营销系统，对于供电企业来说，最核心的业务就是：心的业务就是：l建立并管理用电用户建立并管理用电用户l计算电费计算电费l收取电费收取电费l形成供电收入形成供电收入l这是支撑起供电企业业务的主线。这是支撑起供电企业业务的主线。供电企业业务主线供电企业业务主线 问题问题l当一条业务主线确定以后，很多业务用例都会当一条业务主线确定以后，很多业务用例都会和这条主线有关系，是不是所有与业务主线有和这条主线有关系，是不是所有与业务主线有关的用例都要挑选出来呢？关的用例都要挑选出来呢？l不是，业务主线自然会和

4、几乎所有的业务用例不是，业务主线自然会和几乎所有的业务用例都有关系，全部进行研究不现实。都有关系，全部进行研究不现实。l只需要视情况挑选一到两个有代表性的典型业只需要视情况挑选一到两个有代表性的典型业务用例就可以。务用例就可以。例如例如l业务主线中业务主线中“受理用电申请受理用电申请”l其相关业务有：其相关业务有：“申请永久用电申请永久用电”、“申请临申请临时用电时用电”，l挑选最常用，最典型的挑选最常用，最典型的“申请永久用电申请永久用电”。l业务主线中业务主线中“抄录电表示数抄录电表示数”l与其相关的业务有：与其相关的业务有：“导出上月示数导出上月示数”、“分分配抄表任务配抄表任务”、“录

5、入抄表示数录入抄表示数”等等l选择最有典型性、支持电费计算最终手段的选择最有典型性、支持电费计算最终手段的“录入抄表示数录入抄表示数”。l经过分析、探讨，决定将下图所示的业务经过分析、探讨，决定将下图所示的业务用例挑选处理作为关键概念分析的业务用用例挑选处理作为关键概念分析的业务用例。例。找出概念用例找出概念用例l依据上述关键业务用例，以及业务主线需要，依据上述关键业务用例，以及业务主线需要，找出找出概念用例概念用例。l概念用例不需要展现所有的业务用例细节，只概念用例不需要展现所有的业务用例细节，只要非常概括的展现出能够完成业务主线的那一要非常概括的展现出能够完成业务主线的那一部份即可。部份即

6、可。例如：申请永久用电业务用例场景例如：申请永久用电业务用例场景 申请永久用电场景申请永久用电场景l包含的内容很多，但只有包含的内容很多，但只有“生成申请单生成申请单”、“安装电表安装电表”、“建立档案建立档案”这几项工作与业这几项工作与业务主线关系最为密切。务主线关系最为密切。l申请单是建立档案的基础申请单是建立档案的基础l安装电表是抄表的基础安装电表是抄表的基础l用户档案是电费计算的基础用户档案是电费计算的基础l这三项工作齐备，业务主线就可以执行了这三项工作齐备，业务主线就可以执行了申请永久用电业务概念用例图申请永久用电业务概念用例图 分析概念用例分析概念用例l确定概念用例后，就要对概念用

7、例进行分析。确定概念用例后，就要对概念用例进行分析。l与业务用例建模过程类似：与业务用例建模过程类似：l绘制概念用例场景（活动图、时序图等）绘制概念用例场景（活动图、时序图等）l找到关键对象，绘制协作图说明对象之间的关找到关键对象，绘制协作图说明对象之间的关系和交互场景。系和交互场景。l要从系统的角度和抽象的角度来分析概念用例。要从系统的角度和抽象的角度来分析概念用例。“生成申请单生成申请单”概念用例场景视概念用例场景视图图 l此图与原始业务不同，此图与原始业务不同，l这个概念用例的最终目的是生成完整的用电申这个概念用例的最终目的是生成完整的用电申请单，以建立用户档案，因此整个概念用例的请单，

8、以建立用户档案，因此整个概念用例的场景是围绕着申请单如何从产生到完成的一系场景是围绕着申请单如何从产生到完成的一系列活动建立的。列活动建立的。l依据相同的方法可以为其他概念用例绘制场景依据相同的方法可以为其他概念用例绘制场景视图。视图。获得关键对象获得关键对象生成申请单生成申请单l从从“生成申请单生成申请单”场景中，分析有哪些业务对场景中，分析有哪些业务对象被创建或者被修改，即可得到这个概念用例象被创建或者被修改，即可得到这个概念用例的关键对象。的关键对象。生成申请单关键对象生成申请单关键对象 建立概念模型建立概念模型l分析清楚一个概念用例，就能得到它的关键对分析清楚一个概念用例，就能得到它的

9、关键对象，这些关键对象是我们建立象，这些关键对象是我们建立概念模型概念模型的基础。的基础。l概念模型从抽象的系统对象视角来解释业务主概念模型从抽象的系统对象视角来解释业务主线如何在计算机中运行。线如何在计算机中运行。l即用这些关键对象去实现业务主线。即用这些关键对象去实现业务主线。关键对象如何实现业务主线？关键对象如何实现业务主线？l关键对象是一些实体对象，显然不能使一个系关键对象是一些实体对象，显然不能使一个系统运行。统运行。l将采用将采用分析模型分析模型的方式来实现核心业务。的方式来实现核心业务。l分析模型采用分析模型采用MVC模式，将用例场景中描述的模式，将用例场景中描述的业务分解为业务

10、分解为边界边界（操作界面和展示界面）、（操作界面和展示界面）、控控制制（业务逻辑）、（业务逻辑）、实体实体（业务数据）。（业务数据）。l用这三个元素建立实现用例场景的对象模型。用这三个元素建立实现用例场景的对象模型。建立分析模型建立分析模型l分析模型中：分析模型中：l操作者所有的操作都通过边界类进行，操作者所有的操作都通过边界类进行，l操作消息通过操作消息通过 边界类传递给控制类，边界类传递给控制类，l控制类进行解释，执行相关的逻辑，并想实体控制类进行解释，执行相关的逻辑，并想实体类进行数据的存取。类进行数据的存取。l初步建立分析模型时，可以非常简单的将边界初步建立分析模型时，可以非常简单的将

11、边界类、实体类、控制类串起来。类、实体类、控制类串起来。例如：分析类场景例如：分析类场景创建申请单创建申请单问题：问题：l上图仅仅说明了业务主线中一个核心业务，是上图仅仅说明了业务主线中一个核心业务，是否要将所有的核心业务具体化到同一副图中？否要将所有的核心业务具体化到同一副图中？l仅仅一个核心业务就花费了十多步，如果整个仅仅一个核心业务就花费了十多步，如果整个业务在一幅图中出现就显得太过复杂。业务在一幅图中出现就显得太过复杂。l实际工作中，可以将不同的核心业务分开绘制，实际工作中，可以将不同的核心业务分开绘制，工作量、可读性都好得多。工作量、可读性都好得多。问题：问题：l核心业务本来是紧密关

12、联的，如果分开绘制，核心业务本来是紧密关联的，如果分开绘制，又如何能知道它们是怎样串在一起的呢？又如何能知道它们是怎样串在一起的呢？l之前已经有了业务主线示例图说明了整个业务，之前已经有了业务主线示例图说明了整个业务，针对每个核心业务有各自的概念用例场景视图，针对每个核心业务有各自的概念用例场景视图，能说明业务是如何串在一起执行的。能说明业务是如何串在一起执行的。问题问题l前面的各种视图，完整的说明了小步骤如何由前面的各种视图，完整的说明了小步骤如何由场景串起来，但是场景只是一个概念性的描述，场景串起来，但是场景只是一个概念性的描述，而不是一个实现，而不是一个实现，l单独的每一步都是一个实现（

13、有操作者、边界单独的每一步都是一个实现（有操作者、边界类、控制类实体类），但是场景不能说明在计类、控制类实体类），但是场景不能说明在计算机中是如何从一个核心业务跳跃到另一个核算机中是如何从一个核心业务跳跃到另一个核心业务的，怎么办？心业务的，怎么办？软件架构软件架构l每一小步都可以理解为系统中的一个功能单一，每一小步都可以理解为系统中的一个功能单一，或最小操作集。系统只有将所有的操作集有机或最小操作集。系统只有将所有的操作集有机的组合起来才能完成业务，成为一个系统，这的组合起来才能完成业务，成为一个系统，这只能由软件架构完成。只能由软件架构完成。l软件架构在哪里呢？软件架构在哪里呢？例如：例如

14、：l最简单的做法，采用数据库。最简单的做法，采用数据库。这就是这就是C/S架构架构l每一步的操作都通过界面，从数据库获取所需每一步的操作都通过界面，从数据库获取所需的数据，并将结果存入数据库。的数据，并将结果存入数据库。l数据库充当了步骤连接者的角色。数据库充当了步骤连接者的角色。l步骤之间的衔接是软件架构的范畴。步骤之间的衔接是软件架构的范畴。例如：例如：l采用工作流来做步骤衔接的工作。采用工作流来做步骤衔接的工作。引入工作流后分析类场景引入工作流后分析类场景创建申请单创建申请单l也可以考虑采用消息中间件模式来实现。也可以考虑采用消息中间件模式来实现。l操作者操作者1在完成其工作后，向消息中

15、间件发送工在完成其工作后，向消息中间件发送工作已完成的消息，该消息被传递给操作者作已完成的消息，该消息被传递给操作者2，操，操作者作者2凭借此消息开始工作。凭借此消息开始工作。l概念模型中，选择不同的软件架构，就会产生概念模型中，选择不同的软件架构，就会产生不同的实现方式。不同的实现方式。l软件架构的选择是否合适这个业务模式，可以软件架构的选择是否合适这个业务模式，可以在绘制概念模型图的过程中被检验。在绘制概念模型图的过程中被检验。l当把概念用例中所有场景都实现以后，关键概当把概念用例中所有场景都实现以后，关键概念的分析就算完成了。念的分析就算完成了。l在此过程中，我们找到了关键对象，用关键对

16、在此过程中，我们找到了关键对象，用关键对象实现业务场景，并引入软件架构。象实现业务场景，并引入软件架构。进一步讨论之一：进一步讨论之一：l关于概念模型和领域模型关于概念模型和领域模型l二者很相似：二者很相似：l都是从业务用例场景出发，找到一些实体类，用实体都是从业务用例场景出发，找到一些实体类，用实体类去实现业务场景来获得业务在系统中的理解。类去实现业务场景来获得业务在系统中的理解。l区别是：区别是：l领域模型不一定针对业务，它针对的是问题。领域模型不一定针对业务，它针对的是问题。l概念模型只针对业务，它要解决的问题是需求向设计概念模型只针对业务，它要解决的问题是需求向设计转换之前，通过概念建

17、模这个步骤，在项目早期发现转换之前，通过概念建模这个步骤，在项目早期发现并解决问题。并解决问题。进一步讨论之二：进一步讨论之二：l有关软件架构：有关软件架构：l软件架构不仅仅是一组技术框架，它只有和业软件架构不仅仅是一组技术框架，它只有和业务结合起来才能发挥作用。务结合起来才能发挥作用。l在选择软件架构时，要从业务的角度出发，而在选择软件架构时，要从业务的角度出发，而不是从技术的角度出发选择先进的、流行的架不是从技术的角度出发选择先进的、流行的架构。构。业务架构业务架构l技术架构提供了如何将构件搭建成系统的手段技术架构提供了如何将构件搭建成系统的手段和办法，但是构件又是什么样子的，从哪里来和办

18、法，但是构件又是什么样子的，从哪里来的呢？的呢？l面对同行业的不同单位，业务需求却差很多，面对同行业的不同单位，业务需求却差很多，做完一个项目，做另一个项目时又要重新开发，做完一个项目，做另一个项目时又要重新开发，行业软件如何才能通用？行业软件如何才能通用？l面对再复杂的迥异的需求，都可以像搭积木一面对再复杂的迥异的需求，都可以像搭积木一样的搭建业务平台，这些积木就是：样的搭建业务平台，这些积木就是：业务架构。业务架构。建立业务架构建立业务架构l建立业务架构的工作，类似于面向过程的结构建立业务架构的工作，类似于面向过程的结构化设计，化设计，l不同的是：不同的是：l结构化设计方法中得到的结果是子

19、系统、模块；结构化设计方法中得到的结果是子系统、模块；l面向对象设计方法中，得到的结果是面向对象设计方法中，得到的结果是业务构件业务构件。lUML中，用组件来表示业务构件。中，用组件来表示业务构件。建立业务架构建立业务架构l建立业务架构，实际上就是在对需求细致分析建立业务架构，实际上就是在对需求细致分析和深刻理解的基础上，抽象出若干相对独立的和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。业务模块，形成自洽的业务构件。l这些业务构件对内可以完成一个或一组特定的这些业务构件对内可以完成一个或一组特定的功能，对外有完善的接口，可以与其他业务构功能，对外有完善的接口，可以与其他

20、业务构件共同组成更为复杂的业务功能。件共同组成更为复杂的业务功能。l在面对新的系统时，可以直接使用这些构件，在面对新的系统时，可以直接使用这些构件，而不是从头开始构造零部件。而不是从头开始构造零部件。如何建立业务架构？如何建立业务架构？l采用自顶向下的方法。采用自顶向下的方法。l从业务用例模型中了解业务细节，从业务用例模型中了解业务细节，l从领域模型中找到业务的若干问题的解决方案，从领域模型中找到业务的若干问题的解决方案，l从概念模型中找到业务骨架的实现和软件架构从概念模型中找到业务骨架的实现和软件架构的方式。的方式。l综合起来就是建立业务架构的重要信息来源。综合起来就是建立业务架构的重要信息

21、来源。业务架构分析示例业务架构分析示例l将以前面建立的概念模型为基础，展示自顶向将以前面建立的概念模型为基础，展示自顶向下建立业务架构的过程。下建立业务架构的过程。供电企业核心业务结构供电企业核心业务结构l供电企业管理系统最核心的业务是：供电企业管理系统最核心的业务是：l建立并管理用电用户建立并管理用电用户l计算电费计算电费l收取电费收取电费l形成供电收入形成供电收入 l对业务名词进行一些抽象化的改动，以业对业务名词进行一些抽象化的改动，以业务构件的形式展示这条业务主线，如下：务构件的形式展示这条业务主线，如下：l上图只是业务用例场景示例图的一个变体，粒上图只是业务用例场景示例图的一个变体，粒

22、度也很粗，但是从面向对象的角度来说，这些度也很粗，但是从面向对象的角度来说，这些构件形成了我们继续抽象的基础。构件形成了我们继续抽象的基础。l后续工作：后续工作：l每一个大的构件时由哪些小构件组成的？每一个大的构件时由哪些小构件组成的？l构件之间的依赖关系是通过什么维系的？构件之间的依赖关系是通过什么维系的？每一个大的构件时由哪些小构件每一个大的构件时由哪些小构件组成的？组成的？l概念模型对象图中的对象就是构成大构件的基概念模型对象图中的对象就是构成大构件的基础。础。l例如：例如：l“生成申请单生成申请单”对象图中的对象就是对象图中的对象就是“业务扩业务扩充充”大构件的基础。大构件的基础。生成

23、申请单关键对象生成申请单关键对象 l将将“业务扩充业务扩充”这个大构件进一步分解为：这个大构件进一步分解为：l此图还缺少一个构件，这个构件要将其他构此图还缺少一个构件，这个构件要将其他构件协同起来工作，最终的件协同起来工作，最终的“业务扩充业务扩充”构件构件图如下：图如下：l通过相同的方法可以将通过相同的方法可以将“抄表台帐抄表台帐”、“计算计算电费电费”等大构件分解成适合的小构件，最终形等大构件分解成适合的小构件，最终形成业务架构。成业务架构。l其中每个业务构件都是其中每个业务构件都是“专业化专业化”的，这样就的，这样就从复杂的业务中剥离了我们所需要的原件，也从复杂的业务中剥离了我们所需要的

24、原件，也就是构件化开发所需要的积木。就是构件化开发所需要的积木。构件之间的依赖关系是通过什么构件之间的依赖关系是通过什么维系的？维系的？l用电申请完毕后将形成用户档案，用电申请完毕后将形成用户档案，l抄表工作、电费计算、都是围绕着用户档案来抄表工作、电费计算、都是围绕着用户档案来进行的，进行的，l因此用户档案是维系这些构件的关键因素。因此用户档案是维系这些构件的关键因素。l结合前面领域模型中用户档案模型，以及核心结合前面领域模型中用户档案模型，以及核心业务架构，得到新的核心业务架构，如下图：业务架构，得到新的核心业务架构，如下图：完整的核心业务架构完整的核心业务架构 l此处的依赖关系粒度较粗，

25、需要进一步细化，此处的依赖关系粒度较粗，需要进一步细化，从小的业务构件层次来分析。从小的业务构件层次来分析。l例如：例如：“业务扩充业务扩充”构件构件l分解出了分解出了“管理申请单管理申请单”、“管理供电方式管理供电方式”等业务构件，要进一步分析这些业务构件如何等业务构件，要进一步分析这些业务构件如何与用户档案构成依赖关系甚至是业务关系。与用户档案构成依赖关系甚至是业务关系。l如果问题过于复杂，可以再次建立新的领域模如果问题过于复杂，可以再次建立新的领域模型或者概念模型帮助理清思路。型或者概念模型帮助理清思路。“管理申管理申请单请单”与与“用户档用户档案案”的业的业务架构建务架构建模模 l以此

26、类推，得到其他构件集之间的关系，关于以此类推，得到其他构件集之间的关系，关于供电企业管理系统中核心业务架构就建立完毕供电企业管理系统中核心业务架构就建立完毕了。了。进一步讨论之一：进一步讨论之一：l关于结构化设计方法和业务架构方法：关于结构化设计方法和业务架构方法：l这两种方法有着本质的差别。这两种方法有着本质的差别。l结构化设计方法得到的是子系统，功能模块。结构化设计方法得到的是子系统，功能模块。l面向对象方法中，业务架构的建立方法有着严面向对象方法中，业务架构的建立方法有着严密的推导过程。密的推导过程。l业务架构方法中，是在业务架构方法中，是在“抽取抽取”各种关系对象，各种关系对象，而结构

27、化设计更多是进行而结构化设计更多是进行“分解分解”。进一步讨论之二：进一步讨论之二：l关于业务构件和业务实体：关于业务构件和业务实体：l业务构件都是围绕一个业务实体产生的。业务构件都是围绕一个业务实体产生的。l大部分的管理类软件最核心的问题就是如何管大部分的管理类软件最核心的问题就是如何管理业务实体，而项目中任何一个功能都是处理理业务实体，而项目中任何一个功能都是处理+数据的结果，最终结果还是以数据的形式进数据的结果，最终结果还是以数据的形式进行保存。行保存。l因此业务实体非常重要，面向对象方法中，无因此业务实体非常重要，面向对象方法中，无论是用例建模还是领域建模、概念建模，最终论是用例建模还

28、是领域建模、概念建模，最终结果都是寻找场景中的实体对象。结果都是寻找场景中的实体对象。进一步讨论之二：进一步讨论之二：l关于业务构件和业务实体：关于业务构件和业务实体：l业务构件可以封装业务实体以及对业务实体的业务构件可以封装业务实体以及对业务实体的处理，也可以只封装处理逻辑。处理，也可以只封装处理逻辑。进一步讨论之三：进一步讨论之三：l关于业务架构和软件架构：关于业务架构和软件架构：l业务架构是拼图单元，研究业务构件和构件之业务架构是拼图单元，研究业务构件和构件之间的联系，间的联系，l软件架构是拼图的方法，解决如何让拼图有机软件架构是拼图的方法，解决如何让拼图有机的结合在一起工作。的结合在一起工作。l不同的软件架构使用不同的方法将业务构件单不同的软件架构使用不同的方法将业务构件单元拼接成一个系统。元拼接成一个系统。