使用催化法的组件式开发

催化法是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,“发动机”这个组件是通过接口和其他的组件联系在一起的。

图1 发动机组件与其他组件联系起来的状态

发动机向仪表发送速度的数据实际上并没有那么简单,可能要分成多个命令。将这些集中起来就成了接口。另外,有时候可能存在类似发动机这样的多个接口。再举一个组件的例子。看一下“编辑”这个组件,其中包含作为内部数据的“word”等对象。

图2 “编辑”组件的例子

将该“编辑”插入到其他应用里的时候,通过这个接口将操作引出。如果作为组件开发的话,就能插入到绘图软件、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的接口就可以了。

图3 DCOM结构

UML组件表记法

那接下来就来看下有关UML标记法。在UML中,有表示组件的组装图。在这我们试一下其中的组件图。图4表示“数据库”组件中包含一个“表搜索”的接口,而这是“CORBA服务”引出的。

图4 组件标记法

到这里为止,说明了有关组装的情况,但是组件技术不仅仅是组装。另外还有分析设计阶段的组件,即业务组件。以前一直称为业务对象,最近都被称为业务组件,而且越来越重要。因为对象数目增加的话单位对象的管理就变得困难,所以将单位组件小组化进行管理比较好。

图5中的“销售额”、“算账”等功能以前都是作为子系统处理的,但是从设计阶段开始就将这些当做组件的话,就可以进行插头&播放器的设计了。这些组件中包括面向对象的分析设计模型,通过从目标系统中获得这些组件类就能实现模型的再利用了。

图5 业务组件(包图)的例子

所谓框架

接下来也简单介绍下对象技术中的重要因素-框架。框架就是指当应用的结构已经完成时,通过修改部分内容能够生成新的应用。接下来看一下框架的例子——Java小程序。 Java小程序包含能够运行的框架。其中包含“init()”、“run()”、“start()”、“stop()”这些方法。编程人员仅仅通过修改这些方法就能简单地生成新的应用。这是组装层次上的例子,设计层次上的框架则被称为“模型框架”。

所谓催化法

催化法就是开发组件式应用的手法。使用了扩展了UML的表记法。提倡者是Alan Wills和Desmond D'Souza这两个人。这个手法最大的特点就是组件的表示方法。如图6所示,在最下面的线下写上接口的操作,然后进行组件内部的建模,与外部有联系的就向组件框连一条线。

图6 催化法中的组件表示

催化法包括“合作”、“类型”、“修正”、“框架”等概念。在合作中整理对象小组的行为,在类型中决定对对象外部的行为,在修正中将行为等抽象化。然后,生成可插入式的框架。催化法中将对象的抽象水平称为类型。类型之间的功能称为行为。这相当于UML中的用例。

图7 催化法的构成概念

看一下关于行为的例子。例如,“宠物主人”和“狗”之间存在“喂食”这个行为。图9表示的就是该关系。这样类型之间的关系就称为“合作”。

图8 合作

类型就是指对象或者是小组化了的对象的抽象水平。这与以数据为中心的设计手法中被称为实体的及类很相似。类型的表记法就是将UML的类图扩展开来。如图9所示,上面是类型名,中间是属性或者模型图,下面是有关类型的操作。操作就是由类型外部生成的行为。

图9 类型

催化法具有修正这样抽象化的层面。因此能明确表示出从具体到抽象的制图过程。在图10的例子中,对“申请”“注册”、“更改”、“删除”这些行为进行修正。

图10 修正的例子

用催化法建模

催化法中的开发过程,如图11所示分为三个建模过程。第一个是明确业务程序等流程的“范围业务”。第二个是将系统化的对象-事件缩小,然后对与之相关联的因素进行分析的“组件式样”。第三个则是分析设计事件内部的“内部设计”。

图11 催化法的建模程序

范围/业务

在这里来看一下课堂研究小组的管理系统。课堂研究小组的听课者申请参加课堂研究小组。用用例图表示则如图12所示。

图12 课堂研究小组管理系统的用例图

听课者申请参加课堂研究小组。在UML中,听课者这样的系统外部因素作为参与者,用人形的符号标记。此外,将“申请课堂研究小组”这个功能称为“用例”,用椭圆形标记。在所有业务中应用这个,就能获得如图13所示的业务程序整体的表示。

图13 课堂研究小组管理系统整体的用例图

组件式样

