本节向大家介绍一下UML实践指南，主要包括用例模型，设计方法选择和面向对象的基本原则等内容，希望通过本节的学习你对UML实践有一定的认识。下面就让我们一起来看一下UML实践指南的详细介绍吧。
UML实践指南
UML仅仅是一种描述语言，它的作用只在于忠实的记录和表达程序员的分析结果和设计思想。它无法告诉开发人员如恶化进行面向对象分析与设计，也无法提供任何有关设计原则和设计技巧的智囊。UML只是开发人员在设计过程横纵表达设计思想、进行交流和沟通的一种工具，使用时应该“点到为止”。只要当前的UML模型能准确反映设计者的思想，就没必要浪费精力取开发和维护更加完整、更加细致的版本。
在UML语言中，用例模型是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与制与系统间的交互关系描述系统对外提供的功能特性，这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求种抽象出用例模型的工作过程。
UML语言中的用例图只反映两类信息：
◆哪些参与者会和我们的系统发生交互；
◆我们的系统需要实现哪些功能特性；
绘制用例图并不是用例分析和用例建模工作的全部。用例模型是一个叙述性的文档应使用描述性的文字或其它类型的视图来概括最终用户完成某个任务的具体过程，确定用户操作系统软件并得到预期结果是的事件发生顺序。UML实践指南中用例模型只描述了软件的功能性需求，对于软件的非功能性需求，必须借助其它的表述手段。
一、用例模型
1、用例和场景的区别
场景是用例的一个执行实例，是用例执行过程中的一条实际路径。一个用例可能包括多个场景，如成功的场景、失败的场景等。
2、用例建模
用例建模就是通过分析用户的功能性需求，得到用例模型的工作过程。用例建模的步骤：
◆确定系统边界；
◆确定参与者；
◆找出所有的用例；
◆确定每个用例的级别；
◆撰写用例的文字描述；
◆画出整个系统为对象的顺序图；
（1）确定系统边界和参与者
UML实践指南中用例分析和用例建模工作通常要求在对软件系统进行分析之前，确定系统的边界。系统的边界就是将系统的功能特性与系统的外部环境分离开来的逻辑分界线。一个完整的软件系统往往包含复杂的内部结构，可由外向内分为若干层次，当考察系统的用例模型时，一般要先明确考察的是系统的哪个层次。
用例分析和用例建模的考察对象可大可小，完全取决于待考察的系统边界是什么，对于不同的系统边界，将获得完全不同的用例模型。
（2）确定用例级别
用例级别是对用例模型的抽象或细化程度。常用的用例级别包括高层用例、用户目标级用例和子功能用例等。借助高层用例，可考察全局问题，了解系统需要为用户提供几大类功能；用户目标级用例是最重要的一个用例级别，他的作用是从用户的观点来观察软件系统，了解用户究竟需要哪些功能特性，这个级别屏蔽了很多低级别的信息；被高层用例和用户目标级用例屏蔽的低级信息被反映在子功能用例中。
◆高层用例
找到高层用例的方法是不断的扩大系统边界，直到再扩大时用例的参与者就会被包括在系统的临界点为止。描述高层用例的目的是为了和用户交流，让用户对软件功能有一个概要性的认识。
◆子功能级用例
这些用例的作用在于：
ü进一步细化用户目标级用例；
ü进一步细化用户目标级用例中的每个执行步骤；
◆用户目标级用例
不能把用户界面和用户目标级用例混同起来，软件的用户界面往往对应于具体的、细化的操作需求，过多的考虑用户界面会分散人们的注意力，应把注意力放在对需求问题的理解上，可以简单的认为用户界面不在考虑范围内。这样做可以使系统的业务功能更适合不同的用户界面。
对系统进行用例建模，用例模型在项目开发中发挥巨大作用。通常，在绘制用例图的基础上，为每个主要用例画一张顺序图。顺序图使UML视图中的一种，可以准确反映某一用例或某一场景的具体操作流程。在这里，绘制顺序图的目的不是为了进行系统设计，而是要把整个系统看作一个黑盒，观察发往系统的所有消息的顺序和流程。#p#
二、设计方法的选择
UML实践指南中传统的面向过程设计方法是功能分解和逐层迭代思想的体现。要求按软件的功能特性，在不同级别上，把系统划分称多个功能模块，并确保模块之间的耦合性最小。该软件必须具备较强的复用性和扩展性的场合，他的功效就不行了。
一个软件的内聚度和耦合度都符合要求，它就具备的较好的可复用性、可扩展性和可维护性。
◆内聚度：表示一个类、模块或函数所承担职责的自相关程度。若一个模块只负责一件事情，则说明这个模块有较高的内聚性；若一个模块负责很多不相关的事情，则说明这个模块的内聚性很低。内聚度高的模块通常很容易理解，很容易被复用、扩展和维护。
◆耦合度：表示模块与模块之间、类与类之间、函数与函数之间关系的亲密程度。耦合度越高，软件单元间的依赖性越强。函数调用时，函数参数包含的信息越多，函数与函数之间的耦合度就较大。在面向对象的程序设计语言中，类与类之间的耦合度由他们为了完成自己的职责而必须相互发送的消息及消息的参数来决定。
“低耦合、高内聚”是所有优秀软件的共同特性。
三、面向对象技术中，一个类若公开了一些方法供其它类调用，则该类就被称为服务器，公开的这些方法被称为服务，而调用这些服务的类就是客户。在理论上，客户类调用服务器类的服务，这一工程可看作客户向服务器发送一个消息。客户和服务器的概念揭示了面向对象技术的核心思维方式。即，每个类都是一个独立的组件，它们有着自己的属性，承担必要的职责，并通过接口向其它类提供特定的服务；客户类通过发送消息的方式请求服务器类履行相应的职责。在这个模型中，系统中的类各司其职、相互协作、共同完成系统的业务功能。下面我们看一下UML实践指南中面向对象的基本原则。
四、面向对象的基本原则
1、开闭原则：一个模块对扩展应是开放的，对修改应是关闭的。
该原则要求我们的代码模块应能很容易的扩展，但在扩展的过程中，无需改动已有的代码。
在面向对象语言中，利用多态性可很容易的满足上述原则的要求。
2、完全替换原则：派生类应该能完全替换掉基类
完全替换指的是在需要一个基类指针或基类引用的地方，传递一个派生类的指针或引用，代码也能正常工作。
要使派生类完全替换基类，派生类和基类就必须拥有相同的接口定义。此外，对接口中的每个方法，派生类和基类还必须拥有相同的前提条件和后置条件，因为当前提条件和后置条件不同时，若用派生类替换基类，就有可能会造成错误的调用。
3、依赖倒置原则：依赖于抽象，而不要依赖于具体。
4、为人写代码，而不是为机器写代码。请期待下节关于UML实践指南介绍。
【编辑推荐】
