论UML建模

论UML 建模

概览：

        现实生活中的一切都是对象，任何一种事物都可以通过对象的特性来描述。面向对象的设计语言有很多种，包括java，C++，C#等。但是，对象也是分类别的。打个比方，譬如说有生命的事物跟没有生命的事物是有区别的，区别在于它们的特性不同，一个是死的，一个是活的；在譬如说，动物跟植物，一个是有思想的，另一个是没有思想的，着也仅仅是它们各自拥有的特性不同。不同的事物包含不同的特性，那么就构成了我们丰富多彩的世界。

       那么，在电子的世界中，同样任何事物都能使用对象描述，我们要做的也仅仅是将这些对象的属性按照一定的规则进行区分而已。世界这么大，选用一个合适的方式去描述当然是非常有必要的。这个时候，UML设计思想就应运而生。

什么是UML:

      UML是一种面向对象的设计方法，更是一种设计语言，它定义了一些包含某些特殊意思的基本元素，这些基本元素就是相当于是我们语言种的词汇，那么有了词汇就会有相应的语法。这些语法就是UML中基本元素之间的规则联系。但是我们要明白一点，UML相当于是一种统一语言、统一过程的工具，但是工具使用的好坏就是另一回事了。要想将这个工具用好就要多用，多积累使用的经验。

获取需求：

      不管是做什么软件，第一步就是要获取需求，没有需求的软件设计就是没有指向灯的航船，前方是到底是冰山，还是暗礁，都是一无所知，是非常危险的。获取需求也是要有好的方法的。

      可以先进行涉众调查。所谓涉众就是跟本次设计、或者是本模块有关联的部门代表，或者是相应的人。接着，对相应的涉众请求进行优先级调整，并进行优先级的重叠和冲突优化，最终的出一张优先级表项。

     有了这么一张优先级表项，再根据项目执行周期，以及相应的客观性因素，确定业务范围。

     有了需求，接下来才是重头戏，设计项目系统的关键。

     下面是进行获取需求的关键步骤：

     1)定义边界 

     2)发现主角，其实是边界内的代表

     3)获取业务用例，就是从主角中获取相应的业务需求

     4)建立业务模型，包括业务用例视图、业务用例场景（使用活动图、使用时序图）、业务用例规约、业务规则、业务对象模型、业务用例实现视图、业务用例实现场景、包图

     5)建立领域模型，就是将所有有关的一类的行为方式，全部打包在一起

     6)提炼业务规则，这里分为全局规则、交互规则、内敛规则

    7)获取非功能上的需求 

需求分析：

1)建立概念模型，使用MVC设计模式来分析对象模型，简单来说就是操作用户对对象的操作去全部在边界完成，操作消息通过边界类将想消息传给控制类，并由控制类解释、执行相关的逻辑，并向实体类进行数据的存取。

2)建立业务构架，核心是工作流引擎。

系统分析：

1)确定系统用例，从业务用例场景中获取，使用抽象、拆分、合并等方法。

2)描述系统用例 ，主要是描述本系统用例的主要功能，以及使用的环境。

3)分析业务规则，包括业务中要遵守的特定规则，业务要求的特殊功能等等。

4)实现用例，根据上层使用的需求，仔细分析本层的本用例的具体对外方法，完成上层需实现功能。

5)建立分析模型，那么什么是分析模型？起始并不难理解，分析模型说白了就是整个业务要进行流畅运转所需要经过的流程步骤，就好比是“寄信”这回事。那么这个过程要经过写信人写信，写信人将信件装信封，写信人将封装好的信件送进邮局，邮局人员分拣，送信人送信，收信人收信，这么6个步骤。分析模型就是分析每个步骤中，每个角色所承担的各自责任，分析共用例的职责。

6）建立组件模型，这步是跟上一步是有紧密联系的，应为这步中所得出的所有组件就是上步中所分析出来的每个用例的独立划分化，明确将每个组件的作用域以及职责范围描述。

7）建立部署模型，这个其实就是描述整体的架构是怎么样的，譬如说，要建一个基于数据库的b/s服务器，哪么就需要一个服务器，一个数据库。

系统设计：

这是一个将系统分析结果进行实际化过程，就是将分析模型中的关系映射，在这个过程中可以使用各种设计模式，各种设计模式的使用还是很不错的。

接口设计：这个就是进行个组件，各模块只见数据交互的对外函数，说白了就是这样，并没有什么太深的奥秘。

接口设计的原则1:为单一对象设计接口，即使这个对象仅有一个

  接口设计的原则2:为具有相似功能或者是行为的方法设计接口，那是因为很多方法无非就是增删查改

接口设计的原则3:为系统个层次设计接口