探讨软件工程概念模型

2019-11-17 04:40:26

字体：大中小

来源：转载

供稿：网友

　　“今天，我比以往更加确信，概念的完整性是产品质量的核心。……这个原理决不仅限于软件系统，它适合于所有的复杂事物。” ——Brooks《人月神话》

　　“模型可以澄清相互间的关系，识别出要害元素，有意识地减少可能引起的混淆。”

　　　 ——Forsberg,K.《可视化项目治理》

　　软件工程内容广泛，新技术新热点层出不穷。如何快速把握软件工程新技术，以及如何对众多软件工程技术综合运用，以取得最佳的实践效果，已经成为很现实的问题。本文认为，通盘把握软件工程概念模型，将对解决上述问题大有裨益。

　　一、什么是软件工程概念模型

　　模型就是抽象，就是有意识地忽略事物的某些特征。抽象带来的好处是能够反映模型中元素之间的关系，清楚把握大局。

　　概念模型是模型的一种，简单说就是抽象程度极高的一种模型。

　　软件工程概念模型是对软件工程领域进行抽象描述的模型，它能够使我们对软件工程有一个完整把握。

　　二、一个精简的软件工程概念模型

　　《软件工程——技术、方法与环境》一书中，有一个极为精简的软件工程概念模型：探讨软件工程概念模型

　　该模型可以用一句话概括：软件工程是（目标，方法，活动）三元组。它体现了目标-方法-活动的3维正交关系：

　　· 任何目标，都要依照特定方法，由特定活动实现；

　　· 任何方法，都是指导特定活动，来完成某种目标；
　　· 任何活动，都由特定方法指导，来完成某种目标。

　　三、一个细化的软件工程概念模型

　　下图是笔者理解的软件工程概念模型（采用UML类图的语法）：

探讨软件工程概念模型

　　1、模型概述

　　图中，“理论与经验”和“工具”可以认为是2个比较独立的概念，其他概念可以被分为4组——“方法论”、“过程”、“目标”、“项目”，分别标以不同颜色。这4组主要概念构成了软件工程概念模型的骨架，可以描述为：为达到一定的“目标”，我们建立起相应的“项目”，在某种“方法论”的指导下，按照一定的“过程”，生产出相应的软件“产品”。

　　从这个模型的骨架中，我们能清楚看到上面精简模型的影子——（目标，方法，活动）三元组。但显著区别是，更加强调“活动”的组织和控制方式——“过程”。这是软件实践发展的必然结果，因为，随着软件产品的复杂程度不断提高，势必要更加强调“过程”。Roger S. PRessman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从“产品”转移到“过程”。

　　2、方法论

　　“方法论”是在一定“原则与策略”指导下的一套相关的“方法与技术”，而“方法论”可以分为“开发方法论”和“过程方法论”2种。相应的，“原则与策略”可以是开发策略，例如闻名的“功能分解”策略；也可以是过程策略，例如迭代模型等“过程模型”，就是过程策略。

　　应当说，“过程方法论”是随着软件实践的深入，在“开发方法论”产生之后才产生的概念。Roger S. Pressman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从产品转移到过程。在本文后面的章节，笔者将用“过程方法论”的概念解释“Agile到底是过程还是方法论”的迷惑。

　　另外，值得一提的是，在实际当中，存在“方法”其实是指“方法论”的现象，在此说明一下。一方面，“方法论”是为完成特定目的一套“方法”，“方法论”和“方法”是一对多的关系；另一方面，实际中人们常将“方法论”简称为“方法”，所以也可以认为“方法”是个递归的概念，它可以是“原子方法”，也可以是“方法论”。至此，当你同时面对“Agile方法”和“Agile方法论”这2种说法时，就不必迷惑了。

探讨软件工程概念模型

　　3、过程

　　“过程模型”是对具体“过程”的抽象，它仅规定了后者的框架，例如瀑布模型规定了“过程”是线性框架；“过程模型”的例子还有螺旋模型、喷泉模型、迭代模型等。一个具体“过程”包括“开发子过程”和“治理子过程”2个子过程，它们分别由一组相关的“开发活动”和“治理活动”组成。“开发活动”开发出或再加工“开发工件”，“治理活动”使用“治理工件”，对“开发活动”和“开发工件”进行治理。
“过程开发与改进”是一个非凡的“治理子过程”。“过程开发与改进”与其它一般的“治理子过程”相比，后者是为软件产品的开发服务的，而前者是以开发和改进软件过程本身为目的。软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出：软件过程也是软件。软件有一个开发的过程，软件过程也有一个开发的过程；软件开发产出软件产品，软件过程开发产出过程产品。

