2008年9月3日

重构集团管理模式、创建 高效组织

——某特大型国有集团公司管理模式及组织机构设计项目

执笔人：李松涛

一、项目背景 　　 某特大型国有集团公司，业务经营领域分布在十多个行业，不同行业发展规模、盈利能力、价值贡献、竞争能力和管理模式等均有较大差异。业务类型上既存在面向国家计划的封闭式业务内容，又存在面向市场竞争的开放式业务内容。 　　由于历史的原因，集团公司在对下属企业的管理控制上没有形成与战略相一致的有效模式，集团总部职能定位不清晰，原有职能部门的职责已不符合当前发展的要求。因此，集团公司必须提高运营效率，适应日益激烈的外部竞争，不断创造集团业务持续发展的能力，方能顺利实现集团公司的战略目标。   　　二、项目目标及内容 　　在对集团管理现状进行了初步分析之后，项目双方就咨询服务的目标和内容达成了一致。项目目标是重构集团管控模式、完善母子公司管理和考核体系；项目的内容为设计集团管理模式，协助实施总部组织机构调整，重构系统化管理流程，完善薪酬与绩效考核体系。 　　 第一阶段的工作内容是集团管理模式及组织机构设计： 　　 "重构集团管理模式"：从集团总部的权利和价值贡献两个方面明确集团总部的管理定位，确定集团总部的关键管理职能；根据集团公司各产业板块的规模、结构、经营特点、管理水平以及其他相关因素，设计集团业务多元化下的管理模式；明确集团总部与各子公司间不同的集权分权关系，合理界定关键管理职能在总部与子公司间的界面。 　　 "创建高效组织"：依据集团总部职能定位，对总部关键管理职能进行分解，并以此为前提为客户设计合理、高效的总部组织；确定总部部门，制定部门职责。 　　 第二阶段的工作内容是重构系统化管理流程，完善薪酬与绩效考核体系。 　　  本文就第一阶段的项目进行阶段性分析。   　　三、项目工作思路 　　 针对集团公司管理面临的主要问题，中华-博略咨询系统、科学地提出了集团管理变革整体思路：确认集团战略目标，实施业务整合，明确各业务单元的发展策略；重构集团管理模式及组织机构；再造管理流程、完善制度体系；设计薪酬与绩效方案；如图1所示。　　 图 1 ：集团管理变革整体思路   　 四、管理模式及组织机构设计方案 　　 项目组在系统地诊断现有问题的基础上，综合分析各业务发展策略对集团总部管理的需求，确定集团本部对子公司的价值贡献方式，进而明确总部管理职能。 　　 1. 集团公司组织管理现状诊断 　　 该特大型国有企业集团的形成经历了部委--行政性总公司--集团公司的演变过程，造成集团总部对子公司的管理起点较低，集团母、子公司管理模式及总部组织结构很不规范。具体表现在： 　　 ① 战略目标清晰，但还没有形成与之配套的科学、系统的战略分解和实施方案；战略运营平台不健全，未能充分发挥集团的战略指导作用。 　　 ② 集团缺乏清晰的母子公司的功能定位；集团业务特点与管理模式不匹配。 　　 ③集团总部管理职能不全面；集团总部与各业务单元在管理界面的责权划分不清晰。 　　 ④ 总部组织设置及内部管理相对薄弱：现有组织机构设置不能很好的支持集团战略发展；部门职责划分不明确，职能存在缺失、交叉重叠现象较多； 集团公司尚未建立适应市场化要求的激励和绩效考核机制；在投资管理、信息化管理、财务管理、人力资源管理等方面有待加强。 　　 2. 集团管理定位和核心职能设计 　　 ① 确定集团总部管理定位，明确总部核心管理职能 　　 中华－博略咨询严格依据国家成立该集团的宗旨，从集团“行使出资人权利”和“承担保值增值”两个角度出发，综合考虑集团总部价值贡献方式，确定集团总部的管理定位： 　　 首先，"出资人权利"中通过法律赋予的"权利"确定了集团对各业务单元的"管理内容"。 　　 其次，"保值增值责任"明确了集团需通过对各业务单元的价值贡献，以实现促其发展的"义务"。 　　 结合集团的权利（管理）和义务（服务），在分析现在各业务需求和集团现状的基础上，提出了集团总部的管理定位和核心管理职能： 　　 集团总部管理定位为：战略管理责任中心、资本运营责任中心、财务监控责任中心、资源管理责任中心及运营协调责任中心； 　　 集团总部应履行的核心管理职能为：战略管理、投资管理、年度预算管理、内部审计管理、绩效考核管理、权属公司高级经营者任命管理、信息规划管理、科技管理及运营协调与监控管理。 　　 ② 确定集团总部混合多元化管理模式 　　 根据对各业务板块在发展阶段、企业规模、业务战略、业务布局、资源关联度、管理水平、信息化水平以及企业文化等因素的分析，运用集团管理模式分析模式，明确了集团总部对各业务板块的多元化管理模式，如图2、3所示。 图 2 ：集团管理模式分析模式 图 3 ：集团对各业务板块的管理模式 　　 ③ 明确集团母、子公司集、分权关系 　　 根据集团总部对各业务板块的管理模式，运用集团母、子公司集分权分析模式我们对总部九大核心职能在总部与权属公司之间进行了集分权的划分，如图4、5所示。 　　 通过集分权的划分，进一步确定了集团总部对各业务板块不同的管控程度，为集团总部有针对性的进行行业管理打下了科学的基础。 图4：集团母、子公司集分权的划分 图5：集团母、子公司集分权示例 　　 3. 集团总部组织机构设计方案 　　 组织设计过程中充分考虑集团实际情况和外部约束条件，保证具有可操作性，并为集团公司未来发展预留足够的空间。如图6所示。 图6 ：集团组织结构设计方案 　　方案设计的前提和依据：围绕组织诊断中所急需解决的问题，为实现集团定位及核心职能，充分考虑主营业务整合的需要，结合集团公司特点所应该具备的高效组织机构原则，中华-博略咨询进行了组织机构设计。设计出的三种方案分别是：     • 目标方案：为实现集团战略目标和管理职能，设计出较为理想的改革型方案；     • 过渡方案：结合集团现状和发展需要，设计出渐进式的改良型方案；     • 调整方案：主要考虑到集团人员状况和变革风险而设计的现阶段调整方案。 　　经过与客户决策层的多次讨论和印证，集团公司最终选择"调整方案"进行组织变革。 　　部门职能调整：依据三个层面的分工界面，中华-博略咨询对集团的战略管理、投资管理、资本运营等职能进行了较大调整。 　　A、战略职能。作为战略控制型集团，为充分发挥战略管理、战略指导的作用，中华-博略咨询针对集团年度综合计划与战略规划不能全面匹配、年度预算与年度综合经营计划脱钩的现状，在职能部门、专业部门以及权属公司三个层面上，确定了战略规划、年度计划、预算管理、绩效考核的管理主线，确立了战略管理在职能层、专业层、权属公司自上而下分解落实的控制主线； 　　B、投资职能。针对集团投资管理缺乏统一控制的现状，在集团投资管理上明确了职能部门和专业部门的职责分工及定位，确立了发展计划部作为集团投资集中管理部门的定位，从职能的实现上解决集团公司投资分散、没有集中控制的局面。强调投资集中管理统一控制、分专业实施、跟踪监控的原则； 　　C、资本运营职能。强化了资本运营职能，并明确了资本运营在决策层面和操作层面的职权划分。 　　层级职责划分：进一步明晰了管理界线，职能部门体现全局管理、专业部门体现专业化管理。划分了"职能部门对上（集团决策层及国家各部委），专业部门对下（集团所属各企业）"的管理，如图7所示。 图7：集团职能部门、专业部门及权属公司管理界面划分原则   　　五、实施效果 　　管理模式及组织机构设计方案得到客户方充分认可及高度评价，并于方案得到认可后的一个月内实施完毕。目前集团各部门已按新设定的管理职能进行各项管理工作，尤其是在集团战略管理、投资管理等重大职能上已经取得了明显的工作成效。 　　以上是本项目第一阶段集团管理模式及组织机构设计的情况，关于第二阶段重构系统化管理流程和完善薪酬与绩效考核体系的情况，请见下期。

