我的学习笔记

数组 (Array)

　　在程序设计中，为了处理方便， 把具有相同类型的若干变量按有序的形式组织起来。这些按序排列的同类数据元素的集合称为数组。在Ｃ语言中， 数组属于构造数据类型。一个数组可以分解为多个数组元素，这些数组元素可以是基本数据类型或是构造类型。因此按数组元素的类型不同，数组又可分为数值数组、字符数组、指针数组、结构数组等各种类别。

栈 (Stack)

　　是只能在某一端插入和删除的特殊线性表。它按照后进先出的原则存储数据，先进入的数据被压入栈底，最后的数据在栈顶，需要读数据的时候从栈顶开始弹出数据（最后一个数据被第一个读出来）。

队列 (Queue)

　　一种特殊的线性表，它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作。进行插入操作的端称为队尾，进行删除操作的端称为队头。队列中没有元素时，称为空队列。

链表 (Linked List)

　　是一种物理存储单元上非连续、非顺序的存储结构，数据元素的逻辑顺序是通过链表中的指针链接次序实现的。链表由一系列结点（链表中每一个元素称为结点）组成，结点可以在运行时动态生成。每个结点包括两个部分：一个是存储数据元素的数据域，另一个是存储下一个结点地址的指针域。

树 (Tree)

　　是包含n（n>0）个结点的有穷集合K，且在K中定义了一个关系N，N满足 以下条件：

　　（1）有且仅有一个结点 k0，他对于关系N来说没有前驱，称K0为树的根结点。简称为根（root）。　（2）除K0外，k中的每个结点，对于关系N来说有且仅有一个前驱。

　　（3）K中各结点，对关系N来说可以有m个后继（m>=0）。

图 (Graph)

　　图是由结点的有穷集合V和边的集合E组成。其中，为了与树形结构加以区别，在图结构中常常将结点称为顶点，边是顶点的有序偶对，若两个顶点之间存在一条边，就表示这两个顶点具有相邻关系。

堆 (Heap)

　　在计算机科学中，堆是一种特殊的树形数据结构，每个结点都有一个值。通常我们所说的堆的数据结构，是指二叉堆。堆的特点是根结点的值最小（或最大），且根结点的两个子树也是一个堆。

散列表 (Hash)

　　若结构中存在关键字和K相等的记录，则必定在f(K)的存储位置上。由此，不需比较便可直接取得所查记录。称这个对应关系f为散列函数(Hash function)，按这个思想建立的表为散列表。

注：非原创

UML类图

使用UML类图，我们可以表示出类的静态内容以及它们之间的关系。在类图中，我们可以显示出类的成员变量和成员函数，以及类之间的继承和引用关系。简而言之，我们可以描绘出类之间所有源码级的依赖关系。 在UML中一个类表示为如下图：

类图中变量和函数名前面的符号。短横线（-）表示private;井号（#）表示protected;加号（+）表示public; 变量和函数参数的类型显示在变量和参数后面的冒号之后。同样，函数的返回值显示在函数后面的冒号之后。

=====================================================================================================

UML中类的主要关系有：依赖、关联、聚合、组合、泛化（继承）。

1.依赖：

在UML中，依赖的图形表示是虚线+箭头，箭头指向被依赖的类，在程序代码中，具有依赖关系的类常常被声明为成员函数的参数，而不声明为类的成员变量。如下图：

=================================================================================

2.关联：

