新兴服装销售管理软件开发方法

随着基于互联网应用(例如电子政务、电子商务、远程教育、远程医疗和网上娱乐等)的迅速普及，为满足竞争的需要，软件的应用和开发也面临新的要求，即以快速的软件开发适应日益变化的用户需求和市场环境。
在这种新需求的驱动下，服装销售管理软件开发人员经常处于进退两难的境地中。一方面他们倾其全力于解决项目开发中所遇到的各种问题，工作量极大；另一方面，要让软件尽快交付使用的客户需求使开发人员焦头烂额。在这种内外交困的情况下，如何筛选、制定最适合的软件开发过程，以最大程度地在开发进度与软件质量之间保持理想的平衡成为软件开发人员所面临的最大挑战之一。
针对这种变化，一些新的软件开发方法相继被提出。所谓新方法是相对于以瀑布式软件开发方法为代表的传统软件开发方法而言的。由于传统方法要求有大量、详实的文档、严格的过程执行纪律和较弱的应对变化的能力，导致了这些方法难以适应快节奏的软件开发要求。在这些新方法中较有代表性的有敏捷软件开发方法、软件复用和基于构件的软件工程方法。
本章针对敏捷软件开发方法、服装销售管理软件复用和基于构件的软件工程方法的基本概念、理论和方法进行介绍。

1．1敏捷软件开发方法
敏捷软件开发方法又称敏捷开发，是一种从1990年开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的软件开发方法。较传统软件开发方法的具体名称、理念、过程、术语都不尽相同。该方法更强调程序员团队与业务专家之间的紧密协作、沟通、频繁交付新的软件版本、紧凑而自我组织的团队、能够很好地适应变化的需求，也更注重人在软件开发中的作用。
敏捷软件开发方法不是一个具体的过程，而是一个概括性术语，用于概括具有类似基础的技术和方法。这些方法包括极限编程方法、水晶系列方法、功能驱动方法、适配性软件开发方法和快速应用开发方法等，这些方法都着眼于快速交付高质量的软件给用户，并做到客户满意。

1．1．1敏捷软件开发方法
2001年初，随着基于Internet应用的广泛普及，众多软件团队陷入了不断变化的技术环境与用户需求的泥潭之中。在一批业界专家的号召下，他们聚集在一起，从以往失败的软件开发案例中总结出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。他们称自己为敏捷联盟。在随后的几个月中，敏捷联盟在综合各家言论的基础上，发布了敏捷联盟宣言。宣言的发布标志着敏捷软件开发方法以一种具有鲜明特色的软件工程方法进入了人们的视野。同时，在敏捷宣言中明确地提出了以下价值观：
(1)个体和交互胜过过程和工具。
(2)可用的软件胜过面面俱到的文档。
(3)客户合作胜过合同谈判。
(4)响应变化胜过遵循计划。

1．个体和交互胜过过程和工具
软件是人类思维的外化产物，因此，人是获得成功软件最为重要的因素。如果团队中没有优秀的开发人员，即使使用再好的软件过程也不能从失败中挽救项目。同样，不好的软件过程也可以使最优秀的开发人员失去效用。例如，如果不能作为一个团队进行工作，那么即使拥有一批优秀的开发人员，项目也一样会惨败。
一个优秀的团队成员未必就是一流的程序员。一个优秀的团队成员可能是一个水平一般的程序员，但却拥有较好的合作、沟通以及交互能力。在敏捷软件开发方法中认为团队成员的合作、沟通以及交互能力要比单纯的编程能力更为重要。一个由水平一般的程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员之间却不能进行有效交流的团队更有可能获得成功。 另外，合适的工具对于项目的成功来说是非常重要的。这些工具包括编译器、程序编辑环境、源代码控制系统等。虽然对于团队的开发者来说，合适的工具对于正确地完成项目开发是至关重要的。然而，工具的作用可能会被过分地夸大。使用过多的庞大、笨重的工具就如同缺少工具一样，都是不好的。

2．可以工作的软件胜过面面俱到的文档
没有文档的软件是种灾难。因为，代码不是传达系统原理和结构的理想媒介，当然，也就更谈不上为软件维护提供支持。对于团队来说易于阅读的文档是必要的。
然而，过多的文档比过少的文档更糟。首先，编制众多的文档需要花费大量的时间、精力、人力和物力，并且保持这些文档和代码的同步的开销将会比创建文档更为巨大。如果文档和代码之间失去同步，那么文档除了会变得庞大、复杂，更有甚者会造成重大的误导。
对于团队来说，编写并维护好关于系统原理和结构文档总是有益的，但该文档应该尽量短小并且主题突出。“短小”意味着最多有二十页。“主题突出”意味着应该仅论述系统的结构和设计原理。

3．客户合作胜过合同谈判
软件系统的开发过程是人类对软件产品问题域进行反复认识、抽象的过程。因此，客户不能指望仅仅依靠一份需求规约，就让程序员在固定的时间内以固定的价格去开发该软件。所有用这种方式来对待软件项目的尝试大多以失败而告终，甚至是惨重的失败。
成功的项目需要有序、频繁的客户反馈。不是完全依赖于合同或者有关软件的需求陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
一个明确了需求、进度以及项目成本的合同根本上是存在缺陷的。在大多数的情况下，合同中指明的条款远在项目完成之前就有可能发生变化。因此，从这个意义上来说，那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。

