电力营销系统的案例——系统分析ppt课件

1、统一建模语言统一建模语言UML电力营销系统案例电力营销系统案例系统分析系统分析确定系统用例确定系统用例l经过需求获取和需求分析，可以开始确定如何经过需求获取和需求分析，可以开始确定如何建设系统。建设系统。l确定系统范围确定系统范围l不同于需求范围，不是所有的需求都要在系统不同于需求范围，不是所有的需求都要在系统中实现，例如不适合在计算机系统里运行的手中实现，例如不适合在计算机系统里运行的手工任务。工任务。系统用例系统用例l从何而来？从何而来？l业务用例抽象、映射得到系统用例业务用例抽象、映射得到系统用例 例如：办理登机手续业务用例场景例如：办理登机手续业务用例场景备选系统用例分析备选系统用例分

2、析l客户出示机票和身份证客户出示机票和身份证l人工行为，无法用计算机实现，不应该被列入人工行为，无法用计算机实现，不应该被列入系统范围。系统范围。l值机人员核对身份值机人员核对身份l对于纸质机票，由人工核对，无需列入系统范对于纸质机票，由人工核对，无需列入系统范围。围。l对于电子客票，必须在系统中进行核对，应该对于电子客票，必须在系统中进行核对，应该被列入系统范围。被列入系统范围。备选系统用例分析备选系统用例分析l值机人员办理登机手续值机人员办理登机手续l值机人员需要在计算机中登记该乘客的登机记值机人员需要在计算机中登记该乘客的登机记录，应该被列入系统范围。录，应该被列入系统范围。l值机人员打

3、印登机牌值机人员打印登机牌l应该被列入系统范围，但如果单独作为一个用应该被列入系统范围，但如果单独作为一个用例不合适，因为它并不具备相对完备的目标。例不合适，因为它并不具备相对完备的目标。l它实际上是值机人员办理登机手续的一个包含它实际上是值机人员办理登机手续的一个包含用例。用例。从业务用例场景中抽象出备选系从业务用例场景中抽象出备选系统用例的方法统用例的方法l映射映射l不加修饰直接被采纳为系统用例不加修饰直接被采纳为系统用例l笼统笼统l找到备选用例在计算机中真正要做的事情找到备选用例在计算机中真正要做的事情l合并合并l备选用例不具备独立性，是其他某个事件的组备选用例不具备独立性，是其他某个事

4、件的组成部分，就要合并到该备选用例中。成部分，就要合并到该备选用例中。从业务用例场景中抽象出备选系从业务用例场景中抽象出备选系统用例的方法统用例的方法l拆分拆分l备选用例粒度很大，包含了好几件事情，就需备选用例粒度很大，包含了好几件事情，就需要进行拆分。要进行拆分。l粒度以描述一次完整的计算机交互过程为宜。粒度以描述一次完整的计算机交互过程为宜。l演绎演绎l业务用例场景中找不到备选用例，或者不合适业务用例场景中找不到备选用例，或者不合适用计算机实现，但能预见到某个可能的系统用用计算机实现，但能预见到某个可能的系统用例潜伏于场景中，就需要用演绎法找出它。例潜伏于场景中，就需要用演绎法找出它。供电

5、企业管理系统案例分析供电企业管理系统案例分析l研究如何从供电企业管理的业务用例模型中推研究如何从供电企业管理的业务用例模型中推导出供电企业管理系统的系统用例。导出供电企业管理系统的系统用例。l以低压用电申请永久用电业务用例场景为例。以低压用电申请永久用电业务用例场景为例。 系统用例分析系统用例分析l申请登记申请登记l业务员创建申请单，录入用户资料。业务员创建申请单，录入用户资料。l适合计算机处理，可以直接映射成系统用例。适合计算机处理，可以直接映射成系统用例。l分配勘察分配勘察l业务班长根据用户资料中的用户地址，将勘察业务班长根据用户资料中的用户地址，将勘察任务分配给片区勘察员。业务班长可以直

