使用催化法的组件式开发
催化法是ICON Computing公司的Desmond D'Souza和Trireme公司的Alan Cameron Wills提出来的方法论。D'Souza作为UML组织的一员参加了OMG召开的UML提案，同时也作为UML的贡献者参与着各种活动。催化法的特征是采用面向组件和构架的方法，即使是大企业水平的系统也能应对自如。此外，如果系统组装是分散对象技术的CORBA或DCOM，就能准确无误地处理从设计到组装的全过程。当然，由于采用了UML表记法，掌握了UML知识就能准确理解催化法中出现的图表。
所谓组件
一般看到组件这个词就会想到微软的DCOM(Distributed Compornent Object Model)或OMG的CORBA(Common Object Request Broker Architecture)。这些不是设计而是组装技术。在这将简单介绍下何为组件。组件就是指集中多个对象（有时是一个对象）或者是指应用等范围大的东西。目的就是要在使用的应用中添加一些类似电脑硬件的插头＆播放器等功能。为了插入插头＆播放器等组件就必须有接口。在组件的设计开发中这点非常重要。
例如图1，“发动机”这个组件是通过接口和其他的组件联系在一起的。
发动机向仪表发送速度的数据实际上并没有那么简单，可能要分成多个命令。将这些集中起来就成了接口。另外，有时候可能存在类似发动机这样的多个接口。再举一个组件的例子。看一下“编辑”这个组件，其中包含作为内部数据的“word”等对象。
将该“编辑”插入到其他应用里的时候，通过这个接口将操作引出。如果作为组件开发的话，就能插入到绘图软件、Web浏览器等所有应用中去。另外假如从应用方面来看的话，也能够从多个编辑组件中进行选择。
那在这里来看一下使用了组件的组装环境，即分散对象。DCOM或者CORBA都是分散对象的代表。其他还有Java的RMI(Remote Method Invocation)和HORB等。在面向对象的应用开发中，引出对象时对象是动态或者静态的链接到应用上的。如果是在一台机器上完成的话没问题，但是当系统是在类似分散系统这样的网上多个机器上构成的时候，就需要有很复杂的结构。因为需要对网上对象进行远程访问。
所谓接口
对于图1这个例子，现在就来看一下Java程序上的接口。“仪表”类能如下所示进行组装。
interface SpeedMeter
{
int start();
int send(int value)
int stop();
}
class ConcreteMeter implements SpeedMeter
{
// 组装编码
}
通过这样的方式对接口SpeedMeter进行操作start()、send(int value)、stop()的定义。然后对ConcreteMeter类实现implementsSpeedMeter。
此外，再用微软的DCOM结构进行简单的确认。如图3所示，应用包含了对象，而且这个对象作为外部来的访问窗口正在打开接口。例如，想要用“word”来获得excel表格的时候，只要从“word”中引出excel的接口就可以了。
UML组件表记法
那接下来就来看下有关UML标记法。在UML中，有表示组件的组装图。在这我们试一下其中的组件图。图4表示“数据库”组件中包含一个“表搜索”的接口，而这是“CORBA服务”引出的。
到这里为止，说明了有关组装的情况，但是组件技术不仅仅是组装。另外还有分析设计阶段的组件，即业务组件。以前一直称为业务对象，最近都被称为业务组件，而且越来越重要。因为对象数目增加的话单位对象的管理就变得困难，所以将单位组件小组化进行管理比较好。
图5中的“销售额”、“算账”等功能以前都是作为子系统处理的，但是从设计阶段开始就将这些当做组件的话，就可以进行插头＆播放器的设计了。这些组件中包括面向对象的分析设计模型，通过从目标系统中获得这些组件类就能实现模型的再利用了。
所谓框架
接下来也简单介绍下对象技术中的重要因素-框架。框架就是指当应用的结构已经完成时，通过修改部分内容能够生成新的应用。接下来看一下框架的例子——Java小程序。 Java小程序包含能够运行的框架。其中包含“init()”、“run()”、“start()”、“stop()”这些方法。编程人员仅仅通过修改这些方法就能简单地生成新的应用。这是组装层次上的例子，设计层次上的框架则被称为“模型框架”。
所谓催化法
催化法就是开发组件式应用的手法。使用了扩展了UML的表记法。提倡者是Alan Wills和Desmond D'Souza这两个人。这个手法最大的特点就是组件的表示方法。如图6所示，在最下面的线下写上接口的操作，然后进行组件内部的建模，与外部有联系的就向组件框连一条线。
催化法包括“合作”、“类型”、“修正”、“框架”等概念。在合作中整理对象小组的行为，在类型中决定对对象外部的行为，在修正中将行为等抽象化。然后，生成可插入式的框架。催化法中将对象的抽象水平称为类型。类型之间的功能称为行为。这相当于UML中的用例。
看一下关于行为的例子。例如，“宠物主人”和“狗”之间存在“喂食”这个行为。图9表示的就是该关系。这样类型之间的关系就称为“合作”。
类型就是指对象或者是小组化了的对象的抽象水平。这与以数据为中心的设计手法中被称为实体的及类很相似。类型的表记法就是将UML的类图扩展开来。如图9所示，上面是类型名，中间是属性或者模型图，下面是有关类型的操作。操作就是由类型外部生成的行为。
催化法具有修正这样抽象化的层面。因此能明确表示出从具体到抽象的制图过程。在图10的例子中，对“申请”“注册”、“更改”、“删除”这些行为进行修正。
用催化法建模
催化法中的开发过程，如图11所示分为三个建模过程。第一个是明确业务程序等流程的“范围业务”。第二个是将系统化的对象-事件缩小，然后对与之相关联的因素进行分析的“组件式样”。第三个则是分析设计事件内部的“内部设计”。
范围/业务
在这里来看一下课堂研究小组的管理系统。课堂研究小组的听课者申请参加课堂研究小组。用用例图表示则如图12所示。
听课者申请参加课堂研究小组。在UML中，听课者这样的系统外部因素作为参与者，用人形的符号标记。此外，将“申请课堂研究小组”这个功能称为“用例”，用椭圆形标记。在所有业务中应用这个，就能获得如图13所示的业务程序整体的表示。
组件式样
在范围/业务建模中，整理了整体的概要之后就能决定系统化的范围了。例如，如图14所示决定系统的范围。在这里，由于“顾客管理”是作为其他系统的，所以表示为参与者。
此外，将图14改写成UML的用例图的话，就会变成如图15所示。
因此可以确定系统的事件。接下来将系统本身作为组件，密切关注该系统的输入/输出。这就相当于用例图中的通信。为了准确生成则使用顺序图。于是，生成了脚本这样具体的事件，并且将每个脚本都制成顺序图。在图16中，导入了“申请（）”这个操作，然后制成了图17中的事件。
内部设计
在内部设计中，分析上个阶段导入进来的事件内容，然后进行详细描述。这是用制约(Constraint)表示的。描述这个制约的语言是OCL(Object Constraint Language)。OCL是UML的一部分，原本是美国IBM公司作为Insurance division中业务建模用的语言开发出来的。对操作制约的句法如图18所示。
Pre是指前提条件(Pre-condition)，是触发该操作的条件。Post是指“后续条件”(Post-condition)，是触发了该操作的结果。此外，因为OCL是建模语言，所以不能详细描述操作的逻辑。有关逻辑的描述，行为语言已在OMG中提出来。(OCL式样书在OMG(Object Management Group)中能取得。)
此外，也能如图20所示用计算式表示。@pre表示执行该操作前。
接下来是数据结构分析。这与以数据为中心的设计中熟悉的E-R图类似。但是，在催化法中不是“实体”而是“类型”。此外，“类”则是用来组装该“类型”的。完成的类型模型如图21所示。
进一步将类型的动态部分-“状态”模型化。这里使用UML的状态图。如图22所示，状态是对每个类型单独制作的。图23表示状态图的例子。
组件设计
由于类型模型是抽象化了的模型，因此不包含组装上的事情。在组件设计阶段一开始就考虑到了组装。在这里如图24所示，将图21的各个类型作为DB组件进行设计。将“课堂研究小组”类型和“课堂研究小组申请”类型画成“课堂研究小组DB”将“请求”画成“请求DB”。这些组件都具有相当于“add()”、“update()”等DB操作的操作。通常，因为设计组件的结果，都必须返回内部设计阶段对类型模型进行修改。
系统架构的决定
组件设计结束之后，接下来就决定系统架构。像之前设计的一样，课堂研究小组管理系统中有“课堂研究小组DB”和“请求DB”这两个组件。如图25所示将这些“课堂研究小组DB”、“请求DB”作为独立的应用。这些最终都会作为CORBA或者DCOM、EJB等应用服务器进行组装。
模式与建模构架
接下来就催化法的模型构架进行简单说明。类型模型完成的时候，有时能在建模时发现模式。说到软件中的模式，很容易想到程序层面的设计模式和分析层面的分析模式，在催化法中通过应用模式也能进行高效率的建模。
在催化法中，将通用的分析模型的模式称为“模型”。此外，将运用模型使其模型化的称为“模型框架”。在这里介绍一下催化法中的“Resource Allocation”模型(图26)。如图27所示，将该模型应用到与系统工程师相关的模型中。可以将<Product>换成Job Type，将<Feature>换成Skill，将<Usage>换成Job，还有将<Resource>换成System Engineer。
该Resource Allocation模型也能适用课堂研究小组管理系统。应用的结果如图28所示。
再添加“讲师”。(图29)
图29的模型与图28的模型相比，再一次使用了模式。因此通过将模式应用到模型中，才有可能作为模型框架进行再利用。此外，在设计、组装阶段，“Resource Allocation”作为框架已经完成了，因为具有很多应用业绩，通过再利用能够大幅提高生产效率。
总结
关于催化法进行了很简单的说明，大家认为怎么样啊。使用系统化的建模方法提高开发的生产效率，关于这点，希望能获得您的一些宝贵意见。