4．响应变化胜过遵循计划
响应变化的能力常常决定着一个软件项目的成败。当构建开发计划时，应该确保计划具有足够的灵活度，并且易于适应商务环境和技术方面的变化。开发计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运行，他们很可能会改变需求。最后，即使软件工程师熟悉需求，并且确信它们不会改变，仍然不能很好地估算出开发它们需要的时问。
对于缺乏经验的管理者来说，创建甘特图并依托这些图进行软件管理是一种常见的方法。管理者认为这张图赋予了他们控制整个项目的能力。根据这些图他们能够跟踪单个人的任务，在任务完成时将任务从图上去除，并且可以对实际完成的日期和计划完成的日期进行比较，并对 出现的任何偏差做出反应。
实际情况是随着开发的推进，团队和客户对系统的认识会变得更加清晰，导致新需求和新设计方案的出现。图中的某些任务会被删除，一些任务会被发现并增加到图中，这张图的组织结构就不再适用。 较好的做计划的策略是：本周只为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。应该清楚地知道下两周要完成的任务，粗略地了解下以后三个月要实现的需求。至于系统年后将要做什么，有一个模糊的想法就行了。 计划中这种逐渐降低的细致度，意味着仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。

1．1．2极限编程方法
极限编程(ExtremeProgramming，XP)是由KentBeck在1996年提出的。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年3月，Kent提出了新的软件开发观念一～XP。
XP是一种轻量级的、灵巧的软件开发方法。同时，该方法具有严谨和周密的特征。XP的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从四个方面入手进行改善：加强交流、从简单做起、寻求反馈和勇于实事求是。XP是一种近似螺旋式的开发方法，它将复
杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
“Extreme(极限)”是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好。XP所不提倡的，则一概忽略(如开发前期的整体设计等)。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。

具体来说，极限编程要求有极限的工作环境、极限的需求、极限的设计、极限的编程和极限的澳l试。
1．极限的工作环境
为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。每个参加项目开发的人都将担任～个角色(项目经理、项目监督人等)并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作，每周40小时，不提倡加。
2．极限的需求
客户应该是项目开发队伍中的一员，而不是和开发人员分开的。因为从项目的计划到最后验收整个过程客户一直起着很重要的作用。开发人员和客户一起，把各种需求分割为一个个小的需求模块，这些模块又会根据实际情况被组合在一起或者被再次分解成更小的模块。上述需求模块都被记录在一些小卡片(StoryCard)上，之后将这些卡片分别分配给程序员们，并在一段时间内(通常不超过3个星期)实现。客户根据每个模块的商业价值进行排序，确定开发的优先级。开发人员要做的是确定每个需求模块的开发风险。风险高的(通常是因为缺乏类似的经验)
需求模块将被优先研究、探索和开发。经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划。
3．极限设计
从具体开发过程的角度来看，XP内部的过程是多个基于测试驱动的开发(TestDrivenDe—velopment)周期。诸如计划和设计等外层的过程都是围绕这些测试展开的，每个开发周期都有很多相应的单元测试(UnitTest)。通过这种方式，客户和开发人员都很容易检验所开发的软件原型是否满足了用户的需求。XP提倡简单的设计(SimpleDesign)，即针对每个简单的需求用最简单的方式进行设计和后续的编程工作。这样写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式(BigDesignUpFront)，因为在这种设计中有很多内容是现在或近期所不需要的。
XP还大力提倡设计复核(Review)、代码复核、重整和优化(Refectory)。所有的这些过程的目标，归根到底还是对设计的优化。在这些过程中不断运行单元测试和功能测试，可以保证经过优化后的系统仍然符合用户的需求。
4．极限编程
编程是程序员使用某种程序设计语言编写程序代码，并最终得到能够解决某个问题的程序的过程。XP极其重视编程，提倡配对编程(PairProgramming)，即两个人一起写同一段程序，而且代码所有权是归于整个开发队伍(CollectiveCodeOwnership)。程序员在写程序和优化程序
的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。
5．极限测试
测试在XP中是很重要的。XP提倡开发人员经常把开发好的模块整合到一起(ContinuousIntegration)，并且在每次整合后都进行单元测试。对代码进行的任何复核和修改，也都要进行单元测试。发现了错误，就要增加相应的测试，因此XP方法不需要错误数据库。
除了单元测试之外，XP还要进行整合测试、功能测试、负荷测试和系统测试等。这些测试是XP开发过程中最重要的活动之一，与之相对应的测试文档也是最终交付给用户的内容之一。