6、接选任务分配给片区勘察员。业务班长可以直接选择勘察员，也可以先查询再指定。择勘察员，也可以先查询再指定。l抽象出查询勘察员，作为分配勘察的一个扩展抽象出查询勘察员，作为分配勘察的一个扩展用例。用例。系统用例分析系统用例分析l现场勘察现场勘察l勘查员更加申请单内容打印出空白的勘察单，勘查员更加申请单内容打印出空白的勘察单，执行现场任务，并将现场情况录入计算机。执行现场任务，并将现场情况录入计算机。l打印和录入是不连续的过程，要拆分为两个系打印和录入是不连续的过程，要拆分为两个系统用例：打印勘察单、录入勘察单。统用例：打印勘察单、录入勘察单。l是否符合用电条件是否符合用电条件l是一个交互类的业务规

7、则。是一个交互类的业务规则。系统用例分析系统用例分析l业务存档业务存档l业务员将现有的工作单据收集并加入档案袋，业务员将现有的工作单据收集并加入档案袋，同时在计算机上终止业务流程。同时在计算机上终止业务流程。l收集单据是人工行为，计算机中实际执行的是收集单据是人工行为，计算机中实际执行的是终止业务流程，抽象出终止业务流程系统用例。终止业务流程，抽象出终止业务流程系统用例。l用电审批用电审批l业务班长填写是否同意的意见。业务班长填写是否同意的意见。l可直接映射为系统用例。可直接映射为系统用例。系统用例分析系统用例分析l配电审批配电审批l配电专员依据该片区变压器容量，选择适合的供电变配电专员依据该

8、片区变压器容量，选择适合的供电变压器，并填写是否同意的意见。压器，并填写是否同意的意见。l配电审批可直接抽象为系统用例，并拆分出查询变压配电审批可直接抽象为系统用例，并拆分出查询变压器容量系统用例作为扩展。器容量系统用例作为扩展。l业务收费业务收费l业务收费员计算业务费用，收取业务费，并打印发票。业务收费员计算业务费用，收取业务费，并打印发票。l拆分出计算业务费用和收取业务费用两个系统用例。拆分出计算业务费用和收取业务费用两个系统用例。l打印发票作为收取业务费用的包含用例。打印发票作为收取业务费用的包含用例。系统用例分析系统用例分析l现场施工现场施工l施工班现场接线入户，并将电气资料绘制成图，

9、扫描施工班现场接线入户，并将电气资料绘制成图，扫描并存入计算机。并存入计算机。l抽象出扫描电气资料图系统用例。抽象出扫描电气资料图系统用例。l安装电表安装电表l装表员从计量资产库中取出电表，现场安装并抄录电装表员从计量资产库中取出电表，现场安装并抄录电表底数。表底数。l从计量资产库中取出电表要填写资产出库单。从计量资产库中取出电表要填写资产出库单。l抽象出抄录电表底数系统用例，增加提交资产出库单抽象出抄录电表底数系统用例，增加提交资产出库单系统用例。系统用例。 描述系统用例描述系统用例l与描述业务用例的方法一样：与描述业务用例的方法一样：l描述系统用例过程描述系统用例过程l采用的工具：用例场景

10、、用例规约、对象模型、采用的工具：用例场景、用例规约、对象模型、用例实现、用例实现场景等。用例实现、用例实现场景等。l与业务建模不同：与业务建模不同：l视角和建模目的变为理解系统、描述系统，引视角和建模目的变为理解系统、描述系统，引入了计算机。入了计算机。l描述计算机应该怎样做，工作人员怎样操作计描述计算机应该怎样做，工作人员怎样操作计算机。算机。用例场景示例用例场景示例l选取用例列表中选取用例列表中“申请登记为例：申请登记为例：l申请登记是业务员创建申请单，录入用户资料。申请登记是业务员创建申请单，录入用户资料。l要描述业务员如何操作计算机来完成这个过程。要描述业务员如何操作计算机来完成这个

11、过程。l选择活动图来描述。选择活动图来描述。 申请登记用例场景示例申请登记用例场景示例申请登记用例场景申请登记用例场景l与业务用例场景相比，系统用例场景中出现了与业务用例场景相比，系统用例场景中出现了计算机这个泳道。计算机这个泳道。l这个场景描述的内容是一个人机交互的过程。这个场景描述的内容是一个人机交互的过程。l所谓系统建模，就是引入计算机系统以后，业所谓系统建模，就是引入计算机系统以后，业务如何通过计算机得以实现的过程。务如何通过计算机得以实现的过程。l如果采用时序图和协作图来描述用例场景，就如果采用时序图和协作图来描述用例场景，就是设计过程，是设计过程，l既然可以直接步入设计过程，为什么

