搜索
7.1软件的定义及特点软件（Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program），数据（Data）及其相关文档（Document）的完整集合。三个特点：（1）软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；（2）软件的生产与硬件不同，在它的开发过程中没有明显的制造过程；（3）在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。7.2软件危机及其表现软件危机（softwardcrisis）是指在计算机软件的开发和维护中所遇到的一系列严重问题。这些问题绝不仅仅是“不能正常运行的”软件才具有，实际上几乎所有软件都不同程度地存在这些问题。具体地说，软件危机主要有下述一些表现。（1）对软件开发成本和进度的估计常常很不准确。（2）用户对“已完成的”软件系统不满意的现象经常发生。（3）软件产品的质量往往靠不住。（4）软件常常是不可维护的。（5）软件通常没有适当的文档资料。（6）软件成本在计算机系统总成本中所占的比例逐年上升。7.3软件工程及三要素软件工程：软件工程是采用工程的概念、原理、技术和方法来指导软件开发和维护的工程学科，以工程化的原理和方法来解决软件问题。软件工程的特性：（1）软件工程关注于大型程序的构造（2）软件工程的中心课题是控制复杂性（3）软件经常变化（4）开发软件的效率非常重要（5）和谐地合作是开发软件的关键（6）软件必须有效地支持它的用户（7）在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人软件工程方法学包含3个要素：方法、工具和过程。7.4软件生命周期软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。每个阶段的任务如下问题定义阶段：该阶段的关键任务是要明确：要解决的问题是什么？可性行研究阶段：该阶段的关键任务是要明确：做不做？需求分析阶段：该阶段的关键任务是要明确：做什么？概要设计(总体设计)阶段：该阶段的关键任务是要明确：怎么做？详细设计阶段：该阶段的关键任务是要明确：具体做法。编码和单元测试阶段：该阶段的关键任务是：编码和单元测试。综合测试阶段：该阶段的关键任务是通过各种类型的测试（及调试）使软件达到预定的要求。软件维护阶段：该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的要求。7.4.1瀑布模型瀑布模型有以下优点1）为项目提供了按阶段划分的检查点。2）当前一阶段完成后，您只需要去关注后续阶段。3）可在迭代模型中应用瀑布模型。4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。瀑布模型有以下缺点1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。4）瀑布模型的突出缺点是不适应用户需求的变化。“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行，用户常常难以清楚地给出所有需求，用户必须有耐心，等到系统开发完成。7.4.2原型模型—快速原型模型在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。优点：（1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。（2）缩短了开发周期，加快了工程进度。（3）降低成本。尽早发现需求，揭示风险缺点：⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。⑶开发过程不便于管理。7.4.3螺旋模型螺旋模型的优点：（1）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标（2）减少了过多测试或测试不足（3）维护和开发之间并没有本质区别螺旋模型的缺点：（1）风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大（2）主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险（3）随着迭代次数的增加，工作量加大，软件开发成本增加7.4.4增量模型增量模型优点：（1）在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。（2）整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。（3）逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。（4）采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。增量模型的缺点：（1）在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。（2）开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。（3）多个构件并行开发，具有无法集成的风险。7.4.5喷泉模型主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征。喷泉模型的优点喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。喷泉模型的缺点由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。其特点如下：（1）开发过程有分析、系统设计、软件设计和实现4个阶段。（2）各阶段相互重叠，它反映了软件过程并行性的特点。（3）以分析为基础，资源消耗成塔型。（4）反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。（5）强调增量开发，整个过程是一个迭代的逐步提炼的过程。7.4.6构件组装模型构件组装模型导致软件复用，而可复用性给软件工程师提供了大量的可见的益处。软件开发不用一切从零开始，开发过程就是一个组装构件的过程，维护的过程就是对构件升级、替换和扩充的过程，大大提高了软件的开发效率。构件模型允许多个项目同时开发，降低了费用，提高了可维护性。构件模型也存在一些缺点，如：由于存在多种构件标准，缺乏通用的构件组装结构标准，如果自行定义会引入较大的风险；构件可重用性和软件系统高效性之间不易协调；如果过分依赖构件，构件质量会影响最终的产品质量。7.4.7RUPRUP是由Rational公司的Booch、Jacobson、Rumbaugh提出的软件过程模型，也称RUP（RationalUnifiedProcess)。RUP重复一系列周期，每个周期由一个交付给用户的产品结束。每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、设计、实现、测试）分别迭代。模型见下图：1.4个阶段初始阶段：进行问题定义，确定目标，评估其可行性，降低关键风险。细化阶段：制定项目计划、配置各类资源、建立系统架构（包括各类视图）。构造阶段：开发整个产品，并确保产品可移交给用户。移交阶段：产品发布、安装、用户培训。在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。2.9个工作流RUP中有9个核心工作流，分为6个核心过程工作流（CoreProcessWorkflows）和3个核心支持工作流（CoreSupportingWorkflows）。商业建模：深入了解使用目标系统的机构及其商业运作，评估目标系统对使用它的机构的影响。需求：捕获客户的需求，并且使开发人员和用户达成对需求描述的共识。分析和设计：把需求分析的结果转化成分析模型与设计模型。实现：把设计模型转换成实现成果。测试：检查个子系统的交互与集成，验证所有需求是否都被正确地实现了，识别，确认缺陷并确保在软件部署之前消除缺陷。部署：成功地生成目标系统的可运行版本，并把软件移交给最终用户。配置和变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。软件项目管理：提供项目管理框架，为软件开发项目制定计划，人员配备，执行和监控等方面的实用准则，并为风险管理提供框架。环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持。7.5UMLUML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。UML由以下5类图来定义：第1类：用例图第2类：静态图（包括类图、对象图和包图）第3类：行为图（包括状态图和活动图）第4类：交互图（包括时序图和协作图）第5类：实现图（包括组件图和配置图）第一类是用例图：从用户角度描述系统功能，并指出各功能的操作者。第二类是静态图：包括类图，对象图，包图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等也包括类的内部结构（类的属性和动作）。第三类是行为图：描述系统的动态模型和组成对象之间的交互关系，其中状态图描述类的对象所有可能的状态，以及事件发生时的状态的转移条件，通常，状态图为类图的补充，在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且状态发生改变的类画状态图，活动图描述满足用例要求所要进行的活动以及活动的约束关系，有利于识别并行的活动。第四类是交互图：描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系，他强调对象之间消息发送的顺序。第五类是实现图：其中构建图描述代码部件的物理结构和各部件之间的依赖关系，一个部件可能是一个资源代码部件，一个二进制部件或者一个可执行部件。它包含逻辑类和实际类的有关信息。部件图有利于分析和理解部件间的相互影响程度。下面分别描述9个图。7.5.1类图类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。7.5.2对象图对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。7.5.3用例图用例图展现了一组用例、参与者以及它们间的关系。可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图的是相当重要的。用例(usecase)：从用户的观点对系统行为的一个描述。用来从用户的观察角度收集系统需求。用例图表达系统的外部事物（参与者）与系统的交互，它表达了系统的功能，即系统所提供的服务。整个软件项目