根据极限编程的价值观，可以总结出使用该方法进行项目开发的时候应该遵循的规则。
1)完整团队
XP项目的所有参与者(开发人员、客户和测试人员等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2)计划
在XP项目中，计划是持续的、循序渐进的。XP项目组只为下两周的开发活动估算开发成本，而客户则根据成本和商业价值来选择要实现的功能模块。
3)客户测试
客户测试已经开发好的模块是否符合客户的需求。
4)简单设计
XP项目团队应当保持设计方案恰好和当前的系统需求相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5)配对编程
所有的产品软件都是由两个程序员并排坐在一起共同开发的。
6)测试驱动开发
编写单元测试是一个验证行为，更是一个设计行为。同样，它也是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。
7)改进设计
随时利用重构方法改进已经过时的代码，保持代码尽可能的干净、具有表达力。
8)持续集成
XP团队总是对现有模块进行集成。
9)代码所有权归集体所有
任何配对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负贡，每个人都可以参与任何兵他方面的开发。
10)编码标准
制定编码标准，并且整个团队都必须遵守该编码标准。使系统中所有的代码看起来就好像是一个人编写的。
11)可持续的速度
XP团队成员以能够长期维持的速度努力工作，保存精力，把项目看做是马拉松长跑，而不是全速短跑。

1．1．3水晶系列方法
Alistair更进一步地探索了敏捷型方法，并在此基础上提出了水晶(Crystal)系列方法。之所以是个系列，是因为他相信不同类型的项目需要不同的软件开发方法。并且他认为决定一个软件开发方法是否有效与两个因素有关：项目参与人数和出错后果。如果用两个坐标轴来分别表示这两个变量的话，那么在这张图上，每一种方法都有其相应的位置。例如，有两个项目，一个是有40人参加，如果失败造成的资金损失可以接受；另一个项目只有6人，其成败生死攸关。那么这两个项目所用的方法在坐标图上就有不同的位置。
水晶系列与XP一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP有那样的产出效率，但会有更多的人能够接受并遵循它。

1．1．4功能驱动方法
功能驱动方法(FeatureDrivenDevelopment，FDD)是由JeffDeLuca和面向对象方法大师PeterCoad提出来的。与其他敏捷方法一样，它致力于用最短的迭代周期实现最多的可见可用的功能模块数。在功能驱动方法中，一个迭代周期一般是两周。
功能驱动方法有以下五项任务：
(1)建立总体模型。
(2)提出功用清单。
(3)针对功用逐项制订计划。
(4)针对功用逐项进行设计。
(5)针对功用逐项开发实现。
前三项在项目开始时完成，后两项在每一次迭代周期中都要做。每一项任务又可进一步分解并制订出相应的检验准则。
在功能驱动方法中，编程开发人员被分成两类：首席程序员和“类”程序员(ClassOwner)。首席程序员是最富有经验的开发人员，他们负责定义系统的各项功能、各功能模块之间的关系。对每一项功能，首席程序员指定出需要哪些类来实现这项功能，并召集“类”程序员们组成一个针对这项功能的开发组。首席程序员作为协调者、设计者和指导者，而“类”程序员则主要作源码编写。

1．1．5适配性软件开发方法
适配性软件开发方法借鉴了开发复杂适配性系统(通常称之为混沌系统)的相关思想、理论和方法。将其运用于在软件开发中。该方法没有像XP那样提供详尽的实践准则，但它从根本上说明了为什么适配性开发方法是重要的，并进一步说明了其对组织结构和管理层的影响。
适配性软件开发方法的核心是三个非线性的、重迭的开发阶段，即猜测、合作与学习。
在一个适配性环境中，因为结果是不可预的。因此，把计划看成是一个“反论(Paradox)”。在传统的计划中，偏离计划是错误，应予纠正。而在一个适配性环境里，偏离计划则是引导向正确的目标迈进。
在不可预测的环境里，需要开发人员和客户能以多种多样的方式合作来对付不确定性。在管理上，其重点不在于告诉开发人员做什么，而是鼓励开发人员和客户交流沟通，从而使其能自己提出创造性的解决方案。在可预测性环境里，通常是不大鼓励学习的。设计师已经都设计好
了，程序员只需要按照已有设计方案进行程序编制就可以了。在适配性环境中，学习对所有各方，包括开发人员和客户，都是一个挑战。他们需要学习以检验他们所作的假设，需要学习以便能用每次开发周期的结果去适配下一个周期。
有了这样的出发点，适配性软件开发方法将其工作重心放在适配性开发的难点上，特别是如何在一个项目中增强合作和学习。基本上说，他的方法是侧重于“软”方法，这样对那些从开发实践中提炼出来的方法如XP、功能驱动和水晶系列方法来说，该方法将是一个很有益的补充。