　　RUP是闻名的软件过程产品。CMM是闻名的软件过程改进框架，它本身不是特定软件过程的定义，它只是建议如何一步一个台阶地改进软件过程。在本文后面的章节，笔者将从“过程开发与改进”的角度，谈谈RUP的定制和CMM的定位问题。

　　4、目标

　　任何实践都是有“目标”的，软件实践也不例外；比如“开发Bug跟踪系统”就是一个“目标”的例子。“目标”的完成，依靠于一系列“任务”的完成；比如上述“目标”可以分解为“分析”、“设计”、“编码”、“实现”等“任务”。

　　“任务”通常在“方法论”的指导下完成；比如“分析”任务，可以选用“OOA方法论”，也可以选用“结构化分析”方法论。每个“任务”还可以进一步分解成多个“子任务”；比如“分析”可以分解为“需求采集”、“需求分析”、“建立分析模型”等“子任务”。
　
　　“子任务”通常使用相关“方法与技术”来实现；比如“建立分析模型”子任务，可以选用“UML建模技术”，也可以选用“结构化建模技术”。

　　5、项目

　　“项目”是“目标”、“过程”和“方法论”3者的关联类；这意味着任何一个“项目”，都采用一定的“过程”，在某种“方法论”的指导下，完成某种“目标”。“项目”的“目标”经常就是“软件产品”本身，但也可以不产出任何“软件产品”。“项目”是为完成特定“目标”所做出的临时性努力，可以是建造一栋大楼，一座工厂，也可以是解决某个研究课题，不一而足。

　　“产品”就是一组“开发工件”的集合，就象经典的“软件”的定义中说的，“软件是程序、文档和相关数据的统称”。“治理工件”是伴随“项目”的进行产生的，但它并不是要交付给最终用户的。

　　6、其他

　　现在回过头来看“理论与经验”和“工具”这2个概念。“理论”是高度系统化的知识，“经验”是尚未进行系统化抽象的知识。“理论与经验”是“方法论”的依据，正是在“理论与经验”的指导下，人们总结出方法论的“原则与策略”，又在后者的指导下，人们将众多“方法与技术”组织成一套完整的“方法论”。“工具”用来支持“方法与技术”的，好的“工具”可以提高人们的工作效率，减小出错几率。

　　其实图中还包含了其它一些信息。比如，“方法”和“工具”是多对多关系：一种“方法”可以采用多种“工具”（比如画Use Case图可以采用Visio、Rose等多种工具），一种“工具”也可支持多种“方法”（比如Visio可以画流程图、UML图等多种图）。

　　又比如，“方法”和“过程”是多对多关系：一种“方法”可以被多种“过程”采用（比如CRC卡方法可以被RUP、XP等多种过程采用），一种“过程”也可采用多种“方法”（比如RUP可以采用OO建模、结构化建模等多种方法）。

　　篇幅所限，恕不一一列举。

　　四、软件工程概念模型的具体应用

　　下面再举几个具体的例子，以说明软件工程概念模型在快速学习、正确理解和深入把握软件工程技术方面的作用。

　　1、搞清楚Agile是过程还是方法论

　　当前，“Agile过程”和“Agile方法论”的说法都很流行，令初学者相当迷惑。下面根据软件工程概念模型的知识，来弄清这个问题。

　　好的开始是成功的一半，我要做的第一步就是先推翻“Agile是过程还是方法论”这个问法，改问“Agile是过程、开发方法论还是过程方法论”。

　　第二步，分析《Agile Software Development》一书中给出的Agile模型：

　　通过对模型的分析，可以看出它是对过程建模：

　　·假如去掉人和团队的因素，上面的模型最主要的要素就是过程（Process）、活动（Activities）、产品（ProdUCts）和技术（Techniques）了，这显然是个过程的模型。

　　· 上面的模型中有相当多的和人相关的要素，包括角色（Roles）、技能（Skills）、个性（Personality）、团队（Teams），对人的因素的极其重视，正是Agile过程的显著特点。

　　· Agile过程是面向人的（people-oriented）过程，实施Agile过程的一个要害之处是让人“接受”一个过程而非“强加”一个过程。

探讨软件工程概念模型

　　我预备提前下结论了——谈过程哪能不谈它背后的方法论呢——Agile是有它自己的过程方法论的过程。

　　2、为CMM定位

　　CMM是一个大家关注已久的话题，CMM标准的提法颇为流行，下面笔者换个角度，根据软件工程概念模型的探讨，将CMM定位为“过程开发与改进的需求和测试方案”。

　　CMM是软件过程开发的需求：

　　· 要害实践描述了应当“做什么”，而不是强制规定“如何做”；要害实践的描述就是过程开发的需求项。

　　· 要害实践被分组，成为一些要害过程域。相当于需求项的分组，便于治理。

