太原科技大学软件工程考试重点.doc

第六章 具体设计

1.具体设计主线目的：拟定如何具体实现所规定的系统。
任务： 不是具体编写程序，而是设计程序的“蓝图”。
具体设计的结果决定最终程序代码的质量
2. 结构程序设计是一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出
口的控制结构。经典的结构程序设计：只允许使用顺序、IF_THEN_ELSE选择DO_WHILE
循环 。
3. 设计人机界面过程中会碰到的4个问题：
1)系统响应时间
系统响应时间指从用户完毕某个控制动作，到软件给出预期的响应之间的这段时间。
系统响应时间有两个重要属性：长度和易变性
2) 用户帮助设施
大多数现代软件都提供联机帮助设施，用户无须离开用户界面就能解决自己的问题。
常见的帮助设施可分为集成的和附加的两类.
3)犯错信息解决
犯错信息和警告信息，是出现问题时交互式系统给出的“坏消息.
4)命令交互
多数情况下，用户既可以从菜单中选择软件功能，也可以通过键盘命令序列调用软件
功能。
4. 设计过程

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.软件产品线的优缺陷
优点：
减少开发费用 、缩短上市时间、灵活的人员配备、更高的可预测性、更高的质量、减低维护成本、减少系统设计复杂度、便于估计开发成本
缺陷
• 产品线的前期投资比较大，投资回报的周期比较长，并且失败的风险也比较大。
• 难以制定遗留系统向软件产品线迁移的有效策略。
• 软件产品线理论还缺少策略化的重用模型和支持系统化重用的发展策略。
• 核心资源设计的通用性规定也许会导致其质量下降，合用范围缩小。