[原创]基础知识第四 讲:怎样对岗位进行UML业务建模

用面向对象的概念来说,岗位是业务人员的类型定义,在UML业务建模中,岗位会建模为业务系统内部的工作者(work)的定义.即:具体的业务人员是业务对象(Object),而岗位则是这种对象的"类"(Class);

在面向对象中,定义一个类,需要定义这个类的很多信息.用知识管理者的说法就是要画一张岗位的知识地图.面向对象的知识表达,只是提供了一种特定的坐标系来画这个地图.

首先,我们来看看,面向对象方法如何定义"类".

最基本的是属性和方法.

类的属性规定这种类型的对象所具备的性状特征(如玫瑰花的花瓣颜色是其本身的性状特征),以及与外部对象的关联投射在这种类型上的特征,比如:"门牌号"作为"住所"类型的一个特征,是住所和街道的关系投射到住所身上的特征.

类的方法规定这种类型的对象所具备的行为能力特征(如玫瑰花能开放,能用来表达爱情等),正是由于类同时结合了性状特征行为能力特征,而且其行为能力特征和性状特征存在相互的依赖性,使得"类"成为了连接静态结构和动态行为的枢纽.这是比结构化方法的,要么只能把实体定义为静态数据结构的结点,要么只能把实体定义为联系输入和输出的处理结点的模式是一大突破.

现实中的业务人员,更象一个对象,是信息和处理的有机结合,而不是割裂出来的要么是一个信息体,要么是一个处理模块.这就是面向对象知识表达方法和结构化方法表达的不同之处.

有了"属性"和"方法"这两个基本的维度,把岗位作为类来定义,不仅仅可以表达岗位是组织结构中的一个静态结构的实体元素,而且还是能在组织业务流程的运作中使用自身能力,调动友类能力的动态过程元素.

所以,从UML业务建模的观点看,岗位知识地图的基本参照系如下:

1.岗位上的人员应该具备怎样的属性(性别,年龄,学历.....).

2.岗位上的人员应该具备怎样的行为能力(方法)(工作能力1,工作能力2,工作能力3....);

从一个面向对象的系统来说,得到类的定义是远远不够的,最重要的是,要说明各种类的对象通过建立怎样的协作关系,来对系统外提出的服务请求做出响应.这就是面向对象的程序部分.

在面向对象的业务模型中,也需要建立响应的面向对象的业务程序,只有在业务程序中,我们才能检验设计的业务对象的所有属性和能力是否都能用上,在什么时候用上的.这些信息,应该会出现在组织的业务流程的定义中.

从对象的角度来看,和业务流程相关的信息除了对象的方法定义之外,还可以有:

1.对象的事件接口(消息接口):对象会响应哪些消息?对于岗位来说,就是岗位职责中定义的必须对哪些种类的业务事件做出反应和处理.

2.对象的状态转移关系:对象在生命周期中会处于多少种不同的状态下,对象从一种状态迁移到另一种状态下的条件是什么?对应岗位,就是对岗位人员的绩效评估和等级晋升的标准.

3.对象所实现的接口类型:这里的"接口"有特殊的含义,一个接口类型定义一组相关的处理能力,这组处理能力有固定的名称和外部约束条件,但可以由多种类型用不同的内部处理机制来实现.对于岗位来说,接口就是岗位员工可以根据需要兼任的其他岗位或所有岗位共同的部分职能的集合,这对应中小企业"一专多能"的岗位设置是非常适应的.

推荐到鲜果： 查阅更多相关主题的帖子: UML 业务模型