转摘于:http://java.chinaitlab.com/UML/36192.html

　　引言
　　
　　随着社会生产的流程化，工作流起着越来越重要的作用。根据 WFMC 的定义，工作流（Workflow）就是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。本文将详细介绍基于UML的工作流管理系统分析与建模。
　　
　　1 工作流概述
　　
　　对工作流的研究起源于二十世纪七十年代，受网络的局限性，最初的工作流系统主要以企业内部的文档处理为主。到了二十世纪九十年代，随着Internet 技术的发展及应用，促进了电子商务应用的极大发展，使得公司与公司之间、公司内部部门之间以及子公司之间的业务相互处理成为可能，这为工作流的发展带来了很大的机遇和挑战。
　　
　　根据国际有关组织的预测，随着电子商务的发展，以数据处理为中心的数据库产品已经进入稳定发展期，以业务过程处理为中心的工作流产品将进入高速发展期。在国内，随着企业管理的规范化和规模的不断扩大，企业的计算机管理将不仅仅停留在信息资源管理上，而将向更复杂的业务过程管理迈进。
　　
　　为了实现组织目标，有关业务活动依时序或逻辑关系相互连接构成业务流程。在业务开展过程中，文档、信息或任务，依据组织规范在参与者之间传递、处理或执行。总体业务流程中，实现了基于计算机辅助处理而达到自动化的全部或部分称为工作流。也就是说，工作流是在计算机辅助下全部或部分自动执行的工作过程，该过程可运行于异质、分布的运行环境中，供多人协同工作。工作流服务器是供业务流程可视化设计、管理和控制业务流程的运行、并在实际执行过程中可动态修改业务流程的一种计算机软件平台。它使得快速开发、部署和运行企业业务管理系统、电子商务系统等成为可能。它也使得企业在复杂多变的市场环境中，为了快速适应市场的变化，在保存现有投资，现有系统不变的情况下，迅速调整业务或商务流程成为可能。如它可应用在：采购处理、各种申请、订单与报价处理、员工绩效考核、人事变动、贷款审批、索赔处理、B2B、电子商务等。
　　
　　2 工作流管理系统概述
　　
　　工作流管理系统是定义、创建和执行工作流的系统，它是一种特殊的计算机支持的协同处理（CSCW，Computer Supported CooperativeWork）软件系统。
　　
　　工作流管理系统的产生
　　
　　工作流管理系统（WfMS，WorkflowManagementSystem）是以计算机支持的分布式、协同工作业务流程的自动或半自动化为研究目标的软件系统。随着计算机网络，特别是Internet/Intranet 的迅猛发展和应用，计算机支持的分布式、协同工作的工作流系统在企、事业单位中的地位显得越来越重要，也有着广阔的前景。
　　
　　工作流管理系统是定义、创建、执行工作流的系统。开发这类软件系统就是要协调分布式、协同处理的各个节点上的活动，按照预定义的控制流程进行执行，以达到对它们的自动执行和有效的管理。开发这类软件有很大的重复性，工作流管理系统就是将这类软件的公共的流程控制部分（工作流运行服务、引擎）、管理部分和其他公共部分抽象出来，形成一种软件开发平台，用户只需要将它们的控制流程描述出来，该平台软件就可对它们的控制流程进行自动执行和有效地管理，而不需要对每次不同的应用重复地开发。
　　
　　不同工作流管理系统可以有不同的实现方法，不同的底层通讯机制，应用的范围也可能有很大的差距，但所有的工作流管理系统从用户的应用层上来看，通用工作流管理系统应该能够提供以下三个方面的功能支持：
　　
　　首先是建造功能，即对工作流的业务流程及组成这些业务流程的活动进行定义和建模。
　　
　　其次是运行控制功能，即在一定的运行环境下，负责创建、执行和控制工作流实例，激活相应的资源和应用，并完成过程中从一个活动到另一个活动的控制转移。它是整个工作流管理系统的核心部分。
　　
　　最后是运行交互功能，即在工作流实例的运行中，工作流管理系统与工作流参与者（业务工作的参与者或控制者）及外部应用程序进行交互的功能。
　　
　　由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和计算机应用，而是需要综合的、集成化的解决方案。作为一种对常规性事务进行管理、集成的技术，WfMS 的出现是必然的。它可以改进和优化业务流程，提高业务工作效率；实现更好的业务过程控制，提高顾客服务质量；提高业务流程的柔性等。
　　
　　3 工作流管理系统的组成
　　
　　一个完整的工作流管理系统中主要包括如下七个部分的部件和数据。
　　
　　a.过程定义工具
　　
　　过程定义工具被用来创建计算机可处理的业务过程描述。它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。
　　
　　b.过程定义
　　
　　过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。
　　
　　c.工作流执行子系统和工作流引擎
　　
　　工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。工作流引擎是WfMS 的核心软件组元。它的功能包括：解释过程定义，创建过程实例并控制其执行，调度各项活动，为用户工作表添加工作项，通过应用程序接口（API，Application Program Interface）调用应用程序，提供监督和管理功能等。工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。
　　
　　d.工作流控制数据
　　
　　指被工作流执行子系统和工作流引擎管理的系统数据，例如工作流实例的状态信息、每一活动的状态信息等。
　　
　　e.工作流相关数据
　　
　　指与业务过程相关的数据。WfMS 使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。
　　
　　f.工作表和工作表处理程序
　　
　　工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。工作表处理程序完成的功能有：支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。
　　
　　g.应用程序和应用数据
　　
　　应用程序可以直接被WfMS 调用或通过应用程序代理被间接调用。通过应用程序调用，WfMS 部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WfMS 的其他部件来说是不可见的。
　　
　　术语解释
　　
　　表1 工作流管理系统术语解释
　　

　　4 工作流管理系统功能分析
　　
　　前面已经介绍过，一个完整的通用工作流管理系统应当包括七个部件，这里限于篇幅的原因，只对工作流管理系统的核心部分：工作流执行子系统和工作流引擎进行分析。
　　
　　工作流管理系统核心功能
　　
　　工作流管理系统的核心组成部分称为工作流执行子系统，它为创建、初始化和执行过程实例提供了一个运行环境。
　　
　　在一个工作流执行子系统中可以包括一个或多个工作流引擎，前者是一种集中式的实现方式，而后者是一种分布式的实现方式。分布式的实现方式又可以分为同构和异构两种不同的情况。所谓同构是指在一个运行服务系统中包含了多个兼容的工作流引擎；所谓异构是指在工作流管理系统中包含了两个以上异构的工作流执行子系统。
　　
　　工作流引擎是工作流管理系统的核心软件部件。它的主要功能有：解释过程定义，控制过程实例（创建、激活、挂起、终止等），按照过程定义已确定的业务逻辑调用各项活动，为用户工作表添加工作项，维护工作流控制数据和工作流相关数据，调用应用程序，提供监督，管理和审计功能。
　　
　　工作流执行子系统涉及四种数据：工作流控制数据、工作流相关数据、组织/角色模型数据和工作表。
　　
　　第一种，工作流控制数据。指只由工作流执行子系统维护的内部控制数据，主要用于表示过程实例与活动实例的状态信息。
　　
　　第二种，工作流相关数据。指与业务过程相关的数据，他们由应用程序或由用户通过工作项处理来产生和更新，工作流引擎根据相关数据来确定过程实例的状态转移，例如过程调度决策数据、活动间的传输数据等。
　　
　　第三种，组织/角色模型数据。是描述组织结构的数据，主要用于确定工作项的执行者。
　　
　　第四种，工作表。列出了与工作流参与者相关的一系列工作项。
　　
　　5 建模实例
　　
　　5.1 创建用例视图
　　
　　用例视图从外部用户的角度捕获系统的行为。它将系统功能划分为对活动者（系统的理想用户）具有意义的事务。这些功能片被称为用例。用例通过系统与一个或多个活动者之间的一系列消息描述了与活动者的交互。其活动者包括人员、其它的计算机系统和进程。
　　
　　活动者用一个小人表示，活动者的名字标在这个小人的下方。用例用一个椭圆表示，用例的名字标在椭圆中或下方，用实线与同自身通

　