1．1．6快速应用开发方法
快速应用开发(RapidApplicationDevelop，RAD)方法是一个增量型的软件开发方法，强调极短的软件开发周期。该模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得了快速开发。如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快创建出功能完善的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD目的是快速发布系统方案，而技术上的优美相对发布的速度来说是次要的。
RAD模型各个活动期所要完成的任务如下。
1)业务建模
确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以辅之以数据流图。
2)数据建模
为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可辅之以E—R图。
3)过程建模
使数据对象在信息流中完成各业务功能，创建过程以描述数据对象的增加、修改、删除和查找，即细化数据流图中的处理框。
4)应用程序生成
利用程序设计语言写出处理程序，重用已有构件或创建新的可重用构件，利用环境提供的工具自动生成应用系统。
5)测试与交付
由于大量重用，一般只做总体测试，但新创建的构件还是要经过测试。
与瀑布模型相比，RAD模型不采用传统的第3代程序设计语言来创建软件，而是采用基于构件的软件开发方法，复用已有的程序结构或使用可复用构件和创建可复用的构件。在所有情况下，均使用自动化工具辅助软件创造。很显然，一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，则其是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现，最后集成起来形成一个整体。
RAD包含了4个方面的技术：
(1)进化原型。
(2)CASE工具(可进行正向工程和反向工程)。
(3)拥有能使用先进工具的专门人员(一个RAD开发小组)。
(4)时间表。
RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是与所有其他软件过程模型一样，RAD模型也有不足之处：
(1)对大型项目而言，RAD需要足够的人力资源。
(2)开发人员和客户必须在很短的时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。
(3)并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合。

1．2软件复用
1．2．1软件复用的概念
传统的软件开发方法认为每一个软件系统的开发应该严格地按照软件生命周期所规定的过程，逐一进行推进。因此，使用传统软件开发方法开发软件系统经历了一个从无到有，从抽象到具体的过程。传统软件开发方法不注意和关心软件重复创建出现的次数。重复创建在软件开发中造成了重大的资源浪费。无数软件项目耗费大量资源去开发已经存在的或相似的软件。软件浪费的现象普遍存在。对软件系统的比较分析表明，在多个系统中，系统功能的60％～70％是相同的．要实现软件开发的自动化、工业化，提高软件开发的质量和速度，需要改变传统的软件开发模式。软件复用技术就是为了实现上述目标，避免软件开发过程中重复劳动而产生的。通过软件复用，开发人员可以通过复用已有的高质量的开发成果，避免了重新开发可能引入的错误，避免在软件开发中的重复劳动，极大地提高了软件开发的劳动生产效率和产品质量。

软件复用是一种通过对预先构造好的、以复用为目的软件构件实施组装活动，从而建立软件系统的过程。它的基本思想非常简单，即放弃那种原始的、一切从头开始的软件开发方式，而是利用复用技术，由可复用构件来组装新的系统，这些可复用构件包括对象类、框架或者软件体系结构等。

1．2．2软件复用的意义
软件复用技术对提高软件产业效率，推进软件产业真正走上工程化、工业化具有如下重要意义。
1)提高生产率
软件复用最明显的好处在于提高生产率，从而减少开发代价。生产率的提高不仅体现在代码开发阶段，在分析、设计及测试阶段同样可以利用重用来节省开销。
2)减少维护代价
这是软件复用的一个重要优点。由于使用经过检验的构件，减少了可能的错误，同时软件中需要维护的部分也减少了。
3)提高互操作性
一个更为重要的好处在于软件复用技术提高了系统间的互操作性。基于复用技术生产的软件系统，大多使用相同的接口对外实现通信。因此，系统将更为有效地实现与其他系统之间的互操作。
4)支持快速原型
软件复用技术的另一个好处在于对快速原型的支持，即可以快速构造出系统可操作的模型，以获得用户对系统功能的反馈。利用可复用构件可以快速有效地构造出应用程序的原型。
5)减少培训开销
软件复用技术还有利于减少培训开销，即雇员在熟悉任务时所需的非正式的开销。软件工程师将使用_个可复用构件库，其中的构件都是他们所熟悉和精通的。

1．2．3软件复用的关键技术
软件复用包含了各种技术因素和非技术因素，它们相互联系，共同影响软件复用的发展。下面将针对软件复用过程中涉及的技术因素和非技术因素展开讨论。
1．构件技术
构件技术是支持软件复用的核心技术。构件技术就是一种类似于集成组装式的软件生产方式。它把零件、生产线和装配运行的概念运用在软件产业中，彻底打破了手工作坊式的软件开发模式。
构件是指语义完整、语法正确和有可复用价值的单位软件，包括程序代码、测试用例、设计文档、设计过程、需求分析文档和领域知识等。广义上讲，构件可以是数据，也可以是被封装的对象类、软件构架、文档和测试用例等。一个构件可以小到只有一个过程，也可以大到包含一个应用程序。它可以包括函数、例程、对象、二进制对象、类库和数据包等。
构件具有以下特点：
(1)构件是一个独立的可部署单位，它能很好地从环境和其他构件中分离出来。同时，作为一个部署单位，一个构件不会被部分地部署，第三方也无法获取构件的内部实现细节。
(2)构件是一个由第三方进行集成的单位，同其他构件一起组合使用。这就要求构件必须封装其实现细节并通过定义良好的接口与其环境进行交互。
(3)构件是可替换的，构件通过接口与外界进行交互，明确定义的接口是构件之间唯一可视的部分。实现接口的具体构件本身就是可以替换的部分。构件的可替换性为构件的装配者、使用者提供了可选择的空间。