12、还要绘制既然可以直接步入设计过程，为什么还要绘制活动图？活动图？l活动图相当于纲领，不容易因为要处理的信息活动图相当于纲领，不容易因为要处理的信息过多而丢失内容。过多而丢失内容。l虽然是系统设计，但系统用例仍然属于要向客虽然是系统设计，但系统用例仍然属于要向客户提交的文档范围，活动图更容易让客户看明户提交的文档范围，活动图更容易让客户看明白。白。用例规约用例规约l场景图只描述了过程，并未展示出系统实现需场景图只描述了过程，并未展示出系统实现需求的所有细节，这些细节使用用例规约来描述。求的所有细节，这些细节使用用例规约来描述。l包含计算机实现业务所需的全部细节：包含计算机实现业务所需的全部细节：

13、l人机交互的场景、计算机执行过程及分支、异人机交互的场景、计算机执行过程及分支、异常情况处理、业务规则应用、实体信息常情况处理、业务规则应用、实体信息l一切编程所需要的细节都可以在用例规约文档一切编程所需要的细节都可以在用例规约文档中显示。中显示。l申请登记用例规约：见书本申请登记用例规约：见书本P307进一步讨论之一进一步讨论之一l从业务需求到系统需求从业务需求到系统需求l系统需求要能追溯到业务需求。系统需求要能追溯到业务需求。l系统需求通过系统模型描述，以系统用例和用系统需求通过系统模型描述，以系统用例和用例规约为主要文档，描述系统如何映射现实中例规约为主要文档，描述系统如何映射现实中的业

14、务。的业务。l采用映射、笼统、合并、拆分、演绎等方法从采用映射、笼统、合并、拆分、演绎等方法从业务用例场景中找到系统用例，从而确定系统业务用例场景中找到系统用例，从而确定系统范围；范围；l再针对系统用例进行建模，通过用例场景和用再针对系统用例进行建模，通过用例场景和用例规约得到系统需求。例规约得到系统需求。进一步讨论之二进一步讨论之二l业务用例和系统用例粒度业务用例和系统用例粒度l业务建模阶段，用例的粒度以每个用例能说明业务建模阶段，用例的粒度以每个用例能说明一件完整的事情为宜，即一个用例可以描述一一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。项完整的业务流程。l用例分析，即概念建

15、模阶段，用例的粒度以每用例分析，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜；可以理个用例能描述一个完整的事件流为宜；可以理解为一个用例描述一项完整业务中的一个步骤。解为一个用例描述一项完整业务中的一个步骤。l系统建模阶段，用例视角针对计算机，以一个系统建模阶段，用例视角针对计算机，以一个用例能够描述操作者与计算机的一次完整交互用例能够描述操作者与计算机的一次完整交互为宜。为宜。l例如：供电企业管理系统中例如：供电企业管理系统中l业务用例：永久用电申请业务用例：永久用电申请l概念用例：生成申请单、安装电表、建立用户概念用例：生成申请单、安装电表、建立用户档案档案l系统用例：申

16、请永久用电系统用例图，书本系统用例：申请永久用电系统用例图，书本P304用例实现用例实现l用例只描述了系统应该做什么，是系统的需求用例只描述了系统应该做什么，是系统的需求l用例实现的目的是实现系统需求，将设想变为用例实现的目的是实现系统需求，将设想变为现实。现实。l面向对象方法中，用对象之间的交互来实现设面向对象方法中，用对象之间的交互来实现设想。想。用例实现用例实现l一个用例可能有多个实现，每个实现都是设想一个用例可能有多个实现，每个实现都是设想的一种实现方式。的一种实现方式。l用例实现视图表明了实现到需求之间的追溯关用例实现视图表明了实现到需求之间的追溯关系。系。l系统用例实现到系统用例关

17、系图如下：系统用例实现到系统用例关系图如下： 实现用例实现用例l以申请登记为例，有两种实现申请登记、批以申请登记为例，有两种实现申请登记、批量申请登记），研究如何为这两种不同的实现量申请登记），研究如何为这两种不同的实现方式建模。方式建模。l以用例场景和用例规约为基础，采用分析模型以用例场景和用例规约为基础，采用分析模型进行分析。进行分析。用例实现建模用例实现建模l要经过三个步骤：要经过三个步骤：l在用例场景中发现和定义实体对象。在用例场景中发现和定义实体对象。l用控制对象来操作和处理实体对象中的数据。用控制对象来操作和处理实体对象中的数据。每个控制对象默认包含所处理的实体对象的所每个控制对象

