统一建模语言UML10电力营销系统案例——系统设计.pptVIP

统一建模语言UML 电力营销系统案例——系统设计 系统分析 vs. 系统设计 前面进行了系统分析，确定了系统的框架、分析类，有类设计，也有类方法和类属性，这些工作是设计吗？ 系统分析 vs. 系统设计 分析和设计有显著的差别： 从工作任务上说： 分析是将需求进行计算机概念化，设计是将计算机概念实例化。 从抽象层次上说： 分析高于实现语言、实现方式； 设计是基于特定语言和实现方式。 系统分析 vs. 系统设计 从角色上说： 分析是系统分析员承担的； 设计的成果是设计类、程序包。 从工作成果上说： 分析的典型成果是分析模型和组件模型； 设计的成果是设计类、程序包。 将分析模型映射到设计模型 以“申请登记”这个系统用例为例，假设采用java语言进行开发。 在前述过程中，我们建立了分析模型，得到了如下所示的申请登记系统用例分析模型类图。 这个分析模型已经非常接近设计类，只需要将分析类简单的意义对应转化为设计类即可。 出于优化类结构的目的，有可能将分析类进行简单的分拆，或者做一些简单的设计工作。 用电申请边界类 考虑采用JSP来实现它。 并考虑采用两种方式实现申请数据的录入： 采用向导模式，指导用户一步步录入数据。 保留非向导模式，让熟练用户直接快速填写数据。 边界类映射到设计类结构如下： Biz_用电申请Control类 同时与来自WEB层的用户请求、来自业务规则管理库的业务规则工厂、来自软件架构中的工作流引擎和来自Entity层的EntityControl交互， 出于职责单一的面向对象设计原则，决定将其分解为四个类，每个类负责不同的职责。 分解结果如下图： 前述两个映射例子中，出于一些特殊考虑，一个分析类被映射到了多个类的情况。 对于申请边界类的映射，如果不考虑向导输入，只需要SimpleApply.jsp一个页面就购了， 对于Biz_用电申请Control，如果不考虑职责单一的原则，也可以不分解。 很多时候分析类到设计类的映射是可以一一对应的。 WEB层类分析 ActionForm分析类、用电申请action分析类，它们都是struts框架下的标准类，可以直接映射成ApplyForm和ApplyAction设计类。 实体类ent_申请单po，也可以简单的映射成为ApplyFormEntity设计类。 申请登记WEB层设计模型示意图如下： * * *