原文地址：http://soft.ccw.com.cn/it/htm2010/20100604_866695.shtml
CSSPI2010中国系统与软件过程改进年会专场，“UML专家培养：架起甲乙方有效沟通的桥梁”大会于2010年6月4日下午，在北京京仪大酒店隆重召开。东软集团软件工程顾问王英辉会上做主题为“UML：良好沟通的开始”的演讲。
东软集团软件工程顾问王英辉会上做主题演讲
以下是演讲全文：
王英辉：各位来宾大家下午好！我是东软的王英辉。今天跟大家一起分享一下UML的案例，我今天演讲的主题就是“UM：良好沟通的开始”。我们大概回忆一下UML产生的历史，大约20年前正是面向对象方法比较兴旺的时候，当时有很多出名的方法。这个时候有3个泰斗级的人物：一个是Booch，一个是Rumbaugh，还有一个是Jocobson，他们想建立一个统一的面向对象的方法。但是经过努力也没有最后达到一个想法，而是产生了一个统一建模语言，这是UML的在历史。我们一般的理解，狭义的角度来讲是建模的语言，广义的来讲，UML是建模的方法，有效沟通的开始，通过UML这个方式，它可以建立起团队相关群众之间一个有效的交流，并且不只是交流，它更能够提升分析和设计的能力。
今天我们就开始跟大家一起分享这样一个案例，先介绍一下案例的背景和相关的问题。我这块介绍的是东软国内的业务线，我们从国内这个角度讲，基本上来说可以分成三类业务：一类是面向最终用户的，它是专门专注于客户领域；另一类是专注于承接来自于行业解决方案事业部的一些开发项目，它是对内的接包方；第三类是相当于做平台类的软件。这三类之间是有一个协作关系，今天主要是突出它们的协作，特意把不同的事业部的业务拿出来，分析他们内部的一些基于UML的协作。
为什么会有这样一种协作模式？公司主要是想通过专业化的方式，让不同的事业部专注于不同的领域，通过这种方式来降低专门的成本，提高产品质量，并从组织上进一步强化这样一种协作模式。在此，这样一种模式可能会产生一系列的问题，主要的问题：第一如何专注？第二如何交流？专注就是说不同的事业部如何把自己应该做好的事情给做好呢？大家闭上眼睛说一二三念专注，挣开眼睛就专注了，这个当然不太可能。专注其实需要我们对业务领域有一个深入的分析，首先来说行业解决事业部它需要对客户的业务有深入的理解，它就需要做更多的事情。软件开发的事业部需要对系统的一些开发做好工作，他也需要做很多这样的事情。在此基础之上，会产生这样一些常见的问题，比如说我们如何让相当于发包方的他能够在资产的积累上做更多的工作，如何让分包方快速的理解业务，如何让发包方驾驭整个项目，而不是让整个项目最后成为分包方的核心，这都是一系列的问题。在下面的过程当中，讲解分享一下具体的做法。
首先，我们有一个大致的分工，就是解决方案类事业部一般负责业务分析，也就是创建业务模型，创建需求模型，创建一个分析模型，并且详细描述系统的应用架构。软件开发事业部主要负责理解业务、需求和分析模型，并创建详细的设计模型。除此之外，还有很多其他的事情这里没有说，比如说最基本的软件开发事业部，他需要完成系统的开发。
说一下发包方或者说行业解决方案事业部做这个业务模型，他在做这个过程当中，首先是需要做几件事情，就是业务分析，业务分析一个是动态方面，一个是静态方面。动态方面就是业务流程分析，换句话说就是识别出一个组织有哪些流程。比如说一家电力企业征收电费的时候，最开始是从抄表开始，中间有核算，中间再有收费，最后把这个钱交给上一级的公司。这中间我们首先需要识别一系列的业务流程，这里我们就需要通过UML的方式把它表达出来。当然，UML它可以表达内容。
这是一个示意图，通过这样一个过程，我们会让流程方面的资产得到梳理和整理。除此之外，还会对它的静态方面进行梳类，通过对它内部组织的一种结构、角色和职责进行一些划分，通过这个方式进一步理解一个目标内部具体的分工是什么样的，也就是说我们代建系统的目标组织到底面临一个什么样的问题。
其次，我们还会对目标组织，也就是相关角色、相关实体做一些分析。通过这个，去更进一步的认识到整个企业的角色、职责和流程当中的协作关系，从而进一步搞清楚信息系统应该在哪些地方起到一个支撑的作用。换句话说，整个业务分析我们通过UML做如下这样三件事情，理解业务，也就是说我们通过流程分析和组织的静态分析，首先认准客户的业务是什么，他的问题是什么，然后对这两个方面进行优化，最后一步是探索他在什么地方和什么时机应该进行信息化和自动化。通过业务分析，我们主要输出两个内容，也是和UML相关的，一个是系统的用例，我们在建系统应该有哪些核心功能；再一个是系统的应用架构。
这个就是从我们模型当中输出的内容，系统应该具有哪些功能。这个一般是通过UML当中的活动图直接输出的。一般来说，我们把每一个上面的参与者，如果说他相关的活动有信息系统相关的工作，那就把它识别成一个系统当中的Actor，把他一系列连续的活动合并起来，有可能就做成这个Actor相关的系统用例。在我们做需求的时候，除了定义用例模型之外，我们会对用例模型做进一步的细化，针对每一个用例规划它的基本步骤。比如说这是一个在项目管理当中完成任务的基本步骤，在我们没有编写一个详细的用例规约的时候，我们是通过UML的方式，把完成任务的基本步骤给描述出来。
当然，需求里面不只是UML表达的那一部分，还有很多非功能性需求，包括系统的原型还是通过文档的方式表达出来的，这些都是发包方要做的工作。除此之外，他要想驾驭整个项目，我们认为他需要做好分析模型和架构设计，只有这样，他才能够驾驭得了整个项目。我们知道，分析和设计从另一个纬度来看，还可以分详细的分析和架构分析，设计也可以分成详细的设计和架构级的设计。在这里面，我们一般强调是分析，在发包方这个角度讲，详细分析和架构分析都要做，架构设计和详细设计中主要是做架构设计，详细设计和开发都是接包方来做。分析模型主要是建立这样一些东西，首先是领域的概念，这个就是我们用UML表达的一个概念模型，是有关安全管理的。
其次我们会对整个系统做一下逻辑上的分包，这个分包会构成系统的初始架构，换句话说我们会对包括实体在内的分析类、边界类、实体类按照一定的规则进行分包，形成系统的原始结构，这个原始结构应该从业务领域去实现这样一个结构，这样的结构是将来整个系统架构的基础。这也是在发包方来做的，做这件事会使他对领域的控制类进一步加强。
除此之外，我们还会对用例做进一步的分析。发包方需要做这件事情，也就是说他会对用例的实现过程进行分析，这个主要是概念上的实现过程，我们知道用例分析不会包含太多技术因素或者说非功能性的因素，主要还是站在领域的角度来看待业务领域的。我们之所以要做这个分析模型，还是希望发包方在业务领域这个角度控制住核心资产。
从架构设计这个角度来控制核心资产，我们主要是定义逻辑架构、实现架构、进程架构和部署架构，从几个纬度去定义。首先逻辑架构它主要来源于分析模型当中的分析包，这里面唯一的一个区别就是加入了很多非功能性需求。我们知道，在做分析的时候，常常不考虑比如说性能、可靠性的问题，在这个时候我们会加入一些考虑，会对这些分析包加以调整，最后会形成这样的一个结构。我们经常采用的一种架构模式应该说是三种模式的混合，主要是按通用程度分成、按职责分成和组件化这样三种模式形成的架构。
我们还会以整个系统的原代码架构加以定义，比如一个系统分成几个项目，在哪些团队对应哪些项目，这些原代码之间的依赖关系是什么，我们会通过这种方式把它定义出来。其次，还会对可执行的代码进行一些定义，也就是说整个系统目标产生出来之后，它要输出一些什么样的可执行性文件或者是库，库之间的关系组成是什么样子的，也会对它进行一些详细的定义，定义完之后也是接包方要遵循的。最后我们会对整个系统的部署结构做一个定义，这个有可能跟接包方关系不是特别大，因为接包方很少对系统的部署有很多的影响。但是整个的部署实际上是接包方设计软件系统时候的一个约束，这个也是从发包这个角度来讲需要详细定义的一个结构。
刚才简要介绍了一下从发包这个角度，他怎么从整体上驾驭我们的项目。现在站在另一个视角，从承接项目这个角度讲，他如何让做好的系统将来可以被承接方做一些维护，这样就要求他做一些详细的设计。当然还有开发的工作，要想达到这样一个目标，我们实际上采用了这样一些方式，主要对系统常见通用的模式加以总结。
我们知道软件的一些内在结构，比如说展现层的结构、业务层的结构是什么样子的。这是一个展现层的结构，这是一个领域层的结构（PPT），我们可以通过常用的模式加以定义。除了这些结构之外，对事物如何处理都是可以总结出一些通用的模式，这些通用的模式在基础软件事业部会有一个统一的定义，在这里会有一个选择，选择之后会成为项目的规范，这个规范加强了发包方和接包方之间的约束。
除此之外，还需要对整个系统组建内部具体有哪些设计类和设计类之间的关系做出一些描述，以及设计类之间如何协作都有一些描述。整个过程我们是用UML的方式来执行的，在UML背后，我们执行的是东软AUP的方法，AUP是统一的过程，AUP是东软根据自己的特点创建的一个东软的统一过程。在实践使用这样一个方法的背后，我们还是取得了比较大的成效，首先来说，它降低了发包方与承包方之间的沟通成本，UML是一种比较高的语言，它可以避免一些自然语言的二次性。其次可以增强了同外部合作方的协作能力。
因为UML越来越多的被更多的企业所采用，做一个比较大的项目的时候，难免有很多合作方，所以大家常常还是使用一个业界公认的方式来表达我们的系统，来建好我们的系统，在这个过程当中，我们还是有比较深的体会。
除此之外，团队内部的沟通，比如说架构师设计好的系统，他想让团队的成员理解整体的架构设计，并遵循架构设计，光用语言描述是不行的，我们需要对整个架构，比如有哪些子系统，子系统之间的协作关系是什么，依赖关系是什么，接口之间的参数是什么，子系统依赖于哪些子系统，这些都应该有详细的描述，而UML在这方面有比较强的表达能力。
最后，我们通过UML积累了很多技术无关的领域资产，其实我们知道除了代码之外，我们的设计、我们的分析也是一个重要的资产，技术可能今天是PB，明天是JAVA，后天又变成脚本语言，这个时候技术在不断的变化。但是我们很多设计理念、很多领域资产的变化还是相对小一些的，我们可以通过UML的方式把它积累下来。
最后一点是我们感悟最深的，像我们初创的时候，2000年之前，基本上还是处于一种作坊式的方式，当时大家的工作都是以编码为中心，不知道什么是分析，什么是设计。在2000年之后，项目的规模不断的变大，团队动辄是三五十人，在这种情况下，分析、设计尤其重要，特别是架构分析和架构设计以及系统的定义是非常重要的。通过UML和UML的建模方法（主要是东软的AUP），我们提升了团队的业务分析系统、系统分析和架构设计的能力，这种能力实际上对东软来说是一个非常大的收益。
在这个基础之上，东软做了很多投入，首先是在UML的建模方法和UML本身的培训上面，包括邀请过很多比较著名的专家给我们做过培训，包括内部建立起来一些培训机制，都是我们对UML工作非常重视的体现。初期我们可能是以代码为中心，输出很多UML的制品，刚开始的时候，大家觉得这是一种成本，除了写代码之外，还要输出很多UML的内容，好像增加了很多工作。而实际上，这种投入在我们的实践过程中发现，它是一种必要投入，因为它可以避免你大量的返工，它加强了你分析的工作、设计的工作，使你系统更加的稳健向前推进。
在这样的背景之下，我们一直着力于UML的发展，现在越来越多的企业或者越来越多的公司都在采用UML。UML在业界也不是什么新东西，应用的也越来越多。除此之外，在国际方面，日本很多客户也是开始要求使用UML进行一些设计，所以对此我们内部关于UML有很多应对的策略，比如说在公司开展UML的培训，以UP作为公司主体的软件工程过程和方法，当然UP是基于UML的。在一些招聘当中，我们会对UML的能力提出一些要求，而且将来也会积极的鼓励很多员工参与到UML的学习与认证，或者说参与相关的一些工作当中。
这一些是我们对UML趋于不断增长的需求或者未来发展的应对方式，以上我概要的介绍了一下UML在东软的应用。谢谢大家！