我的第一次UML学习和实践（上）

　　很早之前就想学习一下UML了，几次拿起书本翻几页，太抽象，没情趣，不好理解，看几页就放下、看几页就放下，缺乏恒心、毅力，然后工作忙，自己给自己找台阶。所以一直没实现。

　　前年底换了工作岗位，没那么忙了，寻思着把以前零零碎碎编的一些程序整合在一起，于是决定借此机会把UML也结合起来，学、练、用三结合。
　　先是上网搜索、收集学习资料，这都是习惯性动作了。以前买的书还是UML 1.x，现在2.x了，又网购了一本。手头上有一套PowerDesigner，搞数据库设计时留下的，这次也升级到15版。除了编码，整理需求、设计用例、类都在PowerDesigner里完成。
　　PowerDesigner提供有各种模型的样板，正好拿来借鉴。虽然是自己给自己下任务，心里琢磨着还是要看看规范是个什么样子，于是装模作样从需求开始写起，Powerdesigner里新建一个自己的需求模型，总体目标、场景描述、功能需求、非功能需求、开发和使用环境等等，挨个写下去。
　　下面是一些过程和体会。

一、 需求和场景
　　一些网络达人说需求要写成小说、故事，要实景描述。比如买火车票，从张三决定春节回家开始讲起，去售票大厅询问车次、买票……下雨了，结果没等到公交、错过了火车。等等，一路写下去，就像纪实小说一样，细节、对话全部写出来。
　　我比较支持这种写法。都知道需求是开发软件最关键环节，引领开发方向，出什么差错，后面弥补成本太高。但开发人员和用户之间对需求的理解、偏重又极可能存在很大差异，这我们也都体会过。开发人员把时间顺序、前提条件、约束关系看得很重，规范、标准、模式一套一套。用户却觉得很奇怪，这些事有那么重要吗，我从来没有在意过啊，临时调整一下也不是没有可能的，你到那一步我们再说嘛。
　　其实这是双方工作经历、人生经验、思考问题角度差异造成，是必须直面、解决的现实，任何一方归罪于对方对自己、对需求、对现实的不理解都是对项目进展的危害，不会给软件开发提供任何有利促进。作为我们软件开发人员，既然去接人家的项目，对此更应有所心里准备，有责任比对方更充分预测各种潜在障碍和困难，准备更多应对预案。
　　道理不难明白，但实际工作还是纠结、磕磕绊绊的多，怎么吧？
　　把实景、实情、过程记录下来吧，需求从现实中提取。一般用户没有现成准备，开发人员进了场才开始归集，双方对需求都会不同程度存在疏忽、肤浅、迷茫、误解、失误，一旦出现分歧、或者发现新问题，最好的办法还是回到具体现实，这个不太容易存在异议。一切回到起点，从头开始梳理思路，抽丝剥茧、追本溯源，解决问题没有比从问题本身出发更好的办法了。
　　当然，真的张三、李四、北京、上海、火车、飞机写成小说也有点教条主义了。有把握的情况下尽可采取提纲的形式，把场景、过程写出来，注意不要有遗漏，不要怕麻烦，不管有没有用，把了解到的情况都先写出来，这是共识、是双方合作的基石，关键是全面，精炼、条理是其次，筛选、归纳以后大有机会、而且肯定要不断做下去。
　　我就是这样写需求。都是自己熟悉的工作，场景不容易遗漏，细节方面会有一时想不起来、想不到的，这也没关系，这种事肯定会发生，但大场景一定要对，这个决定方向。
　　有些不局限于特定场景的需求可以、而且也应该单独罗列出来，强调一下。例如，所有运算结果都直接输出到Excel文件。
　　至于哪些Excel文件需要制作图表、采用特殊排序方式，则写在场景里。

　　需求撰写的第二步是从场景中提取功能，建立场景/功能对照表。注意这个时候的功能需求只要求与场景对应。功能方面会存在重叠、交叉、相似、派生，先不管它，不着急归纳、筛选，重点在罗列，在取得用户的认可。还没到优化的时候。

　　　　
　　再接下来是非功能需求，不由软件实现的功能。例如我这次不考虑数据采集，数据都是从不同系统里导出来的，不存在录入的问题。但要数据转换。不过一次性的特定工作，手工做完拉倒，没必要开发软件。
　　这些都一一注明。

