SOA架构下补偿模型驱动的安全苛求软件开发
SOA架构下补偿模型驱动的安全苛求软件开发
摘要：随着我国高速铁路的快速发展，传统的计算机联锁软件开发方法在灵活性、可维护性、安全性以及开发效率上都显露出不足。针对安全苛求的特点，提出了一个完整的服务组件开发模型，该模型基于soa(service oriented architecture)思想，并成功将其应用到计算机联锁软件系统开发中，进行了试验验证。结果表明，该模型不仅能提高软件的安全性，还大大提高了软件开发效率。
关键词：面向服务架构服务组件架构安全苛求软件
1 引言
铁路车站信号计算机联锁系统，是铁路信号的基础设备，同时也是铁路运输领域中重要的控制系统，它是以现代计算机技术、控制技术和通信技术为基础来实现对车站信号设备的联锁控制。计算机联锁软件成为了计算机联锁系统的核心，因此必须确保它对联锁逻辑的描述和安全控制的实现准确无误。而随着我国高速铁路的快速发展，对联锁软件在技术和功能上提出了新的要求。传统软件开发方法在灵活性、可维护性、软件安全性以及开发效率上都显露出不足。
计算机联锁是以计算机为主要技术手段实现车站联锁的实时控
制系统。其基本任务是对车站值班员的操作命令及现场各种表示信息通过计算机进行逻辑运算，并辅以各种“故障-安全”措施。联锁系统各主要部分的功能和设置地点的划分层次结构，如图1所示。
联锁层是联锁控制系统的核心，联锁机构除了接收来自人机会话层的操作信息外，还接收i/o接口层的反映信号机、动力转辙机和轨道电路状态的信息，即信号控制命令和道岔控制命令。i/o接口层接收来自联锁层的控制命令，经过信号机控制电路，改变信号显示；接收来自联锁层的道岔控制命令，驱动道岔转换。室外设备是联锁系统的控制对象，它包括信号机、转辙机和轨道电路。
本文针对安全苛求软件的特点，面向我国高速铁路计算机联锁软件的应用需求，基于目前主流的soa思想的实现规范，即服务组件体系结构sca，提出并实现了一个完整的服务组件开发模型，挣脱web service框架对soa思想的束缚，并能根据服务组件模型生成代码框架。
2 soa和sca
面向服务的体系架构soa(service oriented architecture)是1996年gartner公司描述实施企业“v英文”时第一次提出来的。w3c将soa定义为：“一套可以被调用的组件，用户可以发布并发现其接口。”soa是一种软件设计开发思想，它超越并包含所有的具体技术和所有的具体架构。服务组件框架sca(service component architecture)的java标准来自ibm。sca是一套面向服务的soa 编程模型或者说编程架构，也是一种soa思想的实现方式。sca通过模块 (composite) 将sca的组件集成在一起的。模型开发应用中，总是期望能提高软件开发效率，增强软件安全性。因此，本文
针对联锁软件安全性高的特性，提出一种面向联锁的soa服务组件开发模型。
3 联锁逻辑服务组件的开发模型
联锁软件主要由两大部分构成，一是联锁功能程序，二是联锁数据。联锁功能程序主要是对联锁数据进行逻辑运算以完成联锁功能；联锁数据主要用于反映监控车站各个设备的区动采集对象的特征和状态。联锁软件的核心部分是关于基本进路过程的处理，包括进路选排、进路锁闭、进路信号开放、进路信号保持和进路解锁等过程。由此，基本进路可以看成联锁软件提供的流程服务，对应人机会话层操作员办理进路的业务需求。对于操作人员来说，基本进路处理流程作为一个整体服务被调用。这个流程服务包括以下几个任务：进路选排、进路锁闭、进路信号开放、进路信号保持和进路解锁，每个任务通过调用相应的服务来完成联锁软件的功能。在业务流程进路办理的过程中，进路选排服务、进路锁闭服务调用成功，但是进路信号开放服务因为信号灯故障不能开灯，此时对于联锁系统软件的人机会话层来说，业务流程进路办理调用已经失败。而进路选排服务、进路锁闭服务的调用已经成功完成，相关的驱动采集对象如信号机、道岔和区段等设备状态和特性已经被这些成功调用的服务修改了。这就有可能导致不可控的命令下发到室外设备，导致安全隐患。因此，在进路办理的执行过程中出现了业务流程服务未成功调用，但却对设备对象数据产生影响的场景。
基于上述问题，本文的服务模块开发模型定义了一种被称为“补偿”的服务机制来完善服务的模型，以解决业务流程服务的执行原子性和数据一致性的问题。例如流程服务逐个调用两个服务，如果只有一个基本服务调用成功，可以通过适当的事情来补偿前一个服务调用成功所产生的影响。每个基本服务都有一个相应的补偿处理服务，用于消除对应基本服务的调用产生的影响。一旦进行补偿，流程服务中已经运行完成的所有服务都会依照特定的逻辑进行补偿。补偿服务机制致力于维护业务流程的执行原子性，即业务流程的执行结果只能是以下两种情形之一：流程服务执行成功或流程服务执行失败但不产生任何影响。当执行特定的流程服务时，相关联的用于补偿调用的就是补偿服务。补偿服务仅在流程服务完成时才能够被调用，当流程执行过程中出现故障时，执行预先关联的补偿服务来补偿业务流程服务的行为。在一个业务流程执行过程中，如果定义了关联的补偿服务，就应该记录业务流程各个服务的执行顺序，注册关联的补偿服务及输入数据到补偿服务处理队列。如果业务流程正常完成，则不需要任何补偿。因此基于以上补偿机制，完善的服务组件补偿模型应该满足这样的条件：对任意一个业务流程服务，每次调用的结构要么是成功执行，要么不产生任何影响。即实现了业务流程的执行原子性。基于以上理论，可以得出sca构架下补偿服务处理机制的通用模型如图2所示。
如图2所示，基本服务1和基本服务2属于同一个组合服务，且
都成功的完成了调用（第1，2步）。而属于流程服务的基本服务3的调用（第3步）也成功完成。若此时基本服务4调用（第4步）失败，被业务流程服务关联的补偿服务捕捉到，触发了补偿服务（第5步）。补偿服务开始执行，通过调用后进先出的补偿服务队列（与业务流程完成的次序相反），依次调用补偿处理服务（第6-10步）来补偿之前操作产生的影响。
实际的联锁软件应用中，用户的需求经常是比较复杂的。联锁软件服务组件除了调用基本的服务组件之外，也需要调用一些优先级较高的紧急操作服务，而这些服务组件往往是依赖外部设备驱动采集的状态。因此，在服务模型中引入了两个特殊的端点，一个是“导入”(import)，使得模块中的服务组件可以调用模块外部的服务。另一个是“导出”(export)，它使得模块外部的应用可以调用模块中的服务组件。导入和导出的引入增加了服务组件的灵活性，使得此模型的服务调用能够跨越服务模块的限制。
4 模型在计算机联锁软件中的应用
为了验证和测试上述模型的有效性，基于以上服务模块模型，在linux平台上开发了一个计算机联锁软件系统。此联锁逻辑补偿模型可以获得计算机联锁软件系统的服务组件补偿模型如图3所示。联锁软件实时监测人机交互层操作人员的操作命令，调用相应的业务流程服务执行相应的软件功能。在执行流程服务的同时，联锁软件监测是否有来自外部的高优先级服务调用，以保证紧急情况下
联锁软件的安全性需求。在以往的联锁软件进路办理过程中，进路办理的进路选排、进路锁闭、进路信号开放、进路信号关闭和进路解锁等过程在程序执行时，除了对联锁数据进行逻辑运算，还需要检测各个执行过程是否成功完成。这提高了联锁软件业务流程各个服务模块的耦合度。每个服务子模块都应包含补偿处理，以消除业务流程执行过程中当前所有已经成功执行的子模块所产生的影响。因此，此服务模型的业务流程子服务模块的补偿处理只关心当前子模块成功调用产生影响，而不会关联到业务流程执行的上下文环境。因此，本文提出的服务组件开发模型能在相当大的程度上减少软件设计开发的冗余，提高软件开发的效率，同时这也限制了各个子模块的功能边界，减少了因为模块之间高度耦合而带来的安全性问题。
5 结束语
本文基于soa思想，针对安全苛求软件的特点，设计了在sca标准下一种完整的服务组件开发模型，通过在北京地铁试验线计算机联锁系统的应用验证了该模型的正确性。由此模型驱动生成服务组件代码框架，不仅提高了软件的安全，还大大提高了软件的开发效率。此服务组件模型的业务流程服务依赖补偿服务，这种补偿服务机制虽然能提高软件开发效率，但其与业务流程关联度还比较高，提高了服务模块的耦合程度。因此，将来的方向是改进当前补偿服务的执行机制，降低与具体业务流程之间的耦合程度。
参考文献：
[1] 卢志杰,覃正.soa构架与电子商务应用集成[j].计算机应用研究,2004,21(10):232-234.
[2] 王紫瑶,南俊杰,段紫辉,等.soa核心技术及应用[m].北京:电子工业出版社,2008.
[3] 蒋林岑,季一木.基于sca的电子商务系统架构研究与设计[j].计算机技术与发展,2010,31(7):203-206.
[4] 钱建平,沈备军,陈德来.模型驱动的服务构件开发工具[j].计算机工程,2009,7(11):42-44.
[5] 刘伯超,马晓轩,葛声.基于web 服务的软件服务体系结构研究与实现[j].北京航空航天大学学报,2004,30(3):263-266.
软件过程模型优缺点
软件过程模型优缺点 一、瀑布模型 1、优点 1）它是一种线性的开发模型，具有不可回溯性。2）过程模型简单，执行容易。3）将复杂的软件开发过程明确分解为几个顺序的步骤，降低开发软件的复杂性。 2、缺点 1）无法适应变更，由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果，从而卡增加了开发的风险。2）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重后果。 二、快速原型模型 1、优点 1）可以得到比较良好的需求定义，容易适应需求的变化。2）开发人员和用户在“原型”上达成一致。可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。3）缩短了开发周期，加快了工程进度，降低成本。 2、缺点 1）不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致。2）不利于开发人员的创新。 三、增量模型 1、优点 1）将待开发的软件系统模块化。可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。2）以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到这个软件系统。3）开发顺序灵活。开发人员可以对构件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时。还能及时第实现顺序进行调整。 2、缺点 1）要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
四、螺旋模型 1、优点 1）将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。2）以小的分段来构建大型系统,使成本计算变得简单容易。3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 2、缺点 1）模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。2）过多的迭代次数会增加开发成本，延迟提交时间。 五、喷泉模型 1、优点 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 2、缺点 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。 六、基于组件的开发模型 1、优点 1）用现有的组件和系统框架进行产品开发，可靠性相对新研发组件高。2)开发简单，降低了开发成本和风险。 2、缺点 任何基于组件技术的系统,在开发前期都会面临一定的风险。对于组件式软件开发而言.对象技术不是必需的,但是又不能完全脱离对象技术,而且组件技术还离不开体系结构，大多数组件技术对于组件都有一定的限制。 七、统一软件开发过程模型 1、优点 1）有利于更好地理解需求、设计出合理的系统架构，并最终交付一系列渐趋完善的成功。2）每个阶段结束时都要进行阶段评估，这样可以及早发现软件中的缺陷。
软件开发模型介绍与对比分析
常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（采用瀑布模型的软件过程如图所示）
常用软件开发模型比较分析
常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③ 以形式化开发方法为基础的变换模型（T ransformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。这样软件与用户见面的时间间隔较长，也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。这
软件开发与项目管理课后练习(参考答案)
软件开发与项目管理参考答案 第一章（软件开发模型和开发方法） （一）知识回顾与思考 1、软件产品的特性是什么？ ①软件是一种逻辑产品，具有无形性; ②软件产品的生产主要是研制;主要是脑力劳动; ③软件不存在磨损和老化问题，但存在退化问题; ④软件产品的成本非常昂贵，其开发方式目前尚未完全摆脱手工生产方式; ⑤软件具有“复杂性”，其开发和运行常受到计算机系统的限制。 2、软件生产有几个阶段？各有何特征？ ①程序设计时代：这个阶段生产方式是个体劳动，使用的生产工具是机器语言，汇编语言。 ②程序系统时代：这个阶段生产方式是小集团合作生产，使用的生产工具是高级语言，开发方法仍依靠个人技巧，但开始提出结构化方法。 ③软件工程时代：这个阶段生产方式是工程化的生产，使用数据库﹑开发工具﹑开发环境﹑网络﹑分布式﹑面向对象技术来开发软件。 3、什么是软件危机？产生的原因是什么？ 软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是指如何开发软件，怎样满足对软件日益增长的需求，如何维护数量不断膨胀的先有软件。 原因：一是软件产品的固有特性(软件的不可预见性、软件的规模大且逻辑较复杂)，二是软件专业人员自身的缺陷。 4、什么是软件工程？它的目标和容是什么？ 软件工程：是用科学的知识程和技术原理来定义，开发，维护软件的一门学科。 目标：付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。 容：研究容包括开发技术和开发管理两个方面。开发技术主要研究：软件开发方法，开发过程，开发工具和环境。开发管理主要研究：软件管理学，软件经济学，软件心。 5、软件工程面临的问题是什么？ ①软件重用性差 ②软件可维护性差 ③开发出的软件不能满足用户需要 6、什么是软件生命周期？它有哪几个活动？ 软件生命周期：一个软件从提出开发要求开始直到该软件报废为止的整个时期。 活动：可行性分析和项目开发计划，需求分析，概要设计，详细设计，编码，测试，维护。
基于模型开发及平台化应用-演讲报告
基于模型开发及平台化应用 梁海强 2015.6
目录 1项目背景 项目目标 2 3项目方案 4 项目成果 5项目应用及效益
公司项目繁多，方案各异，且开发周期短，为满足项目开发要求，解决以上问题，公司对各车型控制软件进行平台化的开发，同时对同一车型不同配置进行软件自适应开发。 项目背景 项目繁多 开发周期短 方案 多样 项目繁多 ?公司不断增加产品开发项目。如绅宝EV 、EV200、EV150、 M307等多个车型，涉及“大中小、高中低、234”等车型 平台。 开发周期短 ?每一个项目开发周期都很短，一个项目从立项到量产要求在 很短的时间内完成。 方案多样 ?为了满足市场需求，每个车型又有多种配置方案。
本项目旨在达成三方面的目标： 建立基于模型开发整车控制策略的软件平台； 对于不同车型进行控制模型软件平台化的开发，保证控制模型软件的可移植性，缩短整车控制软件开发周期；针对同一车型不同车型配置方案，进行软件自适应开发，保证一款车型同一版软件对应不同的车型配置。 软件自适应 开发 控制模型软件平台化 搭建模型开发平台
三、项目方案-建立V 流程的模型软件开发平台 标杆车分析控制需求分析 控制系统定义与 设计 策略模型开发 模型集成自动代码生成SIL 测试 实车测试 匹配标定 HIL 测试 MIL 测试 V erification “验证” V alidation “确认” 控制需求分析V 型开发流程 VS ?简洁、明确?便于交流?便于维护图形化设计 ?及早纠错 ?改善开发过程早期验证 ?开发效率高?代码品质高代码自动生成 ?提高效率?便于交流 文档自动化 优势
几种常见软件开发方法的研究与比较
几种常见软件开发方法的研究与比较 摘要:本文介绍四种常见软件开发方法的过程、特点、优缺点及如何对软件开发方法进行评价与选择。 关键词:软件软件开发 1 引言 在软件开发的过程中,软件开发方法是关系到软件开发成败的重要因素。软件开发方法就是软件开发所遵循的办法和步骤,以保证所得到的运行系统和支持的文档满足质量要求。在软件开发实践中,有很多方法可供软件开发人员选择。 2 常见的软件开发方法 2.1 结构化开发方法 结构指系统内各组成要素之间的相互联系、相互作用的框架。结构化开发方法强调系统结构的合理性以及所开发的软件的结构的合理性,主要是面向数据流的,因此也被称为面向功能的软件开发方法或面向数据流的软件开发方法。结构化技术包括结构化分析、结构化设计和结构化程序设计三方面内容。 2.1.1 结构化分析的步骤 结构化分析是一种模型的确立活动,就是使用独有的符号,来确立描绘信息(数据和控制)流和内容的模型,划分系统的功能和行为,以及其他为确立模型不可缺少的描述。其基本步骤是:(1)构造数据流模型:根据用户当前需求,在创建实体—关系图的基础上,依据数据流图构造数据流模型。(2)构建控制流模型:一些应用系统除了要求用数据流建模外,通过构造控制流图(CFD),构建控制流模型。(3)生成数据字典:对所有数据元素的输入、输出、存储结构,甚至是中间计算结果进行有组织的列表。目前一般采用CASE的“结构化分析和设计工具”来完成。(4)生成可选方案,建立需求规约:确定各种方案的成本和风险等级,据此对各种方案进行分析,然后从中选择一种方案,建立完整的需求规约。 2.1.2 结构化设计步骤 结构化设计是采用最佳的可能方法设计系统的各个组成部分以及各成分之间的内部联系的技术,目的在于提出满足系统需求的最佳软件的结构,完成软件层次图或软件结构图。其基本步骤如下:
软件开发模式及优缺点
软件开发模式有哪些? 快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题） 快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善） 优点： 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险 缺点： 、所选用的开发技术和工具不一定符合主流的发展 、快速建立起来的系统加上连续的修改可能会造成产品质量底下 增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品） 与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代 与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发） 优点： 、人员分配灵活，一开始不需要投入大量人力资源 、当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用） 、增量能够有计划的管理技术风险 缺点： 、如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析 注： 这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程原型模型：（样品模型，采用逐步求精的方法完善原型）
主要思想： 先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求， 采用方法： 原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应 优点： (）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 （）缩短了开发周期，加快了工程进度。 （）降低成本。 缺点： 、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。 、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致： 喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目） 它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性 相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分 无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>） 优点： 、可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程 不便之处：
模型驱动体系架构 计算无关模型 平台无关模型 模型转换论文
模型驱动体系架构论文：MDA中从CIM到PIM的模型转换研究 【中文摘要】模型驱动体系架构(MDA)是由对象管理组织(OMG) 提出的一种新的软件体系架构,它以模型为核心,模型转换为关键技术,通过模型间的转换来驱动整个软件开发。其中,模型转换是MDA开发方法的重点和难点。在MDA和统一建模语言(UML)的理论基础上, 本文首先研究了MDA中从计算无关模型(CIM)到平台无关模型(PIM) 的模型转换,重点分析了属于CIM范畴的用例图与属于PIM范畴的序列图和活动图的对应关系,并给出了它们之间的转换规则；然后,为了实现转换并保证转换的准确性,本文在国内外已有的研究基础上定义了一种用例描述规范化语言,并基于该语言给出了用例图到序列图及活动图的半自动化转换方法。最后,基于该转换方法,设计和实现了一个模型转换工具,验证了转换方法的可行性和有效性。 【英文摘要】Model Driven Architecture (MDA), proposed by Object Management Group (OMG), is a new kind of software architecture, which focuses on models, taking model transformations as the key technology. By the transformation between models, the development of software is driven. In the development based on MDA, model transformation is a challenging and critical point.Firstly, according to MDA and Unified Modeling Language (UML), this thesis studies an examination of the model transformation from Computation Indep...
软件过程模型的优缺点对比
软件过程模型的比较 瀑布模型 瀑布模型（经典生命周期）提出了软件开发的系统化的、顺序的方法。其流程从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。 优点： 1. 强调开发的阶段性，各阶段具有顺序性和依赖性 2. 强调早期调研和需求分析，推迟编码实现的观点 3. 提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导 缺点： 1. 文档驱动，用户无法及时了解产品的情况 2. 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定 性。 3. 流程单一，必须要完成前一阶段的任务，才能进行下一阶段，开发过程中的 成功经验无法用于本产品。 4. 测试在后期引入，对于系统存在的重大缺陷，如果在可执行程序评审之前没 有被发现，将可能造成重大损失。 5. 组织庞大，人员闲置。 适用范围：需求确定，工作能够采用线性的方式完成的软件。 增量过程模型 增量过程模型包括增量模型、RAD 模型。 （一）增量模型增量过程模型以迭代的方式运用瀑布模型，把软件产品作为一系列的增量构 件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量往往是核心功能。 优点： 1.能在较短的时间内向用户提交可完成部分工作的产品。 2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。 3. 规避技术风险 4. 可并行开发构件，加快开发的进度 缺点：
1. 没有考虑软件的整体质量和长期的可维护性。 2. 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。 3. 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计 适用范围：项目在既定的商业要求期限之前不可能找到足够的开发人员； （二）RAD 模型 RAD 模型是一种侧重于短暂的开发周期的增量软件过程模型，它是瀑布模型的“高速”变体，通过基于构建的构建方法实现快速开发。开发团队能够在非常短的时间内创造出“全功能系统” 优点： 1．开发速度快，质量有保证。 2．对信息系统特别有效。 缺点： 1. 对于大型的可伸缩的项目，RAD 需要大量的人力资源来创建多个相对的独立 的RAD 团队 2. 如果开发者和用户没有为短时间内急速完成整个系统做好准备，RAD 项目将 会失败。 3. 如果一个系统不能合理的模块化，RAD 构件建立会有很多问题。 4. 如果系统需求是高性能，并且需要通过调整构件接口的方式来提高性能，不 能采用RAD 模型 5. 技术风险很高的情况下 适用范围：1、不适合技术风险很高的开发，不适合系统需求是高性能，并且需要通过调整构件接口的方式来提高性能的产品开发。 2、适用于工期紧张，又可细分功能，还要有合适的构件 演化过程模型 演化过程模型包括原型开发，螺旋模型，协同开发模型。 （一）原型开发从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需 求并且规划出需要进一步定义的区域。然后是“快速设计”，它集中于软件中那些对客户可见的部分的表示，这将导致原型的创建，并由客户评估并进一步精化待开发软件的需求。逐步调整原型使其满足客户的需求，这个过程是迭代的。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质
MDA模型驱动架构
MDA 百科内容来自于: 中科永联高级技术培训中心（https://www.360docs.net/doc/1f9264311.html,）MDA(Model Driven Architecture)是模型驱动架构，它是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。MDA把建模语言用作一种编程语言而不仅仅是设计语言。MDA的关键之处是模型在软件开发中扮演了非常重要的角色。 MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径（通过相关的工具）来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。 模型驱动架构（MDA）是OMG组织近年来一直热炒的一个新的技术体系，同时也是众多搞软件模型研究人员的一个新热点。MDA（模型驱动）核心的思路是希望通过对商业模型（比如企业信息化或建筑领域的解决方案）的领域研究。进而提炼出一个相对核心的领域模型，同时抽象出一个PIM（平台无关模型）。之后根据不同的开发平台（例如.net或J2EE），应用平台（windows或unix）形成相应的PSM（平台相关模型）。依照相应的工具，例如ArcStyler可以完整地生成相应的代码和软件系统。当然这里只是罗列出一个大致的思路和方法。 1 MDA理论还处在一个探索期，很多理论和方法并不成熟，当然无从谈起有成熟的工具，从目前的趋势而言，从理论到实际的工具都离OMG组织所提出的预想有较大距离，至少还需要数年的努力才能成型。 2目前无论是国外的开源组织还是国内的一些组织对MDA都只是处在一个草创阶段，很多人所谓的应用MDA 其实都只是在MDA的体系中作一个最初的探索和尝试。例如ORM就是在一定层次上实现MDA 在数据库应用方面的探索，但也只是解决了一个实体模型映射的问题。前几天一个面试人员用ArcStyler4.X 做了一个银行POS系统的应用模型，生成了一点还需要修改的框架代码。就告诉我说他已经掌握了MDA，斯等水准真是让我汗颜！佩服！ 3 MDA的第一个热点可能是桥接器，而在MDA领域中，映射是个很重要的点，而转换和交互都只是在这个点上的延伸。 4 目前而言，最有可能在MDA体系中得以实现的语言是JAVA。 5 MDA的核心是PIM，因为他是最抽象和协同性最高的。同时就当前形势而言，PIM 也是一个瓶颈！同时就目前的UML2.0（从OMG那里得到最新的）而言，还不足以作为建立整个MDA体系的语言。同时对于MOF中的一些定义似乎还有提升的必要。因为对于整个体系而言，MOF应该更多的作为一个标准，只有在标准成熟的前提下，才有可能产生正确的映射规则。 6 等到MDA风光无限的那天，会使一部分程序员失业，但不会是全部，起码MDA工具要有人做，因为一个MDA工具不足以应付所有的领域。这就好比没有一个财务系统能适应所有的企业一样。因为各个领域的标准化不同。 一、MDA（模型驱动架构）背景 MDA目前在以下领域得到了应用：
常用软件开发模型
常用软件开发模型比较分析 正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。在软件工程中，这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。目前，常见的软件开发模型大致可分为如下3种类型。 ①以软件需求完全确定为前提的瀑布模型（Waterfall Model）。 ②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。 ③以形式化开发方法为基础的变换模型（Transformational Model）。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。 图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，
常见的软件开发模型
常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 1.软件开发模型是对软件过程的建模，即用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，好比工厂的流水线。 2.软件开发模型能清晰、直观地表达软件开发全部过程，明确规定要完成的主要活动和任务，它用来作为软件项目工作的基础。 3.软件开发模型应该是稳定和普遍适用的 软件开发模型的选择应根据： 1.项目和应用的特点 2.采用的方法和工具 3.需要控制和交付的特点 软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.快速原型模型 4.增量模型 5.螺旋模型 6.喷泉模型 边做边改模型（Build-and-Fix Model） 国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改. 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； （2）忽略需求环节，给软件开发带来很大的风险； （3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
瀑布模型（Waterfall Model） 1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子. 快速原型模型（Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 增量模型（Incremental Model） 又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各
常见软件开发模型
常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于 维护 增量模型开发早期反馈及时，易于维护需要开放式体系结构，可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(Waterfall Model ) 1970年Winston Royce 提岀了著名的“瀑布模型“，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、
软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如 同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，开发的风 从而增加了险； （3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 快速原型模型（Rapid Prototype Model ） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么； 第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速 原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真 正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速 建立原型，随之迅速修改原型，以反映客户的需求。
软件过程模型的优缺点和适用范围
软件过程模型 1、4种模型的对比 瀑布模型： 优点：文档驱动 缺点：阶段划分固定，大量文档；开发成果最后出增加风险；不适应用户的变化适用范围：需求准确无重大变化的软件项目开发 快速原型模型： 优点：关注了客户的需求，降低了开发风险 缺点：可能导致系统设计差，难维护；不宜用原型产生最终产品，最终产品还是要考虑质 量和可维护性 适用范围：需求复杂，难以确定、动态变化的系统 增量模型： 优点：分批提交产品；减少新软件对用户的冲击；可维护性增加，需求变更只需要更改构 件 缺点：构件逐渐加入，不能破坏已经构造的系统，要求软件具备开放式结构；需 求变化时，适应性大于瀑布和快速原型，但容易退化为边做边盖，失去整体控制性；有无法集成的风险； 适用范围：风险较大用户需求较稳得大型软件系统 螺旋模型： 优点：1)设计上的灵活性,可以在项目的各个阶段进行变更。 2)以小的分段来构建大型系统,使成本计算变得简单容易。 3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 4)随着项目推进,客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互。 5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。 缺点：建设周期长，和当前技术水平差距大，无法满足需求； 适用范围：庞大复杂并具有高风险的系统，特别适合内部开发的大规模软件项目 2、喷泉模型 特点：无明显边界、阶段内迭代 优点：各阶段无明显界限，开发人员同步进行，提高项目开发效率缺点： 重叠的项目不利于项目管理，审核难度加大 适用：面向对象的软件过程 3、重用构件模型 4、RUP 通用的过程框架 4个阶段 9个核心工作流 前6个为核心过程，后3个是核心支撑
模型驱动的体系架构MDA
模型驱动的体系架构MDA 很多组织已经开始对模型驱动的体系架构（MDA）进行关注，MDA 是一种应用系统设计和实现的方法。对于几个原因来说这都是非常积极的发展。 MDA 鼓励在软件的开发过程中有效的使用系统的模型，并且它支持创建类似系统的最佳实践的重用。所谓由对象管理组织（OMG）定义的标准，MDA 是一种组织和管理被自动化工具支持的企业体系架构和用于定义模型和推动不同模型类型之间的转换的服务的方法。 当被 OMG 定义的 MDA 标准和用于创建和进化企业级软件系统的术语在业界被广泛的引用时，仅仅到目前为止， OMG 和它的成员，包括 IBM Rational ，已经能够在 MDA 意味着什么、MDA 将向哪里发展、MDA 的哪些方面对于今天的技术是可能的和如何在实践中利用 MDA 上提供清晰的指导。 有效的企业软件开发 今天开发企业级的应用要求一种软件架构的方法，这种方法应该能够以一种灵活的方式帮助架构师来发展他们的架构。这种方法应该允许在及时的实现业务功能的新的能力的情况下重用已有的劳动成果，甚至是当目标基础架构本身在一直的演进。两个重要的思想现在被认为是应对这种挑战的中心： ? 面向服务的体系架构(SOA)。企业解决方案能够被视作通过良好的说明定义了他们的服务接口契约连接的服务联合。结果的系统设计通常被称作面向服务的体系架构（SOAs）。通过将一个系统组织成为被封装好的服务集合，这些服务可以通过他们定义的服务接口被操作，系统的灵活性被大大的增强了。现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。 ? 软件的产品线。通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。从捕获核心业务过程和领域概念的标准领域模型，到开发人员在代码中使用的实现设计的实现细节方案，我们在企业的软件项目的每一个级别上看到了重用的方法。当模式能够被经验丰富的从业者开发出来并在跨越组织的范围内传播时，软件开发组织将获得大量的效率。这表现了一种朝着促进计划的资产重用，增加自动化的级别来实现被开发系统大部分的方案的软件产品线开发视图的迁移。更加普遍的情况下，我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。 这两种思想对对象管理组织（OMG）的思想有着重大意义的影响，一个开发和支持规范以改进企业软件开发和部署实践的软件组织联盟（在下一个部分 OMG 将扮演更重要的角色）。OMG 已经创建了一个概念性的框架，这个概念性的框架将平台选择与独立的面向业务的决定分离开来以使在架构和演进这些系统时允许更大的灵活性。这个概念性框架和帮助实现它的标准就是 OMG 称为的"模型驱动的体系架构（MDA）."。应用的架构师使用 MDA 框架作为表示他们企业架构的蓝图，并且使用在 MDA 中的开发标准作为他们独立于供应商和技术的"未来的证明"。 OMG 的 MDA 的概念通过 OMG 的构建模型的标准对系统的交互性提供了一种开放的、供应商中立的方法：统一建模语言（UML），Meta-Object Facility (MOF)，XML Metadata Interchange (XMI) 和Common Warehouse Meta-model (CWM) 。企业应用的描述能够使用这些建模标准被建立并被转化到一种主流的开发的或者是私有的平台上，包括 CORBA ，J2EE ，.NET 和基于 Web 的平台。 在我们开始深入的了解 MDA 之前，让我们考虑一下在软件开发中进行建模的基本概念和好处。 建模的基本原理 模型提供了一个物理系统的抽象，模型可以让工程师们通过忽略无关的细节而把注意力放到系统的重要部分来思考系统。工程中的所有工作形式都依赖模型来理解复杂的、真实世界的系统。模型被用在很多的方面：预期系统的质量，当系统的某些方面变化时推理特定的属性，和为各种涉众沟通关键的系统特征。模型也可以作为实现物理系统的先驱被开发，或者模型可以根据一个已存在的系统或者开发中的系统被产生作为理解系统行为的帮助手段。
(Model Base Design)基于模型的设计
什么叫基于模型的设计？ 为什么要基于模型的设计？ 基于模型的设计过程中，需要做什么事情？ 再问几个小问题： 模型验证是否必要？ 模型验证有哪些工作可以做？ 模型验证是否一定需要被控对象模型？ 代码生成效率如何？ 底层驱动是否要建模？ Embedded Coder（以前的RTW Embedded Coder）支持哪些芯片？ MIL、SIL、PIL、HIL的目的和实现方式？ 如何定点化？ 如何做代码集成？ 什么叫基于模型的设计？ 这是一个很大的话题，因为本人能力所限，仅讨论使用Simulink模型开发嵌入式软件的设计过程。也就是说，我只能聊基于模型的嵌入式软件设计。 我的理解是，通过对算法建模进行软件设计的过程，都可以叫基于模型的设计。 当然，如果仅限于算法建模，把Simulink/Stateflow当做Visio使用，而不去进行其他环节的工作，这样的基于模型设计是不完整的，可能对你的开发效率不会有很大的提升。 如果想通过基于模型的设计提升软件开发团队的开发效率，提高软件品质，我觉得至少有如下几点可以考虑： 算法建模 算法模型的验证 文档自动化 代码生成 代码和模型的等效性验证。 传统的开发过程中，我们有一个环节，需求捕获，也即，从系统需求分解出软件需求。 在基于模型的设计过程中，我们同样可以通过分析系统需求，获得软件需求。 当然，根据系统需求的详细程度，我们可以考虑是否要写专门的软件需求。 在基于模型的软件设计中，我们主要关心的是系统的功能需求，或者说可以通过软件实现的功能需求。如果这部分需求在系统需求文档里已经有非常清楚的定义，那么我们可以以系统需求文档作为依据建立模型。 当然，如果系统需求不是足够清楚，那我们有必要编写专门的软件需求文档。 如果不考虑Simulink/Stateflow的应用上的问题，也就是说，如果我们都是熟练的Simulink/Stateflow用户，那么建模过程的主要工作是需求分析，通俗点讲，需求弄清楚了，建模也就是非常简单的事情了。 当然，建模的时候，要考虑未来的验证、实现以及后期维护的问题。 我个人的体会，这个阶段，不要着急建模，一定要先弄清需求，另外，建模的时候，模型架构非常重要。
基于软件复用的信息系统开发模型
收稿日期:2004206226;修返日期:2004208231 基于软件复用的信息系统开发模型 殷 磊,王润孝,王东勃 (西北工业大学制造自动化软件与信息研究所,陕西西安710072) 摘 要:在简要地介绍软件复用的概念和关键技术的基础上,结合领域工程、应用工程、组件化开发、原型开发方法以及面向对象开发方法等技术的优势,提出了一种基于软件复用的信息系统开发模型。关键词:软件复用;信息系统;开发模型 中图法分类号:TP311154 文献标识码:A 文章编号:100123695(2005)0820086203 I nfor mati on Syste m Devel opment Model Based on Soft w are Reuse YI N Lei,WANG Run 2xiao,WANG Dong 2bo (Institute of M anufacturing Auto m ation Soft w are &Infor m ation,N orthw estern Polytechnical U niversity,X i ’an Shanxi 710072,China ) Abstract:W ith the concep t and the key contents of s oft w are reuse t o intr oduce concisely,this paper p resents a inf or mati on syste m devel model based on s oft w are reuse with the advantages of domain engineering,app licati on engineering,com 2ponent 2based method,p r ot otype method and oriented 2object method .Key word:Soft w are Reuse;I nfor mati on Syste m;Devel opmentModel 1 软件复用 随着计算机应用领域的不断扩展,以及人们对利用计算机来解决各种问题的日益依赖,软件开发所需要解决问题的复杂程度急剧膨胀,系统的规模和复杂度也随之空前地扩大。软件的复杂性和其中包含的错误已经达到了开发人员无法控制的程度,这便是人们所说的软件危机。为了解决这个问题,人们提出了软件复用的方法。 所谓软件复用是指在软件开发活动中,利用已有的、可复用的软件成分来构造和生成新的软件系统。该软件成分可能是已有的软件成分,也可能是为复用而专门设计开发的可复用软件成分。可复用软件成分范围比较广泛,包括源代码、组件、需求分析结果、软件体系结构、设计方案、测试计划以及测试案例等。软件复用被认为是解决软件危机、提高软件生产率和软件质量、增强软件的开放性和对外部扰动的适应性的主要途径[1]。如今,软件复用技术已经发展成为软件工程的一个重要研究领域,人们对软件复用技术和方法进行了广泛、深入的研究,在复用技术上取得了一定的成果和成功的实践经验。 2 软件复用的关键技术 系统化软件复用有两个基本问题:①必须有可以复用的对象;②复用者需要知道如何去使用被复用的对象。因此软件复用包括两个相关的过程:面向复用的开发(Devel opment for Re 2 use )和使用复用进行开发(Devel opment with Reuse )[2] 。面向 复用的开发生成可复用的软件资产,包括软件组件、需求规范以及开发文档,即可复用的对象。这一生成可复用对象的过程可以是软件生产者从已经存在的应用系统中提取,也可以是由软件生产者重新进行设计开发。使用复用进行开发是利用已存在的可复用对象进行应用系统的开发。 实现系统化软件复用的关键技术主要包括:面向对象技术 (O riented Object Technol ogy )、软件组件技术(Soft w are Compo 2nent Technol ogy )、领域工程(Domain Engineering )、应用工程(App licati on Engineering )、软件体系结构(Soft w are A rchitec 2ture )、设计模式(Design Patterns )、软件再工程(Soft w are Ree 2ngineering )、开放系统(Open Syste m )、软件过程(Soft w are Pr ocess )、C ASE (Computer A ided Soft w are Engineering )技术以及 各种非技术因素等[2]。 211 领域工程 领域工程[3]是针对一个应用领域中的若干系统进行分析,建立基本能力和必备基础,并识别这些系统共享的领域需求,设计出能够满足这些需求的构架,并在此基础上开发和组织该领域的可复用构件的过程,它覆盖了建立可复用软件构件的所有活动。可复用软件构件的含义比较广泛,它包括了领域内所有可复用的软件成分。 领域工程包括领域分析、领域设计以及领域实现等三个主要的步骤,其中,领域分析是实施领域工程的关键步骤,也是人们研究的重点。领域分析输出的产品为领域模型。领域模型用于收集、组织和表示领域中所有可复用的信息,其目的是帮助用户了解问题域,并明确领域中可以复用的软件资产。图1显示了领域分析的输入和输出 。 ?68?计算机应用研究 2005年