电力营销系统的案例——需求分析课件.ppt
统一建模语言UML,电力营销系统案例需求分析,统一建模语言UML电力营销系统案例需求分析,关键概念分析,需求确定后，接下来进行系统的分析和设计工作。面对复杂的需求，需要对其中的关键概念进行分析。支撑起客户整个业务架构的主线。这些主线由一些关键业务（关键用例）构成。,关键概念分析需求确定后，接下来进行系统的分析和设计工作。,需求分析的任务,找到关键的业务用例，并对它们进行分析，建立概念模型，依据概念模型搭建业务架构，为验证这个架构或者进行技术可行性分析开发系统原型。,需求分析的任务找到关键的业务用例，并对它们进行分析，建立概念,建立概念模型,建立概念模型,建立概念模型,概念模型始于业务用例，从业务模型中抽象出一些概念用例，针对概念用例进行分析，得到一些分析类和分析场景。注意：概念模型针对需求中的关键业务，业务核心来建立，非全面覆盖。概念模型由需求人员、系统分析员、软件架构员、系统设计人员共同参与。,建立概念模型概念模型始于业务用例，从业务模型中抽象出一些概念,获取概念用例,回顾电力营销系统，对于供电企业来说，最核心的业务就是：建立并管理用电用户计算电费收取电费形成供电收入这是支撑起供电企业业务的主线。,获取概念用例回顾电力营销系统，对于供电企业来说，最核心的业务,供电企业业务主线,供电企业业务主线,问题,当一条业务主线确定以后，很多业务用例都会和这条主线有关系，是不是所有与业务主线有关的用例都要挑选出来呢？不是，业务主线自然会和几乎所有的业务用例都有关系，全部进行研究不现实。只需要视情况挑选一到两个有代表性的典型业务用例就可以。,问题当一条业务主线确定以后，很多业务用例都会和这条主线有关系,例如,业务主线中“受理用电申请”其相关业务有：“申请永久用电”、“申请临时用电”，挑选最常用，最典型的“申请永久用电”。业务主线中“抄录电表示数”与其相关的业务有：“导出上月示数”、“分配抄表任务”、“录入抄表示数”等选择最有典型性、支持电费计算最终手段的“录入抄表示数”。,例如业务主线中“受理用电申请”,经过分析、探讨，决定将下图所示的业务用例挑选处理作为关键概念分析的业务用例。,经过分析、探讨，决定将下图所示的业务用例挑选处理作为关键概,找出概念用例,依据上述关键业务用例，以及业务主线需要，找出概念用例。概念用例不需要展现所有的业务用例细节，只要非常概括的展现出能够完成业务主线的那一部份即可。,找出概念用例依据上述关键业务用例，以及业务主线需要，找出概念,例如：申请永久用电业务用例场景,例如：申请永久用电业务用例场景,申请永久用电场景,包含的内容很多，但只有“生成申请单”、“安装电表”、“建立档案”这几项工作与业务主线关系最为密切。申请单是建立档案的基础安装电表是抄表的基础用户档案是电费计算的基础这三项工作齐备，业务主线就可以执行了,申请永久用电场景包含的内容很多，但只有“生成申请单”、“安装,申请永久用电业务概念用例图,申请永久用电业务概念用例图,分析概念用例,确定概念用例后，就要对概念用例进行分析。与业务用例建模过程类似：绘制概念用例场景（活动图、时序图等）找到关键对象，绘制协作图说明对象之间的关系和交互场景。要从系统的角度和抽象的角度来分析概念用例。,分析概念用例确定概念用例后，就要对概念用例进行分析。,“生成申请单”概念用例场景视图,“生成申请单”概念用例场景视图,此图与原始业务不同，这个概念用例的最终目的是生成完整的用电申请单，以建立用户档案，因此整个概念用例的场景是围绕着申请单如何从产生到完成的一系列活动建立的。依据相同的方法可以为其他概念用例绘制场景视图。,此图与原始业务不同，,获得关键对象生成申请单,从“生成申请单”场景中，分析有哪些业务对象被创建或者被修改，即可得到这个概念用例的关键对象。,获得关键对象生成申请单从“生成申请单”场景中，分析有哪些,生成申请单关键对象,生成申请单关键对象,建立概念模型,分析清楚一个概念用例，就能得到它的关键对象，这些关键对象是我们建立概念模型的基础。概念模型从抽象的系统对象视角来解释业务主线如何在计算机中运行。即用这些关键对象去实现业务主线。,建立概念模型分析清楚一个概念用例，就能得到它的关键对象，这些,关键对象如何实现业务主线？,关键对象是一些实体对象，显然不能使一个系统运行。将采用分析模型的方式来实现核心业务。分析模型采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）、实体（业务数据）。用这三个元素建立实现用例场景的对象模型。,关键对象如何实现业务主线？关键对象是一些实体对象，显然不能使,建立分析模型,分析模型中：操作者所有的操作都通过边界类进行，操作消息通过 边界类传递给控制类，控制类进行解释，执行相关的逻辑，并想实体类进行数据的存取。初步建立分析模型时，可以非常简单的将边界类、实体类、控制类串起来。,建立分析模型分析模型中：,例如：分析类场景创建申请单,例如：分析类场景创建申请单,问题：,上图仅仅说明了业务主线中一个核心业务，是否要将所有的核心业务具体化到同一副图中？仅仅一个核心业务就花费了十多步，如果整个业务在一幅图中出现就显得太过复杂。实际工作中，可以将不同的核心业务分开绘制，工作量、可读性都好得多。,问题：上图仅仅说明了业务主线中一个核心业务，是否要将所有的核,问题：,核心业务本来是紧密关联的，如果分开绘制，又如何能知道它们是怎样串在一起的呢？之前已经有了业务主线示例图说明了整个业务，针对每个核心业务有各自的概念用例场景视图，能说明业务是如何串在一起执行的。,问题：核心业务本来是紧密关联的，如果分开绘制，又如何能知道它,问题,前面的各种视图，完整的说明了小步骤如何由场景串起来，但是场景只是一个概念性的描述，而不是一个实现，单独的每一步都是一个实现（有操作者、边界类、控制类实体类），但是场景不能说明在计算机中是如何从一个核心业务跳跃到另一个核心业务的，怎么办？,问题前面的各种视图，完整的说明了小步骤如何由场景串起来，但是,软件架构,每一小步都可以理解为系统中的一个功能单一，或最小操作集。系统只有将所有的操作集有机的组合起来才能完成业务，成为一个系统，这只能由软件架构完成。软件架构在哪里呢？,软件架构每一小步都可以理解为系统中的一个功能单一，或最小操作,例如：,最简单的做法，采用数据库。,这就是C/S架构,例如：最简单的做法，采用数据库。这就是,每一步的操作都通过界面，从数据库获取所需的数据，并将结果存入数据库。数据库充当了步骤连接者的角色。步骤之间的衔接是软件架构的范畴。,每一步的操作都通过界面，从数据库获取所需的数据，并将结果存入,例如：,采用工作流来做步骤衔接的工作。,例如：采用工作流来做步骤衔接的工作。,引入工作流后分析类场景创建申请单,引入工作流后分析类场景创建申请单,也可以考虑采用消息中间件模式来实现。操作者1在完成其工作后，向消息中间件发送工作已完成的消息，该消息被传递给操作者2，操作者2凭借此消息开始工作。概念模型中，选择不同的软件架构，就会产生不同的实现方式。软件架构的选择是否合适这个业务模式，可以在绘制概念模型图的过程中被检验。,也可以考虑采用消息中间件模式来实现。,当把概念用例中所有场景都实现以后，关键概念的分析就算完成了。在此过程中，我们找到了关键对象，用关键对象实现业务场景，并引入软件架构。,当把概念用例中所有场景都实现以后，关键概念的分析就算完成了。,进一步讨论之一：,关于概念模型和领域模型二者很相似：都是从业务用例场景出发，找到一些实体类，用实体类去实现业务场景来获得业务在系统中的理解。区别是：领域模型不一定针对业务，它针对的是问题。概念模型只针对业务，它要解决的问题是需求向设计转换之前，通过概念建模这个步骤，在项目早期发现并解决问题。,进一步讨论之一：关于概念模型和领域模型,进一步讨论之二：,有关软件架构：软件架构不仅仅是一组技术框架，它只有和业务结合起来才能发挥作用。在选择软件架构时，要从业务的角度出发，而不是从技术的角度出发选择先进的、流行的架构。,进一步讨论之二：有关软件架构：,业务架构,技术架构提供了如何将构件搭建成系统的手段和办法，但是构件又是什么样子的，从哪里来的呢？面对同行业的不同单位，业务需求却差很多，做完一个项目，做另一个项目时又要重新开发，行业软件如何才能通用？,业务架构技术架构提供了如何将构件搭建成系统的手段和办法，但是,面对再复杂的迥异的需求，都可以像搭积木一样的搭建业务平台，这些积木就是： 业务架构。,面对再复杂的迥异的需求，都可以像搭积木一样的搭建业务平台，这,建立业务架构,建立业务架构的工作，类似于面向过程的结构化设计，不同的是：结构化设计方法中得到的结果是子系统、模块；面向对象设计方法中，得到的结果是业务构件。UML中，用组件来表示业务构件。,建立业务架构建立业务架构的工作，类似于面向过程的结构化设计，,建立业务架构,建立业务架构，实际上就是在对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。这些业务构件对内可以完成一个或一组特定的功能，对外有完善的接口，可以与其他业务构件共同组成更为复杂的业务功能。在面对新的系统时，可以直接使用这些构件，而不是从头开始构造零部件。,建立业务架构建立业务架构，实际上就是在对需求细致分析和深刻理,如何建立业务架构？,采用自顶向下的方法。从业务用例模型中了解业务细节，从领域模型中找到业务的若干问题的解决方案，从概念模型中找到业务骨架的实现和软件架构的方式。综合起来就是建立业务架构的重要信息来源。,如何建立业务架构？采用自顶向下的方法。,业务架构分析示例,将以前面建立的概念模型为基础，展示自顶向下建立业务架构的过程。,业务架构分析示例将以前面建立的概念模型为基础，展示自顶向下建,供电企业核心业务结构,供电企业管理系统最核心的业务是：建立并管理用电用户计算电费收取电费形成供电收入,供电企业核心业务结构供电企业管理系统最核心的业务是：,对业务名词进行一些抽象化的改动，以业务构件的形式展示这条业务主线，如下：,对业务名词进行一些抽象化的改动，以业务构件的形式展示这条,上图只是业务用例场景示例图的一个变体，粒度也很粗，但是从面向对象的角度来说，这些构件形成了我们继续抽象的基础。后续工作：每一个大的构件时由哪些小构件组成的？构件之间的依赖关系是通过什么维系的？,上图只是业务用例场景示例图的一个变体，粒度也很粗，但是从面向,每一个大的构件时由哪些小构件组成的？,概念模型对象图中的对象就是构成大构件的基础。例如：“生成申请单”对象图中的对象就是“业务扩充”大构件的基础。,每一个大的构件时由哪些小构件组成的？概念模型对象图中的对象就,生成申请单关键对象,生成申请单关键对象,将“业务扩充”这个大构件进一步分解为：,将“业务扩充”这个大构件进一步分解为：,此图还缺少一个构件，这个构件要将其他构件协同起来工作，最终的“业务扩充”构件图如下：,此图还缺少一个构件，这个构件要将其他构件协同起来工作，最,通过相同的方法可以将“抄表台帐”、“计算电费”等大构件分解成适合的小构件，最终形成业务架构。其中每个业务构件都是“专业化”的，这样就从复杂的业务中剥离了我们所需要的原件，也就是构件化开发所需要的积木。,通过相同的方法可以将“抄表台帐”、“计算电费”等大构件分解成,构件之间的依赖关系是通过什么维系的？,用电申请完毕后将形成用户档案，抄表工作、电费计算、都是围绕着用户档案来进行的，因此用户档案是维系这些构件的关键因素。结合前面领域模型中用户档案模型，以及核心业务架构，得到新的核心业务架构，如下图：,构件之间的依赖关系是通过什么维系的？用电申请完毕后将形成用户,完整的核心业务架构,完整的核心业务架构,此处的依赖关系粒度较粗，需要进一步细化，从小的业务构件层次来分析。例如：“业务扩充”构件分解出了“管理申请单”、“管理供电方式”等业务构件，要进一步分析这些业务构件如何与用户档案构成依赖关系甚至是业务关系。如果问题过于复杂，可以再次建立新的领域模型或者概念模型帮助理清思路。,此处的依赖关系粒度较粗，需要进一步细化，从小的业务构件层次来,“管理申请单”与“用户档案”的业务架构建模,“管理申请单”与“用户档案”的业务架构建模,以此类推，得到其他构件集之间的关系，关于供电企业管理系统中核心业务架构就建立完毕了。,以此类推，得到其他构件集之间的关系，关于供电企业管理系统中核,进一步讨论之一：,关于结构化设计方法和业务架构方法：这两种方法有着本质的差别。结构化设计方法得到的是子系统，功能模块。面向对象方法中，业务架构的建立方法有着严密的推导过程。业务架构方法中，是在“抽取”各种关系对象，而结构化设计更多是进行“分解”。,进一步讨论之一：关于结构化设计方法和业务架构方法：,进一步讨论之二：,关于业务构件和业务实体：业务构件都是围绕一个业务实体产生的。大部分的管理类软件最核心的问题就是如何管理业务实体，而项目中任何一个功能都是处理+数据的结果，最终结果还是以数据的形式进行保存。因此业务实体非常重要，面向对象方法中，无论是用例建模还是领域建模、概念建模，最终结果都是寻找场景中的实体对象。,进一步讨论之二：关于业务构件和业务实体：,进一步讨论之二：,关于业务构件和业务实体：业务构件可以封装业务实体以及对业务实体的处理，也可以只封装处理逻辑。,进一步讨论之二：关于业务构件和业务实体：,进一步讨论之三：,关于业务架构和软件架构：业务架构是拼图单元，研究业务构件和构件之间的联系，软件架构是拼图的方法，解决如何让拼图有机的结合在一起工作。不同的软件架构使用不同的方法将业务构件单元拼接成一个系统。,进一步讨论之三：关于业务架构和软件架构：,
