概览：
页面缓存->页面片段缓存->数据缓存->分布式数据缓存
http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
http://kazge.com/archives/210.html
http://kazge.com/archives/661.html
Squid 设计与规划
http://oss.org.cn/ossdocs/column/chedong/cms.html
缓存的分类:http://blog.csdn.net/zhghost/article/details/5344962
http://kazge.com/archives/662.html
Continue reading 大型站点缓存技术
Internet的规模每一百天就会增长一倍，客户希望获得7天24小时的不间断可用性及较快的系统反应时间，而不愿屡次看到某个站点“Server Too Busy”及频繁的系统故障。
网络的各个核心部分随着业务量的提高、访问量和数据流量的快速增长，其处理能力和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量的需求。于是，负载均衡机制应运而生。
负载均衡(Load Balance)建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
什么是负载均衡
负载均衡(Load Balance)
由于目前现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。
针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡(Load Balance)。
负载均衡技术主要应用
1、DNS负载均衡
最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。
2、代理服务器负载均衡
使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。
3、地址转换网关负载均衡
支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。
4、协议内部支持负载均衡
除了这三种负载均衡方式之外，有的协议内部支持与负载均衡相关的功能，例如HTTP协议中的重定向能力等，HTTP运行于TCP连接的最高层。
5、NAT负载均衡
NAT(Network Address Translation 网络地址转换)简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。
6、反向代理负载均衡
普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
7、混合型负载均衡
在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群)，从而达到最佳的性能。我们将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。
哪些地方需要使用负载均衡
在国内的环境中有三个地方可以使用到这个功能，首先应该是网吧，网吧对带宽的要求较高，而因为国内ISP混乱的情况，有些网吧也会用到多线路接入，所以负载均衡对网吧是很实用的功能，其次是企业和小区运营商。企业也会有这样的需求，有些企业对网络要求也很高，甚至没有网络就不能办公。另外就是小区运营商了，小区运营商也有很多使用多线路接入，这样负载均衡也就很适合了。
如何使用负载均衡
现在很多路由都带有负载均衡功能，可以直接在路由上设置然后使用，比如软路由海蜘蛛、ROS等，硬路由有侠诺，飞鱼星等。需要注意的是最好在使用前了解清楚路由的具体的型号支不支持。
软/硬件负载均衡
软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的优点是基于特定环境，配置简单，使用灵活，成本低廉，可以满足一般的负载均衡需求。
软件解决方案缺点也较多，因为每台服务器上安装额外的软件运行会消耗系统不定量的资源，越是功能强大的模块，消耗得越多，所以当连接请求特别大的时候，软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好，受到操作系统的限制;由于操作系统本身的Bug，往往会引起安全问题。
硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。
负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。
一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。
本地/全局负载均衡
负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance，也叫地域负载均衡)，本地负载均衡是指对本地的服务器群做负载均衡，全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。
本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题，并且不需花费昂贵开支购置性能卓越的服务器，充分利用现有设备，避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级，也只是简单地增加一个新的服务器到服务群中，而不需改变现有网络结构、停止现有的服务。
全局负载均衡主要用于在一个多区域拥有自己服务器的站点，为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器，从而获得最快的访问速度，也可用于子公司分散站点分布广的大公司通过Intranet(企业内部互联网)来达到资源统一合理分配的目的。
全局负载均衡有以下的特点：
实现地理位置无关性，能够远距离为用户提供完全的透明服务。
除了能避免服务器、数据中心等的单点失效，也能避免由于ISP专线故障引起的单点失效。
解决网络拥塞问题，提高服务器响应速度，服务就近提供，达到更好的访问质量。
Continue reading 负载均衡技术的原理及分类
鲁棒性翻译为健壮性:
鲁棒图（Robustness Diagram）'的作用有两点，除了初步设计之外，就是检查用例规约是否正确和完善。'鲁棒图'正是因为第2点作用而得名的--所以严格来讲'鲁棒图（Robustness Diagram）'所指的不是'鲁棒性（Robustness）'。
从Doug Rosenberg在《用例驱动的UML对象建模应用》的描述中，也可得到上述结论：
在ICONIX过程中，鲁棒分析扮演了多个必不可少的角色。通过鲁棒分析，您将改进用例文本和静态模型。
有助于确保用例文本的正确性，且没有指定不合理或不可能的系统行为（基于要使用的一组对象），从而提供了健康性检查（Sanity Check）。这种改进使用例文本的特性从纯粹的用户手册角度变为对象模型上下文中的使用描述。
有助于确保用例考虑到了所有必需的分支流程，从而提供了完整性和正确性检查。经验表明，为实现这种目标，并编写出遵循某些定义良好的指南的文本，而在绘制鲁棒图上花费的时间，将在绘制时序图时3～4倍地节省下来。
有利于发现对象，这一点很重要，因为在域建模期间肯定会遗漏一些对象。您还可以发现对象命名冲突的情况，从而避免进一步造成严重的问题。另外，鲁棒分析有利于确保我们在绘制时序图之前确定大部分实体类和边界类。
如前所述，它缩小了分析和详细设计之间的鸿沟，从而完成了初步设计。
参见:
http://xueqi.iteye.com/blog/1001577
Continue reading 鲁棒性，容错性，鲁棒分析，鲁棒图
可以这么去理解，“抽象工厂模式”这个称呼中的“抽象”是一个动词，即对工厂方法模式进行了抽象，就变成了抽象工厂模式，这么理解后，就不难看出它们的区别：
工厂方法模式：每个抽象产品派生多个具体产品类，
抽象工厂模式: 每个抽象工厂类派生多个具体工厂类，每个具体工厂类负责一个具体产品的实例创建；
工厂：
Continue reading 工厂方法模式与抽象工厂模式的区别 http://www.infoq.com/articles/perera-data-storage-haystack Continue reading 【链】为你的应用程序找到合适的数据存储解决方案 见http://www.infoq.com/news/2011/04/newsql nosql听说过，newsql…… . 啊这技术名词更新太快了！ 一图顶千言: Continue reading 【链】NoSQL, NewSQL 还有其它 switch 语句可以用字符串了,try-with-resources 语句(jdbc4.1[jdk7的一部分]新特性就是基于这一点)等 1. 驱动及连接管理 2. 异常处理 3. 数据类型支持 sqlxml(为什么不是json?) 4. API 的变化 jdk7的try资源特性，rowset改进。 异步处理支持 还可以，参见异步io:https://blog.kazge.com/%E8%AE%A1%E7%AE%97%E6%9C%BA%E5%9F%BA%E7%A1%80/2011/10/21/io-e6-8e-a5-e5-8f-a3-ef-bc-8c-e8-ae-be-e5-a4-87-ef-bc-8c-e6-93-8d-e4-bd-9c/ 以及http://www.ibm.com/developerworks/cn/java/j-nioserver/ 如果是使用nio实现的话，倒更像多路io。 一个简单的模拟异步处理的 Servlet 示例如下： Continue reading jdk7,jdbc4,servlet3.0 方法概要 1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。 1 分析并确定输入数据和输出数据的逻辑结构，并用Jackson结构图来表示这些数据结构 分析并确定输入数据和输出数据的逻辑结构，并用Jackson结构图来表示这些数据结构。 2 找出输入数据结构和输出数据结构中有对应关系的数据单元 找出输入数据结构和输出数据结构中有对应关系的数据单元。 3 按既定规则由输入、输出的数据结构导出程序结构 规则一：对每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框。 规则二：根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。 规则三：根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。 4 列出基本操作与条件，并把它们分配到程序结构图的适当位置 列出基本操作与条件，并把它们分配到程序结构图的适当位置 5 用伪码写出程序 与三种基本结构对应的伪码是： 顺序结构： 图中的“O”表示选择，“*”表示重复；在顺序结构中，表示A由B和C两部分组成；在选择结构中，表示A可以包古B或c；在循环结构中，表示A由B重复H次组成。 Jackson图具有如下优点： 缺点是: 用这种图形工具表示选择或重复结构时,选择条件或循环结束条件不能直接在图上表示出来,影响了图的表达能力,也不易直接把图翻译成程序,此外,框间连线为斜线,不易在行式打印机上输出.为了解决上述问题,我们建议使用改进的Jackson图. 面向数据流的分析方法 1975年，英国人M.A.Jackson提出了软件工程领域中著名的Jackson方法，当时它只用于软件设计。1983 Jackson方法在需求分析阶段的主要步骤是： 类似于面向对象分析中对象及其行为的识别，Jackson方法针对初步需求分析形成的用户需求描述进行语法分析： 在Jackson方法中，实体结构是指实体在时间坐标系中的行为序列。这种序列以顺序、选择和重复三种结构 参见: http://211.64.47.133/web/kcghjs/wwb_rjgc/subject/kejian/7.pdf 面向数据的分析方法 Continue reading Jackson设计方法和JACKSON分析方法 Maureen Field ([email protected]), Group Leader, IT Project Office, Ford Credit Venkat Alladi, Process Methodologist, Ciber, Inc. 简介： 本文来源于 2003 年 Rational 用户大会的一个演讲稿，这个学习案例的研究讨论了一个公司成功的开发和部署以 IBM RUP 作为过程框架的迭代开发方法的真实经验。实现一个标准的过程和这个过程为开发组织提供的未来机会也将在本文中被关注。 本文被划分为五个部分。首先是一个简要的介绍，然后我们将讨论我们的开发工作，随后我们将讨论我们的部署工作、经验教训和对本文的总结。 这个案例研究是一个现实世界的真实的经历，它是关于我们的团队如何成功的开发和部署一个使用 RUP® 作为过程框架的迭代开发的方法的。这是福特公司和福特金融信贷公司共同工作的结果。福特金融信贷公司是福特公司的一个全资控股子公司，并且是汽车金融的最大供应商。我们在四十个国家为超过 11,000 个经销商提供车辆金融服务，并且自从 1959 年以来我们已经为超过五千万量汽车提供了贷款服务。我们以福特金融而闻名，通常媒体称我们为福特信贷。我们拥有超过 700 个职员的庞大的 IT 队伍。 我们很难跨越项目实现项目交付产物的共享。每一个团队都拥有自己的一套模板和他们自己的方法。当职员被从一个团队调到另一个团队时，他们必须学习新的方法。同时我们也很难利用公共团队。这些团队是外部的应用团队，他们提供良好的产品和项目服务。服务团队的例子包括象 DA 、DBA 、框架团队和构建团队。每个服务某一方面的应用团队都有不同的交付产物集合，因此他们没有一个公共的过程框架。 我们也有些晚的在项目中包含这些服务团队，因此导致了一些问题。人们在需要进入产品化阶段时才想起构建团队，而不是在适当的时候联系他们。 此外，我们的框架架构师一直被过程问题压的喘不过来气。框架架构师的工作是设计并维护我们的设计模式；相反他们一直被询问如何组织一个项目、什么过程应该被使用和项目应该有多少迭代。那不是他们的工作。 项目也正感觉到了另一个痛处：过晚的项目风险的识别。我们有一个必须连接数据仓库和为报告目的返回信息的项目。他们将这个需求留到了最后的时刻，并发现应用的性能不是足够快的。这对项目造成了很大的影响。 最重要的是，这种对拥有一个公共过程的努力是一个拉动的工作，而不是一个推动的工作。我们并没有在我们的组织中推进这种方法。而是我们被要求实施一个公共的软件开发过程。 在我们的组织中我们拥有一些在 RUP 方面的技术专长。我们也知道 RUP 是可以定制的。一些框架团队的人员说他们非常了解 RUP ，并起草了一份一页纸的 RUP 的概要，这显然是被过份的裁剪了。 我们也知道无论在公司内还是公司外我们都已经拥有丰富知识的资源。我们知道 RUP 提供了一个丰富的被在工业中清晰定义和良好理解的术语集合，我们也知道这是 RUP 真正的优势。RUP 的工业领先的位置给了我们和我们的管理层很大的信心。 RUP 是可以高度定制的，并且我们知道我们必须要做什么。 首先我们在六个项目中尝试使用 RUP ，这些项目覆盖了四个不同的业务领域。然后我们在公司论坛中推动大家对 RUP 的了解。RUP 已经在一些项目人员群体中有了一定的立足空间了，这给了我们很大的鼓励。我们确定了公司中的领域问题专家（SME）。然后我们开始了两个项目：一个负责开发 RUP 的自定义版本，另一个负责部署开发出来的自定义的 RUP 版本。我们的产出结果是我们称作为统一方案交付方法或者 USDM 的过程实例。它是基于 RUP 的，但是对于福特公司特定的组织和项目是需要定制的。例如，我们必须包括内部的控制考虑和我们的数据和记录的保留政策。此外，我们必须包括按照福特公司熟知的工作家族来定义角色。 USDM 也是非常注重实效的以保证实现真正的价值，甚至是对于快进度的项目，并且它也是足够灵活的以便我们能够使用它来满足我们众多项目的需要。 我们将开发工作作为一个项目来实施。（见图 1） 图 1:开发项目 我们有一个目标，这个目标是针对福特的需要创建一个健壮的并且注重实效的面向对象的开发过程。我们同时还确立了这样的目标：定制 RUP 、开发培训和定义一个支持的组织。我们的时间限定在六个月，我们拥有三个资源：三个方法专家将工作在这个项目中。 我们所要执行的步骤被列在图 2 中。 图 2:在开发项目中的步骤 通过我们对 RUP 的实施 ，那六个我们尝试的项目，我们确定了 USDM 的进入标准。在福特信贷公司中所有的项目都必须使用对象技术。对于我们来说，就是 J2EE 。我们通过浏览 RUP 的产物准备我们过程中的产物，然后决定哪一个是我们需要的，哪一个是我们不需要的。之后我们为过程方法添加了福特特有的一些过程。在福特公司我们有很多我们自己的工作产物和被需要的过程。 我们文档化了服务团队的角色和职责以及这些不同的团队应该在一个项目中包括过程的哪些方面。我们也通过识别进入和退出初始、细化、构建和转换阶段意味着什么定义了阶段的出口标准。此外，我们创建了简化的工作流。我们接受了 RUP 中已有的工作流程，一些工作流程按照 RUP 中的定义那样使用，另一些被我们进行了有意义的简化。 我们细化了词汇表并合并添加了一个推荐的读物列表。我们创建了一些培训材料。此外，我们搜集了一些工作产物的样例并定义了我们的支持组织。最重要的是，我们创建了一个 Web 网站。所有的结果产物构成了 USDM 。 我们通过创造拥有权的感觉和将服务团队作为 SME 包含在项目当中合并了服务团队（组织外部的提供服务和向应用团队提供产品的应用团队）。然后我们确定服务团队过程的入口点 — 他们应该什么时候进入项目。这是非常重要的并且添加了很大的价值。接下来我们将服务团队的职责映射到了适当的活动或者工作流程中。我们建立了与服务团队管理层的良好关系，这一点对我们是非常重要的。 每一个项目都面临着挑战。我们遇到了组织的复杂性和鸡与蛋的问题。当我们尽力的改进我们过程时我们必须要进行培训，同时我们有好怀疑的指导团队的参与者。在我们尝试 RUP 实现过程中与我们一起工作的指导团队的一些经理是顽固的。经理们想要看到接下来六个月项目计划的每一个最终的细节，否则他们是不满意的。他们想预先知道每一件事情。我们必须说服他们这与他们管理的项目类型的做法是不同的。 在我们的 SME 中也存在着不一致的看法。无论什么时候进入专家们讨论的房间，你都会听到很多的看法，这些看法都是明确的针对我们的案例的。我们也很难协调在福特公司和福特信贷公司之间的工作（比如，什么时间在哪里我们应该进行会议）。 我们也很难拥有在福特公司和福特信贷公司的项目管理方法论。因为那些福特公司的管理人员，甚至虽然他们是我们项目的发起者，并不理解我们项目的管理方法论，因此对我们来说产生了一些问题。他们不理解什么应该被包括在项目中、一个项目的发起者意味着什么和他们的职责是什么。 总而言之，在 USDM 中我们有大约 20 个工作产物。我们也拥有定义良好的与服务团队的连接点。我们拥有简化了的工作流程。我们拥有定义良好的支持组织，包括指导服务，我们发现指导服务是极其重要的。我们的整个过程都在一个全面的网站上被描述出来。 当我们定制 RUP 的一个关键产物时我们引入了一个项目的章程，这个项目章程代替了 RUP 中的远景文档。我们创建了一个系统架构文档。我们采用了 RUP 中的系统架构文档，并对这个文档进行了一些重要的改变以满足福特公司和福特信贷公司的需要，同时也改变了文档的名字。我们也创建了一个有用的被称为风险用例映射的产物，它被用于根据用例划分风险的等级或者优先级。 图 3 显示了一些关键的产物。 图 3:核心的产物 图 4 显示了我们定制的过程流程中的一个。 图 4:需求工程流程 我们采用了 RUP 的工程流程，并和我们的领域问题专家一起检查了这些流程，然后我们在流程中添加了一些我们决定被需要的额外活动。 然后我们必须让组织了解 USDM ，这可以通过浏览我们建立的全面的网站来完成。我们也为高层和中层的管理人员进行了关于 USDM 的介绍。我们引导大家来了解 USDM 并在公司的面向对象的兴趣论坛中对 USDM 进行了介绍。这可以帮助我们使整个组织了解我们将要部署的新的方法论。 在我们开发了 USDM 这后，我们需要将它部署到我们的组织中。这个工作也被作为一个项目来实施，见图 5 。 图 5:部署项目 我们的目标是实现能够提供所有必要的支持和指导服务的 USDM 支持中心，以便 USDM 能够被容易的理解并在组织中使用。 我们的目标是建立一个支持中心的过程，产生和交付适当的培训材料，并且伴随过程的度量方法。 部署的步骤被显示在图 6 中。 图 6:部署项目 我们建立了一个变更控制过程。我们定义了一个指导认证的过程和指导的程序。当我们想让服务团队了解我们的过程是怎样的并且他们应该在什么时候和如何使用我们的过程时，我们也为我们的服务团队开发了培训材料。然后我们定义并签署了服务团队协议。（这些协议的一个是关于框架团队的，我们知道他们希望在项目的早期就被包含进来）。最重要的是，我们向合格的项目交付和部署了指导服务。 我们的支持组织有两种武器，如图 7 所示。 图 7:支持组织 一种武器是研究行业并开发和维护过程的产品。他们是支持团队持续改进的部分。另一种武器能够帮助应用团队。我们拥有指导人员来提供培训，我们觉得培训真的是非常的重要，并且已经使我们成功的应用过程。 我们也创建了一个描述变更控制过程如何工作的流程图。我们想包括适当的人员，利用已有的工具进行跟踪和记录我们的建议，并且建立一个变更控制委员会。变更控制委员会包括方法专家、项目指导人员、来自服务团队的领域问题专家和管理人员。这个小组决定建议是被采纳还是被拒绝。 就像我们所提及的那样，我们的过程的一个重要的特点就是指导。好的指导能够帮助平滑的示范迁移。福特公司的大部分人员从事需求方面的所有工作、根据需求签署和约、分析和设计的工作、编码的工作和并交付能够在项目末尾阶段被集成在一个的软件产物。在我们的组织中有一些从事 Cobol 编程的人员，他们不懂任何关于面向对象编程的知识。存在大量的学习曲线要克服，我们的指导服务能够帮助消除这些学习曲线。 我们想要为这个过程确保跨组织的一致性。我们想要确保团队以项目的方式应用我们方法论，而不是在人们自己的思想趋向上使用他们。通过指导，我们获得了在过程上的立即反馈。我们希望积极的而不是被动的工作。我们想要在项目的一开始就参与其中，而不是当项目遇到麻烦时。我们的指导向各个团队展示了如何执行过程，甚至如果团队需要技术上的帮助，我们会帮助他们创建 UML 图。 过去我们仅仅是将一堆过程交给团队，然后说按照他们去做吧。结果却是非常的不好。我们也雇佣了一些顾问。他们向我们出售了一个大的过程，这过程成生了一个复杂的工作计划。过程中包括了很多任务，并且任务的名字与我们一直使用的名字是不同的。这一次我们决定我们需要手把手的指导来帮助我们的团队应用这个方法论，并且到此为止我们是成功的。 对于项目指导人员的要求是我们希望他们能够向对待病人一样始终如一的对待项目团队。他们需要具有坚实的方法论的经验。他们需要在 RUP 方面是训练有素的。他们也必须是迭代开发方面的专家。他们需要传授给项目团队可信性的技术上的经验。他们必须精通使用 UML 进行面向对象的分析与设计，并且知道如何进行项目管理。 通过我们与服务团队的协调，我们的指导人员被包括进了项目中。服务团队告诉我们项目开始时需要一名指导人员。作为一个可选的方法，我们在我们的网站上设置了一个请求按钮，以便项目能够请求一个指导人员。项目的管理沟通也应该包括指导人员。然而，我们认为指导人员的引入应该在项目管理和优先过程之前进行，而不是在项目随意的过程中引入指导人员。从开始和成为优先过程和项目管理的一部分，我们处于引入指导人员的早期阶段。福特信贷公司也有项目管理的指导人员。当项目管理的指导人员被引入到项目中时，我们希望我们的 USDM 指导人员也被引入到项目中。 项目团队的感觉是一个衡量成功的方法。我们在细化和构建阶段结束时对我们指导的团队进行了调查。我们知道我们是成功的另一种方法是当我们认为我们的服务团队能够更早的在过程中工作时，我们就已经成功了。 还有一种确认我们成功的方法是在细化阶段后对指导的要求减少了。团队能够按部就班的工作，并且他们知道他们应该做什么，他们正确的去做了。在细化阶段结束时我们的指导人员已经不被需要了。我们已经拥有按时被完成并且被良好的开始使用项目。 自从 2002 年 5 月我们已经在 18 个项目中采用了 USDM 。由于指导的要求我们已经增强了从事支持的人员，我们雇佣了其他的指导人员，并且继续保持对管理的强有力的支持。我们也发现对于需求开发的培训要求。我们正在开始培训一些业务人员，以便当他们进入项目时知道如何开发用例。我们想预先的培训他们，使他们了解在定义需求方面领导工作是他们的职责。我们已经实现了很多的变更请求，虽然我们已经有了将变得更大的记录。 我们计划制定一个供所有福特信贷公司的项目使用的标准配置管理计划。我们觉得这将为项目添加大量的价值。每一个人都将按照相同的方式做事情。他们将拥有相同的构建结构和相同的目录结构并且这将为我们带来真正的好处。我们也拥有一个标准的参考实现模型以便我们所有的项目都能够从相同的系统架构框架开始。我们正着眼于为我们的外包工作制定过程。我们已经有了一个将六个 Sigma 的概念纳入我们过程的计划。我们有一个新的基于用例的项目计划。我们也有一个项目人员安排辅助和缺陷管理过程，他们将很快的被并入到 USDM 中。 我们觉得我们没有正确的完成的事情之一是在开发和固定软件开发过程之前直到项目管理过程被完全制度化我们一直在等待。我们的项目经理们知道管理项目是什么样子。我们实际上使用了这个项目管理过程来管理我们的开发和部署项目。我们在所有的层次上获得了管理层的支持。中层管理人员是非常重要的，因为他们是与项目最接近的管理人员。我们将开发和部署工作独立出来。我们在早期就引入了服务组织的领域问题专家。我们雇佣了经验丰富的指导人员，他们拥有真正的资产。我们保持事情的简单化并适时的提供培训。 象很多项目一样，我们在得到适当的资源之前就承诺了日期。我们直到我们进入项目环境之前我们一直在等待培养业务团体。我们应该提早一点通知他们。我们花费了太多的时间来定制工作产物。我们过份的强调了我们已有产物和模板的重用，我们几乎总是回到 RUP 中，并对 RUP 的产物进行一些改动。我们花费了太多时间来讨论我们的入口标准。我们有大量的不同意见，尤其是与福特公司的人员。在我们开发这个方法论期间，我们也接受了一些具有错误技能的项目资源，并且我们低估了一些我们的项目交付产物，尤其是网站的开发。 RUP 是一个良好的开始方法。它是一个非常好的框架，可以为福特这样的公司提供所有工具和必要的信息。这个框架是非常容易定制以满足我们的需要的。我们发现的一个重要的事情是集成是关键。 RUP 是一个打包的解决方案。如果你将它带入你的组织，你仍然必须做一些工作。你不能直接为一个项目使用它。在福特信贷公司我们拥有自己的项目管理过程和其他必须集成的过程。定制是重要的。最重要的是，对于我们来说指导是制度化象 RUP 这样的过程的基本要素。 我们得到的下一个结论是保持过程的简单性。我们有项目管理、六个 Sigma 、拥有自己过程的服务团队和 RUP 。我们应该尽量简洁、清晰的显示这些过程的连接点，这样可以产生更少的产物和有限的文书工作。 在最后的分析中我们觉得与你正在通过得到有价值的反馈支持的团队享受你们的成功乐趣是重要的。 USDM 的一个关键特点是开发案例，一个我们用来为项目配置过程的重要产物。我们识别出了三个不同的项目类型：构建新应用的项目；对一个应用系统范围进行增强的项目；修改 bug 的维护项目。 使用用例模型，我们识别出对于哪些个迭代哪些用例要被开发。然后我们进行了初始的计划，计划中安排了迭代的时间。这就是我们如何开始每一个项目的。我们了解项目的范围，然后通过对时间线和迭代如何被定义的理解来创建定制的开发案例。然后开发我们的工作计划（进度表）。 基于项目的类型，我们建议哪些产物应该被使用。这是一个协作的团队工作。作为指导人员，我们与团队站在同一立场上，并讨论项目的需要。此外，在每次迭代和阶段的结束我们来确定被使用的产物是否是有价值的。如果产物没有提供价值，我们将停止使用它。 USDM 的另一个特点是为不同类型的项目工作流程的定制。对于增强或者维护项目的工作来说，你可能仅仅需要一定的活动；因此你可以重用已有的产物。例如，在增强路径的活动中，“设计用户界面”，我们也许只是检查已有的 GUI 以确定用户的交互，从而了解增强如何能够被集成到这个流程中。对于所有的工作流程或者活动，我们为增强类型的项目识别关键的事情。 过程的下一个关键特点是一个服务团队连接点的 Web 页面。我们为福特公司和福特信贷公司各建立了一个页面，因为我们每个公司有不同的服务要求。再一次说明，服务团队是提供公共资源的项目外的组织。服务团队的例子比如 DA/DBA 、可重用的团队、框架架构师、构建团队和生产管理。当应用团队使用服务团队连接点网页时他们了解在过程中服务团队应该在什么时候被联系。 USDM 的另一个关键特点是针对过程改进指导人员的使用。指导人员能够带来很大的帮助，因为他们能够始终如一的和不断的提供关于什么产物正在被使用、什么过程正在被使用和什么没有被有效的使用方面的反馈。我们就像记录变更请求一样记录了被建议的改进。然后变更控制委员会对于变更请求说可以或者不可以。如果答案是可以，我们就实施变更。 此外，我们保存了一个指导请求日值。当一个指导人员被分配到一个项目中时，我们记录一些信息，比如指导人员被估计参与项目指导的时间和针对项目的指导人员的资源分配。我们计划使用这些信息进行度量。我们正尽力的构建允许我们执行趋势分析的统计数据。我们希望使用这些信息来改经我们的过程。我们也从我们的用户得到过程改进的建议。他们使用一个简单的网站反馈表单来提交建议的改进。然后这些建议被提交到变更控制委员会。 对于培训，当团队开始一个项目时，我们为他们提供几个过程的展示。我们没有打印的过程指南。以前，福特公司的开发过程包括巨大的活页封面，有时是几卷的纸张。这一次我们决定将过程的每一件事情发布到网站上，并提供可下载的页面。这是节约成本的方法，但它的更大的好处是我们每两个月就要更新一些东西。人们可以访问这个网站，并可以得到他们需要的更新材料。我们认为这是一个有效的沟通过程和在过程中交流知识的方法。 USDM 过程的另一个特点是指导人员的网站。这个网站为我们的指导人员收藏了信息，包括一个文档化的指导过程。过程列出了当指导人员参加项目时他们要做的事情。他们要做的事情从初始阶段就开始了，也包括其他三个阶段。这是一个我们的指导人员要遵守的以在指导工作中促进一致性的指导方针。我们也有一个指导认证程序，新加入的指导人员必须通过这个认证过程以确保他们理解了福特公司和福特信贷公司特定的组织过程，从而使他们能够一致的指导我们的应用团队。 我们的 USDM 网站非常类似于 RUP 的过程工具，但用起来更加简单。在 RUP 中有更多的特性，我们主要是为我们的指导人员使用这些特性作为辅助的工具。我们的所有的工作产物和模板都存储在 USDM 网站上。 你什么时候开发 Web 网站，你使用了 WorkBench 或者 任何其他的 Rational 工具了吗？ 我们唯一使用的工具是 RUP 的过程工具。我们没有使用 WorkBench 或者其他的工具。我们开发了我们自己的 Web 网站； RUP 不在下面。我们作为方法专家在我们的桌面是有 RUP ，但是团队并不能访问它。 在未来你将包括遗留的、非面向对象的开发吗？ 目前来看，我们还没有这方面的计划。组织，福特公司，也有另一个 SDM ，被叫作 Classic SDM ，我们使用它来进行我们的主机系统和瀑布型的开发。那就是我们现在的计划，虽然我们有对 USDM 进行一些变化以使我们能够为两种开发使用我们的基于 RUP 的过程的想法，但是从策略上看还不能立即实施。目前来看，我们只是对我们的使用了对象技术的开发项目使用 USDM 。 在应用 RUP 后，你看到了在时间和质量上的改进了吗？ 我的确看到了在质量上的改进。项目按时完成了，客户对项目更加的满意了。商业客户自始自终的被包括在项目中。他们能够更早的在细化阶段对系统进行测试，这导致在项目的后期有更少的痛苦。 什么样类型的信息被用来定义方法论的成功？ 我们有一个正在进行的工作来定义一个能够证明价值和捕获一些其他关系的信息的度量模型。我们目前的基本反馈来自于我们的客户、我们的服务团队和我们指导管理的会议。此外，在项目结束的时候，我们有一个总结经验教训的会议，在会议中我们可以直接得到回复。我们有一个提交给项目经理和项目团队成员的评估表格，他们能够在过程和指导工作中提供反馈。 在时间上你的最大挑战是什么？ 这个过程是非常简单的，并且很多人都想用它，但是我们没有足够多的支持人员。因为在福特信贷公司，一个非常大的组织，这个过程正慢慢的变成主流，我们没有足够的支持服务来为所有需要帮助的团队提供支持。第二点是我们只关注在 基于 OO 的项目、使用 J2EE 平台的项目和使用组件架构的项目上。如果你正工作在一个大的组织中，所有数据都被存储在主机系统中，那对我们来说将这个过程扩展到遗留类型的项目上挑战是巨大的。 你为什么将开发和部署分离开来？这样做对我们有什么意义？ 我们做的第一件事是开发方法论。我们用了六个月开发这个方法论，然后用了另外五个月将它部署到我们的组织中。我们的 Web 网站在开发项目结束时是可得到的，然后在部署项目期间我们建立了指导服务。我们确定了指导的过程是怎样的，培训了我们的服务团队，并且与我们的服务团队达成了协定。 你指导的项目使用什么类型的迭代时间周期？ 这依赖于项目，但是我们尽量的保持那些迭代在两周到六周，迭代的周期也依赖于什么被包括在项目中。指导人员与团队一起来帮助确定迭代的周期。 Maureen Field has authored this article Venkat Alladi has co-authored this article 参考: http://topic.csdn.net/u/20090226/15/948dfe5d-9333-4396-b8b1-c510e47e27a8.html 这里面的有些观点值得考量 Continue reading 【转】一个学习案例: 使用 IBM Rational Unified Process 作为方法框架 http://blog.csdn.net/cheny_com/article/details/6622656 摘录: 与敏捷开发相比，CMMI是更专业的外包管理模型，因为它的初衷就是“为美国国防部选择和管理供应商设定标准”。此标准具有法律效力，按照国防部规定只有3级以上企业才可称为承包商。但也正因为有了“美国”“国防部”“标准”这些定语和中心词，导致我们在一般外包中使用CMMI会感到困难。 对于这句话我觉得还是不能以外包与否来判断，而是说甲方对软件的需求严格程度，文中后面也谈到电信行业，银行行业，也存在属于外包类型的。还是“管理和技术永远要服从于业务”这句话经典！ 管理和技术永远要服从于业务，从这一点上CMMI整体覆盖了部分业务和大多数管理和技术，而敏捷覆盖了部分管理和部分技术。笔者推荐以CMMI为整体模型，内部配合敏捷开发实践，而不是“用敏捷开发代替CMMI”。 敏捷开发整体上适合小团队、产品研发（所以才有product owner一称）的环境，而外包软件开发中常常存在的则相反，因此在创建团队的时候要充分认识到这一点。 参见: 敏捷开发沉思(真实对话) http://www.blogjava.net/pengpenglin/archive/2011/09/20/351552.html 硝烟中的Scrum和XP http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches 敏捷不是过程，SCRUM只是框架，XP也是别人的实践 http://www.uml.org.cn/SoftWareProcess/2201012165.asp RUP和敏捷方法的优缺点 http://www.szpm.org/forum/thread-33-1-1.html Continue reading 【链】敏捷外包工程系列之三：固定合同（敏捷外包工程，敏捷开发，产品负责人，客户价值） 【链】为你的应用程序找到合适的数据存储解决方案
【链】NoSQL, NewSQL 还有其它
jdk7,jdbc4,servlet3.0
>@WebServlet(urlPatterns = "/demo", asyncSupported = true) public class AsyncDemoServlet extends HttpServlet { @Override public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException { resp.setContentType("text/html;charset=UTF-8"); PrintWriter out = resp.getWriter(); out.println("进入Servlet的时间：" + new Date() + "."); out.flush(); Jackson设计方法和JACKSON分析方法
Jackson方法有时也称为面向数据结构的软件设计方法。
A seq
B
C
D
A end
选择结构：
A select cond1
B
A or cond2
C
A or cond3
D
A end
重复结构：
A iter until (或while) cond
B
A end示例:
(1) 便于表示层次结构，是对结构进行自顶向下分解的有力工具。
(2) 形象直观可读性好。
(3) 既能表示数据结构也能表示程序结构（因为程序结构也只有上述三种基本类型）。
年，Jackson又对它进行了多方面的扩充和完善，最终发展成为一种需求分析方法。其核心思想是：根据作用于数据的行为序列的结构（顺序、选择、重复），建立目标软件系统的模型，然后在软件设计阶段将模型转换为相应的程序结构 。
（1）标识实体与行为。
（2）生成实体结构图。
（3）创建软件系统模型。
名词及名词短语——潜在的实体，
相关的动词——构成实体的潜在行为。
分析人员根据应用问题的边界及自己的理解，决定对潜在实体和行为的取舍。
进行复合。Jackson给出的实体结构图的表示机制如图所示。其中的子结点既可以是行为，也可以是
子实体。在后一种情况下，子实体应该继续分解，不能作为实体结构图的叶结点。 【转】一个学习案例: 使用 IBM Rational Unified Process 作为方法框架
ibm上的文章,不知道为什么G内不能访问，故此转载http://www.ibm.com/developerworks/cn/rational/r-rup-fw/index.html 其实我是想找这个口头上非常火的RUP的实际实践，但是确实很难找，只找到这么个国外的文章，内心里我很反感这种虚火的东西。不管敏捷也好，CMMI也好，什么其他衍生出来的乱七八糟的方法学也好。炒作过头了反倒说明了内在的空虚！软件开发不同工程制造，人的智慧因素很重要，因此程序员以及管理者的智商情商那才是基础因素，说白了就是人的因素。方法学和管理学必须建立在这个基础上才有用。软件做得好首先是人的功劳，不是什么几十年，几年前前定的个方法学管理学好。这些只是辅助手段，是种工具而已。基础不好，想通过这些工具来起作用，那只能是厨子不好怪灶歪！ 一个学习案例: 使用 IBM Rational Unified Process 作为方法框架
【链】敏捷外包工程系列之三：固定合同（敏捷外包工程，敏捷开发，产品负责人，客户价值）
很实际的一篇关于敏捷的文章：
敏捷外包工程系列之一：序言（敏捷外包工程，敏捷开发，CMMI，软件外包，政府项目，银行项目，电信项目）
Pagination
