软件工程导论作业.docx
《软件工程导论作业.docx》由会员分享，可在线阅读，更多相关《软件工程导论作业.docx（22页珍藏版）》请在冰豆网上搜索。
软件工程导论作业
软件工程导论作业
Chapter1
1.1什么是软件危机?
它有哪些典型表现?
为什么会出现软件危机?
答：
软件危机是指在计算机软件开发和维护过程中所遇到的一系列的严重问题。
它的典型表现：
1.软件开发成本高，成本难以控制。
2.研究周期长，软件开发进度难以控制，周期拖得很长。
3.正确性难以保证，软件质量差，可靠性难以保证。
4.软件维护困难，维护人员和维护费用不断增长。
5.软件发展跟不上硬件的发展和用户的要求。
它出现的原因一方面是由于软件生产本身存在着复杂性，另一方面是与软件开发所使用的方法和技术有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
管理和控制软件开发工程相当困难，软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
目前相当多的软件专业技术人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成为软件危机的主要原因。
1.2什么是软件工程?
它有哪些本质特性?
怎样用软件工程消除软件危机?
答：
软件工程是将系统化的，规范化的，可度量的方法应用于软件开发，运行和维护的过程，即将工程化应用于软件中。
它的本质特性：
1.软件工程关注于大型程序的构造2.软件工程的中心课题是控制复杂性3.软件经常化4.开发软件的效率非常重要5.和谐地合作是开发软件的关键6.软件必须有效地支持它的用户7.在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品。
基本原理:
1.用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计的技术5.结果应能清楚地审查6.开发小组的人员应该少而精7.承认不断改进软件工程实践的必要性。
1.3什么是软件？
它有什么特点？
答：
软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据结构及其相关文档的完整集合。
它的特点是：
1.抽象而非具体2.开发而非制造3.退化而非磨损4.定制而非基于构件5.不可见6.复杂7.易改变8.易复制
1.4什么是软件过程?
它与软件工程方法学有何关系?
答：
软件过程是为了开发出高质量的软件产品所需完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程定义了运用技术方法的顺序，应该交付的文档资料，为保证软件质量和协调软件变化必须采用的管理措施，以及标志完成了相应开发活动的里程碑。
软件过程是软件工程方法学的3个重要组成部分之一。
软件工程的基础是软件过程。
1.5什么是软件生命周期模型?
试比较瀑布模型、原型模型、增量模型和螺旋模型的优缺点，说明每种模型的适用范围。
答：
软件生命周期模型是软件开发全部过程，活动和任务的结构框架，它能直观表达软件开发全过程，明确规定要完成的主要活动，任务和开发策略。
也叫软件开发模型。
瀑布模型优点：
有利于大型软件开发过程中人员的组织，管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
缺点：
1，开发过程一般不能逆转，否则代价太大2.实际的项目开发很难严格按照该模型进行3.客户往往很难清楚地给出所有的需求，而该模型却要求如此4.软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
适用范围：
1.用户的需求非常清楚全面，且在开发过程中没有或变化很少2.开发人员对软件的应用领域很熟悉3.用户的使用环境非常稳定4.开发工作队用户参与的要求很低。
原型模型优点：
1.可以得到比较良好的需求定义，容易适应需求的变化2.有利于开发与培训的同步3.开发费用低，开发周期短且队用户更友好。
缺点：
1.客户与开发者对原型的理解不同2.准确的原型设计比较困难3.不利于开发人员的创新
适用范围：
1.对所开发的领域比较熟悉而且有快速的原型开发工具2.项目投标时，可以以原型模型作为软件的开发模型3.进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型非常合适。
增量模型优点：
1.采用增量模型的优点是人员分配灵活，刚开始不用投入大量的人力资源2.如果核心产品很受欢迎，则可增加人力实现下一个增量3.可先发部分功能给客户，对客户起到镇静剂的作用。
缺点：
1.并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构2.增量模型的灵活性可以使其适应这种变化的能力大于优于瀑布模型和原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
适用范围：
1.进行已有产品升级或新版本开发，增量模型是非常适合的2.对完成期限严格要求的产品，可以使用增量模型3.对所开发的领域比较熟悉而且已有原型系统，增量模型也非常适合。
螺旋模型优点：
1.实际上的灵活性，可以再项目的各个阶级进行变更2.以小的分段来构建大型系统，是成本计算变得简单容易3.客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性4.随着项目推进，客户始终掌握项目的最新消息，从而是他或她能够和管理层有效地交互。
缺点：
1.采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失2.过多的迭代次数会增加开发成本，延迟提交时间。
适用范围：
只适合于大规模的软件项目。
1.6怎么理解软件工程的概念及其意义？
答：
软件工程是一门将理论和知识应用于实践的工程，它借鉴了传统工程的原则和方法，以求高效地开发高质量软件。
它是一种层次化技术。
意义：
从历史上讲，软件工程的作用，是为了克服上个世纪60年代出现的软件危机，这种危机表现为软件开发的成本大、进度慢、维护难和质量得不到保障。
从当前来讲，软件工程的作用，就是告诉人们怎样去开发软件和管理软件。
具体地讲，它表现在与软件开发和管理有关的人员和过程上。
1.7软件过程的通用过程框架包含哪两类活动？
答：
一类是框架活动，还有一类是保护性活动。
1.8描述基于构件开发的思想以及目前的发展情况。
答：
基于构件开发强调将被设计的系统分解成功能的或逻辑的构件，构件用定义好的接口进行通信。
它是现在软件复理论实用化的研究热点，在构件对象模型的支持下，通过复用已有的构件，软件开发者可以“即插即用”地快速构造应用软件，这样即可以节省时间和经费，提高工作效率，也可以产生更加规范，更加可靠的应用软件。
1.9请简要说明RUP的9个规程（disciplines）及之间关系？
答：
RUP的9个规程为：
业务建模，需求，分析与设计，实现，测试，部署，配置与变更管理，项目管理以及环境。
对于一个大型项目，RUP九个规程的活动不可或缺，但对于有些项目可能不需要经过所有九个规程，在项目开发时需要对这些规程涉及的活动做具体的裁剪，以适应具体项目的开发需要。
1.10说明面向切面编程的特点，有什么优势？
答：
该范型以一种称为切面的语言构造为基础，切面是一种新的模块化机制，用来描述分散在对象、类或函数中分离出来可以大大增强程序的模块性。
优势：
他把特定领域问题的代码从业务逻辑中独立出来，业务逻辑的代码中不再含有针对特定领域问题代码的调用，业务逻辑同特定领域问题的关系通过切面来进行封装，维护。
优势：
面向切面编程的特点是针对业务处理过程中的切面提取，所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果，降低了耦合性。
1.11模型驱动工程中MDA的基本思想是什么？
答：
MDA的基本思想是系统的功能性是用合适的规约语言以平台无关的模型的方式定义，然后为实际的实现翻译到一个或多个平台相关的模型上。
Chapter2
2.1描述面向对象的基本概念和思想。
答：
面向对象是一种以对象为基础，以事件或消息来驱动对象执行处理和程序设计技术。
面向对象的基本思想是认为客观实体和实体之间的联系构成了现实世界的所有问题，而每一个实体都可以抽象为对象。
2.2面向对象分析设计的基本思路和过程是怎样的？
答：
分析过程主要包括理解、表达和验证。
设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。
过程：
识别系统的用例和角色，进行系统分析并抽象出类，设计系统并设计系统中的类及其行为。
2.3面向对象程序设计中的概念主要包括哪些？
分别阐述其主要思想。
答：
对象：
封装了数据和操作这些数据的代码的逻辑实体。
类：
具有相同类型的对象的抽象。
封装：
保证软件部分具有优良的模块性的基础。
继承：
让某个类型对象获得另一个类型的对象特征。
多态：
使不同内部结构的对象可以共享相同的外部接口，减少代码复杂度。
动态绑定：
多态实现的具体形式，将一个过程调用与相应代码链接起来的行为。
消息传递：
使得对现实世界的描述更容易。
方法：
定义一个类可以做的，但不一定去做的事。
2.4描述UML的主要概念和历史。
答：
UML是统一建模语言，用来对软件密集系统进行可视化建模的一种语言。
UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
历史：
Rumbaugh和Booch将Booch93和OMT-2统一起来，发布了UM0.8；后经过Booch，Rumbaugh和Jacobson的共同努力，发布了UML0.9和UML0.91，并将UM重命名为UML。
97年，Rational组织成立了UML合作者联盟，以完善、加强和促进UML的定义工作。
2000年启动了UML2.0标准的制定工作。
2.5RUP是什么？
应用RUP对软件开发有什么意义？
答：
RUP（RationalUnifiedProcess）是统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。
应用RUP为软件开发提供了一个模版，使得软件开发过程规范化，统一化。
Chapter3
3.1为什么要进行业务建模？
业务建模适用什么场合的软件项目开发？
答：
进行业务建模的原因：
业务人员、IT技术的业务知识、IT技术知识彼此之间存在着较大的差异，而规模较大的软件开发项目是不太可能让所有参加项目的IT技术人员都先熟悉业务知识而再进行开发的，所以需要通过“业务建模”将“业务需求”准确地转换为IT技术人员所熟悉的“软件需求”。
适用场合：
规模较大的软件项目开发。
3.2业务建模可以分哪些工作流进行？
答：
评估业务状态、描述当前业务、定义业务、探索流程自动化、开发领域模型。
3.3什么是领域模型？
与业务模型的关系是什么？
答：
领域模型：
领域模型是描述业务用例实现的对象模型。
它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。
领域模型从业务角色内部的观点定义了业务用例。
该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。
它注重业务中承担的角色及其当前职责。
这些模型类的对象组合在一起可以执行所有的业务用例。
关系：
开发领域模型是一个备选活动，领域模型是业务分析模型中独立的一部分，注重于说明对于业务领域很重要的概念、产品、可交付成果和事件。
这样一个模型仅描述业务中的重要信息，并不包括人员承担的职责。
3.4什么是系统上下文？
明确目标系统的上下文有什么意义？
答：
系统上下文：
指的是目标系统、与之交互的用户和外部系统。
意义：
业务建模作为软件需求的前一阶段，了解目标系统的上下文是很有必要的，便于确定目标组织和业务范围。
3.5什么是业务涉众？
业务涉众可能来自哪些方面？
答：
业务涉众：
所有跟目标业务有利害关系的人。
方面：
可能来自目标组织内部及目标组织外部且跟目标组织有关系的人和组织。
3.6什么是业务愿景？
怎么理解业务愿景的重要性？
答：
业务愿景：
定义业务建模工作所针对的一组目标。
重要性：
要了解组织的业务过程，对业务进行建模，首先必须理解组织的共同愿景，业务建模时期的重要任务就是确定项目涉众的共同愿景，而了解最有影响力的涉众的愿望和目标是非常重要的环节。
所以业务愿景对整个业务建模过程来说是十分关键和重要的。
3.7业务建模的作用是什么？
哪些人和组织是潜在的业务执行者？
答：
作用：
（1）了解目标组织（将要在其中部署系统的组织）的结构和机制；
（2）了解目标组织中当前存在的问题并确定潜在改进的可能性；
（3）确保客户、最终用户、开发人员和其他各方就目标组织达成共识；
（4）导出支持目标组织所需的系统需求；
（5）了解要部署的软件系统将如何融入组织。
潜在的业务执行者：
客户、合作伙伴、供应商、权威机构（法律、法规等制订机构）、子公司、所有者和投资者、业务以外的信息系统等。
3.8结构化业务用例的三种关系是什么？
答：
三种关系：
包含关系、扩展关系、泛化关系。
3.9业务用例的包含与扩展关系、包含与泛化的区别是什么？
答：
包含与泛化的区别：
（1）对于用例泛化关系，子用例的执行取决于父用例（重用部分）的结构和行为，而在包含关系中，基本用例的执行只取决于包含用例（重用部分）所执行的功能的结果。
（2）在泛化关系中，子用例的用途和结构是相似的，而在包含关系中，重用同一个包含用例的基本用例可能有完全不同的用途，但需求执行相同的功能。
包含与扩展的区别：
（1）包含关系：
如果基本用例的某个部分代表一个功能，而业务用例只依赖于本功能的结果，而不是产生结果的方法，那么可以将这部分分离出来，形成一个附加用例。
使用包含关系，将附加部分明确包含于基本用例中。
包含关系将基本用例和包含用例连接起来。
（2）扩展关系：
如果基本用例的一部分是可选的，或对于理解该用例的主要目的来说不是必需的，那么可以将这部分分离出来，形成一个附加用例，以简化基本用例的结构。
利用扩展关系，将附加部分隐含地包含于基本用例中。
扩展关系将扩展用例与基本用例连接起来。
3.10业务分析模型的作用是什么？
与业务用例模型的之间是什么关系？
答：
作用：
业务分析模型描述通过与业务系统、业务工作者和业务实体交互来实现业务用例。
它充当了为了执行业务用例而所需业务系统、业务工作者和业务实体之间的相关和协作方式的抽象。
它还定义了在执行业务用例时由业务执行者调用的外部业务服务。
关系：
业务用例模型是从与客户和业务流程对应的业务执行者和业务用例的角度，对业务进行描述。
业务用例模型包括工作流程说明，此说明确定完成了那些工作。
所以业务用例模型描述在业务执行者和业务之间发生了什么，对于业务结构或如何实现业务用例不作任何假设。
而业务分析模型就是用于描述如何执行业务用例，并具体定义业务提供的服务，内部业务工作者及其使用的信息，将它们的结构化组织描述为独立的单元，定义业务工作者如何通过交户来实现业务用例中所描述的行为。
3.11
（c）
2.以医院为研究对象，请描述医生、病历的性质分别是（）
（a）businessactor、businessworker
（b）businessworker、businessactor
（c）businessactor、businessentity
（d）businessworker、businessentity
3.12综合案例分析-餐厅点菜业务分析
某餐厅的点菜服务流程与规范如下：
1.递上菜单
（1）客人入座后，服务员询问客人需要什么茶水。
准备好茶水后，按“女士优先，先
宾后主”的原则从右边为客人斟上茶水。
（2）将菜单打开第一页，按照“女士优先”原则，用双手从客人右侧将菜单送至客人
手中，然后站在客人斜后方能观察客人面部表情的地方，上身微躬。
2.推荐介绍酒店菜品
（1）在客人点菜前，服务员应留有时间让客人翻看菜单。
（2）在客人翻看菜单时，应及时向客人简单介绍菜单上的菜，回答客人的询问。
（3）向客人介绍厨师长今日特别推荐的菜品、其他的特色菜、畅销菜和高档菜等菜品，
并介绍其样式、味道、温度和特点。
3.接受点菜
（1）服务员先在点菜单上记下日期、本人姓名及台号、就餐人数等。
（2）客人点菜时，应注视客人，听清客人点的菜名，适时帮助客人选择菜品和主动推
介菜品，准确地记录菜名。
（3）对于特殊菜品，应介绍其特殊之处，并问清客人所需火候、配料及调料等。
（4）若客人用餐时间较紧，点的菜需时间较长，则应及时向客人征求意见；若有客人
点相同的菜式，如汤和羹或两个酸甜味型的菜时，应有礼貌地问客人是否需要更换菜式。
（5）若客人有特殊要求，应在点菜单上清楚注明，并告知传菜服务员。
4.复述点菜内容
（1）客人点菜完毕后，服务员应清楚地重复一遍所点菜品内容，并请客人确认。
（2）复述完毕后，在点菜单的右上角写明当时的时间，以便查询。
（3）收回菜单并向客人致谢，同时请客人稍等，说明大致的等候时间。
5.分送点菜单
（1）服务员将点菜单的第一联送至收银处。
（2）将点菜单的第二联送至厨房。
（3）将第三联给客户，第四联交给传菜员、值台服务员留底备查。
根据案例的描述，请你完成下列任务：
1.分析餐厅的点菜业务，建立点菜业务模型。
这项业务的业务涉众：
外部涉众：
客人，
内部涉众：
服务员，收银处，厨房，值台服务员
分析点菜业务模型：
业务执行者为：
客人
业务用例是：
入座，推荐菜品，点菜，确认内容，分送菜单，上菜
2.用活动图描述客人点菜的活动。
3.分析点菜业务模型，找出有哪些业务工作者和业务实体，并用交互图来说明之间的通信和交互关系。
业务工作者为：
服务员,收银处，厨房，值台服务员
业务实体为：
菜单，点菜单
Chapter4
4.1需求的类别有哪些？
答：
需求可分为功能性需求和非功能性需求。
功能性需求规定了系统无需考虑物理约束而必须能够执行的动作，描述支持用户目标、任务或活动的系统行为（功能或服务）。
非功能性需求是功能性需求之外的需求，包含质量和约束，它们仅仅说明系统或系统环境的属性。
4.2怎么理解文中FredBrooks关于需求的那段话？
构建软件系统最难的部分是确定要构建什么（即系统需求）。
相比其他工作，如果这个工作做错，会严重影响将产生的系统，也更难在以后矫正。
答：
需求工作对于整个软件系统来说是非常重要的，它是实现和测试的先启阶段，需求建模解释如何理清涉众的请求及如何把这些请求转化为一组需求工作产品，确定要建系统的范围，提供系统必须做的详细要求。
此阶段是后续工作以及整个系统的基础和关键，一旦这个阶段出现问题，将会直接影响到后续工作的正常顺利进行，而如果想要在以后改，代价是非常大的，并且也难纠正。
4.3系统用例模型可以描述什么方面的需求？
补充规约主要补充哪方面的需求？
答：
系统用例模型可以描述设计软件系统方面的需求，参与者与软件系统的交互，在系统用例说明中书写足够详细的事件流。
补充归约主要补充那些无法在用例中记录的需求。
包括：
捕捉无用例归约的功能性需求，捕捉系统资量，捕捉约束，捕捉符合性需求，捕捉文档需求。
4.4什么是系统执行者？
如何寻找潜在的系统执行者？
答：
系统执行者：
是指与目标系统交换数据的任何对象，是在系统之外，透过系统边界与系统进行有意义交互的任何事物。
执行者可以是用户、外部硬件或其它系统。
寻找潜在的系统执行者：
首先可以从业务模型中去查找，那些业务执行者和业务工作者是潜在的系统执行者。
如果没有做业务建模，那可以回答以下问题：
哪些用户组需要系统帮助来执行它们的任务？
执行系统最明显的主要功能需要哪些用户组？
要求哪些用户组执行次要功能，如系统维护和管理？
哪些外部硬件或软件系统会与新系统交互吗？
是否有事情在预定的时间自动发生？
满足一个或多个上面这些范畴的任何个人、小组或事物有可能就是执行者。
4.5如何理解系统执行者与业务执行者、业务工作者的关系？
答：
业务执行者是指某人或某物与业务进行交互时所担任的角色，它是指在业务之外和业务交互的人、组织或事物。
业务工作者代表在业务中进行操作的人、软件或硬件的抽象。
它代表业务中的一个或一组角色。
系统执行者：
是指与目标系统交换数据的任何对象，是在系统之外，透过系统边界与系统进行有意义交互的任何事物。
执行者可以是用户、外部硬件或其它系统。
关系：
系统执行者是针对软件系统来说明的，而业务执行者和业务工作者是针对业务来说明的，系统执行者和业务执行者含义相似，只是所在的描述范畴不一样。
4.6请分析用例中的包含关系和扩展关系的相似与区别？
答：
相似：
都是如果用例包含的一段行为片段可以用于其他用例，则将这段行为片段归到“包含用例”或“扩展用例”中，形成一个新的用例，原始用例就成为基本用例，对“包含用例”和“扩展用例”分别有包含关系和扩展关系。
区别：
（1）扩展用例是可选的，而包含用例不是可选的；
（2）基本用例没有扩展用例是可以完成的，但没有包含用例则不能完成；（3）扩展用例的执行是有条件的，而包含用例没有；（4）扩展用例会改变基本用例的行为，而包含用例不会。
4.7简单说明把用例组织到包中有什么好处。
答：
用例包是用例、执行者、关系、图和其他包的集合，可以通过将用例模型分成更小的部分来结构化用例模型。
这样可以使得具有大量元素的用例模型中的用例结构化，同一包中的用例彼此之间都有某种关系，更加清楚明了，便于以后模型的分析和使用。
4.8用例详细描述中有哪三种事件流，分别表示什么场景？
答：
三种事件流：
主事件流、分支事件流和异常事件流。
主事件流：
在描述正常过程时列出执行者和系统之间相互交互或对话的动作序列。
当这种对话结束时，执行者也达到了预期的目的。
分支事件流：
也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。
异常事件流：
不符合用例流正常或基本行为，引起任务不能顺利完成。
4.9什么是软件需求规约（SRS）？
答：
软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。
4.10如何理解界面原型在需求建模中作用？
答：
可以处理模糊需求，开发者和用户可充分通信，降低开发风险。
静态界面原型：
供分析人员与用户进行进一步交流和沟通，通过这种可视化方法，使双方逐步就明确系统需求达成共识。
交互式界面原型：
便于用户可以操作，展示实际系统效果。
4.11选择题
1.如图4.11-1所示.A1、A2和A3是什么?
（单选题）（C）
（a）role
（b）Actress
（c）Actor
（d）User
2.如图4.11-1中，下面哪个语句是正确的?
（多选题）（BCD）
（a）A3可以使用UC4与系统交互。
（b）Al可以使用UCl和UC4与系统交互。
（c）A3,Al与A2不同。
（d）UC3是没有步骤的抽象用例。
3.如图4.11-1所示,下面哪个语句是正确的?
（多选题）（CD）
（a）UC5是UC4的补充部分。
（b）UC4是UC5的可选部分。
（c）UC1是没有用的。
（d）UC2是UC4的可选部分。
（e）UC4是UC2的补充部分。
4.12综合案例分析-餐厅智能移动终端无线点菜系统需求
根据第3章的练习3.11综合案例分析的业务描述，来分析点餐系统的需求。
现在该餐厅为了提高管理效率，避免在点菜过程中出现掉单、飞单,错单、舞弊等现象，计划采用智能移动终端无线点菜系统。
无线点菜系统的要求：
1.即时点菜
服务员随时随地地使用智能掌上电脑系统，为顾客点菜、加菜，系统自动将数据传到后台和分布在厨房与前台的打印机上。
打印机立刻打印所点的菜单。
2.无需布线
系统前台使用无线网络与掌上电脑技术，使前台使用者可以在营业大厅内随意走动，自
升级会员 