　　图1表示工作流执行子系统的用例图。活动者包括WfClient（工作流客户端）、Monitor（工作流监控端）、DefinitionDB（工作流定义数据库）、EnactmentDB（工作流运行数据库）、OrganizationDB（组织机构数据库）、ApplicationDB（应用程序数据库）、WorkItemDB（工作项数据库）、ConfigFile（工作流系统配置文件）。这里，WfClient 作为接收用户交互的界面部分，将用户所作的行为，依照固定的规则，将请求送给工作流执行子系统进行处理。Monitor 作为接收系统管理员交互的界面部分，将系统管理员对系统作出的调整，发送给工作流执行子系统进行处理。其余的DefinitionDB 等活动者，负责将工作流执行子系统每一步的操作与状态记录到数据库中，以永久保存。用例包括ResourceLocate （ 资源定位）、EngineContainer （ 引擎容器）、ProcessDefLoad（定义装载）、ProcessMonitor（过程监控）、Util（公用程序）。其中，EngineContainer 通过ResourceLocate 定位所有系统所用到的资源，表EngineContainer 用例使用ResourceLocate 用例，用带有箭头的实线表示。EngineContainer 不直接与用户交互，活动者对工作流的参与都是通过ProcessMonitor 这个工作流执行子系统的入口来进行的。EngineContainer 通过ProcessDefLoad 将现有的工作流定义装入，这样才能运行该工作流，EngineContainer 用例与ResourceLocate 用例之间是使用关系。
　　
　　这里仅给出用例ProcessMonitor 的具体功能分析。这些功能分析作为对ProcessMonitor 用例的注释，不在用例图上标识，只作为系统详细设计时的要点。对其余用例的分析方法与之类似。
　　
　　过程监督服务器作为引擎容器的一部分，主要提供外部对引擎容器的运行状况的监督，即对引擎当前运行状况的查询。
　　
　　譬如，当客户端或管理端需要了解引擎的运行状况时，首先发出一个消息请求，消息服务器接受到该消息后对消息进行解释，如果属于查询引擎的运行状况，则调用监督服务部分提供的API（应用程序接口）对引擎进行查询，然后将结果返回至请求者。
　　
　　监督服务器处理的查询请求根据请求对象的不同主要有如下内容：
　　
　　引擎容器运行状况的查询；各引擎运行状况的查询；过程定义信息的查询；过程实例信息的查询；活动实例信息的查询；工作项信息的查询；同步命令请求的响应。
　　
　　b.工作流引擎
　　

　

　　图2表示工作流引擎的用例图。其中的活动者包括EngineManager（引擎管理器）与LogFiles（日志文件）。EngineManager 负责控制工作流中所有元素的状态，是工作流调度的核心。LogFiles 阶段性将固定格式的文字记录为日志，用以保存。这里的用例有ProcessControl（控制过程实例）、TransitionControl（控制转移）、ActivityControl（控制活动）、WorkItemControl（控制工作项）、DanamaticModify（动态修改流程）、CreateLogfile（创建日志文件）。EngineManager 根据一定的条件，通过ProcessControl、TransitionControl、ActivityControl、WorkItemControl 与DanamaticModify，控制工作流各个组成元素的状态，以达到控制工作流的目的。
　　
　　c.过程监督
　　

　

　　图3表示过程监督用例图。其中的活动者包括EnactmentDB（工作流运行数据库）与engineContainer（引擎容器）。用例有EngineQuery（对引擎的查询）、ProcessDefQuery（对过程定义信息的查询）、EngineContainerQuery（引擎容器运行状况的查询）、ProcessInstanceQuery（对过程实例进行查询）、ActivityInstanceQuery（对活动实例进行查询）、WorkItemQuery（对工作项进行查询）、TransitionQuery（对转移信息查询）。
　　
　　这里仅对用例ProcessInstanceQuery 进行详细功能分析，对其余用例的分析方法与之类似。
　　
　　ProcessInstanceQuery 是对系统中的过程实例进行查询，主要包含如下内容：取得过程实例列表：得到系统中的所有过程实例的一个列表；从过程实例列表中取得一个过程实例的信息；根据给定的过程实例编号得到该过程实例的详细信息；关闭已经打开的过程实例列表；取得系统中过程实例的各种状态的一个列表；根据给定的过程实例编号查询其状态；关闭打开的过程实例列表；取得系统中过程实例的各种属性信息的列表。
　　
　　5.2 创建交互视图
　　
　　交互视图描述了实现系统行为角色之间的消息交换序列。分类角色是对交互中充当特殊角色的对象的描述。交互视图提供了系统中行为在全局的描述，显示了多个角色间的控制流程。交互视图用侧重点不同的两种图来显示：顺序图和协作图。
　　
　　消息指角色间的单向通信，从发送者到接收者的携带信息的控制流。消息可能带有角色间传递值的参数。
　　
　　顺序图和协作图均显示了交互，但它们强调了不同的方面。顺序图显示了时间顺序，但角色间的关系是隐式的。协作图表现了角色之间的关系，并将消息关联至关系，但时间顺序由于用顺序号表达，并不十分明显。每一种图应根据主要的关注焦点而使用。
　　
　　a.顺序图
　　
　　顺序图表示了随时间安排的一系列消息。每个分类角色显示为一条生命线，代表整个交互期间上的角色。消息则显示为生命线之间的箭头。顺序图可以表达场景，即一项事务的特定历史。
　　
　　顺序图以二维图表来显示交互。纵向是时间轴，时间自上而下。横向显示了代表协作中单个对象的分类角色。每个对象用方框表示，对象的名字在方框内部，并在名字的下方加下划线。每个分类角色表现为垂直列－生命线。在角色存在的时间内，生命线显示为虚线；在角色的过程激活时间内，生命线显示为双线。
　　
　　消息显示为从一个角色生命线出发至另一个角色生命线的箭头，箭头用从上而下来的时间顺序来安排。
　　
　　顺序图的一个用途是显示用例的行为序列。当行为被实现时，每个顺序图中的消息同对象的操作或状态机中迁移上的事件触发相一致。
　　

　

　　图4 表示处理请求用例的顺序图。图中五个方框分别表示五个对象：ProcessMonitor、EngineManager、Engine、EntactmentDB、Logfiles。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。
　　
　　当ProcessMonitor 接收到用户在界面上所作的操作后，将这些操作转换为固定的命令请求，发送给EngineManager。EngineManager 再根据接收到命令的类别，将命令分发给不同的Engine。Engine 则具体执行相应的命令。Engine 执行完命令后，通知EntactmentDB 修改相应的数据。接下来，Engine 再通知Logfiles 将所作的操作记录下来，以供以后查询。最后，Engine 直接将结果返回给ProcessMonitor，由ProcessMonitor将结果包装，显示给用户。
　　
　　b.协作图
　　
　　协作图对交互中存在意义的对象和链建模。对象和链仅在提供的上下文中存在意义。分类角色描述了对象，关联角色描述了协作中的链。协作图通过图形的几何排布显示交互中的角色。消息显示为附属在连接分类角色的关系直线上的箭头。消息的顺序由消息描述前的顺序号来表示。
　　
　　协作图的一个用途是表现操作的实现。协作显示了操作的参数和局部变量，以及更永久性的关联。当行为被实现时，消息的顺序与程序的嵌套调用结构和信号传递一致。
　　

　

　　图5表示对应于处理请求用例的协作图。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。这个协作图表现了处理请求用例所涉及的五个相关对象之间相互协作的关系。
　　
　　5.3 创建状态机视图
　　
　　状态机视图通过对一种对象的可能生命历史进行建模，描述了对象在时间序列上的动态行为。每个对象被认为是通过检测事件并对之响应来与外界进行通讯的孤立实体。事件表达了对象可以检测的变动－对象间的调用或显示信号、某个值的改变或时间的推移。任何影响对象的事物可以被描述成事件。真实世界发生的事情被建模成外部世界至系统的信号。
　　
　　状态指就某个特定类而言，对于发生的事件具有相同性质响应的一系列对象值。换言之，同一状态的所有对象以相同的方式响应某个事件，即对于给定的所有对象在接收到同一事件时执行相同的动作。而不同状态的对象可能对相同事件具有不同的响应，执行不同的动作。
　　
　　状态机包含由事件连接的状态。每个状态对对象生命期中的一段时间建模，该时间内对象满足一定的条件。当事件发生时，它可能导致迁移的激发，使对象改变至新状态。当迁移激发时，附属于迁移的动作可　　能被执行。状态机在UML 中显示为状态图。
　　
　　在状态机视图中，状态用带圆角的长方形表示，初始状态用实心填充的圆表示，结束状态用实心填充的圆外套一个圆圈表示。
　　

　

