《面向对象软件工程与UML实践教程》 - 杨林,叶亚琴,方芳编著 - Meg Book Store

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台( 0 )　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』面向对象软件工程与UML实践教程

書城自編碼： 2537150
分類：簡體書→大陸圖書→計算機/網絡→软件工程/开发项目管理
作者：杨林,叶亚琴,方芳编著
國際書號(ISBN)： 9787030426253
出版社：科学出版社
出版日期： 2015-01-23
版次： 1 印次： 1
頁數/字數： 239/330000
書度/開本： 16开釘裝：平装

售價：HK$ 64.8

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《改变历史的意大利豪门：传奇家族美第奇》
售價：HK$ 90.0

《 Procreate插画手绘从新手到高手》
售價：HK$ 105.6

《山河不足重，重在遇知己》
售價：HK$ 54.0

《独自走过悲喜》
售價：HK$ 81.6

《永不停步：玛格丽特·阿特伍德传》
售價：HK$ 94.8

《假努力：方向不对，一切白费》
售價：HK$ 71.8

《北京三万里》
售價：HK$ 93.6

《争吵的恋人：我们为什么相爱，又为什么争吵》
售價：HK$ 70.8

建議一齊購買：

HK$ 66.6
《 UML软件建模技术》

HK$ 91.0
《 UML系统分析与设计（高等院校软件工程专业规划教材）》

HK$ 191.8
《软件工程：面向对象和传统的方法（原书第8版）（软工领域经典著作，被加州伯克利分校等180所美国高校选作教材）》

HK$ 92.8
《 UML2面向对象分析与设计（重点大学软件工程规划系列教材）》

編輯推薦：

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

內容簡介：

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

