统一建模语言UML电力营销系统案例——需求分析.pptVIP

统一建模语言UML 电力营销系统案例——需求分析 关键概念分析 需求确定后，接下来进行系统的分析和设计工作。 面对复杂的需求，需要对其中的关键概念进行分析。 支撑起客户整个业务架构的主线。 这些主线由一些关键业务（关键用例）构成。 需求分析的任务 找到关键的业务用例，并对它们进行分析，建立概念模型， 依据概念模型搭建业务架构， 为验证这个架构或者进行技术可行性分析开发系统原型。 建立概念模型 概念模型始于业务用例，从业务模型中抽象出一些概念用例，针对概念用例进行分析，得到一些分析类和分析场景。 注意： 概念模型针对需求中的关键业务，业务核心来建立，非全面覆盖。 概念模型由需求人员、系统分析员、软件架构员、系统设计人员共同参与。 获取概念用例 回顾电力营销系统，对于供电企业来说，最核心的业务就是： 建立并管理用电用户 计算电费 收取电费 形成供电收入 这是支撑起供电企业业务的主线。 供电企业业务主线 问题 当一条业务主线确定以后，很多业务用例都会和这条主线有关系，是不是所有与业务主线有关的用例都要挑选出来呢？ 不是，业务主线自然会和几乎所有的业务用例都有关系，全部进行研究不现实。 只需要视情况挑选一到两个有代表性的典型业务用例就可以。 例如 业务主线中“受理用电申请” 其相关业务有：“申请永久用电”、“申请临时用电”， 挑选最常用，最典型的“申请永久用电”。 业务主线中“抄录电表示数” 与其相关的业务有：“导出上月示数”、“分配抄表任务”、“录入抄表示数”等 选择最有典型性、支持电费计算最终手段的“录入抄表示数”。 经过分析、探讨，决定将下图所示的业务用例挑选处理作为关键概念分析的业务用例。 找出概念用例 依据上述关键业务用例，以及业务主线需要，找出概念用例。 概念用例不需要展现所有的业务用例细节，只要非常概括的展现出能够完成业务主线的那一部份即可。 例如：申请永久用电业务用例场景 申请永久用电场景 包含的内容很多，但只有“生成申请单”、“安装电表”、“建立档案”这几项工作与业务主线关系最为密切。 申请单是建立档案的基础 安装电表是抄表的基础 用户档案是电费计算的基础 这三项工作齐备，业务主线就可以执行了 申请永久用电业务概念用例图 分析概念用例 确定概念用例后，就要对概念用例进行分析。 与业务用例建模过程类似： 绘制概念用例场景（活动图、时序图等） 找到关键对象，绘制协作图说明对象之间的关系和交互场景。 要从系统的角度和抽象的角度来分析概念用例。 “生成申请单”概念用例场景视图 此图与原始业务不同， 这个概念用例的最终目的是生成完整的用电申请单，以建立用户档案，因此整个概念用例的场景是围绕着申请单如何从产生到完成的一系列活动建立的。 依据相同的方法可以为其他概念用例绘制场景视图。 获得关键对象——生成申请单 从“生成申请单”场景中，分析有哪些业务对象被创建或者被修改，即可得到这个概念用例的关键对象。 生成申请单关键对象 建立概念模型 分析清楚一个概念用例，就能得到它的关键对象，这些关键对象是我们建立概念模型的基础。 概念模型从抽象的系统对象视角来解释业务主线如何在计算机中运行。 即用这些关键对象去实现业务主线。 关键对象如何实现业务主线？ 关键对象是一些实体对象，显然不能使一个系统运行。 将采用分析模型的方式来实现核心业务。 分析模型采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）、实体（业务数据）。 用这三个元素建立实现用例场景的对象模型。 建立分析模型 分析模型中： 操作者所有的操作都通过边界类进行， 操作消息通过 边界类传递给控制类， 控制类进行解释，执行相关的逻辑，并想实体类进行数据的存取。 初步建立分析模型时，可以非常简单的将边界类、实体类、控制类串起来。 问题： 上图仅仅说明了业务主线中一个核心业务，是否要将所有的核心业务具体化到同一副图中？ 仅仅一个核心业务就花费了十多步，如果整个业务在一幅图中出现就显得太过复杂。 实际工作中，可以将不同的核心业务分开绘制，工作量、可读性都好得多。 问题： 核心业务本来是紧密关联的，如果分开绘制，又如何能知道它们是怎样串在一起的呢？ 之前已经有了业务主线示例图说明了整个业务，针对每个核心业务有各自的概念用例场景视图，能说明业务是如何串在一起执行的。 问题 前面的各种视图，完整的说明了小步骤如何由场景串起来，但是场景只是一个概念性的描述，而不是一个实现， 单独的每一步都是一个实现（有操作者、边界类、控制类实体类），但是场景不能说明在计算机中是如何从一个核心业务跳跃到另一个核心业务的，怎么办？ 软件架构 每一小步都可以理解为系统中的一个功能单一，或最小操作集。系统只有将所有的操作集有机的组合起