　　· 要害过程域的实施都是为了达到一定的目的，从需求的层次角度（请参考Wiegers著陆丽娜译《软件需求》一书），可将“目的”理解为“业务需求”，将要害过程域理解为“用户需求”，前者由后者来实现。

　　· CMM通过定义的这些要害实践和要害过程域，覆盖了我们要开发的软件过程的主要目的（比如需求治理、产品工程）。

　　CMM是软件过程开发的测试方案：

　　· 从原理上，需求就是测试依据。软件工程中的一条基本原理就是：依据需求进行测试。

　　· 从实施上，我们通常依据需求来编写测试用例，然后执行这些测试用例。

　　· Brain Marick更是表述了他的具有革命性的观点：“我并不想写出一套用于捕捉用户愿望的需求，取而代之的是，我要写出一套测试，一旦这些测试能够通过，产品就能使她满足。”尽显大师风范。

　　· CMM提供的大量提问单，和测试用例的概念对应得很完美，我们通过这些提问单就可以轻松测试出每一个要害实践进行得怎么样，进一步测试出每个要害过程域完成得如何，该组织的软件过程的能力成熟度有多高。

　　3、理解RUP定制

　　RUP是闻名的软件过程产品，包含了相当优秀的思想，比如：

　　· 为了使风险最小化，RUP引入阶段概念和迭代开发模型，以便给开发者足够多的机会，在付出太多代价之前放弃或调整开发。

　　· 为了使并行最大化，RUP引入工作流的概念，工作流是相关活动的集合，不仅工作流之间也是并行，工作流内部的活动也是可以并行的。

　　然而，根据具体的实践情况不同，使用RUP前应当对其进行适当定制。

　　“RUP定制”属于“过程开发与改进”中的“过程开发”，而且严格来讲，是“过程开发的再工程”。再工程（reengineering）是对现有软件系统或软件过程的重新开发过程，包括逆向工程、新需求的考虑和正向工程三个步骤。

　　值得一提的是，“RUP定制”既可以是“RUP剪裁”，也可以是“RUP扩充”。RUP剪裁大家讨论的比较多了，有爱好的读者可以阅读本文参考文献中所列的《RUP的剪裁原理和剪裁过程》一文。

　　闻名的RUP扩充的例子有：

　　· Ronin International公司将RUP扩充成为EUP。

　　· 再比如爱立信在RUP的基础上进行扩充，开发出ERUP作为公司范围内的框架结构。

　　五、软件工程概念模型的启示

　　1、软件工程，一门实践的科学

　　通过对软件工程概念模型的研究，强烈地感觉到，软件工程是一门实践的科学——它的出发点和最终目的是指导实践。基于此，我们至少应当注重2点：

　　· 从时间上，实践是发展的，基于实践的软件工程学科也必然是发展的，比如近几年，软件工程领域的发展就相当大。我们必须意识到这一点，不断学习新知识，才能适应软件实践的需要。Roger S. Pressman说：“软件工程将发生变化——对此我们可以肯定。”

　　· 从内容上，软件实践的差异是巨大的，我们不能生搬硬套。正如Alistair Cockburn所说：“不同的项目需要不同的方法”。

　　2、软件过程，合适的才是最好的

　　据我所知，好的软件过程在不少人的脑子里，是一个“越……越……”的答案。比如，文档越多越好，分工越细越好，控制粒度越小越好，等等。还有，人们认为好的软件过程是可以照搬使用的，我听到过类似“我在某某大公司都是……”的抱怨。

　　其实通过软件工程概念模型的探讨，我们可以看到，软件过程是整个模型很多节点中的一个而已，这意味着软件过程和很多因素有着影响、被影响的关系：

　　· 软件类型、软件规模、软件重要程度、开发人员素质、治理和支持人员素质、合作单位素质等，都是影响软件过程制定的因素。

　　· 而且，且不可单纯认为软件过程仅仅涉及到开发人员，用户、合同确定者、投标者、项目治理者等，都可以成为软件过程的“涉众”；也就是说，他们都可能是待开发的软件过程的用户，应当收集他们对软件过程的要求。

　　3、对个人的启示

　　分析了软件工程概念模型，可以看出，从某种角度，可以认为软件产品是多种技术协作的结果。技术的协作最终表现为个人的协作，软件工程概念模型对个人有何启示呢？

　　· 明了自己知道的和不知道的，尊重他人，是一个团队的必要基础。

　　· 注重团队成员间技术的互补性和全面性。

　　4、呼唤高层次人才

　　看着模型，想着近年来国际上软件工程的巨大发展，深感国内在软件工程领域的落后，“透过变化看趋势、透过技术抓原理、把握软件工程发展脉搏”的高层次人才太少。

　　我辈尚需努力。

上一篇：养成“好”的编程习惯

下一篇：WinCE嵌入式开发程序入门