　　图6 表示过程实例的状态机视图。从图中可以看出，一个工作流定义的过程实例，在运行时可能有五种不同的过程，分别为初始状态、就绪状态、运行状态、挂起状态与结束状态。
　　
　　一个过程实例在初始时，均为初始状态（initial state）。根据需要，某个过程实例被创建（create），成为就绪状态（Ready）。

转摘于:http://java.chinaitlab.com/UML/38151.html

　　这段时间,使用PD做数据库模型,感觉很不错,将自已的经验总给一下.还有许多功能我没时间总结,以后有时间,继续补吧
　　
　　1 如何在PowerDesigner下建索引
　　2 如何在PowerDesigner 下建自增列
　　3 如何在PowerDesigner 下检查设计模型
　　
　　1 如何在PowerDesigner下建索引
　　
　　1 双击表设计图，出来Table Properties,在Tab 页中选择 Indexes
　　

　

　

　

　

　

　

【IT168 技术文档】

引言
    PowerDesigner支持UML1.3的所有图包括用例图、序列图和类图、活动图表和组件图表等，并全面支持UML2.0。改进了面向对象分析与设计(OOAD)分析方法并增强了与开发过程的集成。

PowerDesigner 能够帮助您构建适应现代 IT 发展的传统商务和电子商务系统，使用 Java 等面向对象的语言以及 XML 等新技术，以物理或虚拟的方式与我们的数据库技术合并。我们的目标是根据您的需求，提供随时随地访问信息、控制业务流程的能力，并通过计算机和最新技术赋予企业在当今任何市场上先拔头筹的竞争优势。

我们的分析方法和设计技术将会是多种多样的，从业务流程建模，到 UML 面向对象分析和设计，以及传统的关系建模等。本文将帮助您深入了解 UML 这项强大的技术，它可以帮助您的企业创建出高效的传统商务和电子商务系统。

面向对象的分析

    在您准备为企业作出系统和软件投资前，必须首先了解企业的实际需求，明确所部署的技术将如何帮助您的企业获取更大的成功。您可以使用 UML，借助用例图、序列图和活动图来进行分析。这些图表将帮助您规划系统的范围、动态性能、以及表现方式等。不必考虑实施细节，您希望获得的只是按照您的需求而表现的系统性能。

用例图(The Use Case Diagram)

UML 用例图提供了一个系统环境的建模方式。它能够帮助您确定系统/应用程序的外部和内部元素以及系统范围。作为图形建模模式，它在您需要与所收集的系统需求进行对话时也将有所帮助，对于研制成品的开发团队来说，更是有着举足轻重的重要性。对于企业的所有者，或第一次接触该软件产品的用户也有很大的帮助作用。用例图能够以可视化的方式，表达系统如何满足所收集的业务规则，以及特定的用户需求等信息。

在项目后期，也能够用到 UML 用例图。您可以通过用例图中定义的需求来协助测试项目的相关功能。您不仅可以验证系统性能是否无错误（无崩溃或明显的非逻辑响应），还可以验证系统运行时是否按照要求，执行了指定命令。这样，您可以测试系统是否完全满足了要求，以确信成品可以投入生产——也就是说，它已完全满足了用户的需求。

只有确保满足了合理、实用的各项需求，才能确保 IT 项目的更大成功。



序列图(The Sequence Diagram)

您可以使用 UML 序列图细化需求并对设计元素进行链接。序列图允许高层和低层对象间的交互文档。该交互在角色（与用例图中的角色相同）和类实例（运行于计算机内存中的技术对象和细节对象）之间显示。

通过序列图，您可以按照系统特定方案中事件（消息）的精确顺序来描述随时间变化的系统行为。使用序列图进行用例分析并引导设计：您可以决定将对用例图所定义的管理任务负责的系统对象类型，并决定哪种对象将管理系统内外的“会话”或通信。由于消息已从序列图中抽出，您可以描述类和接口（我们最后要编译和部署的代码元素）所需的某些关键操作（方法）。


活动图(The Activity Diagram)

UML 活动图设计用于帮助您了解系统中对象的动态变化。用于描述某一特定类或一组类如何协同工作。与序列图有所不同，活动图不是一系列与时间相关的通信，而是从一个任务到另一任务的控制转移，同时指定谁（哪个对象）对发生的任务负责。

UML 活动图也是业务流程的技术视图。可对业务工作流进行分析或在“业务流程建模”工作后可获得活动图。

活动图还可帮助构造系统内元素的详细动态视图（EJB 如何互操作等）。



通过分析推动设计

通过分析模型可捕获独立于实施细节之外的系统意向和预期行为，与使用的语言、部署的应用程序服务器或使用的体系结构都没有关系。但是，设计阶段开始后，一切都发生了变化。您必须进入生产环境的细节并将软件构建至特定的体系结构。设计是对系统的实施。

如果设计是由分析得到的，您可以更加确信所编写的系统行为的正确性，确认所开发的成果将是一个按需求构建的系统。您将获得高度成功——让用户得到所需要的系统。您还可以直接利用分析得出的信息而无需在设计过程中重新生成，从而缩减开发时间，由于不必“重新复制”任何工作，因此减少了人为错误。

通过分析，我们可获得什么呢？通过用例图可以发现对象并促进类和接口的创建。一个或更多类和接口可以实现一个角色，您可以在角色定义中直接创建类和接口。您还可以将角色链接到现有的类和接口，显示如何使用一条代码来满足所分析的多个元素。

通过序列图可以发现方法并促进类操作的创建。如果您需要向类发送消息，您可以调用该类的方法。序列图中的消息可以用来自动创建操作或链接到现有操作。您可以通过链接跟踪方法的功能，包括将哪些作为输入内容和必须返回哪些内容等等。

设计所包含的内容

您已经知道要构建的内容，现在您需要表述如何构建。您需要确定业务逻辑所在的位置：可以置于应用程序服务器的 EJB 等组件中，也可以置于使用 VB 或 PowerBuilder 等语言、作为客户端应用程序一部分的类或组件中，或者做为触发器和过程内置于关系数据库中。您需要根据需求做出一些选择，包括扩展性、安全、性能和可访问性等方面。

UML 类图和组件图将用于定义详细的技术系统静态结构。

类图 (The Class Diagram)

UML 类图、业务逻辑和所有支持结构一同被用于定义全部的代码结构。既然类图用来模拟开发中所维护的实际代码，显然它是 Java 或 PowerBuilder 等对象语言的概括性表述。您还可以使用 UML 类图来概括 XML 中的复杂结构，令其更易于开发和理解。

可以从 UML 类图上生成代码。还可以在开发过程中编辑该代码以完善、测试和部署最终运行的应用程序。由于 PowerDesigner 在对象语言和 UML 类图之间具有 1:1 的映射功能，您还可以实施反向工程代码，读取源文件并创建新的类图。您可以更深入地理解现有系统并简化集成和维护工作。


组件图(The Component Diagram)

UML 组件图将被用于在更大的黑匣视图（Black Box View）中描述高级对象的定义和相关性。它仍然是一个设计模型,并且是代码的直接概括。例如，一个 EJB 的组件标识直接链接到实施所必需的一系列类和接口，并将生成所需代码来推动最终 bean 的开发。



组件图比组件体系结构的代码层视图更容易理解和管理。还可以通过编写组件接口的文档来实现代码的共享和反复使用，用户无需（或很少）了解组件的实施细节即可在其他项目和系统中使用这些代码。

右击Customer EntityBean_CMP，选择Create/Update Class Diagram,生成如下class diagram:


循环叠代工程

世界不是一成不变的，您的 IT 项目也如此。在您了解需求，通过分析进行了设计，并构建了系统的某些元素后，必然还会遇到新的变化，如要更新定义，又或者现有用例图中存在某些需要改正的错误，代码在 IDE 和文本编辑器中被编辑以及数据库被DBA 优化等。必须管理和掌握所有需要更改的细节，以确保所构建的系统能够与业务需求保持一致。

