软件项目实训及课程设计指导—UML静动态建模在详细设计中应用

软件项目实训及课程设计指导——UML静态和动态建模技术在详细设计中的应用示例

1.1.1 在软件应用系统的详细设计中要充分应用UML静态和动态建模技术

1、再次理解UML技术规范中的”统一”的内涵

UML是一种可视化、功能规范和文档化的软件系统分析和设计中的统一建模语言，UML中的”统一”的内涵是能够让软件应用系统开发人员使用一种标准的方法进行软件应用系统的分析和设计，并且它是一种开放式的标准。

2、为什么在面向对象分析、设计和开发实现中大力倡导应用UML技术规范

（1）实现项目组成员之间的无歧义地沟通和交流

在软件应用系统项目分析、设计和开发实现过程中，开发人员应用UML 的价值在于它能够实现团队中的各个成员之间无歧义地沟通和交流——因为人类的自然语言本身是无法达到无歧义的表达，因此需要 UML 这种图形化的语言的辅助帮助。

（2）在课程设计的项目开发中要充分应用UML静态和动态建模技术

因此，读者对UML技术规范的学习和掌握——这包括UML的主要特性和表示方法、使用UML的主要的目的、UML中包括哪些方面的视图以及在UML中是如何描述软件系统的模型等方面的知识内容是读者学习的重点。

3、尽管UML也属于”语言”，但它与计算机编程语言是完全不同的

统一建模语言UML本身并没有什么太深奥难懂的术语，因此读者在学习UML时不会有什么太大的困难。但读者需要明确的是，尽管UML也属于”语言”，但它与读者平时学习的计算机编程语言是完全不同的——计算机编程语言是采用语句及字符符 实现对问题的描述；而UML则是采用图形符 实现对软件系统中的各种组成元素进行描述，并且UML中的各种图形符 都被赋予有一定的语义和语法规范——读者必须严格遵守这些语法。

因此，读者在学习UML时如果能够明确并区分UML与常规的计算机编程语言所存在的这些差别，将能够有助于读者对UML的学习和正确地应用于课程设计的软件系统项目开发的分析和设计工作中。当然，改变这些看法和思维方式对于UML的初学者来说是有一定的难度的。

另外，读者在项目开发实现过程中，不应该直接根据对软件系统的设计结果进行代码编程实现，还必须要对软件系统设计的结果进行重构和优化以保证对软件系统的设计结果是合理和正确的、并满足软件系统需求中的各种要求的。

4、熟悉软件应用系统详细设计相关的主要工作内容

软件应用系统设计中的详细设计是对概要设计阶段中所产生的设计结果进一步精化和细化的设计过程，设计人员工作的主要重点和主要的工作内容为：

用户界面设计、各个模块组件类的成员设计、业务功能实现技术的合理运用等内容，以及典型模块中内部的算法设计等内容。当然，设计人员也还应该考虑如下方面的问题：

（1）考虑软件应用系统中每层的具体的技术实现和采用什么形式的应用框架

（2）软件应用系统中各个层中的每个程序类的详细定义，这包括程序类的成员属性和成员方法

1.1.2 软件应用系统业务处理层中的业务逻辑建模及业务功能类的设计

1、软件应用系统业务层组件中业务类的设计

软件应用系统中的业务层也称为应用服务层，良好的业务层中的各个组件类设计可以使得应用系统中的表示层采用不同的实现技术而不影响到系统中的业务层的功能实现。

（1）什么是好的业务功能模块的设计结果

一个合理的业务功能模块的设计结果，一般应该具有如下几个基本的特性要求——它们是保证达到高内聚和低耦合的设计目标的基本条件：

1）可扩展性（Extensibility）——软件应用系统能够低成本地扩展和添加新的应用功能；

2）灵活性（Flexibility）——软件应用系统对程序代码的修改能够平稳地发生，不会产生修改大批量的功能实现程序代码的状况；

3）可插入性（Pluggablity）——开发人员容易将一个程序类从软件应用系统中抽出去，同时将另一个有同样接口的实现类添加进来而完成系统功能实现的替换。

（2）不良的业务功能模块的设计结果

1）缺乏灵活性——开发人员很难在软件应用系统中添加新的功能，因为每一处的改动就会影响到软件应用系统中过多的程序模块而导致”牵一发而动全身”的维护修改的效果，此时则认为该软件应用系统缺乏灵活性；

2）脆弱性——当开发人员在软件应用系统中的某处做了改动后，却导致软件应用系统的其它的多个模块也发生了”连锁”性的变化而跟随修改——多米诺骨牌效应的”连锁反应”；

