软件工程知识点总结.docx

7.1软件的定义及特点软件（ Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program） ，数据（Data）及其相关文档（ Document）的完整集合。三个特点：（1）软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；（2）软件的生产与硬件不同，在它的开发过程中没有明显的制造过程；（3）在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。7.2软件危机及其表现软件危机（softward crisis）是指在计算机软件的开发和维护中所遇到的一系列严重问题。这些问题绝不仅仅是“不能正常运行的”软件才具有，实际上几乎所有软件都不同程度地存在这些问题。具体地说，软件危机主要有下述一些表现。 （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.7 RUPRUP是由Rational公司的Booch、Jacobson、Rumbaugh提出的软件过程模型，也称RUP（Rational Unified Process)。RUP重复一系列周期，每个周期由一个交付给用户的产品结束。每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、设计、实现、测试）分别迭代。 模型见下图： 1.4个阶段初始阶段：进行问题定义，确定目标，评估其可行性，降低关键风险。细化阶段：制定项目计划、配置各类资源、建立系统架构（包括各类视图）。构造阶段：开发整个产品，并确保产品可移交给用户。移交阶段：产品发布、安装、用户培训。在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。2.9个工作流RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。商业建模：深入了解使用目标系统的机构及其商业运作，评估目标系统对使用它的机构的影响。需求：捕获客户的需求，并且使开发人员和用户达成对需求描述的共识。分析和设计：把需求分析的结果转化成分析模型与设计模型。实现：把设计模型转换成实现成果。测试：检查个子系统的交互与集成，验证所有需求是否都被正确地实现了，识别，确认缺陷并确保在软件部署之前消除缺陷。部署：成功地生成目标系统的可运行版本，并把软件移交给最终用户。配置和变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。软件项目管理：提供项目管理框架，为软件开发项目制定计划，人员配备，执行和监控等方面的实用准则，并为风险管理提供框架。环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持。7.5 UMLUML适用于各种软件开发方法、软件生命周期的各个阶段 、各种应用领域以及各种开发工具。UML由以下5类图来定义： 第1类：用例图 第2类：静态图（包括类图、对象图和包图） 第3类：行为图（包括状态图和活动图） 第4类：交互图（包括时序图和协作图） 第5类：实现图（包括组件图和配置图）第一类是用例图：从用户角度描述系统功能，并指出各功能的操作者。第二类是静态图：包括类图，对象图，包图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等也包括类的内部结构（类的属性和动作）。第三类是行为图：描述系统的动态模型和组成对象之间的交互关系，其中状态图描述类的对象所有可能的状态，以及事件发生时的状态的转移条件，通常，状态图为类图的补充，在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且状态发生改变的类画状态图，活动图描述满足用例要求所要进行的活动以及活动的约束关系，有利于识别并行的活动。第四类是交互图：描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系，他强调对象之间消息发送的顺序。第五类是实现图：其中构建图描述代码部件的物理结构和各部件之间的依赖关系，一个部件可能是一个资源代码部件，一个二进制部件或者一个可执行部件。它包含逻辑类和实际类的有关信息。部件图有利于分析和理解部件间的相互影响程度。 下面分别描述9个图。 7.5.1 类图类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。7.5.2对象图对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。7.5.3用例图用例图展现了一组用例、参与者以及它们间的关系。可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图的是相当重要的。用例(use case)：从用户的观点对系统行为的一个描述。用来从用户的观察角度收集系统需求。用例图表达系统的外部事物（参与者）与系统的交互，它表达了系统的功能，即系统所提供的服务。整个软件项目的开发可以采用Use Case 驱动的方式进行。7.5.4交互图交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用例的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。顺序图和协作图都是交互图，它们既是等价的，又是有区别的。顺序图和协作图都能等价的表现系统运行中对象通过消息发生的交互行为。顺序图表示了时间的消息序列，便于分析交互的时序，但没有表示静态对象关系，顺序图可以有效地帮助人们观察系统的顺序行为。协作图着重表示一个协作中的对象之间的联系和消息。7.5.5顺序图展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。7.5.6协作图展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。协作图显示某组对象为了由一个用例描述的一个系统事件而与另一组对象进行协作的交互图。协作图只对相互间有交互作用的对象和这些对象间的关系建模，而忽略了其他对象和关联。协作图中包括如下元素：1.对象（Object）、2.链（Link）和3.消息（Message）。协作图的用途：如果按组织对控制流建模，应该选择使用协作图。协作图强调交互中实例间的结构关系以及所传送的消息。协作图对复杂的迭代和分支的可视化以及对多并发控制流的可视化要比时序图好。协作图有别于时序图的两点特性： （1）协作图有路径 （2）协作图有顺序号7.5.7状态图展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生命周期。在任一给定的时刻，一个对象总是处于某一特定的状态。状态图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。7.5.8活动图活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序（多为并行的）以及工作流（完成工作所需要的步骤）。它对于系统的功能建模特别重要，强调对象间的控制流程。活动图实质上是一种流程图，只不过表现的是从一个活动到另一个活动的控制流。活动图描述活动的序列，并且支持对带条件的行为和并发行为表达。7.5.9时序图在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。顺序图表达的正是这种基于时间的动态交互。重点是完成某个行为的对象类和这些对象类之间所传递的消息的时间顺序。 7.5.10构件图构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。组件图代表系统的一个物理实现块，代表逻辑模型元素如类、接口的物理打包。7.5.11部署图部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统7.5.12区别1.以描述系统状态转移为主的状态图和活动图状态图：用来描述对象，子系统，系统的生命周期。通过状态图可以了解一个对象所能达到的所有状态，以及对象收到的事件对对象状态的影响。活动图：显示动作及其结果。着重描述操作（方法）实现中所完成的工作以及用例实例或对象中的活动，它是状态图的一个变种。状态图与活动图的区别：活动图主要描述动作及对象状态改变的结果。状态图主要描述的是事件对对象状态的影响。2.以描述系统系统对象通讯和交互为主的协作图和序列图序列图：描述对象是如何交互的。重点放在消息序列上，描述消息在对象间是如何收发的。协作图：描述协作对象的交互与链接。协作图和序列图的区别：协作图和序列图都是描述对象交互的，但是序列图强调的是时间，协作图强调的空间。7.6需求分析与用例建模7.6.1需求分析的任务需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。- 准确地回答“系统必须做什么?”。需求分析的步骤：需求获取分析建模 文档编写 需求验证7.6.2类图类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。类图技术是OO方法的核心。类图标加上它们之间的关系就构成了类图。类图用于对系统静态设计视图建模。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图中可以包含接口，包，关系等建模元素，也可以包含对象，链等实例。类图典型的应用在下面三类建模：（1）对系统的词汇建模（2）对简单协作建模（3）对逻辑数据库模式建模类图通常包含下述内容：类、接口、协作、依赖、泛化和关联关系。关系（Relationship）是事物间的关系。在类的关系中，最常用的4种分别为：依赖（Dependency）：它表示类之间的使用关系泛化（Generalization）：它表示类之间的一般和特殊的关系；关联（Association）：它表示对象之间的结构关系实现（Realization） ：它是规格说明和其实现之间的关系。类主要包含以下几个部分 （1）名称（Name）名称是每个类所必有的构成，用于和其他类相区分。 （2）属性（Attribute）类的一个组成部分描述了类所代表事物的属性 （3）操作（Operation）操作是对类的对象所能做的事务的抽象类在UML中由专门的图符表达，是分成3个分隔区的矩形,顶端为类的名字，中间存放类的属性、属性的类型和值，第3个分隔区放操作、操作的参数表和返回类型，如下图： 7.6.3用例图在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。让用户参与前期的系统分析与设计。用例图的组成：用例（Use Case）参与者（Actor）关系(Relationship)1.什么是参与者参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者可能是人、另外一个系统、时间的流逝等。UML中，参与者用“人形”图标来表示，名字写在图标的下方。 2.什么是用例用例（use case）一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能） 。参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。 3. 用例间、用例与参与者的关系（1）泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化：（2）包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。（3）扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。（4）关联关系：关联关系表示参与者与用例之间的通信。 4. 用例间的关系（1） 泛化关系 当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。 用例可以被特别列举为一个或多个子用例，这被称做用例泛化。（2） 包含关系包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例多个用例的公共用例。（3）扩展关系将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。扩展用例的行为是否被执行要取决于主事件流中的判定点。扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；b.表明只在特定条件（如例外条件）下才执行的分支流；5. 用例之间的关系包含用例与扩展用例的区别相对于基础用例，扩展用例是可选的，而包含用例则不是。如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。扩展用例的执行需要满足某种条件，而包含用例不需要。扩展用例的执行会改变基础用例的行为，而包含用例不会。6.识别用例的方法：参与者希望系统提供什么功能；系统是否存储和检索信息；如果是，这个行为由哪个参与者触发；当系统改变状态时，是否通知参与者；是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。 7.6.4活动图1.什么是活动图活动图是UML中描述系统动态行为的图之一，是描述系统或业务的一序列活动构成的控制流，它描述了系统从一种活动转换到另一种活动的整个过程。2. 活动图用途活动图用于对系统的动态行为建模。活动图常用来描述业务或软件系统的活动轨迹，描述了系统的活动控制流程。我们常用活动图对业务过程、工作流和用例实现进行建模。活动图主要应用对两个方面建模：一是在业务分析阶段，对工作流程进行建模；二是在系统分析和设计阶段，对操作流程进行建模。 7.6.5面向对象分析建立的3类模型对象模型、动态模型、功能模型对象模型 对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。该模型主要关心系统中对象的结构、属性和操作，它是分析阶段三个模型的核心，是其他两个模型的框架。2 对象和类对象。对象建模的目的就是描述对象。 类。通过将对象抽象成类，我们可以使问题抽象化，抽象增强了模型的归纳能力。 属性。属性指的是类中对象所具有的性质（数据值）。 操作和方法。操作是类中对象所使用的一种功能或变换。类中的各对象可以共享操作，每个操作都有一个目标对象作为其隐含参数。方法是类的操作的实现步骤。关联和链关联是建立类之间关系的一种手段，而链则是建立对象之间关系的一种手段。 关联和链的含义。链表示对象间的物理与概念联结，关联表示类之间的一种关系，链是关联的实例，关联是链的抽象。 角色。角色说明类在关联中的作用，它位于关联的端点。 受限关联。受限关联由两个类及一个限定词组成，限定词是一种特定的属性，用来有效的减少关联的重数，限定词在关联的终端对象集中说明。限定提高了语义的精确性，增强了查询能力，在现实世界中，常常出现限定词。 关联的多重性。关联的多重性是指类中有多少个对象与关联的类的一个对象相关。重数常描述为“一”或“多”。 类的层次结构 聚集关系。聚集是一种“整体部分”关系。在这种关系中，有整体类和部分类之分。聚集最重要的性质是传递性，也具有逆对称性。聚集可以有不同层次，可以把不同分类聚集起来得到一颗简单的聚集树，聚集树是一种简单表示，比画很多线来将部分类联系起来简单得多，对象模型应该容易地反映各级层次。一般化关系。一般化关系是在保留对象差异的同时共享对象相似性的一种高度抽象方式。它是“一般-具体”的关系。一般化类称为你类，具体类又能称为子类，各子类继承了父类的性质，而各子类的一些共同性质和操作又归纳到你类中。因此，一般化关系和继承是同时存在的。一般化关系的符号表示是在类关联的连线上加一个小三角形。对象模型模板。模板是类、关联、一般化结构的逻辑组成。对象模型。对象模型是由一个或若干个模板组成。模板将模型分为若干个便于管理的子块，在整个对象模型和类及关联的构造块之间，模板提供了一种集成的中间单元，模板中的类名及关联名是唯一的动态模型 动态模型是与时间和变化有关的系统性质。该模型描述了系统的控制结构，它表示了瞬间的、行为化的系统控制 性质，它关心的是系统的控制，操作的执行顺序，它表示从对象的事件和状态的角度出发，表现了对象的相互行为。 该模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。使用状态图作为描述工具。它涉及到事件、状态、操作等重要概念。 事件事件是指定时刻发生的某件事。 状态状态是对象属性值的抽象。对象的属性值按照影响对象显著行为的性质将其归并到一个状态中去。状态指明了对象对输入事件的响应。 状态图状态图是一个标准的计算机概念，他是有限自动机的图形表示，这里把状态图作为建立动态模型的图形工具。 状态图反映了状态与事件的关系。当接收一事件时，下一状态就取决于当前状态和所接收的该事件，由该事件引起的状态变化称为转换。 状态图是一种图，用结点表示状态，结点用圆圈表示；圆圈内有状态名，用箭头连线表示状态的转换，上面标记事件名，箭头方向表示转换的方向。 功能模型 功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。功能模型表明一个计算如何从输入值得到输出值，它不考虑计算的次序。功能模型由多张数据流图组成。数据流图用来表示从源对象到目标对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表示，同时数据流图也不表示对象中值的组织，值的组织在对象模型中表示。 数据流图中包含有处理、数据流、动作对象和数据存储对象。处理数据流图中的处理用来改变数据值。最低层处理是纯粹的函数，一张完整的数据流图是一个高层处理。 数据流数据流图中的数据流将对象的输出与处理、处理与对象的输入、处理与处理联系起来。在一个计算机中，用数据流来表示一中间数据值，数据流不能改变数据值。 动作对象动作对象是一种主动对象，它通过生成或者使用数据值来驱动数据流图。 数据存储对象数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不一样，数据存储本身不产生任何操作，它只响应存储和访问的要求。7.7设计阶段7.7.1详细设计详细设计阶段的根本目标是确定怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。详细设计的目标: 设计出的处理过程应该尽可能简明易懂。 详细设计的任务：(1) 为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述；(2) 确定每一模块使用的数据结构；为以后的编写程序做好充分的准备。(3) 确定模块接口的细节。7.7.2总体设计1. 面向对象设计面向对象设计的准则：优秀设计就是使得系统在其整个生命周期中的总开销最小的设计, 其主要特点就是容易维护。面向对象设计（OOD，Object-Oriented Design）是面向对象分析到实现的一个桥梁。面向对象分析是将用户需求经过分析后，建立问题域精确模型的过程；而面向对象设计则根据面向对象分析得到的需求模型，建立求解域模型的过程。即分析必须搞清楚系统“做什么”，而设计必须搞清楚系统“怎么做”，从分析到设计不是传统方法的转换，而是平滑（无缝）过渡，而求解域模型是系统实现的依据。静态结构设计：l 类设计l 包设计l 接口设计动态结构设计（行为和交互建模）：l 对象如何进行交互的2.GUI （图形用户界面）设计概述 对于用户来说，一个友好的界面是至关重要的。用户界面（User Interface）的设计质量直接影响用户对软件产品的评价，从而影响软件产品的竞争力和使用寿命，因此，对人机界面的设计必须给予足够的重视。良好的设计原则1、关注用户及其任务，而不是技术2、首先考虑功能，其次才是表现3、与用户对任务的看法保持一致4、设计要符合常见情况5、不要分散用户对他们目标的注意力6、促进学习，从外(用户)到里(设计人员)思考，而不是相反。7、传递信息，而不仅仅是数据8、设计应满足响应需求9、通过用户试用发现错误，然后修复它3. 数据库设计设计原则：每一个类成为一个数据库表。关系映射：（1）一对多的关系映射为数据库表的主外键关联（1方的主键加入n方成为外键）（2）一对一的关系映射为数据库表的主外键关联（1方的 主键加入另一方成为外键）（3）多对多的关系映射：产生第三张表，将两个多方的主键加入其中成为外键，两个外键的组合成为主键。利用数据库三范式检查表，从而考察领域类图的分析是否合理，消除冗余数据。检查数据是否能够反映用例视图的需要；进一步与用户再次确认使用的数据。7.8注释夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释决不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。注释分为两类：序言性注释和功能性注释。1. 序言性注释 通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。序言性注释包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其它有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。2. 功能性注释功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样，而不要解释下面怎么做。 要点： 描述一段程序，而不是每一个语句； 用缩进和空行，使程序与注释容易区别；7.9软件测试软件测试的定义：软件测试是使用人工和自动手段来运行或测试某个系统的过程，其目的在于检测被测试软件系统是否满足规定的需要，或是弄清楚被测系统的预期结果与实际结果之间的差别。黑盒测试：仅需要知道被测试对象的输入和预期输出，不需要了解代码实现的细节。测试方法主要分为两类：功能层面的测试方法和函数层面的测试方法（边界值测试、等价类测试、基于决策表测试）。 侧重于系统业务流程的梳理，是基于动态业务过程设计测试用例。白盒测试：是针对程序代码展开的测试，分为静态测试和动态测试 ：关注对象包括源代码和程序结构。静态白盒测试的方法是代码检查。静态测试不需要运行程序和设计测试用例，侧重于源代码的检查和优化，直接查看源代码和执行代码，直接定位代码中的缺陷。动态测试侧重于程序结构的测试。测试用例的定义：测试用例是一组测试输入，执行条件和预期结果。目的是要满足一个特定的目标。如果执行一条特定的程序路径或者检验是否符合一个特定的需求的用例。 测试用例：输入+输出+测试环境 测试环境包括：硬件环境，软件环境，网络环境，历史数据。测试用例分为两个阶段：测试用例分析阶段，测试用例设计阶段。7.9.1测试和调试的区别1、目的不同软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地 排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分。 2、任务不同 既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶 段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同 样。它是比较有规律的活动，有系统的方法、原则作指导。 而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。3、指导原则和方法不同 软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做 的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。 软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。4、操作者 因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.7.9.2软件维护软件维护活动类型总起来大概有四种：纠错性维护（校正性维护）、适应性维护、完善性维护或增强、预防性维护或再工程。改正性维护改正性维护是指改正在系统开发阶段已发生而 系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随 时进行：而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。适应性维护适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%25%。由于计算机硬件价 格的不断下降，各类 系统软件屡出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出 新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。完善性维护完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的 软件系统增加一些在 系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护 工作的50%60%，比重较大也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外还要注意将相关的文档资料加入到前面相 应的文档中去。预防性维护预防性维护为了改进 应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。这方面的维护工作量占整个维护工作量的4%左右。第一章1.软件有哪些种类？答：1.按功能特征进行划分：(1)系统软件(2)支撑软件(3)应用软件2.按规模大小进行划分微型、小型、大型、甚大型、极大型4.结合自己的亲身经历，谈谈软件工具在软件开发过程中的作用。使软件开发更加模式化，工程化，从而提高软件开发的效率和封装性。第二章2.软件瀑布模型为什么要划分阶段？各个阶段的任务是什么？在软件开发早期，开发只是被简单地分成编写代码和修改代码两个阶段。往往在拿到项目后立刻编写程序，然后调试通过后直接交付给用户使用。如果应用中出现错误，或者有新的要求，都需要重新修改代码。这种小作坊式的软件开发方法有明显的弊端，如缺乏统的项目规划、不太重视需求的获取和分析、对软件的测试和维护考虑不周等，这些都会导致软件项目的失败。概念阶段：计划、需求分析开发阶段：设计、编码、测试维护阶段：运行维护3.举例说明哪些项目的开发适用于原型模型或螺旋模型，哪些不适于采用这两种模型。螺旋模型适合于大型软件的开发，应该说它是最为实际的方法，它吸收了软件工程“演化”的概念，使得开发人员和客户对每个演化层出现的风险有所了解，继而做出应有的反应。不适用:小型软件。原型般是指对某种产品进行模拟的初始版本或者原始模型，在工程领域中具有广泛应用。不适用:大型软件项目；含有对于计算量大、逻辑性较强的程序模块：第三章1.可行性研究的任务是什么？可行性研究的任务是以最小的代价在尽可能短的时间内确定问题是否能够解决。简单的说，可行性研究的最终结果是决定项目y做还是小做”而不是“如何做”。2.项目开发计划有哪些内容？引言(目的、背景、参考文献、术语)；项目概述(功能、条件、运行环境、产品、程序、文档、服务、验收标准、实施计划、工作任务分解、进度、预算、人员)第四章1.什么是需求工程？需求工程包括哪些活动？需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的门学科。它通过合适的工具和记号系统地描述待开发系统，及其行为特征和相关约束，形成需求文档；并对用户不断变化的需求演进给予支持。一个良好的需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。2.需求工程过程包括哪些主要活动？需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。3. 有哪两种主要的需求分析模型？它们的主要思想是什么？答：面向对象分析模型，结构化分析模型。前者是采用面向对象的思想进行软件需求分析的建模过程，而后者模型的核心是DD，它是设计各种数据对象的总和。他们的模型分别起到了描述数据模型，功能模型与行为模型的作用。4.需求规格说明书的主要作用是什么？应该包括哪些主要内容？作用：(1)作为用户方和开发方之间的合同，为双方相互了解提供基础。(2)反映问题的结构，作为系统设计和编码的依据。(3)作为测试和验收目标系统的依据。内容：用户可以通过需求规格说明书检查需求描述是否满足原来的期望。设计人员根据软件需求规格说明书的描述了解所需开发软件的功能和性能，以及开发软件时必须满足的约束，将其作为软件设计的依据。测试人员根据软件需求规格说明书中对产品的描述，设计测试计划、测试用例和测试过程。产品发布人员根据软件需求规格说明和用户界面设计编写用户手册和帮助信息第五章2.简述数据流图分解时的注意事项。上层可分解得快些（即分解成子数据处理个数多些），这是因为上层是综合性描述，对可读性的影(即分解成的子数据处理个数多些)，这是因为上层是综合性描述，对可读性的影响小。而下层应分解得慢性。在不影响可读性的前提下，应适当多分解成几部分，以减少分解层数。3.数据字典的作用是什么？它有哪些基本内容？分解应自然，概念上要合理、清晰。作用：数据字典作为分析阶段的工具，有助于改进分析人员和用户.间的通信，进而消除很多的误解，同时也有助于改进不同开发人员之间的通信；.内容:数据字典的内容主要是对数据流图中的数据项、数据流、加工逻辑、数据存储和外部实体第六章1.什么是面向对象方法？与传统软件开发方法相比，面向对象方法有什么优点？是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法。优点：1.符合人们对问题的认识习惯2.增强问题域与最终软件系统之间的衔接3.易于维护和复用4.易于开发大型软件产品2.什么是模型？在软件开发过程中为什么需要建立模型？在软件开发过程中，建立软件模型具有十分重要的作用，主要体现在以下几个方面：有助于问题的简化，通过抽象降低复杂性；有助于和其他开发小组成员，各种用户以及系统相关者进行交流；有助于维护人员了解软件设计的思路和细节，为以后的维护和升级提供了文档。第七章1面向对象分析包括哪些活动？应该建立哪些类型的模型？面向对象分析OOA模型的过程包括理解用例模型、识别分析类、定义交互行为、建立分析类图、评审分析模型5个活动组成。目标是建立一个符合问题域、满足用户需求的OOA模型。2.什么是实体类、边界类和控制类？为什么将分析类划分成这3种类型？实体类：用于描述必须存储的信息，同时描述相关的行为。实体类代表拟建系统中的核心信息。在RUP的有关文档中对实体类的解释为：“实体类是用于对必须存储的信息和相关行为建模的类。边界类：在系统与外界之间，为它们交换各种信息与事件。边界类处理软件系统的输入和输出。在RUP的有关文档中对边界类的解释为：边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。控制类：与业务过程相关，它们控制整个业务的流程和执行次序。在RUP的有关文档中对控制类的解释为：控制类用于对一个或几个用例所持有的控制行为进行建模。控制类对象可以和边界对象交互，也可以和实体对象交互，但不能和用例的参与者直接进行交互。第八章1.什么是软件设计？它的目标和任务是什么？软件设计：在需求分析的基础上通过抽象和分解将系统分解成模块，确定系统功能的实现。即把软件需求转换为软件包表示的过程。目标：软件设计的最终目标是产生一个设计规约，该规约包括体系结构、描述数据、接口和构件的设计模型。软件设计的任务，就是把分析阶段产生的软件需求规格说明转换为用适当手段表示的软件设计文档。2.完成良好的软件设计应遵循哪些原则？模块化与模块独立性；抽象与逐步求精；信息隐藏。3.如何理解模块独立性？用什么指标来衡量模块独立性？模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。一般采用两个准则度量模块独立性，即模块的内聚性和模块间的耦合性4.说明软件设计阶段的任务和过程软件设计分两步完成，即总体设计与详细设计。第个阶段是总体设计，即概要设计或初步设计。这、阶段主要确定实现目标系统的总体思想和设计框架，确定程序由哪些模块组成，以及模块与模块之间的关系，最后提出概要设计说明书。第二个阶段是详细设计，即过程设计或构件级设计，其任务是通过对结构表示进行细化，确定各个软件构件的详细数据结构和算法，产生描述各个软件构件的详细设计文档。5.试说明软件体系结构在软件设计阶段中的重要性。良好的体系结构设计是决定软件系统成功的重要因素。软件体系结构设计的好坏往往会成为一个系统设计成败的关键。通常，软件体系结构涉及软件的总体组织、全局控制、数据存取及子系统之间的通信协议等。6.简述面向对象设计阶段要做的工作。OOD主要包括三个方面的工作：系统体系结构设计、用例实现方案设计和用户界面设计。第十一章1.简述程序设计语言的基本特征及分类。基本特征包括心理特性，工程特性和技术特性三个方面。语言的的心理特性对人机通信的质量有主要的影响；语言的工程特性对软件开发成功与否有重要的影响，此外语言的技术特性也会影响软件设计的质量按程序设计语言的历史发展过程，计算机语言可分为机器语言、汇编语言、高级程序设计语言。按与机器的依赖程度，可分为低级、中级和高级语言。按应用范围，可分为通用语言与专用语言两大类，通用语言义可细分为系统程序设计语言、科学计算语言、事务处理语言和实时控制语言等。按程序的设计方法，可分为命令性语言和作用性语言。按语言的成分，可以分成顺序语言、并行语言和实时语言等。按语言的组成方法，可以分成汇集式语言和可扩充语言。2.为了具有良好的程序设计风格，应该注意哪些方面的问题？要形成良好的程序设计风格，应从源程序文档化、数据说明、语句构造、输入输出和追求效率几个方面加以注意。3.什么是软件测试？软件I则试的原则有哪些？软件测试是按照特定的规则，发现缺陷而执行程序的过程。一个好的测试用例是指尽可能找到迄今为止尚未发现缺陷的用例。一个成功的测试是指揭示了迄今为止尚未发现缺陷的测试。软件测试的原则： (l)所有的测试都应该能追溯到用户需求。 (Z)应该在测试之前就制定出测试计划。 (3)Pareto原理可应用于软件测试。 (4)测试应从“小规模”开始，逐步转向“大规模” (S)穷举测试是不可能的。 (6)既要做通过性测试，又要做失效性测试。 (D为了达到最佳的测试效果，应该由独立的第三方从事测试工作。第十四章1.为什么说软件维护是不可避免的？因为软件的开发过程中，一般很难检测到所有的错误，其次软件在应用过程中需要随用户新的要求或运行环境的变化而进行软件的修改或纠正软件开发过程未发现的错误，增强、改进和完善软件的功能和性能，以适应软件的发展，延长软件的寿命，软件的维护是不可避免的。2.什么是软件再工程？软件再工程的主要活动有哪些？指在逆向工程所获信息的基础上修改重构已有的系统，产生的个新版本，或者说利用这些信息修改或重构软件系统的工作。它定义了6为活动r即库存目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程。 3.软件调试与软件测试有什么区别？1、目的不同软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务。调试的目的是为了证明程序的正确，因此它必须不断地挤除错误.它们的出发点不一样“前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是-种排除过程，是编码活动的部分2、任务不同既然软件测试属于质量保证活动，因此它贯穿十整个计发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件