第六章 详细设计
1.详细设计根本目标：确定如何具体实现所要求的系统。
任务： 不是具体编写程序，而是设计程序的“蓝图”。 详细设计的结果决定最终程序代码的质量 2.结构程序设计是一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出 口的控制结构。经典的结构程序设计：只允许使用顺序、IF_THEN_ELSE选择DO_WHILE 循环 。
3.设计人机界面过程中会遇到的4个问题：
1)系统响应时间
系统响应时间指从用户完成某个控制动作，到软件给出预期的响应之间的这段时间。 系统响应时间有两个重要属性：长度和易变性 2)用户帮助设施
大多数现代软件都提供联机帮助设施，用户无须离开用户界面就能解决自己的问题。 常见的帮助设施可分为集成的和附加的两类. 3)出错信息处理
出错信息和警告信息，是出现问题时交互式系统给出的“坏消息. 4)命令交互 多数情况下，用户既可以从菜单中选择软件功能，也可以通过键盘命令序列调用软件 功能。 4.设计过程
初步设计建立原型#1的界面建立原型#n的界面需要进行的设计修改设计者研究界面设计完成评估结果界面设计评估周期
用户评估界面
5.过程设计的工具:
1) 程序流程图：是一种描述程序的控制结构流程和指令执行情况的有向图。 缺点：程序流程图的缺点： (1)程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的 控制流程，而不去考虑程序的全局结构。
(2)程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾 结构程序设计的精神，随意转移控制。 (3)程序流程图不易表示数据结构。 2)盒图
特点：
(1)功能域明确，可以从盒图上一眼就看出来； (2)不可能任意转移控制；
(3)很容易确定局部和全程数据的作用域；
(4)很容易表现嵌套关系，也可以表示模块层次结构 3)PAD图
它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易 特点：
(1)使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序； (2)PAD图所描绘的程序结构十分清晰；
(3)用PAD图表现程序，通俗易懂，程序从图中最左竖线上端的结点开始执行，自 上而下，从左向右顺序执行，遍历所有结点；
(4)容易将PAD图转换成高级语言源程序，这种转换可以用软件工具自动完成； (5)可用于表示程序逻辑，也可用于描绘数据结构； (6)PAD图的符号支持自顶向下、逐步求精的方法。 4)判定表
当算法中包含多重嵌套的条件选择时，用程序流程图、盒图、PAD图或后面即将介 绍的过程设计语言(PDL)都不易清楚地描述判定表却能够清晰地表示复杂的条件组 合与应做的动作之间的对应关系。 一个 判定表由四部分组成： --左上部列出所有条件
--左下部是所有可能做的动作 --右上部表示各种条件组合
--右下部是和每种条件组合相对应的动作 5)判定树
判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关 系。
6)过程设计语言（PDL）
过程设计语言(PDL)也称为伪码，它是用正文形式表示数据和处理过程的设计工具。 PDL的优点：
(1)可以作为注释直接插在源程序中间；
(2)可以使用普通的正文编辑程序或文字处理系统来完成PDL的书写和编辑工作； (3)现在已经有一些自动处理程序可以自动地把PDL生成程序代码。 PDL的缺点：不如图形工具形象直观.
6.面向数据流的设计方法是根据数据流确定软件结构；面向数据结构的设计方法是根据数据 结构设计程序处理过程，对程序处理过程进行描述。通常面向数据结构的设计方法的设计步 骤如下：
(1) 画出系统中输入、输出数据对应的数据结构图。 (2) 根据数据结构图，映射得到相应的程序结构图。 (3) 按照程序结构图，分析得到程序的详细过程性描述。
7.在面向数据结构的设计方法中，最典型的代表是Jackson方法和Warnier方法
JACKSON方法的特点： 优点：
1、适合于层次结构表达； 2、形象直观、可读性强；
3、同时表示数据结构和程序结构。 缺点：
不能直接在图上表示选择条件和循环结束条件。影响了图的表达能力，也不易直 接把图翻译成程序，此外，框间连线为斜线，不易在行式打印机上输出。为了解 决上述问题，本书建议使用图6.11中给出的改进的Jackson图。 Jackson结构程序设计方法由五个步骤组成： 1）分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构； 2）找出输入数据结构和输出数据结构中有对应关系的数据单元；
3）用三条规则从描绘数据结构的Jackson图导出描绘程序结构的Jackson图
A．为每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构 图的相应层次画一个处理框；
B．根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应 层次分别为它们画上对应的处理框；
C．根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应 层次分别为它们画上对应的处理框；
4）列出所有操作和条件（包括分支条件和循环结束条件），并且把它们分配到程序结
构图的适当位置； 5）用伪码表示程序。
8. 程序复杂度定量度量方法是评介详细设计阶段模块质量的一种比较成熟的方法。 计算环形复杂度的方法
(1)环形复杂度 V（G）＝流图中的区域数； (2)环形复杂度 V（G）＝E－N+2，
其中：E是流图中边的条数，N是结点数； (3)环形复杂度 V（G）＝P＋1，
其中：P为流图中判定结点的数目。
环形复杂度的用途;：对测试难度的一种定量度量，也能对软件最终的可靠性给出某种预 测。
第7章 实 现
1.通常把编码和测试统称为实现。
编码：把软件设计结果翻译成用某种程序设计语言书写的程序，是对设计的进一步 具体化。
测试：检测程序并改正错误的过程。
测试的目的：在软件投入运行之前，尽可能发现软件中的错误，并改正错误。 2. 选择一种编程语言的理论标准： 1）有理想的模块化机制；
2）可读性好的控制结构和数据结构； 3）便于调试和提高软件可靠性； 4）编译程序发现程序错误的能力强； 5）有良好的独立编译机制。
3.编码风格是指编程遵循的基本原则。良好的编码风格有利于弥补语言的缺陷，编写出高质量的软件。包括程序内部的文档、数据说明、语句构造、输入/输出、效率等方面的问题。 4.程序的效率是指程序的执行速度及程序所需占用的内存的存储空间。即程序的时空复杂度。效率问题涉及3方面： （1）程序运行时间 （2）存储器效率 （3）输入输出效率
5.测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。测试决不能证明软件是正确的，也不能证明错误的不存在，它只能证明错误的存在 6.软件测试准则：
1）所有测试都应该能追溯到用户需求；
软件中的问题根源可能在开发前期的各阶段解决、纠正错误也必须追 溯到前期工作。 2）应该远在测试前就制定出测试计划； 完成需求模型既可以着手制定测试计划，建立了设计模型之后就可以立即开始设计详
细的测试方案。因此，在编码之前就可以对所有测试工作进行计划和设计。 3） 把Pareto原理应用到软件测试中
Pareto（帕雷特：意大利经济学家）原则：也称为80/20法则，即：在众多现象中， 80%的结果取决于20%的原因。
4）从“小规模”测试逐步进行“大规模”测试；
通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错 误，最后在整个系统中寻找错误。 5）穷举测试是不可能的；
穷尽测试：包含所有可能情况的测试称为穷尽测试。
6）为了达到最佳测试效果，应该由独立的第三方从事测试工作。 7.测 试 方 法包括：静态测试和动态测试
静态测试：基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。静 态测试约可找出30～70%的逻辑设计错误。
动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。包括黑盒测试和白盒测试。动态测试的两个基本要素： 被测试程序
测试数据（测试用例） 动态测试方法：
(1) 选取定义域有效值,或定义域外无效值； (2) 对已选取值决定预期的结果； (3) 用选取值执行程序；
(4) 执行结果与预期的结果相比不吻合，则程序有错 8.如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的 规定正常进称为白盒测试。
如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用 称为黑盒测试。
9.白盒测试的内容：对程序模块的所有独立执行路径至少测试一次、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测试一次、在循环的边界和运行边界内执行循环体 、 测试内部数据结构的有效性。
黑盒测试的内容：Alpha/Beta Testing、菜单/帮助测试、发行测试、回归测试。
黑盒测试 白盒测试 优点 ①适用于各阶段测试 ①可构成测试数据使特定程 序部分得到测试 ②从产品功能角度测试 ②有一定的充分性度量手段 ③容易入手生成测试数据 ③可获较多工具支持
缺点 ①某些代码得不到测试 ①通常不易生成测试数据
②如果规格说明有误，则无法发现 ②无法对未实现规格说明的部分进行测试
③不易进行充分性测试 ③工作量大，通常只用于单元测试，有应用局限 10软件测试的步骤 1).模块测试
模块测试又称单元测试，它把每个模块作为单独的实体来测试。 2).子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试. 3)系统测试
系统测试是把经过测试的子系统装配成一个完整的系统来测试。 4).验收测试
验收测试把软件系统作为单一的实体进行测试（利用用户的实际数据测试）。 5)平行运行
平行运行是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个 系统的处理结果。
11.单元测试通过编译系统检查并改正程序中所有的语法错误。然后用详细设计模块说明为 指南，对重要的控制路径进行测试，以便发现模块内部的错误。
测试重点： 1).模块接口
主要检查下述几个方面：参数的数目、次序、属性或单位系统与变元是否一致；是 否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。 2). 局部数据结构
局部数据说明、初始化、默认值等方面的错误。 3). 重要的执行通路 选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设 计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的 错误.
4). 出错处理通路着重测试下述一些可能发生的错误： (1) 对错误的描述是难以理解的； (2) 记下错误与实际遇到的错误不同；
(3) 在对错误进行处理之前，错误条件已经引起系统干预； (4) 对错误的处理不正确；
(5) 描述错误的信息不足以帮助确定造成错误的位置。 5. 边界条件
边界测试是单元测试中最后的也可能是最重要的任务，软件常常在它的边界上 失效。 12.计算机测试
必须为每个单元测试开发驱动程序和(或)存根程序。
驱动程序是一个“主程序”，它接收测试数据，传送给被测试的模块，并打印出有关的结
果。（自底向上的集成测试）
存根程序（虚拟子程序或做桩程序）代替被测试的模块所调用的模块。它使用被它代替 的模块的接口，可能做最少量的数据操作，打印出对入口的检验或操作结果，并且把控 制归还给调用它的模块。（自顶向下的集成测试）
13.集成测试是组装软件的系统化技术，它将经过单元测试的模块联系在一起进行测试。由 模块组装成程序时有两种方法： 1）非渐增式测试方法
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。 2）渐增式测试方法
每次增加一个待测试模块，把它同已经测试好的那些模块结合起来进行测试，反复进行。
直到完成所有模块测试的方法
14.自顶向下集成是一种递增的装配软件结构的方法，这种方法应用非常广泛。它需要存根 程序，但是不需要驱动程序。包括： 1）深度优先策略
先组装软件结构的一条主控制通路上的所有模块，选择哪条主控制通路，具有较大的任 意性。
2）宽度优先策略
沿着软件结构水平地移动，把处于同一个层次的所有模块组装起来。 15.自顶向下集成方法的基本过程如下：
1）对主控模块进行测试，测试时用存根程序代替所有直接被主控模块调用的模块； 2）根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块代替一个存根 程序（新结合的模块往往又需要新的存根程序）； 3）每结合一个模块，就测试一个； 4）为保证不引入新的错误，需要进行回归测试，即重复以前进行过的部分或全部测试； 5）重复回到第二步，直到构成整个软件结构。
16.自底向上集成方法的基本过程如下：
1）把底层模块组合成实现一个特定软件子功能的族
2）为每个模块设计一个驱动程序，作为测试的控制程序，以协调测试用例的输入和输 出。
3）对模块进行测试；
4）用实际模块代替驱动程序组装成新的模块族，在新加入的实际模块上面加上新的驱 动程序进行测试；
5）重复第二到第四步，逐渐向上加入实际模块，直至构造出整个软件结构。
17.回归测试是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的 副作用。回归测试集（已执行过的测试用例的子集）包括下述3类不同的测试用例： （1） 检测软件全部功能的代表性测试用例；
（2） 专门针对可能受修改影响的软件功能的附加测试； （3） 针对被修改过的软件成分的测试。
18.确认测试也称为验收测试，它的目标是验证软件的有效性。确认测试的范围：
确认测试必须有用户积极参与，或者以用户为主进行。用户应该参与设计测试方案，使 用用户界面输入测试数据并且分析评价测试的输出结果。
确认测试通常使用黑盒测试法。应该仔细设计测试计划和测试过程，测试计划包括要进 行的测试的种类及进度安排，测试过程规定了用来检测软件是否与需求一致的测试方案。 通过测试和调试要保证软件能满足所有功能要求，能达到每个性能要求，文档资料是准确 而完整的，此外，还应该保证软件能满足其他预定的要求。
19.Alpha测试：用户在开发者的场所进行测试，并且在开发者的指导下进行，测试在受控环 境中进行，开发者记录发现的错误和问题；
Beta测试：用户在一个或多个客户场所进行测试，不受开发者控制，测试者记录发现的 问题和错误，定期将问题报告发送给开发者。 20逻辑覆盖测试的5种标准：
1).语句覆盖——设计的测试用例能使程序中每条语句至少执行一次
2).判定覆盖——选取足够的测试用例，使得程序中每个判断的可能结果都至少执行一 次，也就是说使程序的每个判断分支至少通过一次。
3) 条件覆盖——选择足够的测试用例，使得程序中每个判定表达式的每个条件都取到 各种可能的结果.
4)判定/条件覆盖 ——判定/条件覆盖是指：选取足够的测试用例使得同时满足判定覆盖 和条件覆盖的要求。
6).点覆盖——点覆盖是指：选取足够多的测试用例，使得程序执行路径至少经过程序 图中每个节点一次。
7)边覆盖——边覆盖是指：选取足够多的测试用例，使得程序执行路径至少经过程序 图中每条边一次。
8)路径覆盖——路径覆盖是指：选取足够多的测试用例，使得程序的每条可能路径都至 少执行一次。 \\21黑盒测试技术
黑盒测试力图发现下述类型的错误： ①功能不正确或遗漏了功能； ②界面错误；
③数据结构错误或外部数据库访问错误； ④性能错误；
⑤初始化和终止错误。
黑盒测试技术：等价划分法、边界值分析法、错误推测法、因果图法等。
22.价类划分是一种黑盒测试技术，这种技术把程序的输入域划分成若干个数据类，据此导 出测试用例。等价类别或等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试用 例。划分等价类的规则：
(1)如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类
(2)如果输入条件代表集合的某个元素，则可定义一个有效等价类和一个无效等价类 (3)如规定了输入数据的一组值，且程序对不同输入值做不同处理，则每个允许的输入 值是一个有效等价类，并有一个无效等价类(所有不允许的输入值的集合)。
(4)如果规定了输入数据必须遵循的规则，可确定一个有效等价类（符合规则）和若干 个无效等价类（从不同角度违反规则)。
(5)如已划分的等价类各元素在程序中的处理方式不同，则应将此等价类进一步划分成 更小的等价类
23.边界值分析是指在设计测试用例时，使用正好等于、正好大于、正好小于边界值的数据 进行测试。边界值分析法与等价类划分法区别：
(1)边界值分析不是从某等价类中 随便挑一个作为代表，而是使这个等价类的每个边界 都要作为测试条件。
(2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
24调试（也称为纠错）作为成功测试的后果出现，也就是说，调试是在测试发现错误之后 排除错误的过程。试就是把症状和原因联系起来的尚未被人深入认识的智力过程。调 试 途 径：
1).蛮干法：打印内存的内容，从中寻找错误的线索，是效率最低的程序调试方法。 2).回溯法：从发现问题的程序段开始人工地往回追踪分析程序代码，直到找到错误。 3).原因排除法包括：对分查找法、归纳法、演绎法
25. 软件可靠性：是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。 软件可用性是：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。
可靠性和可用性的区别是：可靠性是在0到t时间间隔内，系统没有失效的概率。而可 用性是在t时刻，系统是正常运行的概率。
第8章 维 护
1.软件工程的主要目的：提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。 2.软件维护的类型 1）改正性维护
交付给用户使用的软件，即使通过严格的测试，仍可能有一些潜在的错误在用户使用的过程中发现和修改。诊断和改正错误的过程称为改正性维护。 2）适应性维护
随着计算机的飞速发展，新的硬件系统和外部设备时常更新和升级，一些数据库环境、数据输入/输出方式、数据存储介质等也可能发生变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。 包括外部环境和数据环境的变化 3）完善性维护
在软件投入使用过程中，用户可能还会有新的功能和性能要求，可能会提出增加新功能、修改现有功能等要求。为了满足这类要求而进行的维护称为完善性维护。 包括功能和性能的要求。 4）预防性维护
为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而进行的修改，称为预防性维护
3.软件维护过程实质上是一个修改和压缩了的软件定义和开发过程。事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 首先，建立维护的机构；
其次，确定报告及评价的过程，为每一个维护申请规定标准的处理步骤； 此外，建立适用于维护活动的记录保管过程，并规定复审的标准。
4.软件可维护性是指维护人员理解、改正、改动或改进这个软件的难易程度，决定软件的可维护性的因素主要有下述5个：可理解性、可测试性、可修改性、可移植性、可重用性。 5.文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。 6. 软件系统的文档可以分为用户文档和系统文档两类。
用户文档--主要描述系统功能和使用 方法，并不关心这 些功能是怎样实现的； 系统文档--描述系统设计、实现和测试等各方面的内容。
7.软件再工程是一类软件工程活动，是一个工程过程, 它将逆向工程、重构和正向工程组合起来,将现存系统重新构造为新的形式
8.可维护性复审概念：测试结束时进行正式的可维护性复审，称为配置复审。 目的：保证软件配置的所有成分是完整的、一致的和可理解的。
第九章 面向对象方法学引论
1. 面向对象方法学(Object-Oriented Methodology )的出发点和基本原则：尽可能模拟人类习 惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过 程。即：是描述问题的问题空间（问题域）与现实解法的解空间（求解域）在结构上尽可
能一致。
2.面向对象方法具有四个要点：
A. 认为客观世界是由对象组成；
B.把所有对象都划分成各种对象类（Class）；
C.把若干对象类组成一个层次结构的系统（类等级）； D．对象彼此间仅通过传递消息互相联系。 OO = Objects + Class + Inheritance + Communication with message 3.OOM与传统方法的比较：
① 传统方法：面向过程设计，以计算为核心;数据与操作 分离，不易理解。
OOM：以object为核心，强调对现实概念的模拟而不强调算法。“面向对象方
法学的基本原则，是按照人们习惯的思维方式建立问题域的模型，开发出尽可 能直观、自然地表现求解方法的软件系统”。 ②传统方法：结构依赖于功能，不稳定
OOM：以object模拟实体，需求变化不会引起结构的整体变化，因为实体相对 稳定，故系统也相应稳定。
③传统方法：通过建立标准函数库来重用软构件。但标准函数缺少必要的“柔性”，难 以适应不同场合不同需要。
OOM：一个class所有的实例(instances)都可重用它的代码；由继承性(inheritance) 派生出的新的class可重用其父类的代码，并且可以修改、扩充而不影响其父类 的使用。
④ 传统方法：可维护性是最令人头痛的问题。 OOM：从以下几方面改善了可维护性
稳定性好：软件功能需求的变化不牵动全局，只需局部修改；
Class 独立性强：只要修改不涉及class的对外接口，则内部修改完全不影 响外部调用；
继承性(Inheritance)和多态性(polymorphism)使其很容易被修改和扩充； 容易理解、容易测试、调试。
4.面向对象方法的优点
(1)与人们习惯的思维方法一致；
使用现实世界的概念抽象地思考问题从而自然地解决问题。 (2)稳定性好；
系统的功能需求变化时不会引起软件结构的整体变化，往往仅需要作一些局部性的修 改。
(3)可重用性好；
对象是比较理想的模块和可重用的软件成分。 (4)较易开发大型软件产品；
可以把一个大型软件产品分解成一系列相互独立的小产品来处理 (5)可维护性好。
易于理解、修改、测试 5.面向对象的概念
1） 对象是具有相同状态的一组操作的集合。
对象是对属性值和操作的封装
2） 类是对具有相同数据和相同操作的一组相似对象的定义 3） 实例就是由某个特定的类所描述的一个具体的对象。
4） 消息就是用来请求对象执行某个处理或回答某些信息的要求 5） 方法是对象所能执行的操作 6） 属性是类中定义的数据
7） 封装就是信息隐藏，通过封装对外界隐藏了对象的实现细节。 8） 继承，是指能够直接获得已有的性质和特征，而不必重复定义它们。继承是一种“求
同存异”的高度抽象方式 9） 多态性，指子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象，
也可以发送给子类对象。
10）函数重载 指在同一作用域内的若干个参数特征不同的函数可以使用相同的 函数名字。 10） 运算符重载指同一运算符可以施加于不同类型的操作数上面。当被操作数类
型不同时，运算符的含义是不同的。
6.面向对象建模就是根据面向对象观点(模拟人类习惯的思维方式)建立问题的解模式. 面向 对象的实现能将此模式在计算机上实施。用OOM开发软件，通常需要建立三种形式的模 型，它们分别是：
（1）对象模型：描述系统的数据结构； （2）动态模型：描述系统的控制结构； （3）功能模型：描述系统的功能
7. 对象模型表示静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象 以及对象彼此间的关系的映射，描述了系统的静态结构。
8.关联表示两个类的对象之间存在某种语义上的联系。例如，作家使用计算机，我们就认 为在作家和计算机之间存在某种语义连接，因此，在类图中应该在作家类和计算机类之 间建立关联关系。
聚集表示类与类之间是整体与部分的关系。
9.动态模型表示瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。
每一个对象都具有自己的生命周期（或称为运行周期）。对一个对象来说，生命周期由许多阶段组成。生命周期中的阶段也就是对象的状态。 10以用例图建立起来的系统模型称为用例模型，它描述的是外部行为者所理解的系统功能。 11三种模型之间的关系
1）针对每个类建立的动态模型，描述了实例的生命周期或运行周期。
2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射 成用例，它们同时与类图中的服务相对应。
3）功能模型中的处理（或用例）对应于对象模型中的类所提供的服务。
4）数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象 5）数据流图中的数据流，往往是对象模型中对象的属性值，也可能是整个对象。 6）用例图中的行为者，可能是对象模型中的对象。
7）功能模型中的处理（或用例）可能产生动态模型中的事件。
8）对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。
第10章 软件产品线
1. 软件产品线涉及软件工程、管理技术和商业规划等多个方面，几乎涵盖了软件工程的所
有方向。
软件产品线的基本思想：大部分的软件需求并不是全新的，而是已有系统需求的变体 软件产品线开发的核心思想是：采用特定领域体系结构和构件重用技术来解决一类具有 相似需求的领域应用问题。 2. 软件产品线定义
定义1、利用产品间公共方面，预期考虑了可变性等设计的产品族称为产品线（Weiss和Lai）。
定义2、产品线就是由在系统的组成元素和功能方面具有共性和个性的相似的多个系统组成的一个系统族。
定义3、软件产品线就是在一个公共的软件资源集合基础上建立起来的，共享同一个特性集合的系统集合（Bass、Clements和Kazman）。 • 产品线的定义强调了以下几点：
– 预先定义的生产方式 – 共享的软件核心资源
– 以核心资源为基础的软件开发
3.软件产品线的基本活动： 核心资源开发、软件项目开发和技术协调、组织管理三大活动 4.核心资源开发
核心资源开发活动的输出包括：
– 产品线范围：是关于产品线所能包含的产品描述，列举出所有产品的共性和
彼此之间存在的个性差异
– 核心资源：是产品线中应用系统创建的基础设施。
– 开发计划：描述了如何利用产品线中的核心资源去开发软件项目。
4.软件项目开发
• 软件项目开发活动依赖于核心资源开发活动的输出结果，即产品线范围、核心
资源和开发计划
• 软件项目开发活动的输入包括：
– 项目实际需求，被表示为领域中一些通用产品描述的变化或增量，也可表示
为产品线需求集合的一个增量，通过比较应用需求与产品线需求模型来获得。
– 产品线范围，指出当前所要开发的软件项目是否可由产品线来实现，指明该
项目可由产品线实现的模块，同时，还应该说明应用系统开发依赖于产品线的程度。
– 用于创建该项目的核心资源。
– 开发计划，详细描述了如何利用核心资源来设计实现该软件项目。
5.软件产品线工程与其它复用技术相比，主要存在以下两方面的差异：
软件产品线工程涉及一系列具有相似应用需求的软件产品。 软件项目开发是以公共核心资源为基础来进行的
6.软件产品线需求建模是产品线开发过程中的关键性活动，其质量将直接决定整个产品线 的成败。软件产品线需求建模包括： 1） 产品线领域范围定义 2） 产品线领域需求收集 3） 产品线领域需求分析
4） 产品线领域需求层次划分 5） 产品线领域需求规格说明 6） 应用系统需求收集 7） 应用系统需求分析 8） 应用系统需求规格说明 7.软件产品线需求分析的特点
产品线领域需求包括固定部分和变化成分。
其中：固定部分：包括：所有产品公共功能和特征，变化部分：不同产品的独特性。
• 需求模型是客户、领域专家和系统分析师之间进行沟通的有效手段。
• 需求抽取是一个发现、评审、文档化、理解用户需求和阐明系统约束的过程。 • 需求分析是一个提炼用户需求和系统约束的过程。
• 需求规格说明是一个清晰地文档化用户需求和严格地阐明系统约束的过程。 • 需求确认是一个保证系统需求完整、正确、一致和清晰的过程。 8.软件产品线开发评价 1） 核心资源开发评价 2） 软件项目开发评价 3） 产品线管理评价 9.软件产品线的双生命周期模型 领域工程 领域 领域分析 领域设计 领域实现 需求 领域需求模型 领域体系结构 领域构件 应用工程 应应用用 应用系统设计 应用系统实现 应用需求分析需系 求统 • 整个模型由两个重叠的软件生命周期复合而成，即领域工程生命周期和应用工程生
命周期。
• 在领域工程和应用工程中，又分别有各自的分析过程、设计过程和实现过程。 • 产品线领域工程的主要任务是：针对特定领域应用需求，创建可共享的公共软件体
系结构、构件和开发模型。
• 应用工程是在领域工程的基础上开发软件项目的过程。
• 在领域工程和应用工程的相应阶段之间，存在着纵向连接线，其含义是：产品线领
域工程指导应用工程的实施。
• 应用工程的结果可以反馈给领域工程，促进核心资源的建设，因此，整个软件产品
线是一个互相迭代和相互完善的过程。
• 领域工程是一个在较高抽象层次上，从领域遗留系统中抽取公共的、可重用的核心
资源，创建软件产品线以支持应用开发的过程。
• 应用工程使用领域工程所创建的产品线体系结构和构件资源来开发应用系统，此外，
还要根据应用的特殊需求来定制新构件。
若新定制的构件具有领域可重用特性时，则需要进行泛化处理，将其加入到产品线核心资源中
10软件产品线的N生命周期模型
产品线工程 范产品线分析与计 划产品线确认与分 类产品线标准与规产品线发布 企业工程 企业资质确 认与规范发 企业领域工程计 划企业产品线开…… 领域工程 产品线确认 领域分析 体系结构设 计体系结构实 现企业产品演线化 应用工程 市场分析 应用需求分 析应用系统设 计应用系统实 现 • 第一层是产品线工程，主要包括：产品线分析与计划、产品线确认与分类、产品线标准与规范和产品线发布。 • 第二层是企业工程，描述了使用产品线来开发应用系统的软件企业的内部组织结构、
生产过程控制和发展模式。
• 第三层是领域工程，包括产品线确认、领域分析、体系结构设计和体系结构实现。 • 第四层是应用工程，包括市场分析、应用需求分析、应用系统设计和应用系统实现。 11软件产品线组织划分为4个部分：
市场分析人员：是产品线、应用系统和客户需求之间的沟通桥梁； 核心资源组：负责软件产品线体系结构和构件资源的开发工作； 软件项目组：负责完成应用系统的开发工作； 产品线管理者：负责开发过程的协调和计划
12.软件产品线的优缺点
优点：
降低开发费用 、缩短上市时间、灵活的人员配备、更高的可预测性、更高的质量、减低维护成本、减少系统设计复杂度、便于估计开发成本
缺点
• 产品线的前期投资比较大，投资回报的周期比较长，而且失败的风险也比较大。 • 难以制定遗留系统向软件产品线迁移的有效策略。
• 软件产品线理论还缺少策略化的重用模型和支持系统化重用的发展策略。 • 核心资源设计的通用性要求可能会导致其质量下降，适用范围缩小。
因篇幅问题不能全部显示，请点此查看更多更全内容