2．软件框架
软件框架是对系统整体设计结构的规划。包括了全局组织与控制结构；构件间通讯、同步和异步数据访问的协议；设计元素间的功能分配、物理分布；设计元素集成、性能；设计选择等。在基于复用的软件开发中，为复用而开发的框架可以作为一种大粒度的、抽象级别较高的构件进行复用，而且框架还为构件的组装提供了基础和上下文，对于成功的复用具有非常重要的意义。软件框架研究如何快速、可靠地从可复用构件构造系统的方式，着重于软件系统自身的整体结构和构件间的互联。其中主要包括软件框架原理和风格，软件框架的描述和规约，特定领域软件框架，构件向软件框架集成机制等。

3．领域工程
领域工程是为一组相似或相近系统的应用工程建立基本能力和必备基础的过程，它覆盖了建立可复用软件构件的所有活动。其中“领域”是指一组具有公共属性的系统。
领域工程可以从已经存在的系统中提取可复用的信息，把关于领域的知识转化为领域中系统共同的规约、设计和构架，使得可以被复用的信息的范围扩大到了抽象级别较高的分析和设计阶段。也可以把领域内的知识转化为可复用的信息，极大地提高了软件复用的层次，也丰富了软件复用的内容。
领域工程包括三个阶段：领域分析、领域设计和领域实现。
(1)领域分析：识别和捕捉特定领域中相似系统的有关信息，通过挖掘其内在规律及其特征，并对信息进行有效的整理和组织形成模型的活动。其输出是领域模型。
(2)领域设计：通过对领域模型的分析来获取领域架构。
(3)领域实现：依据领域架构组织和开发可复用信息。信息可以从领域工程中获得，也可以新开发得到。
值得注意的是这三个阶段是一个反复、迭代、逐步求精的过程。

4．软件再工程
目前，大量遗产系统仍在运行中，由于其运行多年，经历了长期的用户考验，功能及非功能特性可能确实符合需求，可靠性也有较好保证。但与此同时，也有大量的遗产软件系统由于技术的发展，正逐渐退出使用。如何对优秀的软件进行挖掘和整理，得到有用的构件。对一些落伍的软件进行维护，延长其生命期等问题正是软件再工程技术所关注的问题。
软件再工程是指对已存在对象系统进行分析，并将其重构为新形式代码的开发过程。最大限度地重用遗产系统的各种资源是软件再工程的最重要特点之一。，它将逆向工程、重构和正向工程组合起来，将现存软件系统重新构造为适应新的应用需要新系统。

5．开放系统技术
开放系统(OpenSystem)技术是在系统的开发中使用接口标准同时使用符合接口标准的实现。当前以解决异构环境中的互操作为目标的分布对象技术是开放系统技术中的主流技术。该技术使得符合接口标准的构件可以方便地以“即插即用”的方式组装到系统中，实现黑盒复用。

6．CASE技术
CASE是一种智能化计算机辅助软件工程(ComputerAidedSoftwareEngineering，CASE)工具。随着软件工程思想的Et益深入人心，以计算机辅助开发软件为目标的CASE技术越来越为众多的软件开发人员所接受，CASE工具和CASE环境得到越来越广泛的应用。CASE工具已成为保证软件质量，解决软件危机的主要手段。
软件复用同样需要CASE技术的支持。CASE技术中与软件复用相关的主要研究内容包括：可复用构件的抽取、描述、分类和存储、可复用构件的检索、提取和组装和可复用构件的度量等。

7．软件过程
软件过程(SoftwareProcess)又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。一个良好定义的软件过程对软件开发的质量和效率有着重要影响。

8．非技术因素
非技术因素包括机构组织、管理方法、开发人员的知识更新、知识产权和标准化问题等。

1．2．4软件复用的粒度
可供复用的软件产品包含了10种，其中除源代码外，还包括体系结构、需求模型和规约、各种设计、用户界面、数据、测试用例、用户文档、技术文档、项目计划和成本估计等。按照可复用的粒度的大小，可以将这些软件制品从小到大分为以下几类。
1．源代码复用
源代码的复用是最常见的一种复用形式，指对构件库中用高级语言编写的源代码构件的复用。源代码构件本身就是为复用而开发的，存放在可供访问的构件库中。使用者通过对构件库的检索找到满足用户需求的构件，并设置参数值使之具有新的适应性，即可调用构件完成既定计算任务。不难看出，这类复用的特点是：一方面由于构件是经过充分测试的，因此具有较高的可靠性，而且使用者只需设置参数而无需介入构件内部，降低了复用的难度；但另一方面，正因为构件是为复用而开发的，因此，其通用性、抽象性成为在具体使用时必须要面对的问题。
2．软件体系结构复用
软件体系结构复用是指对已有的软件体系结构的复用。这类复用既可以支持高层次的复用，也可以支持低层次的复用。要求存放体系结构的库能提供有效的检索功能，使用者通过良好定义的接口进行集成。
这类复用的特点是：一方面，可复用较大粒度的软件制品，其修改具有局部性；另一方面，因为难以抽象出简明的描述，存放体系结构的库往往不易管理。
3．应用程序生成器
应用程序生成器用于对整个软件系统的复用，包括整个软件体系结构、相应的子系统和特定的数据结构和算法的复用。理论上来说，应用程序生成器可以用特定领域的需求规约作为输入，生成器根据输入的规约填充原来不具备的细节，并产生一个完整的可执行系统，但这种方法一般仅针对一些成熟的领域。
这类复用的特点是：一方面，自动化程度高，能获取某个特定领域的标准和以黑盒形式输出结果(应用程序)；另一方面，特定的应用程序生成器不易构造。
4．特定领域的软件体系结构复用
这类复用是指对特定领域中存在的一个公共体系结构及其构件的复用。要求对领域有透彻的理解才能进行领域建模；构件库是针对特定领域的；领域模型、基准体系结构和构件库都随着领域的发展而不断发展。基准体系结构用体系结构描述语言来描述，根据相关领域的特定情况．从构件库中选择基准体系结构和构件，并通过良好定义的接VI进行集成。
这类复用的特点是：一方面，复用的程度高，对可复用构件的组合提供了一个通用框架；另一方面，前期投资很大。

