新書推薦：
《
山河不足重，重在遇知己
》
售價：NT$
252.0
《
独自走过悲喜
》
售價：NT$
381.0
《
永不停步：玛格丽特·阿特伍德传
》
售價：NT$
442.0
《
假努力：方向不对，一切白费
》
售價：NT$
335.0
《
北京三万里
》
售價：NT$
437.0
《
争吵的恋人：我们为什么相爱，又为什么争吵
》
售價：NT$
330.0
《
秘史：英国情报机构的崛起
》
售價：NT$
381.0
《
李鸿章及其时代：中西方世界的历史撞击
》
售價：NT$
330.0
|
| 編輯推薦： |
《重点大学软件工程规划系列教材：UML
2面向对象分析与设计》系统地介绍了利用最新的UML2进行面向对象分析与设计的过程，全书的主要目标包括以下三个方面。
OO（面向对象）：建立对象的思维方式，对面向对象思想和理论有深入的理解；
UML（统一建模语言）：能够熟练地使用UML表达面向对象的设计思想；
Model（建模）：运用面向对象的一般原则和模式进行应用系统的分析和设计建模。
|
| 內容簡介： |
分析和设计是软件开发中至关重要的一环，面向对象的方法是主流的软件开发方法，UML是用于面向对象分析设计的标准化建模语言。《重点大学软件工程规划系列教材：UML
2面向对象分析与设计》围绕这三个方面展开，以论述分析设计建模过程为最终目标，以面向对象方法作为建模的理论基础，以UML作为建模支撑语言。全书从面向对象和UML的基本概念人手，循序渐进地讲解业务建模、需求建模、需求分析、设计原则和模式、架构设计、构件设计和代码生成等分析设计期间的各个知识点，并通过多个贯穿全书的案例将各个知识点串联起来，形成一套完整的面向对象分析设计方法论。
《重点大学软件工程规划系列教材：UML
2面向对象分析与设计》是作者多年从事软件工程教学和软件项目开发实践的总结，书中并没有太多抽象的概念，主要关注实际软件开发中所需要的知识和实践技能，力求做到通俗易懂。
《重点大学软件工程规划系列教材：UML
2面向对象分析与设计》可作为高等院校软件工程专业及计算机相关专业的高年级本科生或研究生教材，也可供软件开发人员阅读和参考。
|
| 目錄：
|
第1章 上升到面向对象
1.1 从素数问题看面向对象
1.1.1 问题的提出
1.1.2 传统的结构化解决方案
1.1.3 面向对象的解决方案
1.1.4 从结构化到面向对象
1.2 面向对象技术基础
1.2.1 面向对象技术的发展历史
1.2.2 面向对象技术的优势
1.3 对象和类
1.3.1 对象
1.3.2 类
1.4 面向对象技术的相关原则
1.4.1 抽象
1.4.2 封装
1.4.3 泛化
1.4.4 多态
1.5 建立面向对象思维
1.5.1 引入案例
1.5.2 用面向对象思维分析案例
1.5.3 利用UML表达分析结果
第2章 可视化建模技术
2.1 可视化建模基础
2.1.1 建模的目的
2.1.2 建模的基本原则
2.2 统一建模语言
2.2.1 选择UML
2.2.2 UML统一历程
2.3 UML2组成结构
2.3.1 基础结构
2.3.2 上层结构
2.3.3 四层元模型结构
2.4 UML2概念模型
2.4.1 构造块
2.4.2 通用机制
2.4.3 架构
2.5 应用UML2建模
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 构件图和部署图
第3章 业务建模
3.1 分析设计过程简介
3.1.1 UML分析设计过程解析
3.1.2 结合过程应用UML
3.2 业务建模基础
3.3 业务用例模型
3.3.1 识别业务参与者
3.3.2 识别业务用例
3.3.3 利用活动图描述业务用例
3.4 业务对象模型
3.5 业务建模实践
3.5.1 建模指南
3.5.2 旅店业务建模实例
3.6 从业务模型到系统模型
第4章 用例建模
4.1 理解需求
4.2 从业务模型获取需求
4.2.1 寻找业务改进点
4.2.2 定义项目远景
4.2.3 导出系统需求
4.3 建立用例模型
……
第5章 用例分析
第6章 面向对象的设计原则
第7章 面向对象的设计模式
第8章 架构设计
第9章 构件设计
第10章 从模型到代码
|
| 內容試閱：
|
4.4.5 补充约束
用例的重点在于描述功能需求，但对于系统来说，还存在很多功能之外的东西。如本章开篇就提到的非功能需求。还有其他一些诸如数据项的定义、业务规则、设计约束等内容。本书中把它们统称为补充约束。因此在采用用例模型进行需求建模时也需要把这些补充约束记录到相应的文档中。根据不同的情况有以下两种处理策略。
·与特定用例相关的补充约束，作为该用例文档的一部分来描述。
·一些全局性的补充约束，单独形成一份独立的文档，如RUP中的“补充需求规约”
文档。
对于不同的项目而言，补充约束有不同的方面。本节重点讲解以下四种补充约束的表示方法：数据需求、业务规则、非功能需求和设计约束。
1. 数据需求
数据需求是指与该用例相关的一些数据项的说明。数据需求类似于结构化方法中的数据模型，与之不同的是，数据需求只关注当前用例。
数据需求的描述方法比较灵活，可以采用叙述性的文字来描述，如“房间的状态可能有：空闲、已预订、占用”。也可以采用以下系统化的方法，如数据字典的方式来定义，如“注册信息一用户名十密码+E-mail+{电话）*”。有时候，当一个用例涉及的数据项很多而且比较复杂时，也可以采用实体关系图的方式进行系统的描述。
当然这些数据项往往与用例的事件流相关，如：某个事件流中的某一步会产生或使用这些数据项。此时，应该将这些数据项与事件流建立联系；可以对每个数据项进行编号，再在前面的事件流中记录这些编号，数据需求的编号可使用前缀“D-”（Data）来表示。详细的例子参见第4.4.7节中的案例。
2. 业务规则
业务规则是指与业务相关的业务逻辑和操作规则，这些逻辑和规则对系统实现有一定的影响。有三类业务规则，即事实、推理规则和约束。事实是指业务中普遍认可的规则，为保证用户和开发方的共识，可以将这类规则记录到用例文档中。推理规则是指业务中的一些逻辑推理方法。约束是指在业务推理中的一些限制条件。下面的例子分别说明了这三种业务规则。
事实：设备是资产的一种。
推理：如果过了计划中的交货日期，货物还没有送到，即为“未按时送货”。
约束：合同总金额不能超出买方的信用额度。
……
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
