| 操作系统 办公 实用知识 设计 开发 WEB开发 移动开发 数据库 软件工程 网管 安全 管理 信息化 答疑 渠道 |
UML释义作为众多公司软件发展的战略相关因素，都在试图去寻找可以自动提高软件产品质量、减少成本和缩短市场更新周期的技术。这些技术包含有组件技术、可视化程序设计设计、模型化技术和结构化技术，与此同时，各公司的商务方面也在寻找可以管理增长市场占有率和销售额复杂系统的技术。
在细节上，人们共识是需要解决重复建模的问题。比如：物理分割(可分割性)、协同性、可复用性、安全性、鲁棒性和容错性。又，为之3W（WWW）的发展,一些简单产品的定制就会恶化这些建模问题，UML为之设计并产生。 UML(统一建模语言)是为软件系统的制品进行详述（specifying）、形象化（visualizing）、构建（constructing）、文档化（documenting）的一种语言。同样，对于商业模块和其他非软件系统，UML描述也是一个优秀的成功地提供大而复杂模板的工程实施的集合。 其实，对UML的定义仅仅是个对UML理解的范畴，在“栏目的致辞”我采用是对UML的创建的几家公司的定义和说明，对定义的译文在国内是不一致，这个没关系，大家先来理解，理解完了再具体地谈谈定义。 针对中国汉语的复杂性，我在此处作些强调，“Modeling”是名词来动作的，表示建模的这一个过程，我为什么要此说明这问题呢？因为这词性的使用也可以表示一定的意义。我在“栏目的致辞”中已经述说了UML的三个实质：System,Mothods and Processes，而“Modeling”一词是针对该三个实质进行描述的。 UML是Rational软件公司及其合作伙伴发展而来的，是被创建在Booch, OOSE/Jacobson, OMT和其他一些方法的基础上，大量的公司在他们开发程序和产品时也以此UML为标准，包含了一些如：商业模板（原始需求描述）、需求管理、分析和设计、编码和测试的标准。 模板实施的重要性 为了工业软件系统地发展而提前构建和革新一个模板，其实质性类似有一个建筑蓝图。好的模板实质是为连接众多的项目团队和稳固构件（已有的或以实施的模板和构件）。针对系统增长的复杂化，固然是需要好的模板技术。如此便有了附加的项目成功因素，但本质却是一个严格模板语言标准。 一个模板语言必须包括： 1．模板元素：基本的模板观念和语义。 2．符号：模板元素的可视化描述。 3．指导思想(设计原则)：内部交流的惯用词。 面对日益增长地复杂化的系统，清晰性和模型已经成为其本质，UML是完美被定义的和广泛被响应的所需接受的标准。如此而被选为组建OO系统和基于组件的系统。 UML目标 从UML设计之初,我们就没有把它当着一种设计语言,在本质上它就是把所有的人分开关在各个阁楼里,人们都使用UML进行对话,或许大家在做一件事而采用不同的程序设计语言,好象我自己都晕了,UML就是在程序设计阶段的国际通用语言。 UML是一个标准,标准不会做任何事情,但人们可以根据标准来定做很多具有良好规格的产品,OMG正是致力发展这个标准而为软件设计领域建立一个通用的模板。 关于目前世上"流行"的XML,其实也是被定义的一个标准,但XML更细节地说明于软件行业的程序设计,而UML却为程序设计语言提供设计标准。 最基本UML设计目标如下： 1． 提供待用和深度的可视化建模语言给用户，以让他们能够发展和改变那些有意义的模型。 2． 提供可扩展性和专门化机制来扩展软件（或软件模型）核心概念。 3． 依赖于详尽程序设计语言和发展程序（通常含有操作系统和工具软件）。 4． 提供合理基础去理解标准。 5． 激励日益发展的OO工具市场。 6． 支持高水准开发观念如：协作、构建、模板和组件。 7． 结合最优的练习 OMG-UML的发展空间 OMG：为对象管理组织，认识UML所必须提及的一个组织。本文的原叙述就从其对UML的定义中挖掘并翻译整理的，我不会照抄别人的东西，故加入我的叙述太多，当然我的叙述没有OMG他们该方面的学术泰斗们简洁而到位。我仅仅提供一种思想，一种对UML认识的思想。 统一建模语言(UML)首先是溶合Booch, OMT 和 OOSE观念。其结果是单一化，通用性和可为这些用户广泛使用建模语言和方法。 第二，UML推出能够处理现有模型的包装，举个例子：UML的学者们是以协作性和分布性系统模板为目标的，以致UML能充分利用该领域。 第三，UML致力于标准的模板语言，而非一个标准的程序，尽管UML必须被应用于程序的描述，经验也显示了不同组织和不同问题范围需要不同的程序。然而，浓缩的因素第一为通用的模板元素(统一语义)和第二为通用符号(提供给人们这些语义直观的表示)。UML学者们促进一个发展的使用Case为驱动,建模为中心和复用与增加的程序。 UML范围之外 UML目标是一个简单化和标准模板而不是万能语言。这给出了易于使用去设计一个多样化系统而能涵盖多行业的工业.一些UML范围之外的主要地区包括： 1．程序设计语言 UML是一个可视化建模语言,而不是扩展可视化程序设计语言，在感觉上好似都有必要可视化和语义支持以代替程序设计语言，但它并不能如你改变代码而画一条线。 UML仅仅映射于OO语言家族，如此你能够得到最好两个世界（语言的表述和设施）。 2．工具 作为工具和程序的基础，建立一种语言标准化是必要的。OMG REP最初的目标是使得工具使用的协调性，然而工具和他们的协调性切切是依靠固定的语义和符号定义，正如UML提供的。UML定义的是语义的元素模型，而不是工具接口、存储或运行期的模型，尽管这些可以同样被另一个关闭（仅仅是语义上的问题）。 3．程序 很多公司将为了它们的工程产品而采用UML作为通用语言，他们会在不同程序的中使用同样的UML图表类型，因UML具有任意程序的独立性，定义一个标准程序不是一个UML或OMG的REP的目标。 如何使UML成为OMG标准 确认性的面向对象(OO)模板语言起始出现70年代中期，在80年代末已有不同的方法论学者采用不同逼近算法去测试OO的分析和设计.产生大量的标记模板语言，在先前的1989-1994年，从至少10增加到50种。在众多的OO 方法的使用者已经很难在一种模板语言中找到100%的满意。为此开始了“方法战”，但到了90年代中期，由于这些方法的反复使用而出现技术上的合并，其中一些有明显优势的方法也绽露头角。 UML的发展开始于1994，当Rational 软件公司的Grady Booch 和 Jim Rumbaugh开始致力于统一Booch 和OMT(对象模板技术)方法。于1995末， Ivar Jacobson和他的Objectory公司加入Rational公司和他们的统一的工作并融合和OOSE(面向对象的软件工程)方法。 作为Booch、 OMT 和 OOSE 方法的基本的学者 Grady Booch、 Jim Rumbaugh 和 Ivar Jacobson被激发而创造统一模板语言，基于以下三个原因： 第一,这些方法被展开而又独立自主，创造一种在一起发展而胜过分离发展，排除一些没必要和无理由的差异而使用户糊涂的氛围。 第二,通过定义语义和符号，他们能够带来一些稳定OO市场空间，允许工程去设置成熟模型语言和使的工具可以构建更多的基于继承的有用的方法。 第三,他们希望他们的协作可以改进上述三种早期的方法，帮助他们在先前没有掌握的很好的情况下去捕获有价值的经验和问题所在。 在他们开始统一之期，他们确定了四个发展目标： 1． 能够建模的系统(并不是软件)使用OO观念。 2． 设立一个外在的耦合和执行一个制作一样的观念。 3． 专家系统,在复杂度上深度继承的确信的位置。 4． 创建一种建模语言使得机器和人都能认识。 Booch, Rumbaugh 和Jacobson努力的结果是1996 /6和1990/10 发布了UML0.9版和0.91 版,在1996年,UML的学者引入和接受从大众的反馈。 当Rational公司带来UML集合，以至致力使它达到工业标准模板语言的目的。早在1995年， Ivar Jacobson 和Richard Soley决定强制以自达到市场的标准化。在1995/6，OMG主持了所有高层的方法论学者的会议。结果是在OMG支持下第一次在世界范围内去寻找一种方法标准。 在1996年期间，有几家组织已经很清晰把UML作为他们的商业战略，RFP确信通过OMG提供了对这些组织加入RFP产生的响应力量催化剂。Rational公司确定了UML合作伙伴，将通过与之合作而加强UML1.0版。 对UML1.0版贡献有： Digital Equipment Corp、HP、 i-Logix、 IntelliCorp、 IBM、 ICON Computing、 MCI Systemhouse、 Microsoft、 Oracle、 Rational Software、 TI 和 Unisys。 这次协作的产品1.0版是有良好定义的、有表现了强大的和具有通用性的模板语言。同样，在1997/1 IBM、 ObjecTime、 Platinum Technology、 Ptech、 Taskon、 Reich Technologies 和Softeam也单独地对RFP以响应OMG。这些公司加入UML合作组织，以贡献自己的才智，并合作将其合作产品校订为UML1.1版，以提高1.0版本语义和来自新伙伴合作贡献的透明性。 UML的现状和将来 UML没有版权并对所有人开放，它从事于个人、科学团体的需求，确定基于它的优先方法的的经验。许多方法论学者、组织和工具供应商已经致力发展和使用它。UML从 Booch、 OMT、 OOSE和其他一些先进的方法中建立一套简单的语义和符号，并且把来自公众和普遍的意见的反馈中溶于UML而变得简易。 UML的两个表述＂统一＂的方面：第一，有效的解决的很多分歧，经常性不合乎逻辑，和在建模语言之前的方法。第二，（或许更重要）这个统一了很多不同系统（相对于商业软件）的观点，发展阶段（要求分析，设计和执行）和内部观点。 尽管UML定义了一个精确的语言，但是它并不是建模观念将来发展的障碍，我们已经定位了很多有阶段性领导的技术，但是期望外在的技术来影响UML将来的版本，很多高级技术基于使用UML进行定义，UML也可以扩展UML中现在没有定义的东西。 就当前形式的UML是基于很多工具，包括一些可视化的建模，仿真和发展的环境进行扩展的。作为一个有趣的工具性的综合被发展，执行的标准将基于UML日夜增加其可用性 便捷的组件技术 OMG MOF的主要的目的是提高CORBA能够使用去定义和操纵的共同使用的组件模型的集合的接口，MOF是草拟基于CORBA的分布式发展环境的结构的关键。 组件对象工具轻易地描绘出于起步于OMG在对象领域的智囊团，对象建模工具和在分布式对象环境的数据管理的成员工作．MOF指定使用统一建模语言符号．其简易的接口和语义合并一些高级组件数据管理观念并把它应用于商业对象的智囊团，对象建模工具和对象结构的产品并协同发展。 详述增强性组件数据管理和在分布式对象环境中的组件数据的协同在总体上和在分布发展环境．当初始化工作定位组件数据在对象分析和设计区的协同性．MOF将有足够支持额外的区域的希望。 例如包括覆盖应用发展的生活周期如同额外的区域（例如仓库管理和商务对象管理）的组件模型。 模板定义额外的叙述 现在的*ML的东西太多了,但UML的作用会如何了,我前些日子见有人总结关于*ML(语言模板化或多或少建模语言),在3W上文明于世的XML和古人创建现在并使用着的HTML等。 听了有点伤感,但UML的统一性在何处呢?当你苦思冥想之时,发现自己错了,UML语言并不涉及程序设计语言,或者说不愿意涉及,我是一个C++的使用者,知道模板的重要性,或许各位编程的兄弟姐妹也有同感,我们就不一把鼻涕一把泪的来说过去的伤心的历史了,展望未来吧。 摘要： 没有什么比标准更让人讨厌的了，但如果我没有标准，或者标准在别人手里我们会做什么？我们该做什么？我们该有什么心态？UML是一个标准，面对如此之好的标准，我们如何面对。 关键字：UML 心态 标准化 我已经把UML的释义（二）的一半写了出来，但发现我的说明并没有结束，其实这本来就没有结束的可能，UML1.1版的标准在我手上，但是我是国人，没有过硬的英文水准，也不便把它翻译出来，仅是从中拾点牙慧，写点东西。 但发现这是一个误区，没有想知道那UML1.1标准上说的是什么，我也觉得更多的国人关心程序本身或者UML使用的本身，我放弃原先写的释义（二）。 就是没有人知道UML本身是什么东西，我最近一直在外找项目或者做些项目，比其以前在一家成熟的软件公司来说有更大的挑战性，这个挑战性在那里？就是UML的应用本身，一位客户和我说了句真理：我是客户，我要知道的就是应用！ 无论软件开发者如何操作，目的也就是一个：使得软件界面好的，性能稳定和操作方便。我们如何达到如此的目标，有一个公司提供了一整套服务，就是Rational的建模工具。 UML是标准，是使得建模标准化的一整套标准，既然有全球知名的各家软件公司参与这个标准的建立，那它一定有其道理！ 道理就是在于没有一个公司愿意自己被抛在一个“完美”的标准外，而被社会淘汰（当然由于历史等的原因，这里面没有中国的公司，遗憾），在这个工业化的竞争如此强烈的社会，标准就是一个魔杖，打了许多没有长眼睛的公司。 如此说来的标准化的歪理，想必就没有人认为标准化的理，在很久很久以前，盖茨说过类似的话，别人说，再说就是盗版，就没有受保护的权利。标准化的另一个歪理就是有合法的外衣，这个合法的外衣而且仅有一个人穿是合身的其他的，就有些别扭，或者过敏。 我一写到如此，就想谈谈中国软件的现状，谈也就谈一点吧，自己的体会，没有什么认证的，如果有人我提意见那是最好了（uml@51CMM.COM.com）： 1．有人说我有官架子，凡什么都有一二三的，其实中国软件本身也是如此的情况，在应用软件的领域，从1.1版（有的也称Beta版）开始，在没有什么实际改动的情况下，拼命地升级，现在有的都是3000版。 2．由于历史的原因，中国的软件是小作坊式，但这种方式并不坏，坏就坏在每个人都在抱怨自己在小作坊里开发，而没有去努力改变自己的作坊模式，我在刚刚进入软件开发的行业（并没有什么自嘘的本意）的时候，整天拿着一本Roger.S.pressman软件工程和公司里的开发情况比较，我没有发现相同的东西，我也开始抱怨，但没有人理我，但开发还是按部就班的进行。我受了一句话：如果你觉得自己可以，你就上！改变它 3．又由于历史的原因，我们的软件业发展比别人落后了很多，但从今年年初，全国上下一片惊慌，好象睡了几千年，忽然起来发现自己落后了，不知所措了。其实落后有什么呢？国人便和我一样，到处找东西学，但忽而又觉得自己应该有自己的特色。现在便在各家报刊杂志上，刊登学习的心得。你认为有如此的大起大落去搞吗？落后了吗？已经成为现实，认清这个现实开始去做，至于做什么在心一定要有盘算。 4．又由于历史的原因，好象我们今天谈历史来了，不是的，历史已经存在了，并且毫无改变可能的存在着，我们得尊重它。另外一点也需要尊重，那就是别人的劳动成果。微软公司的产品在应用上存在很多的bug，这个是事实，但有一点，如果你觉得微软的东西不好，你一方面可以做一个比它好的，如果你办不到，那你还必须坐下来学习；另一方面吗？就是你去破坏它（也可以说是变相的测试），你可以找出它的不足，要求他改进。我不便再说下去了，不然就变成谈论中国软件的怪圈，这种怪圈就是没有一个建立一个良好的心态，心态其实是一个人开发出好的项目的先决条件。 UML如何跟人的心态联系起来了，其实这个问题的实质在于我们没有了解软件行业的标准，不要说我们制定标准了，这里有现成的让你了解即可。比如中国的农业，由于科学发展的较为早，农业的操作上基本上符合中国的规范，固然没有什么人在叫嚣，原因是什么，在如此的领域内我们无须去听别人的意见。虽然软件行业和农业不同，但我仅在心态上做比较。 我自己是软件方法的实践者，中间也有（而且有很多）无法实施的东西。怎么办？变通一下，换一条路来走，也许更为简洁，方便。针对UML的标准化设计也不是让用户按照死的东西去操作，而是在一个标准的平台上更好的发挥。 （The UML is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems）关于这个定义我已经解释了，这个仅仅是指UML语言本身的操作对象，即我们使用UML来做些什么，至于如何做UML并不可以定义，那么我们如何做？ 我没有打击什么的意思，也没有打击谁，仅仅是一个对国软件业的理解，站在UML提供的一套标准上，我们的观点都在改变，这就是UML“误区”的第三点。 说起标准，我比谁都差，但是现在刚赶上全球上下制定标准，乘机学习，参与。一旦参与进去心态马上就改变了，就是一个东西在你手里，你应该很塌实。 我也想告诉大家，我说到现在了，把什么东西都说变味，其实UML就是一种“语言”，虽然它不同于XML(标记语言)或GML，但它也是用来描述一种事物的特征的。至于如何使用此语言描述我们面前的软件的世界，我们接下去再谈！ 从设计程序之初我就没有打算把建模让给别人去做，我这并不是自私，引用两句名言来说明我的观点：一拿破仑：“不想当将军的士兵不是好士兵”；二张五常先生的《经济解释》“要现实公司利益的最大化，必然使得能让公司最大化的人来当排头”。 我虽然没有从出生以来就开始注意建模，但也开始学习搭积木了，大家和我一样期待着成为软件模型的设计者，但是要怎么样做，又从那开始做呢？ 在给UML栏目写东西的时候，我一直从事软件开发，是中国传统方式的操作—作坊式的，公司三五十来个人，连个软件小组都称不上。我虽然不是软件开发组的组长，但我是唯一的一个把文档整理好给别人的人。我告诉同事我的三个优点：我很会和客户打交道；我很会写一份详尽的文档；我很会整理，使得一件复杂的东西简单化。 一． 开始构想我们的软件 除了无用的哲学理论之外，我还不知道哪一件东西可以凭空产生。我们开发的软件是供别人使用，学过经济学人都知道经济开始的三个要素：为谁生产？生产什么？如何生产？ 我们可以围绕这三个因素来开始谈论软件建模： a：为谁生产 在软件的领域内我简单把该项过程考察为：软件的需求分析（在最近几期的《程序员》杂志上有高展先生的详细论述）。站在客户的角度（客户正是我们为之生产的对象），有两个方面的需求：一是该软件产品符合操作规范；二是该软件产品操作简单方便、界面友好。许多人都知道软件开发过程中的许多问题，都是由于收集、编写、协商、修改该软件产品的代码、文档（有的人把代码也列入文档）时由于失误、马虎、未确定或不明确等因素造成的。 我在软件工程上找到“客户”两个字的解释：是指直接或间接从产品中获得利益的个人或组织，包括提出要求、支付款项、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。 其实，客户的如此两个字并不能说明我们为谁生产的生产对象，作为软件的开发者已经很了解各个软件开发的差异性，假如说客户是机器（当然机器也是人操作的吗？），我们为之开发驱动程序、操作系统等；如果是商业使用我们为之做CRM、ERP等商务软件或与其相关的财务软件。如此说明就象我们是在建造商务楼还是在造民房。 当然为谁生产的本质并不重要，因为它们在实现起来是一样的。 b：生产什么 没有不骂我是白痴的，讲了半天的软件了，还在问这是生产什么？ 如此说法是正确的，但仔细一想就知道这个问题的答案还很难回答，虽然这是微软风格但也必须把它说明。 在为谁生产的问题中已经有些说明了，生产什么，当然是用户说了算，我们生产什么，我告诉你：“我们生产用户所需要的”。但用户到底是需要什么？在软件的需求中我们赋予用户一些权利：可以要求软件使用客户语言规范；要求软件跟踪客户的系统业务目标；要求软件对产生结果或数据进行详细的说明；要求软件符合质量要求。 根据软件的种类我们来列举一大堆的例子分析说明我们软件开发者生产的是什么：操作系统啦、驱动程序啦或者媒体播放软件啦．．．．．． 其实不然，我生产的是根据用户提出的软件设计的模板来进行软件生产。 c：如何生产 先谈谈分析和设计的区别：“分析是一门科学，设计是一门艺术”，说话者的意思是在所有的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要；当然软件的建模也同样是合乎其理的。需求分析需要一丝不苟、精确的完成,而软件设计的时候反而可以发挥创造力和想象力，不然世界没有进步了。 在实际的操作过程中，软件的设计者（我还不能包括在内）常常遇到一个问题就是：对软件的理解在开发的过程中才愈来愈深，在设计的初期软件的设计者并没有对软件如此理解，如此便造成一种假象：好象是需求经常改动。其实不是，客户对待软件的需求并没有变，但由于交流或其他方式的接触，使得软件设计者对软件的理解加深了，我们改变了对需求的理解而不是需求变。 根据软件的需求，我们如此而知到软件开发的目的。 有了目标我们必须找一条路走过去，而这条路就是如何生产了。 首先，软件的设计不可避免的需要写文档，按照软件设计规范，软件文档有十三种，每一种对应于软件开发的一个时期（具体的内容以后再谈）。 其次，根据软件的文档开始编写代码，该代码就是软件的源代码，源代码的开发在目前的国内软件开发上还是占据主要的份额（其实这个问题在我身上基本上消失了）。 再，软件测试，具统计很少有人愿意干此类的活，虽然每个人都知道该项很重要，在前面的释义(二)我已经讲了心态的问题了。 最后，把开发好的软件放在有电源的设备，并为之添加硬件和软件的环境支持，使其运行。在运行的过程中进行软件维护。 二． 做些准备工作 别把建模当回事（当然说这个话是有目的），建模就是让别人知道如何操作自己而来实现别人对你的要求。模也就是一个Document（使用MFC的兄弟应该对此有很深的体会），但如何把Document叙述的详尽，完整和条理，为此我们（当然不包括我了）利用UML定义了一套标准来规范文档的写作。 为此，理解你要实现的东西是一件建模初期的事，在理解的基础上我们并不能忽略现实的简单性，所以，好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。 我在工程的实践中，遇到了一系列问题，但问题反映出来，其原因有如下几个大问题： 1． 设计者就是设计者 设计者如此费力地把模型搭建起来，然后再费力向各个程序员详细地说明该软件开发的具体步骤，若程序员的水平太差，再给他们写些原代码示例，如此以来，还不如自己写算了，设计者就是设计者，并不需要实际深入地参与软件原代码开发，但应参与其他文档地编制。习惯了好象我们成了幼儿园的老师。 2. 教育你的程序员 你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。 教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。其实该问题是如此地实际，但也正是该问题困扰着我目前的开发状况，例如：我用Playcase的开发工具做了一套流程，使得程序编写起来模块化，第一没有人看懂如此设计文档，我开始讲述如此建模知识；第二有些开发人员学习过其他的建模语言，对此开发工具指手划脚，其实工具并不重要，重要的是用它来实现东西。 另外，你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候，你的团队才能实现真正的合作。 3. 在现有任务中应用多个模型 当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。 当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。 程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。 4. 证明你的设计在实践中可行 在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。软件的设计最忌讳的就是使用不成熟的技术来开发软件产品，我的朋友和谈天的时候说：“我用最成熟技术开发最实用的软件”,“首先客户需要的是一个成熟的软件，稳定、可靠，如果采用最新的技术，由于没有经过时间的检测，不能保证其运行的稳定性”。 你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。 5. 管理接口和使用接口组件 你应该在开发阶段的早期就定义软件模块之间的接口。我是电子商务软件的，对于COM/DCOM组件的使用需要深入地研究下去，这个研究的目的就是使得软件模块的接口方便、简易、易于管理。 接口或接口型组件将有助于开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工一旦模块的接口确定之后，模块怎样实现就不是很重要了。从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。我想再说一次爱因斯坦的话：“外部的证实，内部的完备”。 6. 软件的移植性和封装 移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（当然广告的宣传是带有软件的商业性质）。 即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。记得从16 位Windows 移植到32 位windows 的“乐趣”吗 （微软公司又开始挣我们的钱了）？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程(DCOM/Istorage或其他策略)。你的软件和那个特定的产品结合度就已经很高了。 好的软件设计者把那些特有的实现细节打包隐藏起来—我比较随便把这种东西叫封装（也可能我是C++等OO技术的爱好者），所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。 7. 降低软件模块间的耦合度 高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动，其实这种变动在数据库领域内更让你有很深的体会，尤其是现在人们常用的关系数据库，修改起来很象株连九族一样。 你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。 耦合度低的软件可以很容易被重用、维护和扩充(那什么软件耦合度低—采用中间件，这么这些都是我喜欢的)。 8.最后的绝招 询问.学习.整理。 这个没有人教的，全是我悟出来的。但这是软件设计人员的过程：1、询问客户建立需求文档；2、学习研究需求文档，测试设计的可行性；3、整理文档，编写设计文档。 1．一段废话 写了前面三节，我发现确实需要继续写下去，把自己的观点拿来和别人分享自己也是快乐的吗？看了网上我的文章被访问的情况，自己在私下窃喜，侯捷先生是个业界的知识的传播者，他有个观点我十分地赞同：发表是最好的记忆！ 我很久以前就想写这段废话了，但是不好意识，原因很简单，知识层次不够。但最近有些朋友发来消息问我关于UML的具体问题，但我发现这样一个问题，知其然而不知所以然，我当初写UML释义的动机就是来解释关于所以然的问题。 前三段很简短，告诉兄弟们UML的来历，也简单地谈了一下心态。但很多时候，我想说的不是UML本身，其实本身也没有什么。就是关于如何对待UML，这个问题如何来看呢？可能大家心里还疑惑？对待这个词当然包括''使用''，''学习''，''发展''和''参与''等所有的人类行为。 但并不是所有的计算机界的人都需要了解UML的，但什么样的人需要了解呢？什么时候是最适当去了解UML的呢？好了，时间的概念，人的概念都已经知道了这是个因素，那我们先来谈谈这些因素，然后在谈这个因素带来的结果。 2．人的因素 我收的信件中，有很多关于询问如何学习UML的，我的回复很简单，我告诉他们，UML很简单，而且也无须学习，它是一个标准，标准是不需要学习，你只要知道。但有些人又问了，那么不学，有怎么知道呢？ 问的彻底！ 说明这个问题，我需要先解释一个词：协议。什么是协议，搞过通讯的人都知道，若需要使得通讯双方都能明白对方说什么，就需要规定一个标准，这个标准是大家都需要遵守的，并一直贯彻，不然，就不会明白对方说什么。这个标准就是一个协议。在说明明白一点，我们对方进行语言交流，我们需要采用同一种语言时，双方才能听懂，那么语言是什么？是协议。 那么UML是什么？是一种软件在开发过程中，可以被各类人事理解的软件构架的描述。当然这个描述不是简单地描述，而是详尽地描述待开发的软件（开发完毕，基本上没有什么用处，当经验积累吧）。 这个需要学习吗？我的学习是研究之意，而非是为之认识而进行辨认地记忆。 你这个时候回答是：好象不需要。 那么UML就一无是处了，不是的，既然它是标准，我们就必须贯彻它，如果你不贯彻它也可以，但你需要找一个更好的标准来贯彻（以之来取代UML,技术是发展的吗，这是早晚的事）。 UML是个标准，我早就在这里描述过，这个东西已经不是新鲜的东西，所以没有大惊小怪的必要。既然有许多人希望学习它，那它自然有可学习的地方。 接着讨论上面叙述的问题。 什么人需要学习它？ 开发人员，项目经理，软件设计者，系统分析员等等，一切需要在软件项目和别人进行交流的所有人，都需要学习UML，但小组中的这些成员除外-客户或伪客户(公司领导或市场方面人员)。 学习UML需要基础吗？ 不同类型的人需要不同基础，但有个基本要求就是你必须有关于软件工程开发的部分经验，若你没有，也可以去学，但理解起来很难。我给个基本的要求，就是在从事行业工作两年及以上，有一定的面向对象的编程基础（所有学习Smalltake 、Java 或 C++（还不是纯种OO语言）的人有些优势）。但UML的标准是否适合其他的例如采用汇编语言开发单片机程序的项目，我很怀疑(我一般很少怀疑一件事)。 如果你想成为系统分析员，或者系统的构建师，你就需要学习UML的语言，当然这远远是不够的，更多的是关于软件工程管理的基本知识。 如果你已经有了OO的编程经验，已经有了部分的软件工程管理知识，但你现在还不知道UML的具体应用，没关系，我告诉你，你现在完全可以拿个凳子和一本UML的参考手册就可以到电脑面前去尝试（仅仅是尝试）着建模了。 3．管理因素 有些朋友给我来信，关于讲课的事，我显得很茫然，并不是口才不行，也不是害羞，而是对一个UML的本体没有很好的把握，其实我写UML释义其实就是来证明，UML是不需要学习的，但什么是需要学习的呢？那就是软件工程的具体实施的各个过程地描述和步骤，这些过程需要大量规范化的东西，这些东西需要学习（研究、分析、理解和总结）。 （若是软件工程实施的课，我喜欢听，现在还有资格上讲台。这令想起在电力系统时，我开培训班的情景，下面坐着听课所有人用一种异样眼光看我，当时我太小了！） 科学技术上有天才，但管理上没有，既然我们都不是天才，那么就坐下来，认真地总结经验，听取前辈的教导，少对世界保有敌视，少走弯路。 老毛说了，多快好省地建设社会主义吗，呵呵！ 管理上需要学什么呢？ 软件工程的方法，这些方法很重要，而且也难理解，有些时候，你会站在这个观点的相反方向，这个时候也没有关系，你继续想，直到把它想通（它是不会错的，至少目前的最高水平如此，你也可以来改变世界吗？）。 从需求设计、系统分析、系统构建、代码编写、单元测试、集成测试等等，这些应该是UML之前就应该落实的基础，如果没有落实一个管理化的开发环境，你实施UML干什么？用它来提高开发进度？不可能！用它来规范开发流程？也不可能！那么用它能来干什么？浪费时间！ 这就是目前国内UML实施环境的现状，也是很多人知道UML很有用，但它根本就不知道任何用，所以学习起来也茫然。一个企业如果没有软件开发管理的环境是无法实施UML的具体运作的，这个时候倒有必要静下心来首先搞好企业运转的管理，等到开发过程有记录了，那么这个时候就有实施UML 的成熟的时机和土壤，这个并不要需要为了实施而实施，不然我们不就是为了标准而标准的吗？大家现在对ISO的质量标准有什么认识。(中国的软件企业，现在还没有染上CMM 认证的综合症，不然又是陷入劳民伤财，没有好处的泥潭。) UML是个语言，也是个标准，它用于沟通的，不是用来为企业贴金的。但从深层次的管理角度上，它会为企业带来更大的利益。但对于个人来说，固化人的劳动范围，对于创造性的程序员来说，并不是一件好事。
今日推荐
|
重点推荐
领军企业技术文库
+更多领军技术文库
最新专题
电子杂志订阅
| ||||||||