1．2．5软件复用与面向对象方法
面向对象的软件开发和软件复用之间存在着天然的联系。一方面，面向对象方法的基本概念、原则与技术提供了实现软件复用的有利条件；另一方面，软件复用技术也对面向对象的软件开发提供了有力的支持。
1．类库
在面向对象的软件开发中，类库是实现对象类复用的先决条件。业界基于各种面向对象程序语言已经开发了种类繁多的编程类库，有力地支持了源程序级的软件复用。但若要在更高的层次上实现软件复用，仅有编程类库是不够的。实现对面向对象分析结果和面向对象设计结果的复用，必须有分析类库和设计类库的支持。为了更好地支持多个抽象层次的软件复用，可以在面向对象分析类库、面向对象设计类库和面向对象编程类库之间建立各个类在不同开发阶段的对应与演化关系。即建立一种映射关系，明确每个面向对象分析的类对应着哪个(或哪些)面向对象设计类，以及每个面向对象设计类对应着各种面向对象程序语言类库中的哪个类。

2．构件库
类库可以看作一种特殊的可复用构件库，它为在面向对象的软件开发中实现软件复用提供了基本的物质支持。类库只能存储和管理以类为单位的可复用构件以及保存类构件之间的结构与连接关系，但不能保存其他形式的构件。事实上，构件库中的可复用构件，既可以是类，也可以是其他系统组成单位。
构件库的组织方式，可以不考虑对象类之间存在的各种关系，只按一般的构件描述、分类及检索方法进行组织。在面向对象的软件开发中，可以提炼比对象类粒度更大的可复用构件，例如，把某些子系统或某些主题作为可复用构件；也可以提炼其他形式的构件，如UseCase图或交互图等。这样构件库中构件的形式及内容比类库更丰富，可为面向对象的软件开发提供更强的支持。

3．构架库
如果在某个应用领域中已经运用面向对象分析技术对一个或几个系统进行建模，则每个面向对象分析模型都应该保存起来，为该领域新系统的开发提供参考。当一个领域已有多个面向对象分析模型时，可以通过进一步抽象而产生一个可复用的软件构架。开展领域分析是形成这种可复用软件构架较为有效的途径。通过正规的领域分析获得的软件构架将更准确地反映一个领域中各个应用系统的共性，具有更强的可复用价值。

4．工具
软件工程工具对有效地支持软件复用有着积极的意义。这些工具包括了类库或构件／构架库的管理、维护与浏览工具、构件提取及描述工具，以及构件检索工具等。以支持复用为背景的面向对象分析工具和面向对象设计工具在设计上也有相应的要求。工具对面向对象分析和面向对象设计过程的支持应包括：从类库或构件／构架库中寻找可复用构件；对构件进行修改，并加入当前的系统模型；把当前系统开发中新定义的类(或其他构件)提交到类库(或构件库)。
5．基于复用的面向对象分析过程
在复用技术支持下的面向对象分析过程，可以按两种策略进行组织。第一种策略是，基本保持某种面向对象分析方法所建议的面向对象分析过程原貌，在此基础上对其中的各个活动引入复用技术的支持；另一种策略是重新组织面向对象分析过程。
第一种策略是在原有的面向对象分析过程基础上增加复用技术的支持。在复用技术支持下的面向对象分析过程应增加一个提交新构件的活动。即在一个具体应用系统的开发中，如果定义了一些有希望被其他系统复用的构件，则应该把它提交到可复用构件库中。第二种策略的前提是：在对一个系统进行面向对象的分析之前，已经用面向对象方法对该系统所属的领域进行过领域分析，得到了一个用面向对象方法表示的领域构架和一批类构件，并且具有构件／构架库、类库及相应工具的支持。在这种条件下，重新考虑面向对象分析过程中各个活动的内容及活动之间的关系，力求以组装的方式产生面向对象分析模型，将使面向对象分析过程更为合理，并达到更高的开发效率。