第l章面向对象软件工程概述
1.1软件工程的概念与发展
1.2软件生命周期模型
1.2.1瀑布生命周期模型
1.2.2迭代与递增模型
1.2.3快速原型开发生命周期模型
1.2.4其他生命周期模型
1.2.5生命周期模型的比较与选择
1.3面向对象思想
1.3.1面向对象的提出背景
1.3.2面向对象的几个重要概念
1.4面向对象软件过程
1.4.1统一过程
1.4.2统一过程的核心工作流
1.4.3统一过程的各阶段
1.4.4面向对象软件过程与传统软件过程
1.4.5软件过程改进
1.5本章小结
1.6习题l
第2章统一建模语言UML
2.1UMI。的历史
2.2UML概述
2.2.1什么是模型
2.2.2建模的重要性
2.2.3UML概念
2.3UML模型观点
2.3.14+1模型观
2.3.2动静模型观
2.4UML的组成
2.4.1UML的基本构造块
2.4.2规则
2.4.3公共机制
2.4.4UML的层级结构
2.5UML图形初探
2.5.1类图
2.5.2用例图
2.5.3顺序图
2.5.4协作图
2.5.5状态图
2.5.6活动图
2.5.7包图
2.5.8构件图
2.5.9部署图
2.6UML与面向对象软件开发
2.7本章小结
2.8习题2
第3章需求分析与用例建模
3.1需求分析
3.1.1需求分析的任务
3.1.2需求管理
3.2用例模型
3.2.1用例方法思想
3.2.2用例模型的基本元素
3.3用例
3.3.1用例的概念
3.3.2系统用例和业务用例
3.4执行者
3.5用例关系
3.5.1包含关系
3.5.2扩展关系
3.5.3泛化关系
3.6用例描述
3.6.1基本用例信息
3.6.2执行流程
3.6.3条件或规则
3.6.4相关文档
3.7需求分析中的用例建模过程
3.8本章小结
3.9习题3
第4章系统分析与静态建模
4.1系统分析与设计
4.1.1概要设计与详细设计
4.1.2软件设计原则
4.2包图
4.2.1包的概念与表示
4.2.2包之间的关系
4.2.3导入包和合并包
4.3类图
4.3.1类的概念与描述
4.3.2类图的描述
4.4类之间的关系
4.4.1关联
4.4.2依赖
4.4.3聚合
4.4.4组合
4.4.5继承
4.4.6其他关联
4.5类的一些种类
4.6软件开发中类图的建模方法
4.7本章小结
4.8习题4
第5章动态建模之交互模型——顺序图、协作图
5.1系统设计中的动态建模
5.2顺序图
5.2.1顺序图的基本构成元素
5.2.2顺序图中的动作
5.2.3顺序图高级建模
5.3顺序图的建模方法
5.4协作图
5.5协作图的组成部分
5.5.1对象
5.5.2链接
5.5.3消息
5.5.4消息的序列
5.6协作图的一些高级概念
5.7协作图的建模方法
5.8协作图与顺序图的比较
5.9本章小结
5.10习题5
第6章动态建模之状态模型
6.1状态图
6.1.1状态机
6.1.2状态图的含义
6.2状态图的建模元素
6.2.1状态图的基本组成成分
6.2.2状态
6.2.3迁移
6.2.4引起状态迁移触发的事件
6.3状态图的建模方法
6.4活动图
6.5活动图的基本描述图符
6.6活动图的一些基本概念
6.6.1动作状态
6.6.2活动状态
6.6.3动作流
6.6.4分支与合并
6.6.5分叉与汇合
6.6.6泳道
6.6.7对象流
6.7活动图的建模方法
6.8状态图和活动图的比较
6.9本章小结
6.10习题6
第7章系统体系结构建模
7.1系统体系结构模型
7.2构件图
7.2.1构件和接口
7.2.2构件图
7.2.3工件
7.2.4工件图
7.3部署图
7.3.1节点
7.3.2节点之间的关联
7.3.3署图的建模步骤
7.4本章小结
7.5习题7
第8章设计模式
8.1设计模式概述
8.1.1设计模式起源和概念
8.1.2设计模式遵循的基本原则
8.1.3设计模式分类
8.2创建型设计模式
8.2.1工厂设计模式
8.2.2单例模式
8.2.3构建型其他设计模式
8.2.4创建型设计模式总结
8.3结构型设计模式
8.3.1代理模式
8.3.2外观模式
8.3.3桥接模式
8.3.4结构型其他设计模式
8.3.5结构型设计模式总结
8.4行为型设计模式
8.4.1策略模式
8.4.2命令模式
8.4.3观察者模式
8.4.4行为型其他设计模式
8.4.5行为型设计模式总结
8.5设计模式选择总结
8.6本章小结
8.7习题8
第9章案例分析——电子商城系统建模
9.1需求分析
9.2电子商城需求阶段——用例模型
9.2.1电子商城用侈4图
9.2.2电子商城活动图
9.3电子商城分析阶段——分析模型
9.3.1电子商城类图
9.3.2电子商城顺序图
9.3.3电子商城协作图
9.4电子商城设计阶段一一设计模型
9.4.1电子商城状态图
9.4.2电子商城构件图
9.4.3电子商城配置图
9.5本章小结
第10章 RSA系统建模
10.1RSA简介
10.1.1RSA概述
10.1.2RSA安装
10.2创建模型项目
10.3创建系统用例模型
10.3.1创建用例图
10.3.2创建活动图
10.4创建系统分析模型
10.4.1创建类图
10.4.2创建顺序图
10.4.3创建协作图
10.5创建系统设计模型
10.5.1创建状态图
10.5.2创建构件图
10.5.3创建部署图
10.6本章小结
参考文献

內容試閱：

第1章面向对象软件工程概述
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是计算机程序设计和结构运行以及开发?运行和维护计算机程序所需的相关文档方面的科学知识的实际应用.
2IEEE将它定义为关于软件开发?运行?维护和停用的系统化方法.
3FritzBauer认为，软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行.
综合以上定义，可以反映软件项目经理的观点:软件工程是通过科学知识和过程的实际应用，进行软件开发?运行?维护和停用的严格的系统化方法，它是指导计算机软件开发和维护的工程科学，采用工程的概念?原理?技术和方法来开发和维护软件，目的是生产出能如期交付?在预算范围内?满足用户需求?没有错误的软件产品.
软件工程发展到今天，许多软件组织的软件开发具有以下特点:①软件规模大;②软件开发的方法多，出现了大量的软件工具支持;③软件开发规范化并趋于标准化;④软件维护更加容易;⑤更加注重软件开发的管理.这一切都得益于软件危机的爆发和人们对于软件工程孜孜不倦的研究与实践.
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递增.递增是软件工程的另外一个固有特性.当信息量过大时，人们的处理办法就是逐步求精法则

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　大陸用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.