软件工程课后作业.doc

第一章

1.1
答：软件危机是指在计算机软件开发、使用与维护过程中碰到的一系列严重问题和难题。它涉及两方面：如何开发软件，已满足对软件日益增长的需求；如何维护数量不断增长的已有软件。
软件危机的典型表现：
(1) 对软件开发成本和进度的估计经常很不准确。经常出现实际成本比估算成本高出一个数量级、实际进度比计划进度迟延几个月甚至几年的现象。而为了赶进度和节约成本所采用的一些权宜之计又往往损害了软件产品的质量。这些都减少了开发商的信誉，引起用户不满。
(2) 用户对已完毕的软件不满意的现象时有发生。
(3) 软件产品的质量往往是靠不住的。
(4) 软件经常是不可维护的。
(5) 软件通常没有适当的文档资料。文档资料不全或不合格，必将给软件开发和维护工作带来许多难以想象的困难和难以解决的问题。
(6) 软件成本、软件维护费在计算机系统总成本中所占比例逐年上升。
(7) 开发生产率提高的速度远跟不上计算机应用普及的需求。
软件危机出现的因素：
(1) 来自软件自身的特点：是逻辑部件，缺少可见性；规模庞大、复杂，修改、维护困难。
(2) 软件开发与维护的方法不妥：忽视需求分析；认为软件开发等于程序编写；轻视软件维护。
(3) 供求矛盾将是一个永恒的主题：面对日益增长的软件需求，人们显得力不从心。
1.2
答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在初期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完毕，引入一个变动要对所有已完毕的配置成分都做相应的修改，不仅工作量大，并且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完毕”是在引入变动，当然付出的代价更高。一个故障是代码错误导致的，有时这种错误是不可避免的，但要修改的成本是很小的，由于这不是整体构架的错误。
1.3
答：1993年IEEE的定义：软件工程是：① 把系统的、规范的、可度量的途径应用于软件开发、运营和维护过程，也就是把工程应用于软件；② 研究①中提到的途径。
软件工程的本质特性：
(1) 软件工程关注于大型程序(软件系统)的构造
(2) 软件工程的中心课题是分解问题，控制复杂性
(3) 软件是经常变化的，开发过程中必须考虑软件将来也许的变化
(4) 开发软件的效率非常重要，因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具
(5) 和谐地合作是开发软件的关键
(6) 软件必须有效地支持它的用户
在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人(完毕一些工作)消除软件危机的途径：
(1) 对计算机软件有一个对的的结识(软件≠程序）
(2) 必须充足结识到软件开发不是某种个体劳动的神秘技巧，而应当是一种组织良好、管理严密、各类人员协同配合、共同完毕的工程项目
(3) 推广使用在实践中总结出来的开发软件的成功技术和方法
(4) 开发和使用更好的软件工具
1.4
答：1.传统方法学：也称为生命周期方法学或结构化范型。
优点：把软件生命周期划提成基干个阶段，每个阶段的任务相对独立，并且比较简朴，便于不同人员分工协作，从而减少了整个软件开发过程的困难限度。
缺陷：当软件规模庞大时，或者对软件的需求是模糊的或会承受时间而变化的时候，开发出的软件往往不成功；并且维护起来仍然很困难。
2.面向对象方法学：
优点：减少了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作；促进了软件重用。
1.5
答：(1) 存储容量需求M=4080e0.28（1985-1960）=4474263（字）
存储器价格P=0.048*0.72（1985-1974）*4474263=5789美元
(2) 需要工作量4474263/200=22371（人/月）
指令成本22371*4000=89484000美元
(3) 需求估计M=4080e0.28（1995-1960）=73577679字
存储器价格0.003*32*0.72（1995-1974）*73577679=7127美元
工作量73577679/600=122629(人/月）
成本122629*6000=美元
1.6
答：软件过程是为了开发出高质量的软件产品所需完毕的一系列任务的框架，它规定了完毕各项任务的工作环节。
软件工程方法学：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型。
软件过程是软件工程方法学的3个重要组成部分之一。
1.7
答：软件生命周期模型是跨越整个生存期的系统开发、运作和维护所实行的所有过程、活动和任务的结构框架。
瀑布模型:
优点：它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。虽然有不少缺陷但比在软件开发中随意的状态要好得多。
缺陷：(1) 实际的项目大部分情况难以按照该模型给出的顺序进行，并且这种模型的迭代是间接的，这很容易由微小的变化而导致大的混乱。
(2) 经常情况下客户难以表达真正的需求，而这种模型却规定如此，这种模型是不欢迎具有二义性问题存在的。
(3) 客户要等到开发周期的晚期才干看到程序运营的测试版本，而在这时发现大的错误时，也许引起客户的惊恐，而后果也也许是劫难性的。
快速原型模型:
优点：使用户可以感受到实际的系统，使开发者可以快速地构造出系统的框架。
缺陷：产品的先天性局限性，由于开发者经常需要做实现上的折中，也许采用不合适的操作系统或程序设计语言，以使原型可以尽快工作。
增量模型:
优点：(1) 人员分派灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增长人力实现下一个增量。
(2) 当配备的人员不能在设定的期限内完毕产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。
缺陷：(1) 至始至终开发者和客户纠缠在一起，直到完全版本出来。
(2) 适合于软件需求不明确、设计方案有一定风险的软件项目。
该模型具有一定的市场。
螺旋模型:
优点：对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户可以较好地对待和理解每一个演化级别上的风险。
缺陷：(1) 需要相称的风险分析评估的专门技术，且成功依赖于这种技术。
(2) 很明显一个大的没有被发现的风险问题，将会导致问题的发生，也许导致演化的方法失去控制。
(3) 这种模型相对比较新，应用不广泛，其功效需要进一步的验证。
该模型适合于大型软件的开发
1.8
答：由于使用面向对象方法学开发软件时，各个阶段都使用统一的概念和表达符号，因此，整个开发过程都是吻合一致的，或者说是无缝连接的，这自然就很容易实现各个开发环节的反复多次迭代，达成结识的逐步深化，而喷泉模型则很好的体现了面向对象软件开发过程迭代和无缝的特性。
1.9
答：优点:提高了团队生产力，在迭代的开发过程、需求管理、基于组建的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面、针对所有关键的开发活动为每个开发成员提供了必要的准则、模版和工具指导，并保证全体成员共享相同的知识基础。它建立了简洁和清楚的过程结构，为开发过程提供较大的通用性。
缺陷：RUP只是一个开发过程，并没有涵盖软件过程的所有内容，例如它缺少关于软件运营和支持等方面的内容，此外，他没有支持多项目的开发结构，这在一定限度上减少了在开发组织内大范围实现重用的也许性。
1.10
答：大型的需求不断变化的复杂软件系统项目
1.11
答：合用于商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束
1.12
合用于商业环境下具有有限资源和有限开发时间约束的项目的软件过程模式.

第二章

2.2
答：假如是存款，储户填写存款单，然后交给业务员键入系统，同时系统还要记录存款人姓名、住址（或电话号码）、身份证号码、存款类型、存款日期、利率等信息，完毕后由系统打印存款单给储户。
假如是取款，储户填写取款单，然后交给业务员，业务员把取款金额输入系统并规定储户输入密码以确认身份，核对密码对的无误后系记录算利息并印出利息清单给储户。
为了满足储户的需求，该系统需要迅速的对用户的规定做出反馈，要对用户输入的信息作出最快的解决，所以就需要很大的主存容量，以及强大的数据库支持。由于是所面向的用户是广泛的储蓄用户群，所以需要系统强大的安全性能支持。可行性研究方法
条件、假定和限制
建议开发软件运营的最短寿命：5年
进行系统方案选择比较的期限：2个月
经费来源和使用限制：定制银行
硬件、软件、运营环境和开发环境的条件和限制：
银行中心拥有大型机以及用来支持的数据库，各个银行网点都有安
好的PC机，安装有Windows2023及以上的操作系统。
建议开发软件投入使用的最迟时间：开发完毕后试运营1个月。
可行性研究方法
通过与银行纯熟业务员进行进一步讨论，制定具体用户调查问卷，真正了解用户以及银行业务员的实际需求，根据业务员提供的信息以及问题定义再综合调查问卷中用户提出的意见进行改善。最终拟定项目需要解决的问题，并拟定问题能不能被解决。
决定可行性的重要因素
1）项目开发成本
2）所需设备置办成本
3）技术是否能满足需求
4）操作人员的纯熟限度
5）资源有效性
对现有系统的分析
1解决流程和数据流程
系统流程图
存款流程图：

取款流程图：

数据流图：

2工作负荷
当前大多数银行所使用的银行储蓄系统在办理业务时手续繁琐，人工业务操作过多，办理一个客户的业务就需花费较长的时间，其他客户只有等待。这样太浪费时间，需要大量的业务员解决客户业务。特别是在节假日人流高峰期，导致工作效率非常低，且犯错率高，以致客户等待办理手续过长感到不耐烦，减少了银行效率。这也给银行工作人员增长了非常大的承担和额外的工作负荷；同时业务员增多，银行费用支出多，给银行公司的发展带来严重的制约和压力。
3费用支出
运营现有系统所需要的费用支出涉及：银行业务员及其他工作人员的工资，系统维护所需资金，
4人员
需要大量的业务员、客服人员，系统维护人员以及其他工作人员。
5设备
现有系统所需要的设备有：打印机、PC机、电脑。
6局限性
工作效率底下，不能符合大量群众的及时需求，给群众的生活带来不便。这是现有系统办理业务的流程中出现的一个严重问题。为了解决这一问题，让人们再办理银行业务更加方便快捷，我们急需开发一个更为高效的银行计算机储蓄系统，让储蓄业务不用再排队。
（1）当前银行使用的银行储蓄系统在办理业务时仅仅靠手工操作，人工业务占据了所有，所以规定银行业务员办理业务时细心耐心，对数字敏感，算术水平高。它严重影响了工作效率，且犯错率高，储户办理事务时需要等待时间过长，需要大量的银行业务员才干满足日益增长的存取款规定。
（2）用纸张记录保存用户存款记录查找繁琐，耗时久，不方便，且容易丢失。且人工记录不能保证万无一失，容易出现数据录入错误。随着用户数的增多，这个缺陷会越发凸显。
（3）存款记录保密性差，任何一个业务员都可以随意更改查阅用户数据，用户的资料容易泄漏，带来安全隐患。
（4）业务员服务的时间有限，不能24小时办理业务，没有应急解决，不能更好的解决群众的需求。
（5）所有客户的业务都由业务员手工办理，浪费人力资源。有的简朴的业务经改善可由机器完毕，完全不用人工参与，这样节约了人力成本，也提高效率。
（6）对现有系统的改善维护只能依靠增多业务员数量，增多银行分行数目，提高业务员业务素质来实现。增多业务员数量会导致银行人员支出大大增多，同时需要多选址建设分行，或者扩大分行规模，费用代价巨大。业务员的业务素质需要培养，不能短期无限看见成效，及培养新人员需要一定的时间，这又浪费资金和人力资源。对现用系统的改善型维护已经不能解决储户越来越多、储户时间越来越长的问题。

第三章
3.3
解:数据流图

用ER图描绘系统中的数据对象。

3.4
用ER图描绘系统中的数据对象。

数据流图

3.5
（1）实体-联系图

（2）数据流图

（3）HIPO图

第五章

5.3
① 蓄系统

不能是两个分开的子系统，是相同的前台单个解决

②机票预订系统

可以是两个子系统，预定和取票是不同的解决方式（后台批量和前台单个）

5.4
解：（1）数据流图：

分解后：

（2）需求说明：
1.功能需求：可以输入调资的标准，输入教师档案，经调资给出新的教师档案，
需要存储档案
2．性能需求：软件的响应时间应小于0.5s，更新解决要快
3．灵活需求：当需求发生某些变化时，该软件应当可以适应这些变化
4．故障解决规定：出现错误时，应给予警告或提醒
（3）

（a）比较耗时，由于它要检索所有的档案，（b）从速度上看比较快，但是（b）需要排序算法，比较复杂，（a）对于设计来讲比较简朴 .（4）画出的数据流图比较适合（A）的算法

第六章
6.3
解：流程图：

盒图：

6.7
解(1)

(2)

6.8
解：流程图：

环形复杂度：
V(G)＝结点E－弧数n＋1=17-11+1=7=判断结点 ＋1=6 ＋1＝7＝封闭的区域数
逻辑有问题，当Z>0时，容易形成死循环；条件Y<5包含条件Y=2。

第七章
7.2

语句覆盖的含义是，选择足够多的测试数据，使被测试程序中的每个语句至少执行一次。

第九章
9.1
答: OO=objects+classes+inheritance+communication with messages 也就是说，面向对象就是既使用对象又使用类和继承等机制，并且对象之间仅能通过传递消息实现彼此通信。
面向对象方法学的优点：
1、与人类习惯的思维方法一致；
2、稳定性好；
3、可重用性好；
4、较易开发大型软件产品；
5、可维护性好。
9.2
答:把客观世界中的实体抽象为问题域中的对象。
它与传统数据相同的是，它们都是现实实体特在在计算机中的抽象表达:不同的是，对象是进行解决的主体，而传统数据是被动的接受外部指令对它进行解决；对象对实体特性进行了封装，而传统数据没有封装；对象比传统数据更为接近自然实体。
9.3
类是对具有相同属性和行为的一个或多个对象的描述。
9.4
广义地说，继承是指可以直接获得已有的性质和特性，而不必反复定义它们。在面向对象的软件技术中，继承是子类自动地共享基类中定义的数据和方法的机制。
9.5
答:所谓模型，就是为了理解事物而对事物作出的一种抽象，是对事物的一种无歧义的书面描述。模型是一种思考工具，运用这种工具可以把知识规范地表达出来。
其中，IT=105,MTTF1=0.4,T1=160,n1=100,MTTF2=2,T2=320,n2=300。 为了开发复杂的软件系统，系统分析员应当从不同角度抽象出目的系统的特性，使用精确的表达方法构造系统的模型，验证模型是否满足用户对目的系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。对于那些因过度复杂而不能直接理解的系统，特别需要建立模型，建模的目的重要是为了减少复杂性。
9.6
对象模型表达静态的、结构化的系统的“数据”性质。它是对模拟客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构。
通常使用UML提供的类图来建立对象模型。在UML中术语“类“的实际含义是，一个类及属于该类的对象
9.7
动态模型表达瞬时的、行为化的系统的“控制”性质，它规定了对象模型中的对象的合法变化序列。
通常，用UML 提供的状态图来描绘对象的状态、触发状态转换的事件以及对象的行为(对事件的响应)。每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型。也就是说，动态模型是基于事件共享而互相关联的一组状态图的集合。
9.8
功能模型表达变化的系统的“功能”性质，它指明了系统应当“做什么”，因此更直接地反映了用户对目的系统的需求。
功能模型由一组数据流图组成。在面向对象方法学中，数据流图远不如在结构分析，设计方法中那样重要。简朴的解决(或用例)相应于更基本的对象提供的服务。有时一个解决(或用例)相应多个服务，也有一个服务相应多个解决(或用例)的时候。
(1)数据流图中的数据存储，以及数据的源点/终点，通常是对象模型中的对象。
(2)数据流图中的数据流，往往是对象模型中对象的属性值，也也许是整个对象。
(3)用例图中的行为者，也许是对象模型中的对象。
(4)功能模型中的解决(或用例)也许产生动态模型中的事件。
(5)对象模型描述了数据流图中的数据流、数据存储以及数据源点/终点的结构。
9.9

9.10

第十章
10.1
1、对象模型：

2、动态模型：

3、功能模型

10.4
对象模型是三个模型中最关键的。它的作用是描述系统的静态结构，涉及构成系统的类和对象、它们的属性和操作以及它们之间的联系。UML中类图合用于建立对象模型，状态图合用于建立动态模型。每个类的动态行为用一张状态图来表达，各个类的状态图通过事件合并起来，构成系统的动态模型。也就是说，动态模型是基于事件共享而互相关联的一组状态图的集合。建立对象模型大体上按照下列顺序进行:寻找问题域内的对象，辨认出对象间的关系、定义属性和服务。事实上，分析工作不也许严格按照预定顺序进行，系统的模型往往需要反复构造多遍才干建成。

注：对象硬币计算器和对象硬币检测器可以作为对象自动售货器的一部分，它们的属性作为自动售货器的属性。
建立动态模型对于仅存数静态数据的系统来说，动态模型并没有什么实际意义。然而在开发交互式系统时，动态模型却起着很重要的作用。假如收集输入信息是目的系统的一项重要工作，则在开发这类应用系统时建立对的的动态模型是至关重要的。
建立动态模型的环节：
(1)编写典型的对话脚本；
(2)从脚本中提取出事件，联系该事件与其目的对象；
(3)组织事件的顺序和状态(采用状态图描绘)；
(4)比较各个不同对象的状态图，检核对象之间的一致性，保证事件之间的匹配。

功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型拟定什么时候发生，而对象模型拟定发生的客体。功能模型表白一个计算如何从输入值得到输出值，它不考虑计算的顺序。功能模型由多张数据流图组成。数据流图用来表达从源对象到目的对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表达，同时数据流图也不表达对象中值的组织，值的组织在对象模型中表达。
数据流图中包具有解决、数据流、动作对象和数据存储对象。
1.解决
数据流图中的解决用来改变数据值。最低层解决是纯粹的函数，一张完整的数据流图是一个高层解决。
2.数据流
数据流图中的数据流将对象的输出与解决、解决与对象的输入、解决与解决联系起来。在一个计算机中，用数据流来表达一中间数据值，数据流不能改变数据值。
3.动作对象
动作对象是一种积极对象，它通过生成或者使用数据值来驱动数据流图。
4.数据存储对象
数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不同样，数据存储自身不产生任何操作，它只响应存储和访问的规定。