1．2．6软件复用所面临的困难
软件复用各方面的困难，无论是技术问题还是非技术问题，都影响着软件复用的广泛实行。
1．技术因素
对于某些构件要做到在被其他系统使用时从内容到对外接口都恰好相符，或者做很少的修改，是非常困难的。首先，构件要达到一定的数量，才能支持有效的复用，而大量构件的获得需要有很高的投入和长期的积累。其次，发现适合的构件是一个困难的抉择过程。当构件达到较大的数量时，使用者要从中找到一个自己想要的构件，并断定它确实是自己需要的，不是一件轻而易举的事。最后，基于复用的软件开发方法和软件过程是一个新的研究实践领域，需要一些新的理论、技术及支持环境，目前这方面的研究成果和实践经验都不够充分。
2．人的因素
软件开发是一种创造性工作，长期从事这个行业的人们形成了一种职业习惯：喜欢自己创造而不喜欢使用别人的东西，特别是当要对别人开发的软件作一些修改再使用时，他们常常喜欢自己另写一个。
3．管理因素
在软件生产的管理中，沿袭了一些与复用的目标很不协调的制度与政策，如计算工作量时，对复用的部分打很大的折扣，甚至不算工作量。另外，不是所有项目在开始时自觉地向着造就可复用构件的方向努力。而是在它完成之后，看看是否能从中找到一些可复用构件。这些弊端妨碍了复用水平的提高和复用规模的扩大，甚至会挫伤致力于复用的人员的积极性。

1．3基于构件的软件工程
基于构件的软件开发(Componept—BasedSoftwareDevelopment，CBSD)有时也称为基于构件的软件工程(Component—BasedSoftwareEngineering，CBSE)，它是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用方法。
利用构件的组装来构造应用系统是从20世纪90年代构件和CBSE技术相继出现后开始的。早期的CBSE强调在个人计算机上的应用。随着Internet的快速发展，使得CBSE成为可能。现在一些技术已被广泛运用并正在不断发展。
构件是功能独立的二进制软件单元。构件不仅具有规范的接口描述和构件模型，并且可以提供给第三方进行组装。它具有独立性、互换性和功能性的特点。软件构架描述的是系统整体设计格局、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及实例之间协作的方法，它是构件组装的基础。

1．3．1开发方法
CBSE的目的是用能即插即用的构件在软件构架下组装成一个应用程序，以实现软件复用。软件工程是采用工程的概念、原理、技术和方法来开发和维护软件，把经过考验证明是正确的管理技术与能得到的最好的技术方法结合起来进行软件开发。软件工程包括3个要素：方法、工具和过程。软件工程方法为软件开发提出了“如何做”的技术；软件工具为软件工程方法提供了自动的或半自动的软件支撑环境；过程则是将方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。下面从软件工程的角度来比较CBSE和传统重用技术的不同。
CBSE与传统软件重用采用了不同的方法：
(1)即插即用。这样构件能在不编译的运行状态下进行组合。
(2)以接口为中心。构件将接口和程序的执行相分离，便于在不知道执行细节的情况下进行组装。
(3)标准化。构件接口必须是标准化的接口，以便于广泛重用。
(4)通过市场来进行发布。构件是在市场流通中获得提高，同时也能刺激开发商开发更好、价格更低的通用构件。
大多数传统开发方法如面向对象的开发方法，都是从头开始进行。该方法将大量的开发时间都投入到底层编程中，不仅耗时，而且是重复劳动。CBSE将精力集中于构件的组装上，不必总是要从零做起。但是构件的组装也需要设计构件之间的相互协作关系，对构件进行管理。
如图10-2所示，CBSE的开发方法不仅要处理构件的开发还要处理构件的合成。针对领域的构件开发是非常有价值的。因为该方法具有一定程度的共性。构件开发时首先从应用领域中提取相对稳定的成分，利用建模工具建立模型。统一建模语言(UnifiedModelLanguage，UML)有利于规范这一过程。然后进行构件的设计和实现。它要求遵循开放的标准和应用的发展，这样设计出来的构件可移植性强。构件以构件库的形式组织起来存储，并提供必要的检索手段。这样所生成的构件和构件库将成为领域内相对通用的产品，实现领域内的软件重用。构件合成是构造系统的核心内容，它需要将获取到的构件组装成满足特定需求的系统。构件的组装必须以开放的构件模型和规范的构架描述(包括对构件连接和交互协议的严格定义)为基础，构件实例必须符合系统中其他部分的要求。

1．3．2工具支持
一个CBSD工具结构实际上也是一个构架，这个构架定义了已经选择的和将要进行操作的构件之间的关系。如图10—3所示是一个CBSD工具包结构的例子，包含了支持CBSD的基本元素，并将CBSD工具包分成3层：客户层、规则层和服务层。客户层是工具包用户可以使用的模型、生成、模型管理和服务；规则层提供了最基本的支持CBSD方法的模型引擎；服务层提供了持久的存储和与外在数据源的构件模型间的交换方法。