18、默认包含所处理的实体对象的所有处理逻辑。有处理逻辑。l用边界对象来构建接收外部指令的界面，并将用边界对象来构建接收外部指令的界面，并将指令传达给控制对象，最后将结果展示给外部。指令传达给控制对象，最后将结果展示给外部。 申请登记用例实现场景申请登记用例实现场景申请登记用例场景分析申请登记用例场景分析l创建新申请创建新申请l一条系统外部指令，需要用边界类对象接收。一条系统外部指令，需要用边界类对象接收。l展现新申请录入界面展现新申请录入界面l是一段程序处理逻辑，用控制对象来处理，并是一段程序处理逻辑，用控制对象来处理，并将结果反映到边界对象。将结果反映到边界对象。l录入申请人资料录入申请人资料l

19、是人工活动。是人工活动。l申请人资料是申请单实体对象的一部分。申请人资料是申请单实体对象的一部分。申请登记用例场景分析申请登记用例场景分析l校验用户欠费信息校验用户欠费信息l是业务规则，由业务规则管理器来处理。是业务规则，由业务规则管理器来处理。l提交申请提交申请l是系统外部指令，用边界类接收他。是系统外部指令，用边界类接收他。l校验数据准确性校验数据准确性l是内禀规则，在程序逻辑中处理它，由控制对是内禀规则，在程序逻辑中处理它，由控制对象负责。象负责。申请登记用例场景分析申请登记用例场景分析l生成新申请编号生成新申请编号l一段程序处理逻辑，用控制对象处理。一段程序处理逻辑，用控制对象处理。l

20、申请单编号作为申请单对象的一个属性处理。申请单编号作为申请单对象的一个属性处理。l保存申请单保存申请单l程序处理逻辑，用控制对象处理。程序处理逻辑，用控制对象处理。l申请单是合适的实体对象。申请单是合适的实体对象。申请登记用例场景分析申请登记用例场景分析l推进至下一个环节推进至下一个环节l一段程序处理逻辑，需要用控制对象处理。一段程序处理逻辑，需要用控制对象处理。l显示结果显示结果l一段程序处理逻辑，需要用控制对象处理。一段程序处理逻辑，需要用控制对象处理。 申请登记用例实现申请登记用例实现 批量申请登记用例实现场景批量申请登记用例实现场景 批量申请登记用例实现批量申请登记用例实现关键对象分析

21、关键对象分析l以上针对两个用例实现场景分析，可以从中得以上针对两个用例实现场景分析，可以从中得到一些关键对象以及这些关键对象的方法。到一些关键对象以及这些关键对象的方法。l得到分析类图。得到分析类图。l分析类对象实现用例场景的过程实际就是类的分析类对象实现用例场景的过程实际就是类的推导过程。推导过程。l可以借此得到初始的类以及关键的类方法。可以借此得到初始的类以及关键的类方法。 申请登记分析类图申请登记分析类图进一步讨论进一步讨论l分析类是沟通需求和设计的桥梁分析类是沟通需求和设计的桥梁l从需求到设计有着可验证的推导过程。从需求到设计有着可验证的推导过程。l为什么用分析类而不是设计类来实现用例

22、场景？为什么用分析类而不是设计类来实现用例场景？l分析类的抽象层次高于设计实现，高于语言实分析类的抽象层次高于设计实现，高于语言实现，高于实现方式，验证需求工作时可能的变现，高于实现方式，验证需求工作时可能的变化要少很多。化要少很多。l设计时不用理会复杂的设计要求，例如设计模设计时不用理会复杂的设计要求，例如设计模式的应用等，专心的为需求到实现搭桥梁。式的应用等，专心的为需求到实现搭桥梁。分析业务规则分析业务规则l业务规则中：业务规则中：l全局规则全局规则由架构师处理由架构师处理l交互规则交互规则由设计师处理由设计师处理l内禀规则内禀规则由程序员处理由程序员处理l分析业务规则的目的：分析业务规