往返工程的一个方案是当代码在开发过程中被更改时，需要在类图中反映出来。具体细节如下：
1. 创建类图并将业务逻辑元素添加到模型中
2. 生成文件系统的应用程序代码
3. 在 IDE 或文本编辑器中编辑代码
4. 编辑设计，此时忽略在生成的代码中所发生的更改
5. 对编辑内容实施反向工程，直到与现有类图一致
6. 将设计过程中完成的工作与开发时编辑的内容同步（合并）
7. 生成新代码，该代码是设计代码和开发人员更改代码的总和

当对类图进行了修改以反映新的设计内容时，应该使用同步/合并技术防止丢失开发人员的工作成果，同时允许设计人员接受或拒绝开发过程中所做的更改。这样，PowerDesigner 令 IT 能够完全控制体系结构，这正是制胜的关键。

PowerDesigner 的功能并不是仅限于此！现在设计模型已被更新，您可以将这些更改链接到分析中。有可能您在分析中发现了新的需求，可以将这一更改反映到设计中并编写代码。使用 PowerDesigner 中领先的 Compare/Merge 技术（在 September Blueprint 中讨论过），您可以在开发周期的所有模型和阶段中获得真正的往返同步。

对象图(Object Diagram)

    与类图一样，对象图也是一个 UML 静态结构图；它定义了系统在给定时刻具有的物理元素，而没有具体考虑系统的动态活动。它与代码一一对应，但与类图不同，我们现在讨论的是具体的分类器，而不是分类器定义。将对象图描述为类实例图可能最为合适。

对象图的主要用途是进行分析。类图中无法表示的类之间存在不确定的约束。我们将使用对象图来记录这些约束。而且，在我们查看所管理的具体类实例示例以阐明这些元素之间的交互作用关系时，对象图还允许我们定义具体的“What if”场景。

以下内容适用于 OO 建模的初学者：分类器是抽象的对象结构定义。分类器可以告诉我们所管理的是什么类型的数据（属性/成员表示数据元素）以及该分类器具有什么能力（操作/方法表示对象的行为）。实例是具体的分类器示例。假定定义一个名为 Customer 的类，该类具有 Name 属性。类 Customer 的实例“Jane Doe”是姓名恰为“Jane Doe”的客户。实例通常具有比分类器更丰富的含义，这是因为分类器表示某种级别的概述。收集某个分类器的若干个实例或示例可能有助于您理解其用途并更好地使用它。

因此，对象图是类图的具体形式，表示类实例样本，并且显示了键值和关系。例如，CustomerBean 类具有以下客户实例：该客户的 ID 为 52271，姓名为“John Doe”。该客户实例与三个订单实例（三份订单）相关，订单编号分别为122047、122103 和 122399。


协作图(Collaboration Diagram)

    协作图和序列图非常相似。实际上，序列图和协作图可以有效地交替使用，并可以简便的相互转换。其区别在于用户阅读和理解的方式不同。序列图具有很好的层次性，并且围绕时间构造。协作图则主要是围绕对象结构构造。通过在图中对消息进行编号可以表示消息的顺序。采用这种方式时，即使图的结构不是基于时间的，也将保持定时关系。

协作图借助于系统中元素或对象之间的交互作用，表示系统的动态方面，即在一段时间内的表现方式。它通过表示系统的静态结构来对类图和对象图进行补充，但不是借助于基于结构的关系，而是在系统对象之间传递交互作用“消息”。

构造协作图时还可以在概念级测试静态模型。在类图中定义了类实例，这些类实例之间的交互作用定义了一个具体的使用方案以及将在这些元素之间发生的内部通讯。我们还可以使用其他角色来表示系统的外部作用者和内部使用者，如用例图。

例如，我们可以建立一个订单输入系统，以供客户和销售代表使用。客户通过创建新订单与该系统交互作用。订单对象与销售对象之间进行对话，该对话由链接消息表示，在此情况下，只有两个消息：一个是来自 Orders 类的订单请求，一个是来自 Sales 类的订单确认。对一个链接上的消息数量没有限制。我们在此讨论的对话以一个订单请求开始，然后是对该订单的确认。


适用性

    协作图对于设计人员尤其重要，因为它阐明了对象的作用。您可以在序列图之前构造协作图（如果您计划构造这两个图），但通常是在完成类图之后构造协作图以说明从类中导出的对象之间的交互作用。可以使用一个或多个协作图来实现一个用例，或者将复杂行为分割成多个逻辑子行为。

状态图(Statechart Diagram)

    状态图（也称为状态机）描述了特定类或组件在其整个生命周期中不断变化时的行为。该图显示是什么触发了从一种状态向另一种状态的转换，以及在该类上调用哪些操作以提供该状态的行为或触发这种转换。例如，订单在被创建时处于初始状态。在客户确认订单正确后，订单将进入确认状态。在发货以后，订单需要从确认状态进入发货状态。


因此，每当一个类在其生命周期的不同阶段具有不同的可用选项（不同的有效行为）时，您都可以使用状态图来将这些规则和条件建模。生命周期中的每个阶段都是该对象的一种状态，而每个改变状态的触发器都代表从一种状态到另一种状态的转换。可以根据需要从某个状态转换到任意多个其它状态，也可以从其它多个状态进入某个状态。

子状态图

    若要保持状态图简单和易读，您可能发现所定义的一个或多个状态实际上涉及到更为复杂的行为，以至于它本身就可以定义为一个状态图。此时，与向主图中添加大量复杂细节的做法相比，更好的做法是将这个单独的状态分解为多个子状态，进而组成一个辅助图，以定义父状态的更为复杂的内部行为。

部署图(Deployment Diagram)

    部署图可以帮助我们确定所有代码元素在服务器、工作站和数据库中的存放位置。有的节点需要依赖硬件或软件框来运行部分业务逻辑。这些节点交互作用以演示我们开发的多个计算机和系统是如何交互作用和集成的。节点中包含将部署到数据库、应用程序或 Web 服务器中的组件实例。

部署图用于将组件实际部署到服务器中。通过定义希望组件运行的位置，我们可以快捷的映射、部署和管理分布在客户端应用程序和应用程序服务器端组件之间的业务逻辑或数据库端服务器逻辑。以下是要管理的物理体系结构的 1:1 模型。

例如，假定我们已决定实现两个 Enterprise Java Beans，并且在应用程序服务器上运行它们。下图显示了单个节点以及该节点内的两个组件（每个 EJB 一个组件）。我们可以看出 EmployeeBean 依赖于同一应用程序服务器内的 CustomerBean。


结论

    在我们借助用例图、序列图、活动图、类图和组件图完成基本 UML 建模时，我们将需要其它一些工具来定义有关系统中某些特定元素的详细信息。我们可能希望在对象图中使用精确的示例来表示对象的结构，或者借助于状态图来更多地了解在其内部具有多个复杂状态的类的行为。我们需要使用协作图从结构角度而不是从时间角度来考察系统组件之间的交互作用。最后，还需要使用部署图来显示所有系统组件在运行环境中的物理硬件或服务器中所处的位置，从而更详尽的了解分布式体系结构的使用方式。

UML 为我们提供了更加实用的图表，以便完成对业务逻辑的技术分析、设计、开发、或部署。将这 9 种图表与传统的数据建模方法和新的业务流程建模方法相结合，我们可以在从高级需求到技术和数据需求，以及物理实现的各个方面来全面了解推动软件开发的所有因素

转摘于:http://www.diybl.com/course/3_program/java/javashl/20071225/93447.html

