敏捷软件开发:原则、模式与实践——第19章 类图

第19章 类图

19.1 基础知识
19.1.1 类

  类一般表示成下面的样子:

分成格间的类图标以及对应的代码

  注意类图标中变量和函数名前面的符合。(-)表示private;(#)表示protected;(+)表示public。

19.1.2 关联

  类之间的关联表示的是那些持有对其他对象引用的实例变量。如phone和Button之间的关联:

一个PhoneBook对象和多个PhoneNumber对象相连(星号表示许多):

19.1.3 继承

  UML中所有的箭头都指向源代码依赖的方向。类和类之间的继承用实线,类和接口之间的继承用虚线。我建议在白板上画图是,不要把箭头画成虚线,画虚线太浪费时间了。

  继承关系示例:

  实现关系示例:

等价于如下棒棒糖状接口:

19.2 类图示例

以下为ATM示例:

看到这幅图时,你应该能设想出代码。UI实现的代码如下:

public abstract class UI :
WithdrawalUI, DepositUI, TransferUI
{
    private Screen itsScreen;
    private MessageLog itsMessageLog;
    public abstract void PromptForDepositAmount();
    public abstract void PromptForWithdrawalAmount();
    public abstract void InformInsufficientFunds();
    public abstract void PromptForEnvelope();
    public abstract void PromptForTransferAmount();
    public abstract void PromptForFromAccount();
    public abstract void PromptForToAccount();
    public void DisplayMessage(string message)
    {
        itsMessageLog.LogMessage(message);
        itsScreen.DisplayMessage(message);
    }
}

19.3 细节

  在大多数情况下,细节和修饰是不应该加入的,不过,有时候它们却是有用的。

19.3.1 类衍型

  类衍型出现在一对语法号(<<>>)之间。C#程序员可以使用两个标准的衍型:<<interface>>和<<utility>>。

19.3.2 抽象类

  把名字写成斜体的,或者使用(abstract)属性,即可表示抽象类:

  在白板上画图时,可以使用非正式的表示:

19.3.3 属性

  属性被书写成以逗号分隔的名字/值对列表。属性写在类名右下方:

  除了{abstract}属性,我不知道属性还有什么用处。就我个人而言,画UML图这么多年,我没有找到任何使用类属性有用的地方。

19.3.4 聚集
  聚集(aggregation)是关联的一种特殊形式,暗含整体/部分关系。

19.3.5 组合

  组合(composition)是聚集的一种特殊形式。所有者/所有物关系。

19.3.6 多重性

  对象可以含有其他对象的数组或者集合,也可比不同的实例变量中持有许多其他同类对象。多重性表达式可以是简单的数字、范围或者两者的组合。

允许的多重性格式:

数字——元素的确切数目;

*或者0..*——0个到多个。

0..1——0个或者1个,在C#中,常常用可以为null的引用来实现。

1..*——1个到多个。

3..5——3~5个

0,2..5,9..*——可笑,但却是合法的。

19.3.7 关联衍型

<<create>>衍型意味着源创建出目的并把它传递给系统的其他部分。

<<local>>衍型意味着创建出来的实例的生存期就在创建它的成员函数的作用域之内。

<<parameter>>衍型表示源类通过某个成员函数的参数获取对目标实例的访问权。虚依赖箭头线是一种常用且方便的参数表示惯用法。

<<delegate>>衍型表示源类把一个成员函数调用转交给目标。


19.3.8 内嵌类

  
19.3.9 关联类 

  虽然多重性关联告诉我们源和许多目标实例相连,但是从图中我们却无法看出使用了哪种容器类。可以通过关联类来描述这一点。

19.4 结论
  要避免UML中大多数神秘、复杂的特性,只要了解经常使用的部分就可以了。过少使用UML几乎总是比过多使用要好。

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

转载请注明出处:

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

时间: 2024-10-25 11:14:41

敏捷软件开发:原则、模式与实践——第19章 类图的相关文章

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

一.敏捷软件开发宣言 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类.一个应用程序是有关计算几何