《敏捷软件开发第七讲-UML概述》由会员分享，可在线阅读，更多相关《敏捷软件开发第七讲-UML概述（43页珍藏版）》请在金锄头文库上搜索。
1、广州大学华软软件学院软件工程系主讲教师：谭翔纬 答疑时间：周三 10:30-12:00周四 9:00-12:00 Tel：660028 Email：第七讲：UML概述目录nUML（统一建模语言）nUML图nUML语法描述n有效使用UML图nUML使用原则n总结UML（统一建模语言）UML（统一建模语言）是一个绘制软件概念图的图形化记法(notation)。人们可以用它绘制图形，用这些图形来表示一个计划进行的软件设计的问题域，或者用这些图来表示一个已经完成的软件实现。Fowler描述它们时分成了三种不同的层次：概念层（Conceptual）、规格说明层（Specification）和实现层（Im
2、plementation），现在将细述后面两种。UML（统一建模语言）规格说明层和实现层的图形与源代码有明显的关系，实际上，规格说明层的图是准备用来转换成成源代码的，类似地，实现层的图是打算用来描述已经存在的源代码的。在这些层次的图形，有许多规则和语义学要遵从，这些图较少有歧义，基本上都有严格的格式。UML（统一建模语言）在另外一方面，概念层上的图形与源代码没有什么严格的关系，它们与人类自然语言相关。它们是用来描述有关已经存在的人类的问题领域的概念和抽象的速记。它们无须遵从严格的语义规则，因此它们的意思理解会有歧义、主题可被解释。例如下面是一个概念层次的UML图：UML中的图形UML有三类主要
3、的图，静态图(static diagrams)描述了那些不发生变化的软件元素的逻辑结构，描绘了类、对象、数据结构及其存在于它们之间的关系。动态图(Dynamic diagrams)展示了在运行期间的软件实体的变化，描绘了执行流程、实体改变状态的方式。物理图(Physical diagrams)显示了软件实体的不变化的物理结构，描绘库文件、字节文件、数据文件等等，以及存在于它们之间的关系。UML中图形表达的关系依赖(dependency)：是两个事物之间的语义关系，其中一个事物(独立事物)发生变化，会影响到另一个事物(依赖事物)的语义。关联(association)：是一种结构关系，它指明一个事
4、物的对象与另一个事物的对象间的联系。泛化(generalization)：是一种特殊/一般的关系。也可以看作是常说的继承关系。实现(realization)：是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。各UML图及特征l用例图( Use Case Diagram )用例图是从用户角度描述系 统功能， 是用户所能观察到 的系统功能的模型图，用例 是系统中的一个功能单元类图描述系统中类的静态结构 。不仅定义系统中的类，表示 类之间的联系如关联、依赖、 聚合等，也包括类的内部结构( 类的属性和操作) 类图是以类为中心来组织的， 类图中的其他元素或属于某个 类或与类相关联 l
5、类图(Class Diagram)对象图( Object Diagram )对象图是类图的实例，几乎使用 与类图完全相同的标识。他们的 不同点在于对象图显示类的多个 对象实例，而不是实际的类顺序图(Sequence Diagram)顺序图显示对象之间的动态合 作关系，它强调对象之间消息 发送的顺序，同时显示对象之 间的交互 顺序图的一个用途是用来表示 用例中的行为顺序。当执行一 个用例行为时，顺序图中的每 条消息对应了一个类操作或引 起状态转换的触发事件 各UML图及特征协作图(Collaboration Diagram)协作图描述对象间的协作关系，协 作图跟顺序图 相似，显示对象间 的动态合
6、作关系。除显示信息交换 外，协作图还显示对象以及它们之 间的关系. 协作图的一个用途是表示一个类操 作的实现 状态图(State Chart Diagram)状态图是一个类对象所可能经历 的所有历程的模型图。状态图由 对象的各个状态和连接这些状态 的转换组成 各UML图及特征活动图(Activity Diagram) 活动图是状态图的一个变体 ，用来描述执行算法的工作 流程中涉及的活动 活动图描述了一组顺序的或 并发的活动 构件图(Component Diagram) 构件图为系统的构件建模型 构件即构造应用的软件单元 还包括各构件之间的依赖关系 ，以便通过这些依赖关系来估 计对系统构件的修改
7、给系统可 能带来的影响 各UML图及特征部署图(Deployment Diagram) 部署视图描述位于节点实例上 的运行构件实例的安排。节点 是一组运行资源，如计算机、 设备或存储器。这个视图允许 评估分配结果和资源分配类图顺序图需求分析BDFD/DD类图顺序图用例图用例文档用例图顺序图主要UML图之间的关系UML图的关系各UML图及特征类是对一组具有相同属性、相同操 作、相同关系和相同语义的对象 的描述对象接口是描述了一个类或构件的一个服 务的操作集协作定义了一个交互，它是由一组共 同工作以提供某种协作行为的角 色和其他元素构成的一个群体用例是对一组动作序列的描述主动 类对象至少拥有一个进
8、程或线程的 类构件是系统中物理的、可替代的部件参与 者在系统外部与系统直接交互的人 或事物节点是在运行时存在的物理元素交互它由在特定语境中共同完成一定 任务的一组对象间交换的消息组 成状态机它描述了一个对象或一个交互在 生命期内响应事件所经历的状态 序列包把元素组织成组的机制注释事物是UML模型的解释部分依赖一条可能有方向的虚线关联一条实线，可能有方向泛化一条带有空心箭头的实线实现一条带有空心箭头的虚线UML语法描述使用图(Diagrams)为什么用模型？问题：为什么工程师要建造模型(models)？为什么航天工程师要建造航天器的模型？为什么桥梁工程师要建造桥的模型？提供这些模型的目的是什么？
9、有效地使用UML UML在软件开发人员之间传达设计概念是非常方便的。在一小群开发人员中，许多事情可在一个白板上进行。UML用于表达集中的设计思想相当不错，例如下面的类图：有效地使用UML 另一方面，在表达算法细节时UML不是特别理想。下面是一个简单的冒泡排序代码，表达这个简单的模块使用UML图就不是令人非常满意。有效地使用UML 类图只能给我们一个粗略的结构，但是它不方便、也无法反映出让人感兴趣的细节。有效地使用UML 序列图不比代码容易读，况且它还相当难以创建。有效地使用UML UML在创建大型软件结构时，作为“路标图”(roadmaps) 是比较有用，这样的“路标图”给开发人员一个快速的手
10、段，用来发现某一个类依赖于另外哪些类，并为整个系统的结构的提供了一个参考。有效地使用UML UML图需要经过深思熟虑。我们不需要一个有上千页的序列图，相反，我们需要一个非常明显的描述了系统主要观点的图。没有UML图比一个由许多线和许多框纠缠在一起组成的混乱的图更糟糕的情况了，千万不要做出这样的UML图。有效地使用UML 大多数UML图都是临时性的，使用Case工具或画图工具作图尽量只用一次即可。但是符合下列特征的图应该保存下来，最好放在一个Web服务器上或一个网络知识库中。l表现你的系统中一个通用设计解决方案的图l记录了复杂的协议，难以通过代码了解的图l提供了比较少涉及到的系统范围内的“路标图
11、”的图l记录了比代码更易表述的设计意图的图迭代精化如何建立UML呢？是在灵光乍现时去画下他们？是不是一定要先画类图再画序列图呢？是不是我们丰富完成了部分细节之前一定要搭建好整个系统的架构呢？答案是：绝对不是! 每一个人在一小步的细节上都是做得比较好，并且能够很好地评估它，但是无法实现一次大的跳跃。因此想要建立非常有用的UML图，应该在迭代的每一小步中设计它们。迭代精化行为(Behavior)优先举一个例子，设计一个个控制便携式电话的软件完成一个电话呼叫的软件。先开始画一个有关问题的简单序列图：首先想象一下，软件检测到每一个按钮的操作，然后发一个消息给控制拨号的对象。画了一个Button的对象和
12、一个Dialler对象，并且显示出Button对象发一个digit消息给Dialler对象。迭代精化行为(Behavior)优先当Dialler接收到这个digit消息的时候，它将做什么呢？是的，它需要在一个屏幕上显示数字出来。因此，也许它将发送一个displayDigit消息给Screen对象。迭代精化行为(Behavior)优先接下来，这个Dialler对象最好从扬声器中发一个拨号音，因此，我们将发送一个tone消息给Speaker对象。迭代精化行为(Behavior)优先有时用户将按“发送”按钮要完成呼叫，这时，我们将指示便携式电话连接到无线网络，并发送出被拨打的电话号码。迭代精化行为(
13、Behavior)优先当连接被建立后，这个Radio对象能够告诉Screen对象去显示出“使用中”的指示状态。这个消息将被在另外一个控制线程中被发出(它将会用序列号前面的字符来描述)。最后的协作图将如下图所示：迭代精化检查结构建立支持这个协作图的类图，这个类图将会为协作图中的每一个对象建立一个类(class)，建立针对协作之间联接的联系。迭代精化检查结构前的类图设计Button对象要依靠Dialler对象，会导致出现这样的代码：迭代精化检查结构为了打破Button对Dialler的依赖，并允许Button被实际使用于需要接到到按钮按下操作的任何地方。改进设计：迭代精化检查结构为什么Dialle
14、r会有一个叫做buttonPressed的方法是很奇怪的。通过用一批小的适配器可以解决这个问题，解除所有没有意义的标记。再次改进设计：迭代精化检查结构当做图的时候能够想象到你的代码是极其重要的。我们把图当作了解代码的一条捷径，并不是替代代码。如果画着图但是不能想像出它代表着什么样的代码，你是正在空气中建筑着城堡。停下来你正在做的，想想如何如能将它可以转化成代码。不要为了图而画图，代码才是你要表现的。迭代精化检查结构经过一系列的结构检查，最初的序列图明显不合用了，最终版本演变为：UML使用原则画UML图是一种非常有用的活动，它也可能成为一种浪费时间的、可怕的活动，因为UML图不是源代码，也不能视
15、作方法、变量和关系声明。使用UML的决定是一件好事，也可能成为一件坏事。它依赖你确定怎么使用、多大范围内的使用它。不要制定什么都必须画图的规则，这样的规则将比不用更糟糕。项目的大量时间被浪费在追逐那个根本没有人去读的图上。UML使用原则什么时候画图：l当许多人需要同时进行开发时，这些人需要都理解一个系统的特定部分的设计结构时，开始画图。当所有的人都已经声明理解了的时候，结束画图。l 当两个人或更多人不同意一个特定的元素如何设计的时候，你需要你的团队意见一致的时候，要找一个时间进行讨论做出决定，比如投票，或一个公正的宣告的方式进行，这时需要画图。当决定做出来后，擦掉这些图。l当需要探讨一个设计的
16、想法时，画图能够帮你更好的地思考。当你得到了能够帮助你完成思考的代码的要点的时候，扔掉这些图。 UML使用原则什么时候画图：l 当你需要向其他人或自己解释一部分代码的结构的时候，你可以画图。当你觉得其实最好看代码来进行解释的时候，停止画图。l当项目快要结束，顾客需要你将图与其他文档一起提供的时候，开始画图。UML使用原则什么时候停止画图：l不要因为觉得过程需要而画图。l不要因为觉得一个好的设计者就必须画图、不要因为不画图反而感觉有罪的想法而去画图。好的设计者只有在需要的时候才去编写代码和画图。l不要在编码之前的设计阶段去为创建全面的文档而画图，这样的文档基本没有意义并且将会浪费大量的时间。l不要为了其他人编码而去画图。真正的软件构架师将去实现自己的设计的编码。这样能把设计工作简单明了化。总结一些人站在白板前能够使用UML他们更好地思考一个设计问题。UML图将会在一个极短周期内以迭代的方式创建。最好首先研究动态场景，然后确定静态结