一、 二者的出身

            　　作为世界最著名的两大CASE工具，Rational
            Rose和PowerDesigner的名声可谓如雷贯耳。Rose是当时全球最大的CASE工具提供商Rational的拳头产品，UML建模语言就是由Rational公司的三位巨头Booch、Rumbaugh和Jacobson发明的，后来Rational被IBM收购，所以Rose
            可谓出身名门，嫁入豪族。而PowerDesigner也有一段好玩的历史，作者王晓昀是一位中国人，在法国SDP软件公司工作时，由于苦觅一个好用的CASE工具未果，干脆自由开搞，整了个AMC*Designor出来，居然一炮打响，在法国卖得个“巴黎纸贵”，后来SDP被Powersoft公司收购，同年Sybase这只大黄雀又吃下了Powersoft这只螳螂，所以PowerDesigner也是惊艳出场，星光四射。
            
               
            但两者所走的明星路线却很不相同，Rose出道是时，走的是UML面向对象建模，而后再向数据库建模发展，而PowerDesigner则反其道而行之，它先是一个纯粹的数据库建模工具，后来才向面向对象建模，业务逻辑建模及需求分析建模进军，最终变成“演视歌三栖”明星。
            
               
            由于第一印象的影响，所以Rose常常给人的印象还是只是面向对象分析设计的工具，而PowerDesigner给人的印象则还停留在数据库建模工具上。其实，现在的Rose和PowerDesigner都即可以进行数据库建模，也可以进行面向对象建模，只是存在支持上的偏重而已。
            
            　　二、 二者区别概述
                 
            Rose和PowerDesigner虽然在项目分析设计领域已经成为被高度聚光的明星，但是在具体使用哪款工具的问题上，不同的公司，不同的人，出于成本，习惯抑或个人喜好，往往有自己的判断。由于笔者在不同的公司中被分别要求使用Rose或PowerDesigner进行分析设计工作，所以对二者有着较为细致的体验。
            
                
            Rose走大而全，一站式的策略，它没有将数据库设计和面向对象设计清晰地分开，仅以不同的目录来区分。而PowerDesigner将两者划分到独立的模型文件中，分别对应不同的设计环境，并通过模型之间的转换工具建立各模型的关联。即使对于数据库设计模型，PowerDesigner也需要你选择一个具体的数据库产品及其版本，以便工作环境对具体数据库敏感。所以Rose显得大而化之，而PowerDesigner则比较精细和具体化。Rose的逆向工程，文档输出，代码生成等输入输出功能上表现得比较生硬单调，PowerDesigner在逆向工程，特别是文档输出和代码生成这些功能上提供了精细的控制，让用户拥有高度的自由度。
                 
            Rose在操作体验上存在很多需要改进的地方，Rose偏向于让用户用鼠标进行操作，对键盘操作支持不好。而PowerDesigner在用户体验上得分很高，大部分操作都可以通过键盘完成，在充分熟悉其快捷键的前提下，PowerDesigner将给设计者一种行云流水的感觉，用户交互上更加人性化。此外，Rose往往占用更多的资源，容易异常退出，PowerDesigner则显得轻便稳定。所以，我个人对两者的体验就是“Rose笨拙，PD利索”。下面将具体列出Rose和PowerDesigner的一系列的区别，相信大家可以借由这些比较而见微知著，窥斑知豹，以资在选择工具时，提供参考。
            三、 模型组织和层次结构上的区别
               
            1、模型组织Rose将数据库模型和对象模型放在一起，在进行数据表模型设计时，没有特性化的东西。而PowerDesigner将两者分开，其模型组织层级关系是：工作空间->模型类型->具体语言/数据库的模型->包->文件夹->Diagram->设计元素。在创建模型文件时，会让你选择模型类型，选择模型类型后，还可以选择模型类型下语言及版本相关的细分类。不同设计模型对应软件工程的不同阶段，如业务模型和需求模型属于项目需求阶段，而对象模型属于概要和详细设计阶段，数据库模型属于详细设计阶段。它们之间虽然有很强的内在联系，但差异性也很明显，硬将两者放到一起，就象把猴子和猩猩关进同一个笼子，为了兼顾和平衡两者之间的考量，其结果是两者都得不到很好的支持。

            （Rose）

                
            PowerDesinger可以通过模型转换工具进行数据库建模和面向对象模型的相互转换。但Rose不能将对象转换为表，也不能将表转换为对象。
               
               
            2、工作空间PowerDesigner有工作空间的概念，一个工作空间下可以同时打开多个设计模型文件；而Rose同时仅能打开一个设计文件，如果在设计时，需要参考其他的Rose设计模型，则需要反复关闭现有模型，打开参考模型，显得设计上比较欠考虑。这个问题上两者的差异恰似Eclipse和JBuilder的区别，Eclipse可以同时打开多个工程，而JBuilder只能同时打开一个工程。
                 
            3、设计界面PowerDesigner的设计界面可以左右上下移动，而Rose只能向右，向下移动，此外。PowerDesigner可以将模型元素放大很多倍，而Rose只能放大到正常倍数，不过Rose的Overview工具可以使用户快速定位到设计区中特定的区域，有点类似于游戏界面中常用的小地图，挺不错；

                 　　　　　　　　　　　　　图 3 Overview工具（Rose）

               而在PowerDesigner中，你可以通过F8快捷键查看Diagram的总览图，不过只得通过放大操作定位到定位区域。

            　　　对模型和语言的支持
             　　对设计模型的支持力度和广度
            PowerDesigner对对象模型和数据库建模两者的支持力度已经大抵相等，此外，还支持概念模型、业务模型、需求模型、XML模型、信息流模型、自由模型的分析设计。不过对后面这几个模型的支持比较初级，而且在实际的应用中，这些模型用得也比较少，PowerDesigner的突出亮点还是在数据库建模和对象模型的设计上。

                 
            对于数据库模型，PowerDesigner支持20余种数据库，对于同一数据库的不同版本还提供单独的支持，以便在设计数据库模型时，提供数据库和版本相关的设计。对于面向对象模型，PowerDesigner支持11种主流语言，为对Java
            5.0提供单独的支持。
            Rose基本上可以说是一个对象模型设计工具，对数据库模型的支持相对粗糙，

内嵌的只支持Oracle
            8数据库，对其他数据库设计的支持需要通过安装插件的方式获得，且对数据库物理存储参数等较细粒度的内容支持得比较粗糙。Rose的对象模型主要支持Java、VC和VB三种语言。

             　　对Java语言的支持
            　　Rose对Java语言的支持更好，不但为不同版本的JDK提供了支持（不过Rose 2003还不支持JDK
            5.0），还为Java具体产品及设计模式（如EJB、Corba、Servlet，GOF设计模式等）提供了内嵌性的支持，这些支持直接反应在Rose的主菜单上。正因为如此，使Rose背上的沉重的历史负担，如EJB和Corba这种语言级的东西是易变且不断更新的，如何在这些具体产品的地位和影响已经降低时，对其作出割舍而又保证版本的兼容性，是摆在设计者面前的难题。

            　　PowerDesigner仅提供语言级对象设计的支持，不涉及语言内部的具体产品。其次因为它的设计工作区是和具体的模型类型及语言细分类相关的，而非在主菜单中直接提供支持，所以PowerDesigner在升级时显得更加从容一些。
            这也是为什么PowerDesigner能以每年一个版本的速度升级，而Rose在2003版本后，新版本还迟迟投入市场的内在原因，否则以IBM的财力，研发能力不至于对市场反应如果缓慢。

            　　5  输入和输出功能的比较
            　　反向工程
            从将程序代码转换为设计模型的逆向工程功能上看，Rose更象一个IDE，它会对需要逆向工程操作的程序代码进行深度语义检查，如果存在诸如程序代码引用了类库之外的类，反向工程将失败，而且在报告失败之前，窗口会陷入长时间无响应状态。
            PowerDesigner仅对需逆向工程的程序代码进行浅度语法检查，这种浅度语法检查不涉及包，类之间的关联，仅对诸如类名是否和类文件名匹配，是否少了“}”
            等语法性的内容进行检查。即便存在错误，PowerDesigner也允许你忽略错误，继续进行逆向工程操作，这种宽松的限制带来了很大的便利。

                                           
                                                           图 4逆向工程失败选择三种选择（PD）
               
            忽略错误后，PowerDesigner会尽量修补错误，例如代码中少了对应的“}”，它将会补上，类名和文件名不一致，将忽略类文件名保持类名不变。

               
            Rose一直宣扬的理念是IDE和设计工程进行双向互通：在Rose中完成模型设计后导出为IDE所用的代码，IDE编码调整后又逆向工程到Rose。理念很美，深具吸引力，但是在实现中，往往很少有开发团队会这样做。一般CASE工具只是在分析设计阶段使用，甚至很大比例的设计师仅把它当成画图的工具。
            真正进入编码开发阶段后，将加入大量设计时不涉及的类和方法，如果将这些非骨架性的东西Reverse到CASE工具中，反而会使原来清晰的设计变得雾里花，水中月。所以即使编码时，需要对原分析模型进行调整，一般也是手工去调整设计模型，而不是通过逆向工程去同步，毕竟分析设计是骨架性的，而编码是血肉性的，两者有属性上的区别。如果真的需要频繁进行的代码和UML转换，最好使用类似于Together一样的工具，它嵌入到IDE中，使代码和模型转换方便快捷。

            　　文档导出功能
            　　PowerDesigner对文档导出提供了精细的控制，你不但可以对文档所包含的内容项进行设置，还可以对内容项的格式进行设置。如导出的表结构是否包括名称、数据类型、备注等项目，这些项目在表栏中的宽度占比，颜色，字号等等，不一而足。

                PowerDesinger 12.0 还新增了一个多模型文档整合导出的Milti-Model
            Report模型，允许你以多个模型作为输入生成为统一文档，实现模型设计按阶段分开，文档又统一整合的目的。

               
            由于PowerDesigner文档导出的设置非常精细，所以要设置好一个文档导出模式实非不易。有鉴于此，PowerDesinger提供了三种常用的导出模板，用户也可以自己定义模板。通过模板可以迅速完成设计模型文档的导出工作。
            而Rose没有导出模板的概念，更不能对导出项和格式进行设置，你只能按Rose的系统内置的方式进行模型文档的发布。

            　　代码导出
                
            在导出设计模型的代码时，PowerDesigner提供了精细的控制，不但可以进行对象级别，还可以进行代码级别的控制（如是否要生成字段备注的代码，外键代码在表体代码内声明还是在表体外部声明等），而Rose没有提供代码导出的控制，也只能按其系统内部设置的方式导出代码。

                     
                                                   图 5 数据库模型导出设置（PD）
            　
                生成测试数据
               
            PowerDesigner可为数据表生成批量的测试数据，而且你还可以制定测试数据的生成规则。这个功能给初期项目的开发测试带来很大的便利。Rose中没有提供类似的功能