3）不可重用性——很难在别的软件应用系统程序中重用本软件应用系统中的某个功能模块，因为不能将该程序模块从现有的软件应用他程序中独立地提取出来，其主要原因是由于藕合有其它的功能类的程序代码——”挖出萝卜带出泥”。如下示图为某个Web应用系统中的Web页面实现的代码局部截图——HTML标签和Java处理逻辑代码混杂在一起。

2、如何实现将业务层和表示层相互分离

当然，软件应用系统的设计和开发人员为了能够达到”高内聚和低耦合”的软件应用系统设计的基本目标，除了要遵守面向对象程序类设计中的五大设计原则以外，还可以应用下面列出的各种形式的GOF程序代码设计模式和设计方法以简化对软件应用系统的设计和功能实现过程：

（1）命令模式（Command）

（2）代理模式（Proxy）

（3）门面模式（Facade）

（4）消息队列机制

通过应用这些设计模式能够达到通过”很小的设计改变”就可以应对较大的”软件系统需求”的变化的设计效果。

3、系统业务处理层在设计时要遵守面向对象的”封装”和”隔离”的设计原则

（1）首先要考虑与数据有关的业务实体的封装

对于业务数据的表示方式，为了能够遵守面向对象程序类设计中所倡导的封装的思想，一般采用业务实体组件类包装各个业务数据而产生出VO（Value Object）类；当然，也还要考虑业务数据的存取方式，一般可以借助对象关系映射（O/R Mapping）技术来实现将业务实体映射到关系型数据库表中，业务实体中的各个成员属性映射到关系型数据库表中的字段。

（2）其次再考虑如何设计业务逻辑的组织方式

面向对象的程序类设计中倡导面向接口编程实现，因此应该要为软件应用系统中的各个业务功能类提供对应的业务处理方法的接口定义；然后再依据各个业务功能的接口提供业务接口的具体实现类——从而保证了接口的稳定而针对不同类型的业务处理的需要提供不同的功能实现，提高了程序模块的灵活性。

如果在软件应用系统的业务实现类中还涉及到数据访问的一致性等功能要求时，则应该考虑在软件应用系统中应用事务处理的技术及考虑如何具体地实现事务处理——最好能够应用面向切面编程（AOP）的思想分离软件应用系统的业务功能实现程序类和事务处理功能实现程序类之间的耦合关系。

（3）最后再考虑以何种方式向外界（客户端）提供业务功能服务

软件应用系统的设计人员主要要考虑如何向客户端程序提供本软件应用系统的业务功能服务，并尽可能与客户端程序产生松散藕合的关联。

为此，软件应用系统的设计人员可以根据不同的应用需求充分应用工厂模式以隔离对服务提供者对象实例在创建方面的依赖、利用命令模式分离服务的请求者对服务的具体实现者的过强的依赖、利用代理模式分离服务的请求者对服务的提供者的直接依赖、利用模板模式分离共性的功能实现代码和个性化的功能实现代码等设计模式而最终达到分离服务的提供者和服务的请求者之间的耦合关系。

4、银行账户信息管理应用系统项目详细设计中的UML类图

软件应用系统的设计人员通过对软件应用系统的概要设计阶段所产生的”粗粒度”程序类进一步地细化其设计结果，并为各个程序类定义出类中所涉及的成员属性、方法等组成成员，最后产生出”细粒度”状况的软件应用系统的详细设计程序类，然后再采用UML技术规范的类图描述出各个功能类之间的关系和组成结构。

1.1.3 UML动态建模技术在软件应用系统业务流程的分析、描述和设计中的应用

1、应用软件应用系统中的动态建模机制及具体实现的应用示例

在软件应用系统UML静态模型的基础上建立出相应的UML动态模型，而UML动态模型描述了软件应用系统随时间变化的行为，这些行为是用从UML静态视图中抽取的系统瞬间值的变化来描述的。UML动态模型主要包括UML顺序图、UML协作图、UML状态图和UML活动图，软件应用系统的设计和开发人员利用这些UML技术规范的视图能够便于分析软件应用系统在运行时的行为、印证和修改软件应用系统的静态结构，达到明确软件应用系统的功能实现的目标。

2、应用UML状态图完成对软件应用系统中的各个主要业务流的动态分析以指导后续的编程实现

UML状态图可以用来描述一个特定对象（比如参与者）的所有可能状态及其引起状态转移的各种事件，并且大多数面向对象设计技术都倡导应用UML状态图表示单个对象在其生命周期中的各种可能的行为，同时也显示了该实体如何根据当前所处的状态而做出的各种反应。

