面向对象软件工程与UML实践教程

购买须知：

（1）图书现货且为正版，保证质量，发货后3-4天到达买家手中。

（2）店主是否在线都可以放心直接付款购买！请谅解本店图书不议价！

（3）如对书籍不满意，本店图书均可以无理由或无条件退货！不接受中差评，有任何问题都会与买家及时取得联系！

^.^关注本店可领优惠券，下单更优惠！^.^

基本信息

书名：面向对象软件工程与UML实践教程

作者：杨林,叶亚琴,方芳著

出版社：科学出版社

出版日期：2015-01-23

ISBN：9787030426253

字数：330000

页码：

版次：1

装帧：平装

开本：16开

商品重量：0.4kg

编辑推荐

《面向对象软件工程与UML实践教程》适用于软件工程专业专科学校，同时可供于对面向对象软件工程与建模方法有所了解的软件从业人员参考.9787030426253

内容提要

本书是计算机软件领域中一项实用技术，是软件学科中软件工程系统理论与面向对象方法的结合点。通过对本课程的学习，可以巩固软件工程有关的基本理论知识，提高计算机软件设计的理论水平，培养理论分析能力；另一方面，穿插统一建模语言UML，通过对软件工程、面向对象的软件设计方法、建模语言及工具的相互渗透学习，并结合项目实践，可以培养学生解决软件工程设计中的实际问题的能力。

目录

作者介绍

文摘