在UML中，关联的图形表示是实线+箭头(如果没有加箭头，则是双向关联），箭头指向被关联的类，在程序代码中，具有关联关系的类常常被声明为类的引用类型的成员变量。如下图：

=================================================================================

3.聚合：

在UML中，聚合的图形表示是空心菱形+实线+箭头，箭头指向被拥有的类，聚合是关联的一种特殊形式，暗含整体/部分关系，但是对方却不是唯一属于自己的那种关系。UML为我们提供了一个非常简单的关于聚集的硬性规定：整体不能属于其组成部分。如下图：

例如：Wheel类扮演wheels角色, 聚合4个到Car对象里面去,空心的菱形表示Wheel对象并不随Car的创建而创建,销毁而销毁.

=================================================================================

4.组合：

在UML中，聚合的图形表示是实心菱形+实线+箭头，箭头指向被拥有的类，UML中的组合关系是指两个类之间有严格的所属关系，一般是整体和部分的关系，而且对方是唯一属于自己的那种关系。这同具有关联的类和具有聚合的类一样。区别在于组合关系中该类不能被其它类共享，所以类的生命期是完全被所属类控制的。如下图：

例如：意义和上面类似, 唯一不同的是，实心菱形表示Department对象随Company对象的创建而创建,销毁而销毁.

===========================================================================

5.泛化（继承）：

UML中的所有箭头都指向源代码依赖的方向，因此，箭头指向基类。在UML中使用箭头时要非常的小心，如果画箭头时比较粗心那么就可能难以分辨是继承还是关联，为了清楚起见，总是把继承关系画成纵向的，关联画成横向的。如下图：

在接口继承关系称为实现，连接线使用虚线，如下图：

转载自：http://www.cnblogs.com/playing/archive/2011/04/16/2017870.html

用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。

用例图包含２个元素和４种关系：

1. 参与者(Actor)；
2. 用例(Use Case)，即一个动作；
3. 关联关系(Association)
4. 包含关系(Include)
5. 扩展关系(Extedn)
6. 泛化关系(Generalization)

(以下转自百度百科)

编辑本段简介

　　用例图定义：由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。

用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

　　用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。

　　将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

　　用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。

编辑本段构成

　　用例图由参与者

参与者

（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者

　　参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例

　　用例

用例

是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界

　　系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头

　　箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

编辑本段作用

　　用例图

USE CASE图

主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。

元素之间的关系 用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

角色之间的关系

　　角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系：

　　包含关系：基

USE CASE图

本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

　　泛化关系：代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

　　扩展关系的基本含义和泛化关系类似，但在扩展

USE CASE图

关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

　　用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以

USE CASE图

在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

用例之间的关系举例

　　包含：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

　　扩展：系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。

　　泛化：子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

转自：http://www.cnblogs.com/fan0136/archive/2008/12/14/1354730.html

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。
    *****************************************************************
    (1)系统整体用例图

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别
泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
          ●泛化侧重表示子用例间的互斥性；
          ●包含侧重表示被包含用例对Actor提供服务的间接性；
          ●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
         ⒈无条件发生：肯定发生的；
         ⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

    毕业后，此书带我进入面向象编程的世界。但当时只是入门，还没真正理解。现在，还是有人问题什么是面向对象，只是简单地回答封装、继承和多态显然是未能很好地解释。现在编程工作中，离不开OOP，但为什么是要用OOP，怎样才是好的OOP，其实我心中还是像有一层纱，好像是知道，但说不出来来。

    为了成了一个出色的程序员，决定重新学习（温习）一切与编程有关的知识与技巧。今天，就由这本书开始，重读《面向对象》。什么还是Delphi，现市面上多不胜数C#、JAVA等主流语言关于面向对象编程书箱，那不是更好吗？虽然OOP与语言本身相关不大，只要是OOL就行，但毕竟Delphi是我的第一编程语言，理解起来也更容易。当然，我也不会排斥阅读其它语言的书籍。

内容简介

　　这是一本纯粹讨论dlephi面向对象编程的力作。
　　本书以精通叫delphi面向对象编程为目的，深入浅出地讲解了delphi面向对象的概念和实质、方法和经验、思想和实践；详尽讨论了delphi建立在虚方法、抽象方法、对象接口等动态绑定机制上和向上转型、向下转型、接口转型等类型转换机制上的面向对象高级技巧；并深入研究了通过封装从而实现界面和业务对象的分离，从界面和业务分离逐步实现分布式多层体系结构，进而实现界面和业务应用的跨平台的企业级解决方案。本书还提供了vcl的内幕资料和研究心得。
　　全书使用delphi7附带的modelmaker实现ul比对象建模，并附有大量delphi源代码实例，方便读者研究学习。 本书适用于有一定delphi基础，并希望掌握面向对象编程思想和方法，进一步提升水平的软件开发人员。同样，已经掌握面向对象编程的java和c++程序员通过本书亦能快速掌握delphi编程。
　　本书还适合大专院校用于基于object pascal/delphi的面向对象编程教学。

　　“选择面向对象编程就意味着你需要抛弃某些可视化编程方法。”
　　　　　　　　　　　　　　　　　　　　　　　　　　———marcocantu
　　“以非面向对象的方法使用面向对象的工具是一个错误。使用delphi编写结构化程序可以很快地到达beta 版……你的程序可能永远脱离不了beta版。能迅速得到错误的答案，仍然是错误的。”
　　　　　　　　　　　　　　　　　　　　　　　　　　———paul kimmel
　　“请记住，成功的开发者只需写少量的高质量代码，而不是大量的普通代码。”
　　　　　　　　　　　　　　　　　　　　　　　　　　———grady booch
　　本书主要内容：
　　●面向对象编程入门和delphi的对象模型。
　　●理解delphi对象的实质，活用delphi对象的技巧。
　　●多态、接口、虚方法、抽象类等概念的剖析和面向对象编程上的具体应用。
　　●建立在动态绑定机制上和类型转换机制上的面向对象高级编程技巧。
　　●为了实现程序的可维护性、可扩展性和可重用性，而对封装、界面和业务对象的分离、分布式多层体系结构以及实现界面和业务应用跨平台的深入讨论。
　　●vcl的内幕资料和研究心得。 　

http://product.china-pub.com/14357#ml

    很幸运，在职业叉交口迷茫的时间，在书店看到这本书。我想很多和我一样的程序员一定不少，编程几年后，不知为何工作，出路在何方。或者受到外界如职位、环境等吸引，放弃本来的目标。认真看看此书，从新找回自己。

    最喜欢的章节：第2单 空杯心态，和第3章的“只求最差”一节

内容简介

作为一名软件开发者，你在奋力推进自己的职业生涯吗？面对今天日新月异和不断拓展的技术，取得成功需要的不仅仅是技术专长。为了增强专业性，你还需要一些软技能以及高效的学习技能。本书的全部内容都是关于如何修炼这些技能的。两位作者dave hoover和adewale oshineye给出了数十种行为模式，来帮你提高主要的技能。
本书中的模式凝结了多年的调查研究、无数次的访谈以及来自o’reilly在线论坛的反馈，可以解决程序员、管理员和设计者每天都会面对的困难情形。本书介绍的不只是经济方面的成功，学徒模式还把软件开发看成一种自我实现的途径。读一读这本书吧，它会帮你充分利用好自己的生命和职业生涯。
厌倦了自己的工作？去找一个玩具项目来帮你重拾解决问题的乐趣吧，这叫“培养激情”。
感觉要被新知识淹没了？做点以前做过的事情，重新探索一下自己熟悉的领域，然后通过“以退为进”再次前进。
学习停滞了？那就去寻找一支由富有经验和才能的开发者组成的团队，暂时呆在里面“只求最差”。

http://product.china-pub.com/196977