23、则的目的：l从业务规则中发现将对系统构成重大影响的部从业务规则中发现将对系统构成重大影响的部分，将其转化为系统需求，并针对这一部分进分，将其转化为系统需求，并针对这一部分进行架构、框架、程序的设计。行架构、框架、程序的设计。分析全局规则分析全局规则l全局规则是跨用例的规则，自然也是跨业务架全局规则是跨用例的规则，自然也是跨业务架构的规则。构的规则。l全局规则在应用程序中，应该被反映为软件架全局规则在应用程序中，应该被反映为软件架构，并通过软件架构对用例产生影响。构，并通过软件架构对用例产生影响。分析全局规则分析全局规则l例如：例如：l供电企业系统中，所有的办理业务产生的相关供电企业系统中，所有

24、的办理业务产生的相关文件都要存档，原始手续文件也要存档，以保文件都要存档，原始手续文件也要存档，以保存整个业务办理过程的资料以供以后查证。存整个业务办理过程的资料以供以后查证。l以上全局规则，反映到程序中，即所有办理业以上全局规则，反映到程序中，即所有办理业务过程中的数据都要备份。务过程中的数据都要备份。l此规则将对程序产生很大影响，产生了历史数此规则将对程序产生很大影响，产生了历史数据保存问题和历史数据版本管理问题。据保存问题和历史数据版本管理问题。解决方案一解决方案一l由架构师设计历史数据版本管理框架，通过一由架构师设计历史数据版本管理框架，通过一组接口提供对历史数据的写入和查询。组接口提

25、供对历史数据的写入和查询。l同时规定业务实体类必须实现的接口和继承的同时规定业务实体类必须实现的接口和继承的超类。超类。l程序员在编程过程中，可不必关注历史数据版程序员在编程过程中，可不必关注历史数据版本管理是如何实现的。本管理是如何实现的。解决方案：历史数据管理框架示解决方案：历史数据管理框架示例例 创建历史数据过程创建历史数据过程 查询历史数据过程查询历史数据过程 分析交互规则分析交互规则l一般情况下，交互规则可以在业务用例场景、一般情况下，交互规则可以在业务用例场景、业务用例规约、系统用例场景、系统用例规约业务用例规约、系统用例场景、系统用例规约中找到。中找到。l例如：例如：l供电企业管

26、理系统中，申请登记场景中，根据供电企业管理系统中，申请登记场景中，根据用户名从欠费历史中查询该户名有无欠费记录，用户名从欠费历史中查询该户名有无欠费记录，若有记录，由人工判断该用户欠费是否属实，若有记录，由人工判断该用户欠费是否属实，若属实，应停止申请。若属实，应停止申请。该规则：该规则：l实现较为复杂：实现较为复杂：l判断过程中需要加入人工判断。判断过程中需要加入人工判断。l若采用程序处理该规则，则正常申请登记业务若采用程序处理该规则，则正常申请登记业务流程被流程被“打断打断”，l该业务规则跨用例，跨部门，若由不同的开发该业务规则跨用例，跨部门，若由不同的开发人员来开发，可能变成不同子系统，

27、不同程序人员来开发，可能变成不同子系统，不同程序包，产生许多不必要的依赖。包，产生许多不必要的依赖。解决方案：解决方案：l此例中，为避免依赖的出现，应当将这条业务此例中，为避免依赖的出现，应当将这条业务规则设计成单独的对象或模块，规则设计成单独的对象或模块，l例如可以设计一个专门用于查询欠费的类来处例如可以设计一个专门用于查询欠费的类来处理这个规则。理这个规则。欠费业务规则类示例欠费业务规则类示例 欠费业务规则实现示例欠费业务规则实现示例 对程序中的类似交互规则：对程序中的类似交互规则：l可以设计一个业务规则库来管理和解决所有的可以设计一个业务规则库来管理和解决所有的交互业务规则。交互业务规则

28、。l可采用工厂模式设计规则管理库。可采用工厂模式设计规则管理库。 l当业务程序需要应用规则时，向规则工厂当业务程序需要应用规则时，向规则工厂RuleFactory传入一个规则传入一个规则ID，l规则工厂依据规则工厂依据ID创建具体的业务规则类，如创建具体的业务规则类，如ConcreteRule1，以，以Rule接口类型返回规则接口类型返回规则应用者。应用者。 l规则应用者执行规则应用者执行execute（）方法，将条件以（）方法，将条件以HashMap的形式输入，的形式输入，l具体的规则类进行计算和逻辑判断，结果以具体的规则类进行计算和逻辑判断，结果以Object类型返回，规则应用者得到最终结