但在什么场合下应该要应用UML状态图？一般可以遵守如下的原则——当软件应用系统中的特定对象行为的改变和状态有关时才应该创建出UML状态图。UML状态图在实时系统开发中应用的比较多，当然也可以用于辅助设计软件应用系统的用户界面。

下图所示为银行账户信息管理系统中的注册用户的状态图，通过状态图能够更好地了解类的动态行为，软件应用系统的开发人员在编码前就能了解复杂的业务逻辑实现过程。

在UML的技术规范中一般把初始状态放置在UML状态图的左上角、并且初始状态被建模成一个实心圈；而状态图中的终止状态一般被放置在右下角，并且最终状态被建模为一个带边界的实心圆；在同一个状态图中只能有一个初始状态，但可以有多个终止状态——请见图上述示例图。

3、应用UML活动图完成对软件应用系统中的各个主要业务流的动态分析以指导后续的编程实现

读者首先要认识到”用例描述”和”活动模型”描述之间存在着重要的区别，用例描述只是从软件应用系统的”外部参与者”的角度出发进行编写和描述的，它只描述软件应用系统中的各个用例之间的”静态的关系”，而不能够描述软件应用系统中的各个”参与者”、”各个用例”的动态行为。

而活动模型中的UML活动图则由于采用的是从软件应用系统的”内部实现”的角度出发来编写和描述的，因此使用UML活动图可以表示由软件应用系统内部所生成的各个动作；当然，软件应用系统的设计人员也可以利用UML活动图为用例参与者对软件应用系统的操作行为进行建模、并且可以图示出不同功能之间的前后关系。

下图所示为某个BBS论坛系统中的注册用户请求成为版主的UML活动图（带泳道的UML活动图），在UML中的活动图本质上就是面向过程程序设计方法中的流程图，因此也可以图示某个用例的业务实现过程和体现多个对象相互交互状况。

4、应用UML协作图完成对软件应用系统中的各个主要业务流的动态分析以指导后续的编程实现

UML中的协作图可以表示在特定环境中相关的一组对象之间的协作关系、以及一种交互关系——为实现某个操作或达到某种结果而在对象间交换的一组消息。

由于UML协作图也是一种交互图，但通过该种类型的交互图，可以显示出由一个用例定义的一个系统事件以及其中的一组对象与其它组对象之间是如何彼此进行协作的信息。因此，可以将UML协作图视为UML对象图的扩展——它除了能够展现出软件应用系统中的各个对象间的关联关系以外，还能够显示出对象间的消息传递。

但UML协作图与UML顺序图的不同之处在于，在UML协作图中不能体现出消息的先后顺序——因为UML协作图主要是显示对象之间的交互关系和链接关系，它并不将时间作为单独的一个坐标维度表示出。因此，要对UML协作图中的消息采用数字进行编 以表明这些消息产生的先后顺序。

下图所示为银行账户信息管理系统中的转账用例的UML协作图，在该协作图中对消息采用数字编 以体现各个消息产生的先后顺序，该UML协作图主要表示储户（注册用户）在完成转账时，会涉及到trainmitAccount表单、AccountManageServlet控制层组件、AccountManageBean业务层组件和AccountManageDAOJDBCImple等DAO组件对象，同时还要与这些对象发生协作（关联）关系。

5、为什么要应用UML技术规范中的UML协作图

（1）利用UML协作图能够辅助软件应用系统的分析人员分析软件应用系统中复杂的交互操作状况

虽然应用UML顺序图可以很好地表达操作和行为方面的信息，而且在UML顺序图中的时间关系也表达得比较清楚。但是，当业务流程关系非常复杂的时候，再采用UML顺序图来描述就会很复杂而导致UML顺序图中的各个对象及关系太密集而不清晰，这样反而不利于对软件应用系统相关问题的表达和描述。

所以，对于这些应用情况下的软件应用系统的分析，软件应用系统的分析人员更应该要使用UML协作图来表达复杂的业务流程，将会使表达更清楚和更简洁。在Rose的UML实现工具中可以依据UML顺序图转换创建出对应的UML协作图，如下示图为Rose的UML实现工具中提供的转换功能菜单。

（2）利用UML协作图简化对软件应用系统中的各个对象间的关联建模

由于UML协作图只对相互间具有交互作用的对象和对象间的关联建模，软件应用系统的分析人员在UML协作图中可以忽略其它对象和关联关系的描述。从而使得软件应用系统的分析人员能够更好地描述出实现某个用例时所需要涉及的各个对象以及它们之间的关联关系方面的信息。如下示图为某个BBS论坛系统中注册用户发表文章的UML协作图，该UML协作图图示了文章发表的复杂业务流程和相互关联的对象。