转摘于:http://www.cnblogs.com/mywebname/archive/2007/11/21/966751.html

1． 简介
提高软件质量，缩短开发周期, 并且使软件更能够适应业务需求的变化，以提高投资回报率，是每个企业所面临的、需要解决的关键问题。软件建模一直被认为是提高与有效控制软件质量的解决之道。近些年来为大家关注的主要是数据设计模型、对象模型、和业务流程模型。由于历史原因，面向数据架构，开发以及业务分析的建模工作总是被单独购买，彼此之间没有集成或共享信息。但是，企业不断需要更集成的建模套件，即集成化企业级建模工具，来支持在共享环境下，企业整个架构的不同方面的全面建模。

目前各主要的建模工具厂商如Sybse PowerDesigner, IBM Rational Rose, Computer Associates的ERWin等都在加强各自建模工具的融合与集成。PowerDesigner经过近20年的发展，已经在原有的数据建模的基础上，形成一套完整的集成化企业级建模解决方案（如图1所示），

融合了几种标准建模技术：传统数据库建模、使用 UML 的应用程序建模和业务流程建模。而且支持主流应用程序开发平台（如 Java J2EE、Microsoft .NET、Web Services 和 PowerBuilder，Eclipse等）以及流程执行语言（如 ebXML 和 BPEL4WS）。业务或系统分析人员，设计人员，数据库管理员DBA和开发人员都可以对其裁剪，以满足他们的特定的需要。

本文首先介绍PowerDesigner12对企业级建模支持所提供的各个模型及其之间的关系。并通过典型实例－客户订单处理子系统展示PowerDesigner12在以数据为中心的企业应用分析开发这个生命周期的全面建模的支持。

2. 企业级建模 ＝ PowerDesigner
Sybase PowerDesigner是Gartner评出的2004年全球排名第一的数据库建模工具。PowerDesigner灵活的分析和设计特性允许使用一种结构化的方法有效地创建数据库或数据仓库，并支持最新的RDBMS引擎以及数据库中的Web services和XML等功能，而且不要求严格遵循一个特定的方法学。PowerDesigner提供了直观的符号表示使数据库的创建更加容易，同时能更加简单地向非技术人员展示数据库和应用的设计。目前PowerDesigner支持60多种数据库及其不同版本，主要的数据仓库以及数据分析工具(OLAP)等

PowerDesigner是一个功能强大而使用方便的工具集，为新一代数据库应用的建模提供了全面的支持。具体地，PowerDesigner提供：
1． 需求分析模型（Requirements Model—RQM）
2． 企业业务流程模型（Business Process Model—BPM）
3． 概念数据模型(Conceptual Data Model—CDM)
4． 物理数据模型(Physical Data Model—PDM)
5． 对象模型(Object Oriented Model－OOM)
6． 信息流动模型（Information Liquidity Model—ILM）
7． XML 模型（XML Model）
8． O/R 映射支持（如Hibernate，JDO等）
并提供了强大的模型间生成、链接和同步技术（具体地转换关系见图2），比如由CDM可以生成PDM，PDM可以生成OOM，OOM可以生成

应用程序的代码，并可以从应用程序代码（如C#, Java等）生成类图（双向工程）等。并提供了冲突分析(impact analysis)，有效地评价各个模型修改带来的冲击，从而得到更好的敏捷性和可预测性。这样，用户可以根据需求分析模型(RQM)，从面向对象分析设计（OOM）开始，依次建立用例图，时序图及类图，由类图转化为CDM以及PDM；或者从结构化分析开始，依次产生流程分析模型(BPM), CDM，PDM并转化为类图等。为了支持企业团队的开发管理，PowerDesigner更进一步，建立了所有模型的统一共享环境，一套元数据库(metadata repository)，为企业级应用的分析、设计与开发提供了一个企业建模、UML和数据建模等三种建模的集成化的工作环境。

3．PowerDesigner 应用实例

3.1客户订单处理子系统需求定义
建立需求模型的目的是定义系统边界，使系统开发人员能够更清楚地了解系统需求，同时为计划迭代的技术内容提供基础，为估算开发系统所需成本和时间提供基础。 PowerDesigner提供了有效的需求建模，保证更准确的项目结果，并通过建立设计和需求的关联保证更好的可追踪性。图3给出的是客户订单处理子系统中的部分需求模型，PowerDesigner通过层次结构显示了该系统的主要功能。用户可以通过属性对话框（如图3所示），进行详细的需求描述。同时，为了进一步分析该子系统的业务需求，结构及机制，发现企业中当前存在的问题并确定改进的可能性，可以进行业务流程分析。图4给出了该子系统的最上层的企业业务模型表示。在PowerDesigner中，不仅支持业务过程建模，而且也提供了业务流程仿真，业务流程经过配置，可以导入Simul8中进行仿真，帮助用户对业务过程进行量化的评价。

由于该企业原来已经有若干Legacy子系统，包括CRM，ERP以及订单管理系统，因此，该企业提出基于XML的Web Service的集成，同时为了有效响应市场的变化，必须建立决策支持子系统，如库存趋势分析或客户响应分析等，提高企业资源的合理分配及其敏捷性。


3.2 概念数据模型 (CDM) 建模
概念数据数据模型（CDM）设计是建模过程的关键阶段，此阶段把现实世界中需要保存的信息抽象成信息世界中的实体(Entity)和关系(Relationship)，产生实体关系图(E/R Diagram)。这一阶段可以为高质量的应用提供坚实的基础。建立概念数据模型(CDM)是一项综合性的工作。通常在一个清晰的、包括全部业务过程描述的应用需求的基础上，由具有业务领域知识的专家和数据模型专家共同合作，把这些原始数据转化成数据流程图和概念数据模型。

PowerDesigner并不限制CDM的建模过程，用户可以（1）从数据项开始，“自底向上”地从最小的数据单位开始向上构造，当收集到足够的信息时进行归纳，把数据项分组放入不同的实体中，然后归纳产生域；（2）从感兴趣的对象开始，即实体开始，然后指定它们的属性。当收集到足够信息时，进行归纳产生域；图4的CDM就是根据上面的系统需求分析中的从实体选择出发，如在图3的需求模型以及图4业务过程模型中，可以抽取Customer, Order, Product等实体，逐渐完善各实体的属性，并建立它们之间的关系。（3）也可以“自顶向下”，从域开始，使用这种方法，在收集开发数据模型前，必须有某些业务问题所需要的预备知识，以此对数据进行标准化。