29、果。类型返回，规则应用者得到最终结果。 交互规则管理库实现图交互规则管理库实现图分析内禀规则分析内禀规则l内禀规则性质非常类似于对象的封装原则，因内禀规则性质非常类似于对象的封装原则，因此应当在对象内部程序逻辑中实现。此应当在对象内部程序逻辑中实现。l内禀规则可以单独写成一个方法，也可以单独内禀规则可以单独写成一个方法，也可以单独写成一个类。写成一个类。分析模型分析模型l用例实现描绘了系统的蓝图用例实现描绘了系统的蓝图l软件架构和框架搭起系统的骨架软件架构和框架搭起系统的骨架l分析模型的工作就是在骨架中注入血肉分析模型的工作就是在骨架中注入血肉l让系统运转起来。让系统运转起来。问题问题l在建立

30、领域模型、概念模型过程中都采用了分在建立领域模型、概念模型过程中都采用了分析类来建立模型，但是这些模型是属于不同项析类来建立模型，但是这些模型是属于不同项目阶段的，分析模型到底应该在哪个阶段使用目阶段的，分析模型到底应该在哪个阶段使用呢？呢？l凡是在项目过程中，需要对需求进行分析，得凡是在项目过程中，需要对需求进行分析，得到系统视角的理解时，都可以采用分析模型。到系统视角的理解时，都可以采用分析模型。建立分析模型的过程建立分析模型的过程l即采用分析类，将系统需求这个蓝图在软件架即采用分析类，将系统需求这个蓝图在软件架构和框架构成的骨架中注入血肉的过程。构和框架构成的骨架中注入血肉的过程。 l例

31、如：例如：l供电企业管理系统中，通过前述分析，得到了供电企业管理系统中，通过前述分析，得到了“申请登记分析类图。申请登记分析类图。要将这些分析类要将这些分析类与软件架构结合与软件架构结合起来，首先要确起来，首先要确定这些类在软件定这些类在软件架构的哪个层次架构的哪个层次中。中。软件架构软件架构l一个软件里存在许多可逻辑划分出来的部分一个软件里存在许多可逻辑划分出来的部分如处理计算的、处理界面的、处理数据的、如处理计算的、处理界面的、处理数据的、处理业务规则的），处理业务规则的），l软件架构的意义就是要将这些部分独立出来，软件架构的意义就是要将这些部分独立出来，用约定的接口和协议将它们有机的结合

32、在一起，用约定的接口和协议将它们有机的结合在一起，形成职责清晰、结构清楚的软件结构。形成职责清晰、结构清楚的软件结构。软件架构软件架构l大部分的软件架构由设计思想，加上若干设计大部分的软件架构由设计思想，加上若干设计模式，再规定一系列接口规范、传输协议、实模式，再规定一系列接口规范、传输协议、实现标准等文档构成。现标准等文档构成。l可以使用包图来描述软件架构。可以使用包图来描述软件架构。 包图描述的五层软件架构包图描述的五层软件架构l上如展示了上如展示了WEB、BusinessControl、Entity、DBControl、DB五个软件层次，下面将逐一五个软件层次，下面将逐一分析前述分析类所

33、在的层次，以及当软件架构分析前述分析类所在的层次，以及当软件架构引入分析模型后的变化。引入分析模型后的变化。分析过程：分析过程：l这两个分这两个分析类应当析类应当位于位于WEB层层 分析过程：分析过程：l用于处理业务逻辑，用于处理业务逻辑，应当属于应当属于BusinessControl层层分析过程：分析过程：l是软件架构的一个组成是软件架构的一个组成部分，与此交流的类是部分，与此交流的类是con_申请登记控制，申请登记控制，l因此它应该位于因此它应该位于BusinessControl层。层。分析过程：分析过程：l是业务规则框架的接口，是业务规则框架的接口，同样是和同样是和con_申请登申请登记