章面向对象软件工程概述
1989年，Humphrey提出软件开发的历史就是软件规模逐渐变大的历史，初，少数几个人就可以编写小的程序，但软件规模很快就变得让他们无法应付.
于是，1968年在德国召开的北大西洋公约组织(NorthAtlanticTreatyOrganization，NATO)会议上首次提出了“软件工程”概念，希望用工程化的原则和方法来克服软件危机.与此同时出现了各种不同的软件生命周期模型来实践软件工程原则.终，随着面向对象技术的发展，将面向对象思想与软件工程相结合成为当前软件开发组织的一种主流选择.
1.1软件工程的概念与发展
从20世纪40年代计算机出现以来，计算机技术开始蓬勃发展，到现在软件已经在各个领域得到了广泛的应用，并在各个专业领域和人们的日常生活中扮演着重要的角色.
在20世纪40~60年代的20多年时间里，人们对软件开发的理解就是编制程序，并且编程是在一种无序的?崇尚个人技巧的状态中完成的.从20世纪60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始作为一种产品被广泛使用，出现了“软件作坊”专职应别人的需求写软件.软件开发的方法基本上仍然沿用早期的个体化软件开发方式，但软件的数量急剧膨胀，软件需求日趋复杂，维护的难度越来越大，开发成本非常高，而失败的软件开发项目却屡见不鲜.以前可以应付小的软件开发的方法，随着软件规模的增长，参与项目开发人员的增多，软件开发过程变得难以控制，软件危机爆发并愈演愈烈，使许多软件开发组织无法自保.
因此，软件过程管理成为一个令软件组织头疼的问题，如何能够科学地完成软件的生产过程则成为软件组织非常关心的话题.首先了解软件开发演变过程中软件危机的产生原因.
(1)人们对于软件概念与范畴的理解.人们对于软件这个概念的理解在发展和变化.早期软件工程师崇尚个人英雄主义，整个软件开发通常处于一种无序的状态.他们大多认为编写程序就是软件开发的.这种观念随着软件规模的增大，会导致程序员对于文档的忽略与不重视，使软件开发产品不健全与维护困难.同时导致软件进度?成本控制方面的其他问题.直到20世纪60年代初期，BaryBoehm提出软件是程序以及开发?使用和维护程序所需要的所有文档.这时许多软件工程师逐步认识到编写程序只是软件开发的一个阶段(10%~20%)，程序只是完整产品的一个组成部分.
(2)软件的规模日益增长?设计日益复杂.近年来，计算机硬件取得了飞速的发展，20世纪70年代的CPU还是一个雏形，仅有2300多个晶体管.而如今，由于制造技术越来越先进，其集成度越来越高，内部的晶体管数达到几百万个，并且由单核升至六核，由单线程扩充至十二线程.早期的内存芯片也只有256K，现在的4-内存比原来足足增长了16000多倍.硬盘容量也由早期的5M提升到现在的以T为单位，增长了百万倍.同时，软件功能的扩充?软件体系的日渐庞大?软件效率的优化提高也都使软件规模迅速增长.无论是系统软件(操作系统?数据库系统等)还是应用软件(工具软件?办公软件?业务软件等)的规模都在成倍增长.以微软的VisualStudio软件开发环境为例，从几十兆规模增长至几百兆，再从几百兆增长至几吉，软件规模的增长无疑使软件开发的难度加大.
(3)软件开发组织发生变化.在上述因素发生变化的同时，软件开发组织也在发生着变化.早期开发一款小型软件，可能1~2个开发人员就可以完成.然而随着软件规模的飞速增长，软件开发组织也在同比例增长，由单打独斗的状态改为一个团队若干开发人员共同研发一款产品.人员由一个变成团队协同开发，这种组织形式的转变，必然给软件开发的协同组织带来挑战.同时造成潜在的进度?成本和质量的问题.
上述因素相互影响，使得软件开发存在诸多问题.“软件危机”一词即指在软件开发和维护过程中遇到的一系列严重问题.软件危机具体表现在以下几方面.
(1)对软件开发的成本估计不准确.
(2)对软件开发的进度估计不准确.
(3)软件产品质量很不可靠.
(4)软件可维护性差，软件的文档资料不完整和不合格.
(5)软件开发生产率不高，不能满足软件生产的需要.
软件危机的出现，促使人们不断对软件的特性和设计方法进行更深入地研究.1968年10月，在德国的-armish举行了NATO科学委员会(NATOScienceCommite)会议，会议上首次提出了“软件工程”概念，希望用工程化的原则和方法来克服软件危机.会议成员均为专业人士，包括来自11个国家的50位软件工程师.会议中，尽管大部分讨论集中在有关软件设计?生产?实现?发行和服务的技术上，但还是有一些报告与众不同，提出了如“大型软件项目中难以满足进度和规范要求”这样的问题.这可能是人们首次认识到软件项目管理的重要性.毋庸讳言，与“进度和规范”相关的难题至今仍然困扰着人们.软件工程的出现就是为了解决这些问题.
概括起来，软件危机包含两方面问题:一是如何开发软件，以满足不断增长?日趋复杂的需求;二是如何维护数量不断膨胀的软件产品.
此后不久，国际上来自学术界?工业界和研究实验室的22位软件开发领袖聚集到Hedsor公园，这是英国伦敦附近的一个市休养所，重提NATO会议，并分析软件行业未来的发展方向.这些活动被认为是人们开始清醒地注意到即将到来的“软件危机”的标志性活动.
“软件危机”让人们开始对软件及其特性产生更深的认识，人们改变了早期对软件的不正确看法.早期那些认为是的程序常常很难被别人看懂，通篇充满了程序技巧.现在人们普遍认为的程序除了功能正确?性能优良之外，还应该容易看懂?容易使用?容易修改和扩充.
程序员开始摒弃以前的做法，转而使用更系统?更严格的开发方法.为了使控制软件开发和控制其他产品生产一样严格，人们陆续制定了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高.随着遇到的问题越来越多，规则和流程也越来越精细和复杂.
(1)根据BaryBoehm的说法，软件工程(softwareenginering)是计算机程序设计和结构运行以及开发?运行和维护计算机程序所需的相关文档方面的科学知识的实际应用.
(2)IEEE将它定义为关于软件开发?运行?维护和停用的系统化方法.
(3)FritzBauer认为，软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行.
综合以上定义，可以反映软件项目经理的观点:软件工程是通过科学知识和过程的实际应用，进行软件开发?运行?维护和停用的严格的系统化方法，它是指导计算机软件开发和维护的工程科学，采用工程的概念?原理?技术和方法来开发和维护软件，目的是生产出能如期交付?在预算范围内?满足用户需求?没有错误的软件产品.
软件工程发展到今天，许多软件组织的软件开发具有以下特点:软件规模大;软件开发的方法多，出现了大量的软件工具支持;软件开发规范化并趋于标准化;软件维护更加容易;⑤更加注重软件开发的管理.这一切都得益于软件危机的爆发和人们对于软件工程孜孜不倦的研究与实践.
1.2软件生命周期模型
在认识到软件对人类生活的重要影响之后，人们便着手改进软件开发设计过程.描述软件开发设计中发生时间序列的软件生命周期(SoftwareLifeCycle，SLC)就是其中一个.
生命周期方法学是从时间角度对软件开发和维护的复杂问题进行分解.生命周期模型是对在构建一个软件产品时应完成的步骤的描述.因为执行一系列较小的任务总是比执行一个大的任务容易，因而将整个生命周期模型划分为一系列较小的步骤，称为阶段.
对某个具体的软件产品所做的一系列实际步骤，从概念开发到终退役，称为该产品的生命周期.
软件生命周期的定义和关于其存在的讨论已经成为软件行业中许多论坛和出版物的主题.20世纪70年代后期，出现了这样的说法:“不要生命周期，我不想这样!”尽管人们各持己见，但一致认为，软件开发过程要有文档说明.1970年，Royce确定了软件生命周期中的几个典型阶段.Royce和BaryBoehm提出，开发过程中，在每个阶段控制进入和退出点，将会改进软件质量，提高效率.例如，在确定了详细需求之后，再设计软件模块接口，可以减少重复劳动.
在理想世界中，软件产品的开发流程就是“需求—分析—设计—实现”.首先明确客户需求，然后进行分析.当分析制品完成后，就从事设计，然后是整个软件产品的实现，后将该软件安装在客户的计算机上.然而，软件开发在实践中有很大程度的不同，有两个原因:软件专业人员是人，因此会犯错;当软件正在开发时客户的需求会发生改变.
因此为了更好地进行软件开发，出现了多种生命周期模型.
软件生命周期模型主要有瀑布生命周期模型?迭代与递增模型?快速原型开发生命周期模型和螺旋生命周期模型等.
1.2.1瀑布生命周期模型
1970年Royce首次提出瀑布模型.瀑布模型是基本的和有效的一种可供选择的软件开发生命周期模型，直到20世纪70年代末，大多数软件组织都使用一种称为瀑布模型的生命周期进行软件开发.
该模型的核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开.瀑布模型将软件生命周期划分为软件计划?需求分析和定义?软件设计?软件实现?软件测试?软件运行和维护6个阶段，规定了它们自上而下?相互衔接的固定次序，如同瀑布流水逐级下落，如图1-1所示.
图1-1瀑布模型
瀑布模型具备如下几个关键特点.
(1)各个阶段的结束认定严格.在任何阶段的文档完成并且该阶段的产品被软件质量保证小组认可之前，该阶段不能认为结束.每一个阶段都必须定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都需要组织相关的评审和验证，只有在评审通过后才能够进入下一个阶段.
(2)各个阶段有明确的产出要求.由于需要对每一个阶段进行验证，瀑布模型要求每一个阶段都有明确的文档产出.
(3)各个阶段具有严格依赖关系.对于严格的瀑布模型每一个阶段都不应该重叠，而应该是在评审通过，相关的产出物都已经建立基线后才能够进入下一个阶段.
(4)各个阶段都包含测试.测试不是仅在产品建造完成后才能进行的独立阶段，也不是仅在每个阶段结尾时进行.相反，测试应在软件过程中连续进行.特别是在维护期间，必须确保修改的产品版本不仅仍能做先前版本所做的，而且能满足客户提出的任何新的需求.
如果在设计期间发现了一个需求中的差错引起的差错，顺着虚线向上的箭头，软件开发人员可以回溯设计到分析并由此到需求，并在那里进行必要的修改.然后，向下移到分析，改正规格说明文档以反映对需求的改动，并顺次纠正设计文档.设计工作现在可以在原来差错的地方继续进行.这种严格的过程模型能够确保文档与程序的良好一致性，提升软件的可维护性，极大地避免了程序修改而对应的需求及设计文档并没有及时更新的问题.
然而，瀑布模型是文档驱动的事实也是其弱点:客户通常没有阅读软件规格说明的习惯，而且规格文档通常是以一种客户不熟悉的风格写成的.但是，客户不管是否真的明白，都会签署规格说明文档的.并且，客户只有在整个产品完成编程之后才首次看到能够工作的产品.这样，就容易导致生产的产品并不是客户想要的情况.
特性的蔓延即连续地向需求中加入小的甚至琐碎的特性.该行为对软件健康有害.然而，一个软件产品是现实世界的一个模型，而现实世界是不断改变的.故特性蔓延问题又是无法避免的，因此生命周期模型应该考虑如何适应移动目标.
1.2.2迭代与递增模型
递增迭代是常采用的软件开发生命周期模型.迭代与递增分别是软件开发的两个固有特性.
(1)迭代.首先，人们要认识到无法仅通过一次过程就开发出理想而的软件产品，一个经得起考验的软件产品通常是经过若干次迭代过程才逐步趋于的.即一个软件会有多个版本，每个版本都比前一个版本离用户的真正需求更近一步，终构建出一个满意的版本.迭代是软件开发的一个固有特性，瀑布模型亦符合迭代的特性.
(2)递增.递增是软件工程的另外一个固有特性.当信息量过大时，人们的处理办法就是逐步求精法则

序言