PowerDesigner支持非常复杂的概念模型建模，包括中间实体（Association Entity），标识符（Identifier），检验约束(包括数据项或实体属性的取值范围及有效性规则)，实体继承，复杂关系定义，如：一对多，多对一及多对多以及反身（Reflexive）与依赖关系等（见图5）。

这里需要特别指出，PowerDesigner引入了业务规则。定义了6种业务规则的类型：定义型(Definition)，事实型(Fact)，有效型(Validation)，公式型(Formula)，需求型（Requirement）和限制型(Constraint)。这些规则能够定义实体、联系的状态、数据一致性及业务表达式。在CDM转换成PDM的过程中，概念级定义的业务规则直接转换成物理级的业务规则。在PDM 中，实现业务规则需要使用特定的RDBMS 的代码（例如，触发器或存储过程）。上述功能大大增强了数据库系统的分析建模能力。

3.3 物理数据模型(PDM)建模
CDM反映了业务领域中信息之间的关系，它不依赖于物理实现。只有重要的业务信息才出现在CDM 中。PDM定义了模型的物理实现细节。例如，所选RDBMS的数据类型特征、索引定义、视图定义、存储过程定义、触发器定义等。PowerDesigner支持CDM和PDM之间的双向工程。图6是由图5所示的CDM模型自动生成的PDM模型，CDM中的实体，实体属性，标识符，联系，甚至继承关系等都将自动转换为PDM中的表，列，主键或外键，参照完整性等。用户可以通过属性对话框，修改PDM模型并反向生成并合并（Merge）原来的CDM模型。

PDM建模除了最基本的数据库建模（如表，列，主键/外键以及关系定义）的支持，还支持触发器(Trigger)和存储过程或函数的建立与优化，并建立它们与业务规则的关系。用户可以针对选择的RDBMS，进行数据库的优化设计。并且经过PDM的模型校验后，设置生成属性（自12.0后，为了提高用户设置的复用性，这些设置可以保存在模型内/外），可以生成SQL脚本，直至通过ODBC直接生成到最终的DBMS中。当然PowerDesigner还支持由DBMS的逆向生成PDM模型，即用户可以选择DBMS中现有的表，生成它们的PDM模型。整个过程都是可以迭代进行，不断完善用户的物理数据库模型。

在完成PDM建模以后，用户可以根据需求，如本书中的实例中要求基于XML的Web Service的集成，因此需要生成相应的XML模型。PowerDesigner可以根据用户的选择（如选择所需的表等）生成相应的XML模型，并提供了进一步编辑与修改环境。图7是本书实例对应的XML模型及其属性对话框。


3.4 数据仓库(Data warehouse)建模
数据仓库的作用在于从企业的应用系统中获取信息并转换到一个新的数据库，通过对新库中的历史信息和面向主题的信息进行分析，为决策提供支持。以本书的客户订单处理子系统为例，企业需要作出如下典型决策，如哪些产品最有利可图?哪些客户会为我们带来最大利益?哪些环节需要花费很高的费用?哪些市场活动运行得最好，为什么?我们有可能会失去哪些客户等等。图8是PowerDesigner建立的本书实例

相关的一个典型数据仓库，表示订单立方体(Cube)包含客户，产品，区域以及门店等维度(Dimension)，在ORDER刻面(Fact)定义了不同的评价(measures)来进行订单分析。通过这样的数据仓库，用户可以查看某个区域的某个产品的订单情况，也可查看每天的订单变化趋势等等。

PowerDesigner不但是业界知名的数据库设计工具，也是数据仓库模型设计工具。支持多种数据仓库模型，包括星型模式（Star）和雪花模式（Snowflake）。这是同行业中最优秀、最灵活的开发工具，可用来设计一个关系的或OLAP(联机分析处理)的软件仓库。

PowerDesigner在数据仓库设计工具市场中占有最大份额。它能从已有的数据库进行反向工程，从运行系统中将现存的数据结构抽取出来形成数据模型，使设计变得简单。

3.5 面向对象模型(OOM)建模
除了数据库建模，采用标准建模语言UML，对企业应用系统从需求，分析与设计，实施等不同阶段的全面建模，也是目前的主流方式。PowerDesigner支持UML1.3的所有模型从PowerDesigner11.0开始就全面支持UML2.0。

在PowerDesigner中用户可以采用典型的面向对象分析方法，如用例驱动的软件分析与开发，即由需求模型出发，建立用例图，类图及其顺序图，进而组件与部件图。同时，PowerDesigner是一个集成环境，各个模型之间可以快捷的模型同步与管理。特别地，本书实例是数据驱动的企业应用，因此，OOM可以有PDM来自动生成（如图9）。

（特别需要指出，OOM和PDM地关系等价于模型级的O/R映射关系，可以很直接地支持现有比较流行地O/R 映射地框架，如Hibernate， JDO等，在1.8节中提到Hibernate代码生成的支持。）用户在此基础上，对OOM修改，进一步定义系统的动态行为特性，如通过顺序图，活动图等。图10是订单处理子系统中的典型顺序图。当然用户在进行OOM建模的过程中，会加深对应用系统的理解，通常会对先前的PDM甚至CDM进行优化，可以利用PowerDesigner的双向工程，在重新生成并合并已有模型。


3.6 信息流模型(ILM)建模
在企业应用的分析与开发整个过程中，会有大量的模型产生，这些模型之间都存在相应的关系。PowerDesigner创新地提出信息流模型(ILM)，并通过非常直观的映射编辑器来表达模型之间的信息流动关系，大大方便了企业级建模的管理能力。图11是订单处理子系统的典型信息流模型以及信息流动关系的定义，这里表示的是PDM和OOM之间的一个信息映射关系。


3.7 程序生成的支持
在建模的基础上，PowerDesigner可以生成应用程序代码（如C#, Java等），当然也可以反向由应用程序更新相应的模型如类图（双向工程）。因此用户可以选择建模或代码优先的不同的软件开发过程。

特别地，PowerDesigner由于其内置的模型映射关系（包括O/R mapping即PDM和OOM之间的映射关系），可以很直接支持目前比较流行的ORM mapping框架，如Hibernate，JDO的支持。图12是典型的Hibernate的映射文件的代码预览。不仅如此，PowerDesigner提供了UI界面生成的支持，如现在比较流行的JSF(Java Server Faces)支持，真正实现了以数据为中心应用程序的完整的建模与开发环境。


3.8 团队开发的支持
企业级应用的开发通常都是有一个庞大的团队来完成，而且在整个软件开发过程中的不同阶段，会产生庞大的分析与设计模型，必须提供一个理想的团队开发解决方案，允许多个建模成员在一个相同的模型上同时工作，这个和传统的软件代码版本管理如CVS，ClearCase有相似之处，不同的是模型的管理粒度，如支持类图甚至类及其属性的版本管理等。PowerDesigner基于RDBMS提供了所有模型的统一共享环境，一套元数据库(metadata repository)，成为企业知识库，

图13给出了一个典型实例，具体包括：
• 元模型管理—能在一个位置上存储、管理和版本化PowerDesigner模型，以及其他类型的文档，同时全面的权限管理模型，能控制用户对模型的访问和可视化。
• 跨模型的冲突分析—知识库能为跨企业的冲突分析提供和维护完整的存储和跨模型的依赖关系。
• 软件资产管理—查找和重用跨越所有模型和项目的对象。
• 安全—基于角色的安全机制，同时伴有记录日志的功能。

4 .总结
PowerDesigner提供了一整套可以灵活组合了数据建模、UML和业务处理建模技术的集成环境，支持产品生命周期的所有阶段。

PowerDesigner利用基于可靠方法、真正的两级(概念上和物理上)关系数据库建模，设计并生成数据库，还支持数据仓库建模技术。同时，PowerDesigner使用标准的UML技术完成面向对象的设计和分析。PowerDesigner不仅加速了分析、设计与开发的全过程，也向最终用户提供了管理和访问项目的信息的一个有效的结构，真正地提供了一个“一站式”建模与设计解决方案，最大限度地增强IT企业的生产效率和迅速适应变化的能力。