UML对象、组件和框架——Catalysis方法
点击看大图基本信息
- 作者： （美）Desmond Francis D’Souza, Alan Cameron Wills
- 译者： 王慧 施平安 徐海
- 丛书名： 软件工程实践丛书
- 出版社：清华大学出版社
- ISBN：7302096406
- 上架时间：2004-11-9
- 出版日期：2004 年10月
- 开本：16开
- 页码：566
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > UML
编辑推荐
Catalysis的主要特征包括：
展示了如何建立明确的共享业务模型
精确地定义了基本的共享术语表
在抽象细节的早期指出了关键性需求和设计决策
使用UML作为分析员和设计人员之间的一种强健而明确的交流工具
通过聚合的可插式组件包建立自适应系统族
分配以界面为中心的组件设计和组合
使用精确的规范和设计技术，建立强健的组件
为设计、规范和构架应用并提取可重用框架
自1992年以来，经过很多客户的开发和使用，Catalysis已经影响了UML标准和Microsoft Repository中实现的Microsoft-TI组件定义模型。它具有简单的内核、任选的精度，以及支持基于Java，CORBA，COM+和RM-ODP的组件技术和标准的任务划分。
内容简介回到顶部↑
[a href="http://www.china-pub.com/computers/ebook20001-25000/21945/uml.rar" target="_blank"][font color="#ff6600"]本书前言和目录下载[/font][/a]
catalysis的主要特征包括：
●展示了如何建立明确的共享业务模型
●精确地定义了基本的共享术语表
●在抽象细节的早期指出了关键性需求和设计决策
●使用uml作为分析员和设计人员之间的一种强健而明确的交流工具
●通过聚合的可插式组件包建立自适应系统族
●分配以界面为中心的组件设计和组合
●使用精确的规范和设计技术，建立强健的组件
●为设计、规范和构架应用并提取可重用框架
自1992年以来，经过很多客户的开发和使用，catalysis已经影响了uml标准和microsoft repository中实现的microsoft-ti组件定义模型。它具有简单的内核、任选的精度，以及支持基于java，corba，com+和rm-odp的组件技术和标准的任务划分。
本书介绍了如何使用对象、框架和uml表示法来设计、建立和重用基于组件的软件。catalysis是一种新兴的、发展势头强劲的、基于uml的对象和组件开发方法。catalysis提供了uml表示法的明确含义和系统的使用方法，并开辟了通过修改和组合通用的和特定领域的建模框架来快速建立模型的途径。 本书可作为计算机专业的教材，也可作技术人员参考之用。
目录回到顶部↑
目录· ix ·目录
第ⅰ部分概述
第1章 catalysis指南 3
11 对象和动作 3
12 细化：不同规模的对象和动作 5
13 开发的层次 9
14 业务建模 9
15 作为模板的模型框架 11
16 软件的放大：系统上下文 12
17 需求规范模型 14
18 组件 16
19 分配职责 21
110 面向对象的设计 25
111 开发过程 26
112 3个构成部分与框架 27
113 建模的3个层次 29
114 3个原则 30
115 小结 32
第ⅱ部分对 象 建 模
第2章 静态模型：对象的属性和不变式 37
第ⅰ部分概述
第1章 catalysis指南 3
11 对象和动作 3
12 细化：不同规模的对象和动作 5
13 开发的层次 9
14 业务建模 9
15 作为模板的模型框架 11
16 软件的放大：系统上下文 12
17 需求规范模型 14
18 组件 16
19 分配职责 21
110 面向对象的设计 25
111 开发过程 26
112 3个构成部分与框架 27
113 建模的3个层次 29
114 3个原则 30
115 小结 32
第ⅱ部分对 象 建 模
第2章 静态模型：对象的属性和不变式 37
前言回到顶部↑
前言
企业及其运营环境总是处于不断变化之中，几乎所有的企业都在工作中使用软件，而且许多企业还把软件嵌入到它们的产品中。我们开发的软件系统必须满足这些业务需求，必须能够正常工作、由团队有效开发并能够灵活应变。
软件的第一需求：完整性
前两项需求并非什么新闻，自1968年以来，软件界就一直在研究有助于理解和满足业务需求的方法。一般性桌面软件总体上可以正常地工作，偶尔也许会出现bug，但这总比一直等到开发者开发出完美的软件以后再使用要好一些。另一方面，现在越来越多的软件被嵌入到各种各样的产品中，从汽车刹车、飞机和智能卡到烤面包机和补牙机，无处不在。有时，我们更应关注软件的完整性。学习本书所介绍的技术将有助于获得正确的需求，以及正确地实现它们。
软件的第二需求：团队开发
为了使开发任务能够在团队间进行分配，必须根据明确的依赖关系划分工作单元，构架约定和规则必须清楚，同时还必须明确无误地规范接口。组装组件的并不一定就是开发者，并且有可能在建立组件很长一段时间后才进行组装。必须能用系统的方法对实现、接口规范以及最终的用户需求之间的关系进行测试。
本书介绍的技术将有助于你构建具有以上这些属性的工作包和组件。
软件的第三需求：灵活性
为了保持竞争力，企业必须不断地推出新的产品和服务，因此，业务运营必须同步进行调整。例如，银行常常推出新业务，创造竞争优势以吸引客户。现在，它们通过电话和Internet提供的新服务比通过其支行提供的新服务更多。灵活的软件必须随业务的变化而变化，这样才能从根本上保持竞争力。
灵活性不仅意味着能够迅速做出变化，而且还意味着能够同时提供多种变体。银行可能全局上部署了相同的基本业务系统，但是它必须能够修改该系统，以适应许多地方性规则和惯例。软件产品供应商不会把相同的方案强加于所有的客户，他们也不会每次都从头开始开发一个方案。相反，软件开发者更喜欢有一个可配置的软件产品族。
本书介绍的技术将有助于你用系统的方法划分和解耦软件部件。
若要在短期内制作出大量软件产品，关键是能使一项软件开发服务于多种产品。重用并非剪切和粘贴代码：简单的剪切和粘贴操作会引起代码激增，以及无数次局部编辑，这样会使维护费用昂贵到难以承受的地步。
有效的策略是进行通用的设计，创建这些设计以在不同的软件产品中使用。这种可重用的资源不仅包括代码，而且还包括模型、设计模式、规范甚至项目计划等。
下面是建立一个可重用部件集合的两条重要规则。 可重用部件不能被使用它们的设计者所修改。你可能只想维护每个部件的一个版本，它必须有充分的适应性来满足许多需要，这可能通过定制来实现，而不是通过修改来实现。
各个可重用部件应当形成聚合的工具箱。与在汽车库中找到不同材料进行组装相比，建立像Lego那样具有个人喜好拼装结构的玩具要更加简单快捷。虽然在汽车库中找到的材料也可能是部件，但它们并非是按整体搭配的思想设计的。那些能够用来配置但不能修改的可重用部件就是所谓的组件，它们的范围从没有程序源的编译代码到模型和设计的部件。
组件工具箱产品族
多年来硬件设计者们一直致力于研究标准化组件。他们不是设计一辆新的汽车，而是设计一系列汽车。通过组合基本的组件集以形成不同的配置，就可以设计出各种各样的汽车。只有极少数组件是专门为某个产品而制造的。一些组件是为了现有的产品系列而制造的，另一些组件是为了与以往的产品系列共用而制造的，还有一些组件是由第三方制造的，可用于其他品牌的汽车。
对于软件也可以这样做，但是我们不仅需要设计它们的方法，而且还需要创建和组装它们的技术。
组件技术
对于一个通用的组件，我们必须提供方法让客户的设计者能够根据他们的需要自定义组件。这些技术包括调用函数时传递的参数、组件读取的表、组件上的配置或者部署选项、插入点——组件中可以插入其他各种组件的位置，以及像工作流系统那样的框架，可以将各种组件插入其中。
企业及其运营环境总是处于不断变化之中，几乎所有的企业都在工作中使用软件，而且许多企业还把软件嵌入到它们的产品中。我们开发的软件系统必须满足这些业务需求，必须能够正常工作、由团队有效开发并能够灵活应变。
软件的第一需求：完整性
前两项需求并非什么新闻，自1968年以来，软件界就一直在研究有助于理解和满足业务需求的方法。一般性桌面软件总体上可以正常地工作，偶尔也许会出现bug，但这总比一直等到开发者开发出完美的软件以后再使用要好一些。另一方面，现在越来越多的软件被嵌入到各种各样的产品中，从汽车刹车、飞机和智能卡到烤面包机和补牙机，无处不在。有时，我们更应关注软件的完整性。学习本书所介绍的技术将有助于获得正确的需求，以及正确地实现它们。
软件的第二需求：团队开发
为了使开发任务能够在团队间进行分配，必须根据明确的依赖关系划分工作单元，构架约定和规则必须清楚，同时还必须明确无误地规范接口。组装组件的并不一定就是开发者，并且有可能在建立组件很长一段时间后才进行组装。必须能用系统的方法对实现、接口规范以及最终的用户需求之间的关系进行测试。
本书介绍的技术将有助于你构建具有以上这些属性的工作包和组件。
软件的第三需求：灵活性
为了保持竞争力，企业必须不断地推出新的产品和服务，因此，业务运营必须同步进行调整。例如，银行常常推出新业务，创造竞争优势以吸引客户。现在，它们通过电话和Internet提供的新服务比通过其支行提供的新服务更多。灵活的软件必须随业务的变化而变化，这样才能从根本上保持竞争力。
灵活性不仅意味着能够迅速做出变化，而且还意味着能够同时提供多种变体。银行可能全局上部署了相同的基本业务系统，但是它必须能够修改该系统，以适应许多地方性规则和惯例。软件产品供应商不会把相同的方案强加于所有的客户，他们也不会每次都从头开始开发一个方案。相反，软件开发者更喜欢有一个可配置的软件产品族。
本书介绍的技术将有助于你用系统的方法划分和解耦软件部件。
若要在短期内制作出大量软件产品，关键是能使一项软件开发服务于多种产品。重用并非剪切和粘贴代码：简单的剪切和粘贴操作会引起代码激增，以及无数次局部编辑，这样会使维护费用昂贵到难以承受的地步。
有效的策略是进行通用的设计，创建这些设计以在不同的软件产品中使用。这种可重用的资源不仅包括代码，而且还包括模型、设计模式、规范甚至项目计划等。
下面是建立一个可重用部件集合的两条重要规则。 可重用部件不能被使用它们的设计者所修改。你可能只想维护每个部件的一个版本，它必须有充分的适应性来满足许多需要，这可能通过定制来实现，而不是通过修改来实现。
各个可重用部件应当形成聚合的工具箱。与在汽车库中找到不同材料进行组装相比，建立像Lego那样具有个人喜好拼装结构的玩具要更加简单快捷。虽然在汽车库中找到的材料也可能是部件，但它们并非是按整体搭配的思想设计的。那些能够用来配置但不能修改的可重用部件就是所谓的组件，它们的范围从没有程序源的编译代码到模型和设计的部件。
组件工具箱产品族
多年来硬件设计者们一直致力于研究标准化组件。他们不是设计一辆新的汽车，而是设计一系列汽车。通过组合基本的组件集以形成不同的配置，就可以设计出各种各样的汽车。只有极少数组件是专门为某个产品而制造的。一些组件是为了现有的产品系列而制造的，另一些组件是为了与以往的产品系列共用而制造的，还有一些组件是由第三方制造的，可用于其他品牌的汽车。
对于软件也可以这样做，但是我们不仅需要设计它们的方法，而且还需要创建和组装它们的技术。
组件技术
对于一个通用的组件，我们必须提供方法让客户的设计者能够根据他们的需要自定义组件。这些技术包括调用函数时传递的参数、组件读取的表、组件上的配置或者部署选项、插入点——组件中可以插入其他各种组件的位置，以及像工作流系统那样的框架，可以将各种组件插入其中。
)
加载中...
