44
I
nternet  Technology
互联网+
技术
一、引言
UML(Unified Modeling Language)是业内统一的建模语言，有着丰富的基于面向对象概念的模型元素及图形表示元素，还具有强大的描述能力以及广泛的描述范围，其为不同领域的用户提供统一的交流标准。基于UML 的工作流建模可以运用用户例图捕获用户需求，使用活动图阐述业务逻辑，使用状态图描述工作流逻辑中实体状态的变化。基于UML 的工作流建模具有如下优点[1]：
1.具有定义明确的通用的语义及表示法，便于理解与沟通。工作流管理系统往往是大型的、结构复杂的，
需要众多人员协同工作，因此参与者之间能否对彼此在各阶段设计与开发的成果进行有效的无歧义的交流尤为重要，采用UML 建模便能很好地解决这个问题。
2.具有种类繁多的概念与模型，对模型的描述更加全面。
3.对用户友好。然而，用UML 用例图、活动图、状态图对工作流建模，无法直观地区分业务逻辑与工作流逻辑，限制了对外部事件如事件的表达，并且不支持模型验证与优化。在基于UML 的建模过程中，常使用活动图对流程的动态行为进行建模。它支持对信息流的描述，体现活动时序，支持对选择路由与并发路由的描述。与基于Petri 网的建模方法相比，二者各有所长。
二、UML 计算机软件系统设计方法（一）UML 工厂建模设计
UML 工厂方法模式是一种常用的创建型设计模式。该模式将各对象的共同属性抽取出来，构造一个抽象类，将各实例的特有属性抽取出来生成不同的子类，子类继承共同属性对应的抽象类。它为用户提供了创建对象的接口[2]。工厂模式符合并体现了面向对象中封装、分派等思想。常见的工厂模式有：简单工厂模式、工厂方法模式及抽象工厂模式三种。
工厂方法模式的优点：基于UML 的计算机软件开发方法研究
摘要：在基于构件的计算机软件系统管理软件开发中，利用UML 图的良好沟通特性，促进用户、设计人
员、分析人员、编码及测试人员对所开发系统的统一认识，将UML 建模贯穿整个过程。在构件开发的过程中用UML 把对单例模型的描述统一起来，才能达到构件的最大程度重用的目的。但目前还没有把两者的优势充分结合起来，计算机软件系统服务模型接口设计在项目开发中进行了尝试。关键词：UML；构件；计算机软件
1.隐藏实例化细节
在工厂方法模式中，客户不需要关心创建具体产品类的过程与细节（所有的实例化细节都将被隐藏），甚至无需知道具体产品类的类名，只要获取需对应的工厂方法，就能创建所需要的具体类（即使用户对该具体类一无所知）。
2.角的多态性
在工厂方法模式中，无论是产品类还是工厂方法都具有多态性，这也是该模式又称之为多态工厂模式的原因。由于多态性，具体产品类的生成细节完好的封装在具体的生成方法内。使用户可以自主确定创建哪一种产品对象，然而如何创建这个对象的细节，则完全封装在具体工厂内部。
3.符合“开闭原则”
当应用系统引入新产品时，工厂方法模式可以在不影响现有的具体工厂与具体产品类，也不修改现有的
客户端代码的情况下实现新功能的添加。只要添加一个新的具体方法和特定的产品类，添加新的用户界面（如果需要的话），就能实现系统的功能扩展。对修改关闭，对扩展开放，完全符合“开闭原则”。
工厂模式的缺点：1.增加了系统复杂度
对于每个产品，不仅要提供一个具体的产品类，还要提供与之对应的具体工厂类，系统中类的个数将成对增加，增加了系统的复杂性，会给系统带来一些额外的开销。
2.增加了系统的抽象性和理解难度。（二）UML 软件工作流系统对象设计
工作流的业务过程中存在各种业务对象，即实体。以CRCC 标准运维平台为例，平台中有立项申请、标准制定、标准修订、标准废止、添加分类、数据元管理等多个流程。每个流程中都有随着工作流一起流动的对象实体[3]。不同类型的实体之间既有共性，如需求申请号、流程ID 等信息，又有各自特定属性。利用工厂方法模式，首先，将不同类型的实体共性抽
I nternet  Technology
互联网+技术
取出来作为一个抽象的Product；然后，再构建对应的ConcreteProduct 实现类（如立项申请实体、标准
制定实体等），各实现类继承上述Product 抽象类，并实现Product 接口，或者重写Product 中定义的虚函数；再者，构建一个抽象工厂类Factory，声明创建对象的工厂方法；最后，构建对应的产品工厂（如立项申请实体生产工厂、标准制定实体生产工厂等），即ConcreteFactory 类，各具体工厂返回对应的具体产品实体。
采用这种方案，由核心工厂类负责定义创建对象的公共接口，具体工厂（如立项申请工厂）继承核心工厂类，实现CreateEntity 方法，用于创建具体类。具体类是否实例化、实例化哪个类的判断与操作中延迟到子类完成。并且，当新的产品类被增加时，只需要新增一个产品类和一个工厂类，无需对其他子类进行修改。这意味着当一个新的业务流程被引进时，如在实现了立项申请功能的基础上增加标准制定的业务流程，只需要增加一个标准制定的流程实体类和一个对应的工厂类（其中标准制定实体继承流程实体类，标准制定工厂继承核心工厂类并实现CreateEntity 方法），无需对立项申请模块进行任何修改，就能实现系统功能的扩展，符合面向对象的开闭原则。此外，一个大型项目的实施需要多名开发人员协同工作，采用工厂方法模式，可以使功能模块之间相对独立，有效地避免了代码版本冲突的问题。
（三）UML软件系统过程设计
过程定义(Process Definition): 过程定义即过程建模。本功能模块通过对Workflow（工作流模板）和Activity（活动节点）对象的操作，成功实现了过程定义、过程管理的功能[4]。
过程定义——新建一个业务过程时：
首先，创建一个新的Workflow 对象，定义业务过程名称、标识符等信息，每个Workflow 实例相当于一个业务过程实例(Process)的模板。
其次，为新业务过程创建并添加新的Activity，Activity 即是工作流程中的一个逻辑节点。在Activity 中，定义该节点是否为起始节点或者终止节点；定义该节点的当前状态、顺序操作状态、驳回状态，以及节点的上级节点与下级节点；并定义在当前节点上的流程操作(e.g.：顺序操作、驳回操作，或者并行操作等)Process 和Task 分别作为Workflow 与Activity 的实例。当一个实例流程被发起时，系统根据对应的流程模板，创建相应的Process 和Task 实例。过程编辑——修改一个已有的业务流程时，只需要更改相对应的流程对象与它的逻辑节点对象的相关信息即可。除非要为流程设定默认任务处理角，否则任务分配不会在过程定义中进行。
三、UML软件系统模型设计
（一）单例模型设计
软件设计中，单例模式是确保类只生成一个实例对象的一种模式。这是一种十分有用的设计模式，如果在系统中只能有一个对象出现时，单例模式可以很好地发挥作用。这种模式对于某些系统来说，效率是
很高的，因为限制了对象生成的个数，系统的开销大大降低了。一些人认为这是一种不符合设计模式思想的设计方法，认为这种用法完全没必要，它只是增加了一些没必要了限制，完全可以使用全局变量来代替[5]。然而经过多年实践的考验，这种模式的确给编程带来了极大的方便，在Java 的JDK 实现中也多处使用了单例模式来实现，比如：Calendar类，java.lang. Runtime 类等。
单例模式的实现必须满足，只生成一个实例并且是可以全局访问的。这就需要一种机制来保证其他的类不能创建该类的实例，其访问方式也不能通过创建对象的方式来访问。对于这两点限制，可以通过创建一个静态实例的方法和限制构造方法为私有的方式来实现。因为每一个类中静态变量在内存中的实例只有一个，另外构造方法为私有的，并且自己构造了自己的实例，其他的类没有权限调用其构造方法创建实例，这样就实现了单例模式。
单例和类中静态实例成员经常容易被人们混淆，下面阐述一下这两者的区别。类中的静态实例成员，是类的静态成员，使用static 修饰符修饰，在类对象实例化时，静态成员被初始化，一个类实例只对应一个静态成员。多个类实例会对应多个不同的静态成员。而单例只会有一个实例，其中的静态成员也理所当然只有一个。
如果是多线程访问单例时，需要十分小心。当两个线程同时调用其生成实例的方法创建实例对象，他们都需要检查单例是否已经存在，并且只有一个能够创建新的实例。这就要求在多并发处理时，应该使用
互斥访问的机制来创建实例。一个比较传统的方式就是在类上使用互斥机制，来表明对象正在被实例化。Java 语言提供了多种多线程安全访问单例的方法，对于不同的Java 版本，实现的方式也不一样，从Java5.0 开始，最简单的方式是使用enum 类型的方法，后面会对其进行说明。传统的多线程安全的解决方式不需要语言结构的支持，但是这种方式不能实现懒加载。
很多专家提出的双检锁机制，曾经一度被认为是解决单例多线程安全问题的最好方法，而被广泛地使用。后来推翻了双检锁策略，指出其在Java语言中是不能使用双检锁来解决多线程安全问题。对于双检锁的单例实现，本文就不赘述，下面介绍一种简单的单例实现方式，是Joshua Bloch 推荐的一种方式，代码
45
I nternet  Technology
互联网+技术
如下：
public enum Singleton {INSTANCE;//唯一实例
public static Singleton getInstance(){return INSTANCE;}
使用enum 来实现单例的好处很明显，简洁并且无偿提供了序列化，即使是在面对复杂的序列化或者反射攻击的时候，也能绝对防止多次实例化。
（二） UML系统服务框架设计
图1  平台系统软件部署结构图
数据层地应用集成（data-level）：简单来说，可以把各种不同的数据进行存储并且实现有效的移动。一般情况下就是将信息从源数据库中抽取出来，进行需要的格式转换，并对目标数据库进行更新。在对所有的数据进行集成的过程中，其最大优势在于付出的多少，对数据进行集成并不需要对所有的代码进行更换，只需要对代码进行开发：测试和重新部署。通常将数据集成看作其他集成技术与手段的基础。
应用程序接口层地应用集成（application-interface level）：将应用程序的内部接口暴露出来，作为集成开发者可以有效地利用这些不同的接口，对所有参与系统相关的业务进行处理，能够获取大量且简单的信息。采用应用程序技术，开发者可以将各种不同应用程序绑定在一处，并且将所有的程序和系统有效地进行集成，确保这些信息能够被应用。但是这种集成方式所获取的信息内容取决于应用程序所暴露接口的质量和数量。
方法层地应用集成（method-level）：在企业的内部业务逻辑中共享是十分重要的一个逻辑环节，目前
很多企业都在选择共享的方式进行经营管理。而在企业发展的过程中，各类不同的共享方法层出不穷，其中包括了：分布式对象、业务处理监控、应用服务器、框架等等。在这样的过程中，选择共享的模式不仅仅是创建某一个应用程序，而是需要两个或多个以上的程序，才能提高应用集成的效果。当前在企业共存应用过程中，有两种不同的方式：第一，基于同一个共享物理器上进行应用程序的创建。第二，在企业中可以将共享放在应用程序之中，使得在应用程序之内的用户变成分布对象，比如SOA。
用户界面层地应用集成（user-interface level）：是把用户界面作为整个应用过程中各个不同界面最为重要的公共点，其目的是通过这种方式，将各个不同的系统集成在一起。是一种相对原始，但十分必要的集成方法。界面集成不涉及软件系统的数据和功能这两个方面。至少能够在用户使用角度产生一个“整体”的概念。用户界面集成的特点：技术难度不大，更多地需要考虑用户的感观和使用习惯。一般应用集成必须要做的集成方式。
四、服务模型创建与接口实现
1. 服务的创建：创建服务分为两种情况，分别是对原有业务进行封装暴露成服务，以及新建服务。而服务具体的实现是采用WebServices技术对业务代码进行封装。
2. 服务的描述：服务创建后，调用者如何获得相应的服务，需要获取服务的相关描述信息。为用户提供详细的接口说明书。
作者单位：孙志明    江苏省淮阴商业学校
参  考  文  献
[1] 于丽.基于UML的面向对象建模技术研究与应用[J].信息与电脑(理论版),2015(20):16-17.
[2] 唐贻兴. 基于web的高校资产管理系统设计[J]. 安徽建筑工业学院学报(自然科学版),
java单例模式双重锁
2008,(02),17-18 .
[3] 陈佳，吴安青，张建华，刘连忠.基于国际通用流程建模标准的高校仪器设备管理流程[J].
实验室研究与探索,2018,v.37;No.272(10):297-300.
[4] 谢振超. 基于无标志物的虚拟家居布置系统设计与实现[D].重庆邮电大学,2018.
[4] 皇威，曾蕴波，谢政.基于SOA构建集成化企业应用门户[J].中国制造业信息化,
2010,39(05):15-18+23.
46

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。