　　最后说明使用环境、开发平台。
　　这里多说几句。我这次开发软件的目的，是把以前作数据分析开发的软件整合在一起。数据是从别的系统导出来的，不需要考虑录入问题，但有近250万条记录，这么多记录不可能用Excel或文本文件管理，这样没效率。
　　所以要建立自己的数据库。考虑过用MySQL或SQL Server，但最后还是选了Visual FoxPro。
　　这有两个原因，一是基本上个人独立使用的软件，没必要牵扯一大堆网络设置。
　　二是数据库管理、数据分析肯定要大量使用SQL，我的最终目的又是自动生成Excel或Word的报告。MySQL或SQL Server直接编程操纵Excel、制作图表没听说过，好像不太容易吧。其它编程工具，例如VC、VB，作为SQL调试平台又不太方便，一般都是另外调试好SQL嵌入编程里面。我这次SQL的量很大，大部分业务逻辑、计算都是SQL完成的，SQL嵌套、关联频率很高，调试工作量很大，编程的目的是过程控制和结果归集，计算量反倒不大。这样切换来切换去太麻烦，浪费时间。
　　所以想来想去还是Visual FoxPro好，即支持交互SQL命令，又支持面向对象编程，反正速度要求不高，所以选了VFP 9.0。

　　理论上需求还应该包括风险分析，但我一个人自己给自己安排的工作，除了时间，不需要金钱，完不成除了自责，也没人跟我计较，算了，省了不写了。
　　当然，自责也是风险。呵呵。

　　二、 用例和类
　　需求写好了之后就定义与场景对应的用例，建立场景/用例对照表。
　　从场景提取用户。建立场景/用户、用例/用户对照表。
　　UML里用户是不受目标系统控制的一切外部因素，可以是一个真实的用户，也可以是一台触发系统动作的摄像机。
　　我这个软件比较简单，没几个用户，很容易理解，用户对照表用处不大，所以又省略了。
　　完了琢磨绘制活动图和顺序图。
　　这时候又迷茫了一阵子，因为活动细节方面实际上是很灵活的，例如用户提交数据，是批量提交一次处理、还是分批提交、边提交边处理呢？这两种需求都可能存在，用户可能都需要，用户也不会太在意两者之间的区别，一开始很难确定哪种方案最合适。
　　又例如，对象的切割，也就是说对象粒度、对象的外延，哪些功能封装在一起。这个问题也很麻烦，因为对象首先源自我们头脑中的某个概念，而随着认识的深入，这个概念很可能发生变化，分解、合并等等。
　　所以一开始的时候画顺序图、活动图时很不确定，经常改来改去、推倒重来。
　　不过这样折腾了几次之后也让我若有所悟，UML其实是个推荐标准，是草稿，是我们设计汽车轮船、高楼大厦之前的草稿。草稿是整理思路、获取对目标的充分理解，帮我们预计、设想宏观结构、微观构建，编码才是我们的最终产品，编码才是目的。UML其实是前人、高手总结归纳出的一个模式，帮助我们编码之前探求目标的本质、实现的路径。
　　所以，既然是草稿，一旦获得对系统足够的理解就可以动手了，用不着面面俱到，把UML标准里所有的图、模型都画一遍，然后才开始编码，这样就本末倒置了，用不着把草稿当正本。
　　所以画了一两个顺序图、活动图之后我就直接跳到了类图。因为这个时候对系统已经有了一些认识，头脑中有了些概念，及时把这些概念用文字、图形把沉淀下来，在顺序图、活动图体现，予以明确，予以验证，交叉、往复相互修正，比坐在那里苦思冥想这样好、还是那样好更有意义。
　　
　　场景是我们最开始的概念，用例是对场景的模拟，所以思维逻辑一开始很自然会把用例映射到对象。但场景都是具体的、有针对地。这与面向对象编成的思维刚好相反，面向对象编程总是从构建基类、抽象层开始，先定义抽象类、上层控制类，然后逐步向下层具体类、实现类扩展。
　　所以我在写出用例，大致画了活动图、顺序图后，就把顺序调转了一下，由具体用例归纳、提炼，设计一般用例、一般过程、一般活动，然后映射到类。
　　老实说UML我是初哥，我学习面向对象还是Turbo Pascal流行的时候，最近这10年主要精力都在数据库、SQL这方面。我不知道这样做符不符合软件工程规律，是不是最有效的工作方法，甚至不知道用什么专业术语去描述这个过程，我是跟着感觉走，按照最有把实现自己的目标方向走。
　　由于我是把以前的一些工作整合，以前分散开发的软件已经是面向对象的了，有了思想基础，所以这个过程还比较顺利，对以前的类进行整合——提炼基类，分解——建立新类处理个性化问题。
　　类之间的泛化、依赖关系作了比较严谨地推敲，关联、聚集、组合关系就没有仔细斟酌了，全部用了关联。对象图、部署图、构建图之类的也没有画了，一是这个课题还比较简单，二是改造老项目，心里已经有数。
　　
　　这样大概从头到尾两三个月，把这个项目搞了完。也确实体会到了UML的好处，最主要有两点，一是有效帮助自己梳理思路，二是用图形描述类之间关系，一目了然，类再多都不怕忘记，属性在基类和派生类之间转移也不怕搞乱。所以UML真的值得学习、实践，下一步要把其它没用到的潜质都挖掘出来。