1．3．3开发过程
CBSD整个过程从需求开始，由开发团队使用传统需求分析技术或面向对象需求分析技术建立待开发软件系统需求规约。在完成体系结构设计后，并不立即开始详细设计，而是确定哪些部分可由构件组装而成。此时开发人员面临的决策问题包括了“是否存在构件满足系统需求”，
“这些可用构件的接口与体系结构的设计是否匹配”等。如果现有构件的组装无法满足需求，就只能采用传统的或面向对象的软件工程方法开发新构件。反之，则进入基于构件的开发过程，该过程大致包含如下活动。
1．构件识别
通过接口规约以及其他约束条件判断构件是否能在新系统中复用。构件识别分为发现和评估两个阶段。发现阶段的首要目标是确定构件的各种属性，如构件接口的功能性特征(构件能够向外提供什么服务)及非功能性属性(例如安全性、可靠性等)等。由于构件的属性往往难以获取、无法量化，导致了构件的发现难度较大。评估阶段根据构件属性以及新系统的需求判断构件是否满足系统的需求。评估方法常常涉及分析构件文档、与构件已有用户交流经验和开发系统原型。构件识别有时还需要考虑非技术因素，如构件提供商的市场占有率、构件开发商的过程成熟度等级等。
2．构件适配
针对不同的应用需求，用户可以选择独立开发构件或选择可复用的构件进行组装。这些构件对运行上下文环境做出了某些假设。软件体系结构定义了系统中所有构件的设计规则、连接模式和交互模式。如果被识别或自主开发的构件不符合目标系统的软件体系结构就可能导致该构件无法正常工作，甚至影响整个系统的运行，这种情形称为失配(Mismatch)。调整构件使之满足体系结构要求的过程就是构件适配。构件适配可通过自盒、灰盒或黑盒的方式对构件进行修改或配置。白盒方式允许直接修改构件源代码；灰盒方式不允许直接修改构件源代码，但提供了可修改构件行为的扩展语言或编程接口；黑盒方式是指不允许直接修改构件源代码且没有任何扩展机制的构件。如果构件无法适配，就不得不寻找其他适合的构件。
3．构件组装
构件必须通过某些良好定义的基础设施才能组装成目标系统。体系结构风格决定了构件之间连接或协调的机制，是构件组装成功与否的关键因素之一。典型的体系风格包括黑板、消息总线、对象请求代理等。
4．构件演化
基于构件的系统演化往往表现为构件的删除、替换或增加，其关键在于如何充分测试新构件以保证其正确工作且不对其他构件的运行产生负面影响。对于由构件组装而成的系统，其演化的工作往往由构件提供商完成。

1．3．4实施CBSE的两个基本问题
将传统软件系统转换为面向构件的软件系统涉及两个问题：
(1)在转变构件之前，应该明确服装销售管理软件体系结构是否应该变化。这个问题的答案不是很简单的。它依赖于用户系统资源的拓扑安排。如果系统具有稳定的软件体系结构，选择这样的系统来转化将取得较好的效果。如果系统是不稳固的并且是动态变化的，那么在转化为构件之前需要改变它的体系结构。
(2)转化的次序。首先，依据子系统的独立性，将逻辑上相关联的子系统标识为一个待转化构件。然后转化这个子系统为构件，直到子系统能够完全转化为构件为止。通常在转化期间系统需要维护传统系统的一些基本属性，如消息传递路径等。当然也有一些领域的系统不能完全转化为面向构件的软件系统。例如，一个嵌入式系统的引导代码等。

1．3．5几种流行的构件技术
为了便利构件相互之间的集成和装配，必须有一个统一的标准。经过几年的发展，产业界和科学界已经提出了多种构件的模型及规范，形成了一些较有影响的构件技术。其中较有代表性的有：微软公司的C()M／OLE，对象管理组织(ObjectManagementGroup，OMG)的跨平台的开放标准CORBA等。这些技术的流行为构件提供了实现标准，也为构件的集成和组装提供了很好的技术支持。

1．COM(ComponentObjeetModel)技术
COM是Microsoft开发的一种构件对象模型，它提供了在单个应用中使用不同厂商生产的对象的规约。对象链接与嵌入(ObjectLinkingandEmbedding，OLE)是COM的一部分，由于OLE已成为微软操作系统的一部分，因此目前应用最为广泛。最早的组件连接技术OLE1．0是Microsoft公司于1990年11月在C()MDEX展览会上推出的，它给出了软件构件的接口标准。任何人都可以按此标准独立地开发组件和增值组件(指在组件上添加一些功能构成的新组件)，或使用若干组件组装集成软件。在这种软件开发方法中，应用系统的开发人员可在组件市场上购买所需的大部分组件，因而可以把主要精力放在应用系统本身的研究上。

2．CORBA(CommonObjectRequestBrokerArchitecture)技术
CORBA是由OMG于1991年发布的一种基于分布对象技术的公共对象请求代理体系结构。其目的是在分布式环境下，建立一个基于对象技术的体系结构和一组规范，实现应用的集成，使基于对象的构件在分布异构环境中可以复用、移植和互操作。CORBA是一种集成技术，而不是编程技术。它提供了对各种功能模块进行构件化处理，并将它们捆绑在一起的黏合剂。一个对象请求代理提供一系列服务，它们使可复用构件能够和其他构件通信，而不管它们在系统中的位置。当用CORBA标准建立构件时，这些构件在某一系统内的集成就可以得到保证。加上基于CORBA规范的应用屏蔽了平台语言和厂商的信息，使得对象在异构环境中也能透明地通信。对于CORBA定义的通用对象服务和公共设施，用户还可以结合其特殊需求来构造应用对象服务，以提供企业应用级的中间件服务系统。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com