因为学习ACE的过程中，有些涉及到Leader/Follow模式，不是很明白，特从网上找来此篇文章。Leader/Follow模式通常情况下，L/F可以用下图进行描述：通常情况下，对于服务器中的进程采用的都是即时创建的策略，即一旦有一个新的客户端请求立即创建一个新的进程或者线程，而当进程或者线程执行完毕后，进程和线程也随之退出。显然这种策略对于小规模的服务器还能接受，但是如果对于大

图一:此实线箭头表示, 继承, 从一个非接口类的继承.图二:那条连线表示双向关联:看左边, Flight扮演assignedFights角色, 有0到1个Plane跟他关联(一个航班要么取消了没有飞机,要么只能对应一架飞机)看右边, Plane扮演着assignedPlane角色, 有0到多个Flight跟他关联(一个飞机可以参与多个航班, 也可以停在仓库里面烂掉)图三:

 一、  叙述基于UML的面向对象分析设计过程１）识别系统的用例和角色 首先对项目进行需求调研，依据项目的业务流程图和数据流程图以及项目中涉及的各级操作人员，通过分析，识别出系统中的所有用例和角色；接着分析系统中各角色和用例间的联系，再使用UML建模工具画出系统的用例图，同时，勾画系统的概念层模型，借助UML建模工具描述概念层类图和活动图。 ２）进行系统分析，并抽象出类 系统分

在学习Thinking in Patterns chapter 18: Complex system states中的StateMachine的前半部分时（TIPatterns.htm#_Toc41169779），与我原来看那本System Analysis and Design中文译本中的UML建模中的状态图作了一下比较。发现二者有比较大的区别，故把状态图的有关知识再复习了一下。下面是我

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。      状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。状态机用于对模型元素的动态行为进行

developerWorks 中国  >  Rational  > 如何绘制 UML 活动图(Activity Diagram) 记录您所作的一切

 活动图 活动图是活动视图的表示法（如图 7-1）。它包括一些方便的速记符号，这些符号实际上可以用于任何状态图，尽管活动图和状态图的混合表示法多数时候都很难看。 活动状态表示成带有圆形边线的矩形，它含有活动的描述（普通的状态盒为直边圆角）。简单的完成转换用箭头表示。分支表示转换的监护条件或具有多标记出口箭头的菱形。控制的分叉和结合与状态图中的表示法相同，是进入或离开深色同步条的多个箭头。

  浏览了博客园的许多三层/多层设计文章，花了几天时间，自己动手写了个代码来实验这样设计的优缺点。希望在这个实验系列的过程中，能和朋友们一起学习，一起进步。    本文章系列是基于VS2008框架平台进行代码编写的，数据库会用到SQLServer2005 Express和Access2003。    设计的分层架构，层与层之间应该是松散耦合的。之所以这样做，是为了实现层与层之间的“可替换”

    实体类是对象实体在系统中的表示。它贯穿于整个架构，负担着在各层次及模块间传递数据的职责。很多情况下，实体类和数据库中的表（这里指实体表，不包括表示对应的关系表）是一一对应的。但这并不是一个限制，在复杂的数据库设计中，有可能出现一个实体类对应多个表，或者交叉对应的情况。在本实验中，实体类和表是一一对应的，并且实体类中的属性和表中的字段也是对应的。用户对象User实体CodeC

 这里的动态配置工厂，是指添加一个产品类时，不必去修改工厂类的代码，即可使工厂具备创建产品的能力。为了描述简便，代码采用教科书中方式而非实际的代码。 我们有以下一组类： //vehicle.hclass Vehicle{public:    Vehicle(){}    virtual ~Vehicle(){}    virtual void Start

1.  关联：连接模型元素及链接实例，用一条实线来表示；2.  依赖：表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示；3.  聚集：表示整体与部分的关系，用一条实线加空心菱形来表示；4.  组成：表示整体与部分的有一关系，用一条实线加实心菱形来表示；             （关联，依赖，聚集，组成的异同见后描述）5.  泛化（继承）：表示一般与特殊的关系，用一条实线加空心箭头来表

阅读提示：这是关于统一建模语言、即UML 里采用的基本图的文章。在这篇文章中，我将会讨论结构图，这是已经在 UML 2 中提出的一种新图种类。由于本系列文章的目的是使人们了解记号元素及它们的含意，该文主要关注类图。你很快就会知道这样做的理由。随后的文章将会覆盖结构范畴中包含的其它图。 这是关于统一建模语言、即UML 里采用的基本图的文章。在这篇文章中，我将会讨论结构图，这是已经在 UML 

1。依赖与关联 关联分为两种：单向，双向。 在双向关联中，A－－－－（应该是实线）B A知道B的公开属性与操作，反之亦然。所以，在顺序图中两者可以相互发消息。在单向关联中，AB知道A的公开属性与操作，但反之不然。所以，在顺序图中B可以给A发消息，但A不能给B发消息。 依赖：一个类引用另一个类。 A与关联的区别是：上面表示B要设法知道A的存在，B依赖于A。但B

)是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。      协作图(Collaboration Diagram)显示某组对象如何为了由一个用例描述的一个

协作图是一种类图，它包含类元角色和关联角色，而不仅仅是类元和关联。类元角色和关联角色描述了对象的配置和当一个协作的实例执行时可能出现的连 接。当协作被实例化时，对象受限于类元角色，连接受限于关联角色。关联角色也可以被各种不同的临时连接所担当，例如过程参量或局部过程变量。连接符号可以 使用构造型表示临时连接（《 parameter 》或《 local 》）或调用同一个对象（《 self 》）。虽然整

  <!--google_ad_client = "pub-5787667741565849";//300x250, 创建于 08-1-8google_ad_slot = "9612057855";google_a

1、  传授设计模式中存在的问题我个人最近对设计模式中的工厂模式进行了比较深入的学习，通过学习感悟出现在很多设计模式传道者，在讲述设计模式的过程中存在一些问题，使得设计模式变得很难理解。设计模式本身很抽象，但是这些传道者在讲述的过程中，将一个抽象的东西讲的更抽象，从而使我们望而却步。有些人在讲述的时候，没有考虑读者的注意力。比如我在看《C#设计模式》的时候，在讲述抽象工厂模式的时候，直接就进入了一

1。abstract   factory     2。builder     3。factory   method     4。prototype     5。sigleton   贴上copy过来的文章，大家认为下面真的是抽象工厂吗？    －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－    Abstract   Factory,   Template   St

I、创建型模式1、ABSTRACT FACTORY球场作为一个抽象工厂，可以举办球赛（产品）。法兰克福球场作为一个具体工厂，生产 具体的产品（例如巴西对法国的比赛）。你可以直接说到球场看比赛，到底是什么比赛由具体球场产生，比如盖尔森基兴球场（另一个具体工厂）就产生了英格兰对 葡萄牙的比赛。当某个具体工厂的产品发生改变的时候（比如柏林球场原来生产德国对阿根廷的比赛，后来生产XX对YY的决赛），对其他

权限架构设计一、设计说明由于现在系统的设计具有很多不可知的因素，可能存在未来的扩展，故此，在设计本权限架构时，尽可能的顾及到了未来的系统扩充和可操作性、可维护性。把此权限架构作为一个独立的模块进行开发，方便未来的其他系统应用。 设计说明：本架构采用树型权限模型处理，所有节点，都可以作为权限的实体存在。如：         |--权限A         |----