34、控制交互的，记控制交互的，l也位于也位于BusinessControl层层分析过程：分析过程：l比较特殊，比较特殊，ent_申申请单实体被转化为请单实体被转化为两种形式：两种形式：l一种是一种是WEB层和层和BusinessControl层，数据以层，数据以VO形式形式进行展现。进行展现。分析过程：分析过程：l一种是用于持久化一种是用于持久化的的PO形式，形式，lent_申请单实例位申请单实例位于不同的层次，经于不同的层次，经由由Entity层转换。层转换。l将分析类在各个层次的情况分析清楚后，将依将分析类在各个层次的情况分析清楚后，将依据前面的申请登记用例实现图，在每一层次上据前面的申请登记

35、用例实现图，在每一层次上在软件框架的规范内来实现用例场景。在软件框架的规范内来实现用例场景。WEB层实现层实现l该层采用了该层采用了Struts框架，因此框架，因此bun_申请登记申请登记边界应当遵循边界应当遵循Struts框架的规范。框架的规范。l由由MVC模式实现，由模式实现，由Page、Action、ActionForm三个单元组成。三个单元组成。lbun_申请登记边界在申请登记边界在Struts框架内的实现如框架内的实现如下图：下图： 申请登记申请登记WEB层分析模型层分析模型申请登记申请登记WEB层分析类图层分析类图 l上述是申请登记用例在上述是申请登记用例在WEB层实现，下面将层实

36、现，下面将在在BusinessControl层实现它。层实现它。l前面申请登记用例向前面申请登记用例向BusinessControl层的层的Biz_申请登记申请登记Control类发出了三条消息，将类发出了三条消息，将在在BusinessControl层实现它们。层实现它们。 申请登记申请登记WEB层分析模型层分析模型 申请登记申请登记BusinessControl层分层分析类图析类图 同理得同理得Entity层上实现的申请登记层上实现的申请登记 申请登记申请登记Entity层分析类图层分析类图 申请登记用例最终分析模型申请登记用例最终分析模型组件模型组件模型l组件可以容纳分析类或者设计类。组

37、件可以容纳分析类或者设计类。l建立组件的目的是将一些类组织在一起完成一建立组件的目的是将一些类组织在一起完成一组特定的功能。组特定的功能。何时使用组件？何时使用组件？l项目是一个分布式系统，在各个节点上部署的项目是一个分布式系统，在各个节点上部署的应用程序通常应当建立组件模型。应用程序通常应当建立组件模型。l若所实施的项目需要向第三方提供支持服务，若所实施的项目需要向第三方提供支持服务，应当为该服务建立组件模型。应当为该服务建立组件模型。l若项目需要将某部分业务功能单独抽取出来，若项目需要将某部分业务功能单独抽取出来，形成一个可复用的单元，在许多系统或者子系形成一个可复用的单元，在许多系统或者

38、子系统中使用时，可以建立组件模型。统中使用时，可以建立组件模型。何时使用组件？何时使用组件？l所实施的项目需要与其他第三方系统集成，集所实施的项目需要与其他第三方系统集成，集成的接口部分应当建立组件模型。成的接口部分应当建立组件模型。l所实施的项目采用了构件化的软件架构，如所实施的项目采用了构件化的软件架构，如SOA，应当建立组件模型。，应当建立组件模型。例如：例如：l假设供电企业管理系统业务扩展了，用户可以假设供电企业管理系统业务扩展了，用户可以通过网络自助申请，或者可以拨打呼叫中心由通过网络自助申请，或者可以拨打呼叫中心由客服代为提出申请。客服代为提出申请。 l上述情况符合两种建立组件模型

39、的条件上述情况符合两种建立组件模型的条件l若项目需要将某部分业务功能单独抽取出来，若项目需要将某部分业务功能单独抽取出来，形成一个可复用的单元，在许多系统或者子系形成一个可复用的单元，在许多系统或者子系统中使用时，可以建立组件模型。统中使用时，可以建立组件模型。l所实施的项目需要与其他第三方系统集成，集所实施的项目需要与其他第三方系统集成，集成的接口部分应当建立组件模型。成的接口部分应当建立组件模型。解决方案一：解决方案一：l由于由于Biz_申请登记申请登记Control这个业务用能被多这个业务用能被多方使用，尤其是客户自助服务系统与供电企业方使用，尤其是客户自助服务系统与供电企业管理信息系统是两个异构系统，虽然其要完成管理信息系统是两个异构系统，虽然其要完成的内容一样，但是其调用方式、消息结构、内的内容一样，但是其调用方式、消息结构