在范围/业务建模中,整理了整体的概要之后就能决定系统化的范围了。例如,如图14所示决定系统的范围。在这里,由于“顾客管理”是作为其他系统的,所以表示为参与者。

图14 系统范围的决定

此外,将图14改写成UML的用例图的话,就会变成如图15所示。

图15 系统范围的决定(用例图)

因此可以确定系统的事件。接下来将系统本身作为组件,密切关注该系统的输入/输出。这就相当于用例图中的通信。为了准确生成则使用顺序图。于是,生成了脚本这样具体的事件,并且将每个脚本都制成顺序图。在图16中,导入了“申请()”这个操作,然后制成了图17中的事件。

图16 脚本的顺序图
图17 脚本的事件

内部设计

在内部设计中,分析上个阶段导入进来的事件内容,然后进行详细描述。这是用制约(Constraint)表示的。描述这个制约的语言是OCL(Object Constraint Language)。OCL是UML的一部分,原本是美国IBM公司作为Insurance division中业务建模用的语言开发出来的。对操作制约的句法如图18所示。

图18 制约的句法

Pre是指前提条件(Pre-condition),是触发该操作的条件。Post是指“后续条件”(Post-condition),是触发了该操作的结果。此外,因为OCL是建模语言,所以不能详细描述操作的逻辑。有关逻辑的描述,行为语言已在OMG中提出来。(OCL式样书在OMG(Object Management Group)中能取得。)

图19 OCL的例子

此外,也能如图20所示用计算式表示。@pre表示执行该操作前。

图20 用计算式表示OCL的例子

接下来是数据结构分析。这与以数据为中心的设计中熟悉的E-R图类似。但是,在催化法中不是“实体”而是“类型”。此外,“类”则是用来组装该“类型”的。完成的类型模型如图21所示。

图21 课堂研究小组管理系统的类型模型

进一步将类型的动态部分-“状态”模型化。这里使用UML的状态图。如图22所示,状态是对每个类型单独制作的。图23表示状态图的例子。

图22 对每个类型制作状态图
图23 表示状态图的例子

组件设计

由于类型模型是抽象化了的模型,因此不包含组装上的事情。在组件设计阶段一开始就考虑到了组装。在这里如图24所示,将图21的各个类型作为DB组件进行设计。将“课堂研究小组”类型和“课堂研究小组申请”类型画成“课堂研究小组DB”将“请求”画成“请求DB”。这些组件都具有相当于“add()”、“update()”等DB操作的操作。通常,因为设计组件的结果,都必须返回内部设计阶段对类型模型进行修改。

图24 组件设计

系统架构的决定

组件设计结束之后,接下来就决定系统架构。像之前设计的一样,课堂研究小组管理系统中有“课堂研究小组DB”和“请求DB”这两个组件。如图25所示将这些“课堂研究小组DB”、“请求DB”作为独立的应用。这些最终都会作为CORBA或者DCOM、EJB等应用服务器进行组装。

图25 作为组件的应用进行组装

模式与建模构架

接下来就催化法的模型构架进行简单说明。类型模型完成的时候,有时能在建模时发现模式。说到软件中的模式,很容易想到程序层面的设计模式和分析层面的分析模式,在催化法中通过应用模式也能进行高效率的建模。

在催化法中,将通用的分析模型的模式称为“模型”。此外,将运用模型使其模型化的称为“模型框架”。在这里介绍一下催化法中的“Resource Allocation”模型(图26)。如图27所示,将该模型应用到与系统工程师相关的模型中。可以将<Product>换成Job Type,将<Feature>换成Skill,将<Usage>换成Job,还有将<Resource>换成System Engineer

图26 Resource Allocation模型
图27 应用Resource Allocation模型的框架举例

该Resource Allocation模型也能适用课堂研究小组管理系统。应用的结果如图28所示。

图28 在课堂研究小组管理系统中应用Resource Allocation模型

再添加“讲师”。(图29)

图29 添加了讲师的模型

图29的模型与图28的模型相比,再一次使用了模式。因此通过将模式应用到模型中,才有可能作为模型框架进行再利用。此外,在设计、组装阶段,“Resource Allocation”作为框架已经完成了,因为具有很多应用业绩,通过再利用能够大幅提高生产效率。

总结

关于催化法进行了很简单的说明,大家认为怎么样啊。使用系统化的建模方法提高开发的生产效率,关于这点,希望能获得您的一些宝贵意见。