敏捷软件开发:原则、模式与实践——第13章 写给C#程序员的UML概述

第13章 写给C#程序员的UML概述

  UML包含3类主要的图示。静态图(static diagram)描述了类、对象、数据结构以及它们之间的关系,藉此表现出了软件元素间那些不变的逻辑结构。动态图(dynamic diagram)展示了软件实体在运行过程中是如何变化的,其中描述了运行流程或者实体改变状态的方式。物理图(physical diagram)展示了软件实体不变的物理结构,其中描述了诸如源文件、库、二进制文件、数据文件等物理实体以及它们之间的关系。

  查看如下代码,这段程序实现了一个基于简单二叉树算法的映射(map)数据结构,熟悉代码后,查看后面的图示:

using System;
namespace TreeMap
{
    public class TreeMap
    {
        private TreeMapNode topNode = null;
        public void Add(IComparable key, object value)
        {
            if (topNode == null)
                topNode = new TreeMapNode(key, value);
            else
                topNode.Add(key, value);
        }
        public object Get(IComparable key)
        {
            return topNode == null ? null : topNode.Find(key);
        }
    }
    internal class TreeMapNode
    {
        private static readonly int LESS = 0;
        private static readonly int GREATER = 1;
        private IComparable key;
        private object value;
        private TreeMapNode[] nodes = new TreeMapNode[2];
        public TreeMapNode(IComparable key, object value)
        {
            this.key = key;
            this.value = value;
        }
        public object Find(IComparable key)
        {
            if (key.CompareTo(this.key) == 0) return value;
            return FindSubNodeForKey(SelectSubNode(key), key);
        }
        private int SelectSubNode(IComparable key)
        {
            return (key.CompareTo(this.key) < 0) ? LESS : GREATER;
        }
        private object FindSubNodeForKey(int node, IComparable key)
        {
            return nodes[node] == null ? null : nodes[node].Find(key);
        }
        public void Add(IComparable key, object value)
        {
            if (key.CompareTo(this.key) == 0)
                this.value = value;
            else
                AddSubNode(SelectSubNode(key), key, value);
        }
        private void AddSubNode(int node, IComparable key,
        object value)
        {
            if (nodes[node] == null)
                nodes[node] = new TreeMapNode(key, value);
            else
                nodes[node].Add(key, value);
        }
    }
}

13.1 类图

  类图展示了程序中主要的类和关系。

  • 矩形表示类,箭头表示关系。
  • 在本图中,所有的关系都是关联(association)关系。关联是简单的数据关系,其中一个对象或者或者持有另一个对象的引用,或者调用其方法。
  • 关联上的名字映射为持有该引用的变量名。
  • 一般来说,和箭头相邻的数组表示该关系所包含的实例个数。如果数字比1大,就意味着某种容器,通常是数组。
  • 类图标中可以分成多个格间。通常,最上面的格间存放类的名字。其他格间中描述函数和变量。
  • <<interface>>符号用来说明IComparable是一个接口。
  • 这里显示的大部分符号都是可选的。

13.2 对象图

  它展示了在系统执行的某个特定时刻的一组对象和关系。你可以把它看做是一个内存快照。

13.3 顺序图

  它描述了TreeMap的Add方法是如何实现的。

  人形线条图表示了一个未知调用者。这个调用者调用了TreeMap对象的Add方法。如果topNode变量为null,TreeMap就创建一个新的TreeMapNode对象并把它赋给topNode。否则,TreeMap就向topNode发送Add消息。

  方括号中的布尔表达式称为监护条件(guard)。它们指示出应该选择哪条路径。终结在TreeMapNode图标上的消息箭头表示对象构造。带有小圆圈的箭头称为数据标记(data taken)。TreeMap下面的窄矩形条称为激活(activation)。它表示Add方法执行了多少时间。

13.4 协作图

  

  它描述了TreeMap.Add中topNode不为null的情况。协作图中包含了顺序图中所包含的同样的信息。不过,顺序图是为了清楚地表达出消息的顺序,而协作图则是为了清楚地表达出对象之间的关系。

  对象被称为链(link)的关系连接起来。只要一个对象可以向另外一个对象发送消息,就存在链关系。在链上传递的正是消息本身。它们表示为小一些的箭头。消息上标记有消息名称、消息顺序号以及任何使用的监护条件。

  带点的顺序号表示调用的层次结构。TreeMap.Add函数(消息1)调用TreeMapNode.Add函数(消息1.1)。因此,消息1.1是消息1所调用的函数发送的第一条消息。

