登入帳戶　 |　訂單查詢　 |　購物車/收銀台(0)　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入   新用戶註冊

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / 物流，時效：出貨後2-4日

新書推薦： 《 《日本文学史序说》讲演录 》 售價：NT$ 332.0 《 无尽的海洋：美国海事探险与大众文化（1815—1860） 》 售價：NT$ 454.0 《 治盗之道：清代盗律的古今之辨 》 售價：NT$ 556.0 《 甲骨文丛书·剑桥世界暴力史（第一卷）：史前和古代世界（套装全2册） 》 售價：NT$ 959.0 《 甲骨文丛书·中华早期帝国：秦汉史的重估 》 售價：NT$ 1367.0 《 欲望与家庭小说 》 售價：NT$ 449.0 《 惜华年（全两册） 》 售價：NT$ 320.0 《 甲骨文丛书·古代中国的军事文化 》 售價：NT$ 454.0

建議一齊購買： + NT$ 656 《 Python 3面向对象编程 》 + NT$ 561 《 编码整洁之道：专业程序员的行为准则（英文版） 》 + NT$ 751 《 设计原本：计算机科学巨匠Frederick P.Brooks的思考（评注版） 》 + NT$ 1216 《 程序设计语言：实践之路（第3版）（含CD光盘1张） 》 + NT$ 561 《 灾难拯救——让软件项目重回轨道 》 編輯推薦： 一项技术产品只有在获得了Jolt奖之后才能真正成为行业的主流，一本技术图书只有在获得了Jolt奖之后才能真正奠定经典的地位。 內容簡介： 本书是UML创始人Grady Booch的代表作之一。 全书分为理论和应用两部分。理论部分深刻剖析了面向对象分析与设计（OOAD）的概念和方法。应用部分连续列出了5个不同类型、不同领域的应用，描述如何从初始阶段到交付阶段，将OOAD理论和方法应用到项目中。应用部分所涉及的领域包括系统架构、数据获取、密码分析、控制系统和Web开发，还给出了一些关于重要问题的有效建议，包括分类、实现策略和高性价比的项目管理。 书中介绍的概念都基于牢固的理论基础。同时，作者十分注重实效，基于其丰富的经验，面向软件工程实践者的实际需要，提出了改进的对象开发方法，用于解决系统和软件开发者面临的复杂问题；运用大量例子说明了基本概念，解释了方法，并展示了在不同领域的成功应用。 书中的表示法采用最新的UML 2.0，因此本书是学习UML 2.0不可多得的参考书。 本书非常适合实际系统和软件的开发者、系统分析师或架构师、项目经理阅读，也可以作为高等院校软件工程和高级编程课程的教材使用。 關於作者： Grady Booch，在软件架构、软件工程和建模领域的创新工作是世界知名的。从1981年Rational公司创建开始，他就一直担任该公司的首席科学家。Grady于2003年3月成为了IBM院士（IBM Fellow）。 Grady是统一建模语言（UML）最早的开发者之一，也是几个Rational产品的最早开发者之一。Grady曾担任世界各地一些复杂的软件密集型项目的架构师和架构指导者。 Grady是6本畅销书的作者，包括UML Users Guide和Object-Oriented Analysis with Applications。Grady发表了几百篇有关软件工程的技术文章，其中包括在20世纪80年代早期发表的文章，这些文章最先提出了面向对象设计的术语和实践。他曾在世界各地演讲和咨询。 Grady是美国计算机协会（ACM）、美国电气电子工程师学会（IEEE）、美国科学促进会（AAAS）、有社会责任的计算机专家协会（CPSR）的成员。他是IBM院士、ACM院士、世界技术网络院士，也是软件开发论坛梦想家。Grady是敏捷联盟、Hillside集团和软件架构师世界学院的创始委员会成员，也是Northface大学的顾问委员会成员。 Grady于1977年从美国空军学院获得学士学位，于1979年从加州大学圣巴巴拉分校获得电子工程科学硕士学位。 Grady与他的妻子和他的猫生活在科罗拉多。他的兴趣包括阅读、旅行、唱歌和弹奏竖琴。 Robert A. Maksimchuk，是Unisys Chief Technology Office的一名研究主管。他关注新出现的建模技术，目的是提升Unisys 3D可视企业建模框架的战略方向。Bob为这项任务带来了不同行业的大量系统工程、建模、面向对象分析与设计的专业知识。他是UML for Mere Mortals和UML for Database Design的合著者，也写了许多文章。他曾经周游世界各地，在各种技术论坛上作为重要演讲者发言，举办关于UML和面向对象开发的研讨会和培训。Bob是电气电子工程师学会（IEEE）和国际系统工程学会（INCOSE）的成员。 Michael W. Engle，是洛克希德马丁公司的首席工程师。他有超过26年的技术和管理经验--从项目启动到运营支持，涵盖了完整的系统开发生命周期。利用系统工程师、软件工程师和系统架构师的背景，Mike运用了面向对象技术，为复杂的系统开发提供创新的开发方式。 Bobbi J. Young， Ph.D.，是Unisys Chief Technology Office的一名研究主管。她有着多年的IT行业从业经验，与商业公司和国防部合同供应商一同工作。Young博士是一名咨询师，她在项目管理、企业架构、系统工程和面向对象分析与设计方面提供现场指导。在她的职业生涯中，她关注于系统生命周期过程和方法学，同时也关注企业架构。Young博士拥有生物学、计算机科学和人工智能学位，她获得了管理信息系统的博士学位，也曾是美国海军预备役的一名指挥官（已退伍）。 Jim Conallen，是IBM Rational的模型驱动开发战略小组的一名软件工程师。在这个小组中，他积极参与，将对象管理集团（OMG）的模型驱动架构（MDA）计划应用于IBM Rational的模型工具中。Jim在基于资产的开发和可复用资产规范（RAS）领域也很活跃。Jim经常在会议上演讲，也经常写文章。他的专业领域是Web应用开发。 他开发了UML的Web应用扩展（WAE）。这是对UML的一种扩展，让开发者能够利用UML在合适的抽象和细节层面上对Web应用的架构进行建模。这项工作是IBM Rational Rose和Rational XDE Web Modeling功能的基础。 Jim与人合著了两个版本的Building Web Applications with UML，第一个版本采用微软公司的ASP技术，后一个版本采用J2EE技术。 Jim的经验也来自于加入Rational之前的工作，那时他曾是独立的咨询师、Peace Corps的志愿者和大学讲师。他还是3个孩子的父亲。Jim从Widener大学获得了计算机和软件工程的学士学位和硕士学位。 Kelli Houston是IBM Rational的IT咨询专家。她是IBM内部方法的方法架构师，负责编写方法并集成IBM的方法。除了方法架构师的角色，Kelli还在IBM内部领导Rational Method Composer（RMC）特别兴趣小组（SIG）工作，为客户和IBM内部咨询师提供有效使用RMC方面的咨询和现场指导服务。 目錄： 第1篇 概　 念 第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 复杂系统的5个属性 1.3.1 层次结构 1.3.2 相对本原 1.3.3 分离关注 1.3.4 共同模式 1.3.5 稳定的中间形式 1.4 有组织和无组织的复杂性 1.4.1 复杂系统的规范形式 1.4.2 人在处理复杂性时的能力局限 1.5 从混沌到有序 1.5.1 分解的作用 1.5.2 抽象的作用 1.5.3 层次结构的作用 1.6 复杂系统的设计 1.6.1 作为科学和艺术的工程 1.6.2 设计的含义 1.7 小结 第2章 对象模型 2.1 对象模型的演进 2.1.1 程序设计语言的换代 2.1.2 第一代和第二代早期程序设计语言的拓扑结构 2.1.3 第二代后期和第三代早期程序设计语言的结构 2.1.4 第三代后期程序设计语言的结构 2.1.5 基于对象和面向对象的程序设计语言的结构 2.2 对象模型基础 2.2.1 面向对象编程 2.2.2 面向对象设计 2.2.3 面向对象分析 2.3 对象模型要素 2.3.1 抽象的意义 2.3.2 封装的意义 2.3.3 模块化的意义 2.3.4 层次结构的意义 2.3.5 类型的意义 2.3.6 并发的意义 2.3.7 持久的意义 2.4 应用对象模型 2.4.1 对象模型的好处 2.4.2 开放式问题 2.5 小结 第3章 类与对象 3.1 对象的本质 3.1.1 什么是对象，什么不是对象 3.1.2 状态 3.1.3 行为 3.1.4 标识符 3.2 对象之间的关系 3.2.1 链接 3.2.2 聚合 3.3 类的本质 3.3.1 什么是类，什么不是类 3.3.2 接口和实现 3.3.3 类的生命周期 3.4 类之间的关系 3.4.1 关联 3.4.2 继承 3.4.3 聚合 3.4.4 依赖关系 3.5 类与对象的互动 3.5.1 类与对象的关系 3.5.2 类与对象在分析和设计中的角色 3.6 创建高品质的类与对象 3.6.1 评判一种抽象的品质 3.6.2 选择操作 3.6.3 选择关系 3.6.4 选择实现 3.7 小结 第4章 分类 4.1 正确分类的重要性 4.1.1 分类的困难 4.1.2 分类的增量和迭代本质 4.2 确定类和对象 4.2.1 经典方法和现代方法 4.2.2 面向对象分析 4.3 关键抽象与机制 4.3.1 确定关键抽象 4.3.2 识别机制 4.4 小结 第2篇 方　 法 第5章 表示法 5.1 统一建模语言 5.1.1 简单历史回顾 5.1.2 模型与多重视图 5.1.3 图分类 5.1.4 在实践中使用图 5.1.5 概念模型、逻辑模型和物理模型 5.1.6 工具的角色 5.1.7 面向对象开发的产品 5.1.8 规模上的伸缩 5.1.9 UML的语法和语义 5.1.10 UML 2.0信息资源 5.2 包图 5.2.1 基本概念：包表示法 5.2.2 基本概念：元素的可见性 5.2.3 基本概念：依赖关系 5.2.4 基本概念：包图 5.2.5 高级概念：导入和访问 5.3 组件图 5.3.1 基本概念：组件表示法 5.3.2 基本概念：组件图 5.3.3 基本概念：组件接口 5.3.4 基本概念：组件实现 5.3.5 高级概念：组件的内部结构 5.4 部署图 5.4.1 基本概念：工件表示法 5.4.2 基本概念：节点表示法 5.4.3 基本概念：部署图 5.5 用例图 5.5.1 基本概念：执行者 5.5.2 基本概念：用例 5.5.3 基本概念：用例图 5.5.4 高级概念：“include”和“extend”关系 5.5.5 高级概念：泛化 5.6 活动图 5.6.1 基本概念：动作 5.6.2 基本概念：开始和停止 5.6.3 基本概念：判断节点和合并节点 5.6.4 基本概念：分区 5.6.5 高级概念：分叉、结合和并发 5.6.6 高级概念：对象流 5.6.7 高级概念：其他元素 5.7 类图 5.7.1 基本概念：类表示法 5.7.2 基本概念：类关系 5.7.3 高级概念：模板（参数化）类 5.7.4 高级概念：可见性 5.7.5 高级概念：关联端名称和限定符 5.7.6 高级概念：约束 5.7.7 高级概念：关联类和注解 5.8 序列图 5.8.1 基本概念：对象与交互 5.8.2 基本概念：生命线与消息 5.8.3 高级概念：销毁事件 5.8.4 高级概念：执行说明 5.8.5 高级概念：交互使用 5.8.6 高级概念：控制结构 5.9 交互概述图 5.9.1 基本概念：框 5.9.2 基本概念：控制流元素 5.9.3 基本概念：交互图元素 5.10 组合结构图 5.10.1 基本概念：组合结构的部分 5.10.2 基本概念：组合结构的部分与接口 5.10.3 基本概念：组合结构连接器 5.10.4 高级概念：协作 5.11 状态机图 5.11.1 基本概念：初始状态、最终状态和简单状态 5.11.2 基本概念：转换与事件 5.11.3 高级概念：状态活动--入口活动、执行活动和出口活动 5.11.4 高级概念：控制转换 5.11.5 高级概念：复合状态与嵌套状态 5.11.6 高级概念：并发与控制 5.11.7 高级概念：子状态机状态 5.11.8 高级概念：其他状态机图元素 5.12 时间图 5.12.1 基本概念：更多相同之处 5.12.2 基本概念：布局 5.12.3 基本概念：事件 5.12.4 基本概念：约束 5.12.5 高级概念：另一种表示形式 5.12.6 高级概念：事件与消息 5.13 对象图 5.13.1 基本概念：对象 5.13.2 基本概念：对象关系 5.13.3 高级概念：端点名称和限定符 5.14 通信图 5.14.1 基本概念：对象、链接和消息 5.14.2 基本概念：顺序表达式 5.14.3 高级概念：消息与同步 5.14.4 高级概念：迭代子句和警戒条件 5.15 小结 第6章 过程 6.1 首要原则 6.1.1 成功项目的特征 6.1.2 追求理性的开发过程 6.2 宏观过程：软件开发生命周期 6.2.1 概述 6.2.2 宏观过程的内容维：科目 6.2.3 宏观过程的时间维：里程碑和阶段 6.2.4 宏观过程的时间维：迭代 6.2.5 发行计划 6.3 微观过程：分析与设计过程 6.3.1 概述 6.3.2 抽象层次 6.3.3 活动 6.3.4 产品 6.3.5 微观过程与抽象层次 6.3.6 识别元素 6.3.7 确定元素间的协作 6.3.8 确定元素间的关系 6.3.9 详细确定元素的语义 6.4 小结 第7章 实战 7.1 管理和计划 7.1.1 风险管理 7.1.2 任务计划 7.1.3 开发复查 7.2 人员配备 7.2.1 资源配置 7.2.2 开发团队角色 7.3 发布版本管理 7.3.1 配置管理和版本控制 7.3.2 集成 7.3.3 测试 7.4 复用 7.4.1 复用的元素 7.4.2 建立复用制度 7.5 质量保证和测量指标 7.5.1 软件质量 7.5.2 面向对象测量指标 7.6 文档化 7.6.1 开发遗产 7.6.2 文档化的内容 7.7 工具 7.7.1 工具种类 7.7.2 组织上的意义 7.8 特殊主题 7.8.1 领域特定问题 7.8.2 采纳面向对象技术 7.9 面向对象开发的好处和风险 7.9.1 面向对象开发的好处 7.9.2 面向对象开发的风险 7.10 小结 第3篇 应　 用 第8章 系统架构--基于卫星的导航 8.1 初始 8.1.1 卫星导航系统的需求 8.1.2 定义问题的边界 8.1.3 确定任务用例 8.1.4 确定系统用例 8.2 细化 8.2.1 开发一个好的架构 8.2.2 定义架构开发活动 8.2.3 验证所建议的系统架构 8.2.4 分配非功能需求和确定接口 8.2.5 规定系统架构及其部署 8.2.6 分解系统架构 8.3 构造 8.4 交付之后 8.4.1 添加新的功能 8.4.2 改变目标硬件 第9章 控制系统--交通管理 9.1 初始 9.1.1 列车交通管理系统的需求 9.1.2 决定系统用例 9.2 细化 9.2.1 分析系统功能 9.2.2 定义TTMS架构 9.2.3 从系统工程到硬件和软件工程 9.2.4 关键抽象和机制 9.3 构造 9.3.1 消息传送 9.3.2 列车时刻表计划 9.3.3 显示信息 9.3.4 传感器数据采集 9.3.5 发布版本管理 9.3.6 系统架构 9.3.7 子系统规格说明 9.4 交付之后 第10章 人工智能--密码分析 10.1 初始 10.1.1 密码分析需求 10.1.2 定义问题的边界 10.1.3 黑板框架的架构 10.1.4 知识源的分析 10.2 细化 10.2.1 黑板对象 10.2.2 依赖和认定 10.3 构造 10.3.1 设计黑板对象 10.3.2 设计知识源 10.3.3 设计控制器 10.3.4 集成黑板框架 10.3.5 添加新的知识源 10.4 交付之后 10.4.1 系统增强 10.4.2 改变需求 第11章 数据采集--气象监测站 11.1 初始 11.1.1 气象监测站需求 11.1.2 定义问题的边界 11.1.3 场景 11.2 细化 11.2.1 气象监测系统用例 11.2.2 架构框架 11.3 构造 11.3.1 帧机制 11.3.2 发布计划 11.3.3 传感器机制 11.3.4 显示机制 11.3.5 用户界面机制 11.4 交付之后 第12章 Web应用--休假跟踪系统 12.1 初始 12.1.1 需求 12.1.2 用例模型 12.2 细化 12.2.1 部署视图 12.2.2 逻辑视图 12.2.3 进程视图 12.2.4 实现视图 12.2.5 用例视图 12.3 构造 12.3.1 用户体验模型 12.3.2 分析和设计模型 12.3.3 实体 12.3.4 控制器 12.3.5 Web页面和用户界面 12.4 交付和交付之后 附录A 面向对象编程语言 附录B 进一步阅读 注解 术语表 分类书目 內容試閱： 2.时间和空间语义 当确定存在某个操作，并定义了它的功能语言之后，必须决定它的时间语义和空间语义。这意味着我们必须决定它完成操作需要的时间以及存储空间。这样的决定通常是用最佳、平均和最差等术语来表达的，最差的情况规定了能够接受的上限。 前面也曾提到，当一个对象通过一个链接向另一个对象传递消息时，这两个对象必须以某种方式同步。在多控制线程的情况下，这意味着消息的传递比子程序调用要更复杂。在使用的大多数语言中，对象之间的同步不成问题，因为我们的程序只包含一个控制线程，这意味着所有的对象都是被依次访问的。这种情况下的消息传递很简单，因为它的语义基本上与简单的子程序调用相同。但是，在支持并发的语言中，我们必须关注更为复杂的消息传递形式，以避免两个控制线程以无限制的方式访问同一个对象，从而引发问题。前面曾提到，在多个控制线程下仍能保持语义的对象要么是守卫的，要么是同步的。 3.6.3选择关系 在类之间和对象之间选择关系与选择操作是有联系的。如果决定对象x向对象Y发送消息M，那么X必须能够直接或间接地访问Y；否则，就不能够在X的实现中命名操作M。所谓能够访问，指的是一种抽象能够看到另一种抽象，并引用它的外部视图中的资源。只有当它们的范围重叠，并且访问得到授权时（例如，类的私有部分只能被该类本身和它的友元访问），一种抽象才可以访问另一种抽象。因此，耦合是度量可访问程度的指标。 1.Demeter法则 在选择对象间的关系时，有一条有用的指导原则，称为Demeter法则。它指出，“类的方法不应该以任何方式依赖于任何类的结构，除了它自己类的当前（顶层）结构之外。而且，每个方法只能够对一个非常有限的类集的对象发出消息”[56]。应用这一法则的基本效果就是创建了一些松耦合的类，它们的实现秘密被封装了起来。这样的类是相当没有负担的，即为了理解一个类的意思，不需要理解许多其他类的细节。

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式	台灣用户　|　香港/海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.