13.5 状态图

  UML可以非常全面地表示有限状态机。下图展示了一个地铁旋转门的状态机:

  它有两个状态:Locked和Unlocked。可以向这个机器发送两个事件。coin表示向旋转门投入了一枚硬币。pass表示用户已经通过了旋转门。

  图中的箭头称为迁移(transition)。其上的标记有出发迁移的事件以及该迁移执行的动作。当一个迁移被触发时,会导致系统的状态发生改变。

  翻译成自然语言描述:

  • 如果在Locked状态收到coin事件,就迁移到Unlocked状态并调用Unlock函数。
  • 如果在Unlocked状态收到pass事件,就迁移到Locked状态并调用Lock函数。
  • 如果在Unlocked状态收到coin事件,就保持在Unlocked状态并调用Thankyou函数。
  • 如果在Locked状态收到pass事件,就保持在Locked状态并调用Alarm函数。

13.6 结论

  本章中的图示对于大多数场合来说足够了。大部分程序员了解这么多UML知识就足以应对实际工作需要了。

摘自:《敏捷软件开发:原则、模式与实践(C#版)》Robert C.Martin    Micah Martin 著

转载请注明出处:

作者:JesseLZJ
出处:http://jesselzj.cnblogs.com

时间: 2024-12-17 22:24:10

敏捷软件开发:原则、模式与实践——第13章 写给C#程序员的UML概述的相关文章

敏捷软件开发:原则、模式与实践(笔记)

一.敏捷软件开发宣言 1.个体和交互 > 过程与工具 a)人是获得成功最为重要的因素: b)合作.沟通以及交互能力要比单纯的编程能力更为重要: c)团队的构建要比环境的构建重要. 2.可以工作的软件 > 面面俱到的文档 a)文档应该短小并突出主题: b)在给新的团队成员传授知识方面,最好的两份文档是代码和团队: c)直到迫切需要并且意义重大时,才来编制文档. 3.客户合作 > 合同谈判 a)成功的项目需要有序.频繁的客户反馈. 4.响应变化 > 遵循计划 a)构建计划时,应该确保计

敏捷开发-原则 模式与实践(1)

敏捷开发-原则 模式与实践 这的确是一本关于开发者的好书,对于我们开发者.研究人员,它提出了一个开发的全新的价值观(对我来说),甚至人生都有启发.需要认真阅读. 书中总结了敏捷开发的实例,确确实实更够感觉到对于项目的完成大有裨益,有种相读恨晚的感觉.想想自己之前的开发状态,想想自己导师安排公司项目的情况,就是低效率,就是小儿科,就是书上批评讽刺的那样,这正是开发者十几年开发智慧的结晶,前人的经验,前人的智慧,激发了我的阅读的快感,我获取知识的兴奋感,激发了我的成就感. 阅读前两天(结合思维导图)

敏捷软件开发 – STATE模式

地铁旋转门 最直接的实现FSM策略的方式是使用嵌套switch/case语句. public enum State { LOCKED, UNLOCKED }; public enum Event { COIN, PASS }; public class TurnStile { private State state = State.LOCKED; private TurnstileController turnstileController; public TurnStile(Turnstile

敏捷软件开发原则

敏捷软件开发原则 ----<敏捷软件开发原则.模式与实践>学习笔记 最近在系统地学习并且有意地在工作中实践敏捷软件开发,文章乍看起来,都是一些说教性.理论性,比较无聊的东西. 但是如果静下心来结合自己自身的经历.思考地去阅读,可能会发现,有的观点确实很赞同,然而有的可能会有自己的想法. 以下是在<敏捷软件开发 原则.模式与实践>一些读书笔记,斜体字是直接摘录于书本,非斜体字是自己的一些理解.   一.尽早的,持续地交互有价值的软件来使客户满意.初期交付的系统功能越少,最终交付的系统

敏捷软件开发 – FACADE模式和MEDIATOR模式

FACADE模式 Db类使得Application类不需要了解System.Data命名空间中的内部细节.它把System.Data的所有通用性和复杂性隐藏在一个非常简单且特定的接口后面. 像Db这样的FACADE类对System.Data的使用施加了许多规约.它知道如何初始化和关闭数据库连接.它知道如何将ProductData的成员变量转换成数据库字段,或反之.它知道如何去构建合适的查询和命令去操纵数据库.它对用户隐藏了所有的复杂性.在Application看来,System.Data是不存在

[书摘]《敏捷软件开发: 原则、模式与实践》第一部分:敏捷开发

面向对象设计的原则 单一职责 开放-封闭 Liskov替换原则 依赖倒置原则 接口隔离原则 重用发布等价原则 共同封闭原则 共同重用原则 无环依赖原则 稳定以来原则 稳定抽象原则 人的重要性 交付产品的关键因素是人,而不是过程.(敏捷 Agile) 人与人之间的交互式复杂的,并且其效果从来都是难以预期,但却是工作中最为重要的方面. ------ Tom DeMacro 和 Timothy Lister<人件> 有凝聚力的团队将具有最强大的软件开发力量. 敏捷软件开发宣言 我们一直在实践中探寻更

读书笔记-敏捷软件开发 原则,模式与实践

看了一下夹在书中的发票,2010年在当当网购买的. 断断续续的也看过几次,一直没有看完过. 这次试着写写读书笔记.看看能不能坚持住.

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何