摘要：Esper4.2.0 srchttp://dist.codehaus.org/esper/esper-4.2.0-src.zipEsper4.2.0 src dochttp://esper.codehaus.org/esper-4.2.0/doc/api/overview-summary.html#overview_description待续。。。
阅读全文
posted @ 2011-06-28 16:59
06 2011 档案
摘要：【转载】http://www.blogjava.net/bacoo/archive/2009/06/22/283480.html对模板特化的理解：特化整体上分为全特化和偏特化，这一点大家都没有什么置疑，但是细分它们各包括哪几种状态就很难界定了，而且很多权威的书上都不一致，管它呢，反正我们能会用各种特化就可以了。下面就谈谈我个人对特化的划分和定义：所谓特化，就是将泛型的东东搞得具体化一些，从字面上来解释，就是为已有的模板参数进行一些使其特殊化的指定，使得以前不受任何约束的模板参数，或受到特定的修饰（例如const或者摇身一变成为了指针之类的东东，甚至是经过别的模板类包装之后的模板类型）或完全被指
阅读全文
posted @ 2011-06-27 17:07
摘要：【转载】esper的官网 http://www.espertech.com/1.1介绍CEP和事件流分析Esper引擎是为了满足对事件进行分析并做出反应等这些应用需求而产生的。这些应用要求事实或接近事实处理事件（或消息）。有时候是为了应对复杂事件处理(CEP)和事件流分析的。关键要考虑这些类型应用的（高）吞吐量、（低）响应时间和需求逻辑的复杂程度（复杂计算）。esper可以用在股票系统、风险监控系统等等要求实时性比较高的系统中。1.2 CEP和关系数据库关系型数据库不适合每秒成百上千的数据量的查询内存数据库与比传统的关系数据库相比，有更好的查询性能，更适合处理CEP应用。1.3 专注于CEP的
阅读全文
posted @ 2011-06-22 09:17
摘要：黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。在实际应用中常见的实现模式有：A 利用数据库利用数据库充当黑板，不同的应用共享数据库中信息，并且可以更新数据信息。这也是最常见的实现方式。特点：1 便于实现信息的查询，筛选和统计，这方面关系数据库提供了SQL 92的强大支持。2 不能用于较高实时性要求的环境，这种实现是工作在“拉模式”下的，并且高频率的访问数据库会导致严重的系统性能问题。B 利用发布—订阅模式
阅读全文
posted @ 2011-06-13 16:33
摘要：本书每一个应用实例将主要强调宏观生命周期的一个特定部分以及适用的分析和设计（即微观）技能。《基于卫星的导航》-从简化视角开发第一（segments，同汇编课中代码段、数据段、堆栈段等等释义是一样的，即代表系统中不同的部分）和第二（sub-systems）个级别的架构。我们意图是探索表示法和过程如何应用到系统架构的开发中。架构的开发时伴随着系统功能需求与非功能需要逐步深入而一步步建立起来的，它是系统的最明了的蓝图。宏观过程初始1. 定义问题边界，提供给我们的功能需求实际上是众多使命级别用例的容器（在UML中就是包）。2. 决定mission用例，敲定高级别抽象的segments级别的逻辑架构。
阅读全文
posted @ 2011-06-11 11:22
摘要：【转载】原文链接：http://www.cnblogs.com/shanyou/archive/2010/09/16/cep.html近年来，面向服务架构 SOA一直是热门的议题。面向服务架构SOA 使用了比组件、程序(procedure)层次更高的服务做为处理单元，通过开放格式交换标准例如XML、Web Service 来交换数据，避免不同平台间的差异带来的不便，达到在异构IT 环境中有效且弹性的组合企业逻辑，并且更快速的产生响应，期望达到所谓实时化的企业。事件驱动架构(Event-Driven Architecture, EDA)以面向服务架构为基础，将面向服务中的服务进一步转化成以事件作
阅读全文
posted @ 2011-06-09 17:20
摘要：第5章描述了表示法-UML图，分为两大类，即描述静态结构的结构图和描述动态行为的行为图。在这不一一列举，实践地时候可以去查如何使用相应的表示法。这些表示法可不是一出来就一成不变的，而是需要经历概念模型、逻辑模型和物理模型的演变，在项目开发的不同阶段使用不同的模型。问题：1. 这么多的表示法，我们在实践中都要一一画出吗？2. 在项目开发的不同阶段，都应该相应地使用哪些表示法。对于问题一，答案是不必使用全部表示法，就像RUP过程理论一样，它是力求一种通用的理论，但在实际的项目过程中，往往是理论的子集。对于问题2，后面会结合实战来分析。第6章描述了软件开发过程，首先描述了成功项目的特征：存在很强的架
阅读全文
posted @ 2011-06-07 09:41
摘要：RUP是一套管理方法，用于项目从需求到发布的管理而敏捷则是一种思想，一种价值观：价值迭代交付，以人为本有一些基于敏捷思想的实践比如Scrum、XP等也都是管理方法或开发方法层面的内容RUP可以与敏捷的思想结合，可以在敏捷思想指导下进行管理，那就是敏捷的RUPXP 与CMM 、RUP 的比较CMM 告诉组织为了系统化地建立、实施和改进软件开发过程应该做些什么，但没有说明如何去做以及采用哪些具体的技术、策略和方法。CMM 是一套通用的过程实践标准，适用面很广。实施CMM 要求组织在过程的制度化建设上付出大量努力，通常被认为是重载（heavy-weight）的模型。XP 是一个针对某种特定环境（需求
阅读全文
posted @ 2011-06-06 20:23
摘要：简介：敏捷方法的兴起对设计提出了新的要求，其最核心的一点是针对无法在项目一开始就固化的需求进行演进型的设计。在项目一开始就进行细致、准确的架构设计变得越来越难，因此，架构设计在项目的进展中被不断的改进，这相应导致了编码、测试等活动的不稳定。但是，软件最终必须是以稳定的代码形式交付的。因此，架构设计必须要经历从不稳定到稳定的过程。而架构设计能够稳定的前提就是需求的稳定。需求冻结敏捷方法和传统方法的区别在于对待变化的态度。传统的做法是在编码活动开始之前进行充分、细致的需求调研和设计工作，并签署合同。确保所有的前期工作都已经完成之后，才开始编码、测试等工作。如果发生需求变化的情况，则需要进行严格的控
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：要保证架构的稳定和成功，利用代码对架构进行验证是一种实用的手段。代码验证的核心是测试，特别是单元测试。而测试的基本操作思路是测试优先，它是敏捷方法中非常重要的一项实践，是重构和稳定核模式的重要保障。面向对象体系中的代码验证代码验证是保证优秀的架构设计的一种方法，同时也是避免出现象牙塔式架构设计的一种措施。我们在上一篇稳定化中提到说架构设计最终将会体现为代码的形式，因此使用形式化的代码来对架构进行验证是最有效的。由于是代码验证，因此就离不开编写代码，而代码总是和具体的语言、编译环境息息相关的。在这里我们主要讨论面向对象语言，代码示例采用的Java语言。利用面向对象语言来进行架构设计有很多的
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：敏捷架构设计一文到目前已经全部结束，由于架构设计是一个很大的话题，要在一篇文章中完全把架构设计讲清楚是很难的。因此本文的最后一个章节中提供了一组书籍和文章，这些资料都和架构设计有关，本文的写作过程也从中获益良多，故而推荐给有兴趣的读者。Refactoring To Patterns（Joshua Kerievsky）勿庸置疑，模式是软件设计的一种有效的工具。但是在将模式和现实中的软件设计关联起来时，很多人往往迷惑于模式到底是如何应用的。结果是表现出两种极端：一是用不好模式，二是过度的滥用模式。模式是他人设计经验的总结，但是它在提供优秀的设计思路的同时也会增加一定的复杂性。因此，不了解模式
阅读全文
posted @ 2011-06-06 20:22
摘要：简介：上篇我们用了大量的篇幅来观察了一个实际的例子，相信大家已经对分层有了一个比较具体的概念了。在这一篇中我们就对分层在实践中可能会遇到的问题做一个讨论。分层在架构设计中是一种非常常见的，但是又很不容易用好的技术。因此我们这里花了很大的气力来讨论它。由于这是一篇介绍软件设计技术的文章，为了尽可能让更多的人理解，本应该尽可能不涉及到过于具体的技术或平台。但是这个目标可能很难实现，因为软件设计是没办法脱离具体的实现技术的。因此本文能够做到的是尽可能的不涉及具体的编码细节。何时使用分层技术？分层技术实际上是把技术复杂化了。和以往简单的CS结构的系统不同，分层往往需要使用特定的技术平台来实现。当然，不
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：对于一个已经初步建立好的模型（分析模型或是设计模型）来说，对其进行精化和合并是必要的步骤。Context建立架构愿景，为架构的设计定义了主要的设计策略和实现思路。应用分层的原则则对整个的软件进行了结构上的划分，并定义了结构的不同部分的职责。而现在，我们需要对初步完成的模型进行必要的改进。Problem我们如何对初始架构模型进行改进？Solution对模型进行改进的活动可以分为精化和合并两种。我们先从精化开始。首先，我们手头上的初始架构模型已经包括了总原则（参见架构愿景模式）和层结构（参见分层模式）两部分的内容。现在我们要做的工作是根据需求和架构原则来划分不同的粗粒度组件。粗粒度组件来源于
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：当架构模型进行迭代的过程中，必然伴随着对模型进行修改和改进。我们如何防止对模型的修改，又如何保证对模型进行正确的改进？Context架构模型通过精化、合并等活动之后，将会直接用于指导代码。而这个时候，往往就会暴露出一些问题出来，通常在实际编码中，发现架构存在或大或小的问题和错误，导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计的过程本身是一个迭代的过程，这就意味着在每一次的迭代周期中，都需要对架构进行改进。Problem我们如何避免对架构模型进行修改？又如何保证架构进行正确的改进？Solution我们从XP中借用了一个词来形容架构模型的修改过程――Refactori
阅读全文
posted @ 2011-06-06 20:21
摘要：简介：从这一篇开始，我们将会进入另一个不同的主题，和前面所讨论的模式专注于组织、过程、方法不同，以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。Context在单次的迭代开始阶段，我们已经收集好了单次迭代的需求。Problem架构和分析设计是密不可分的，有时候很难说得清楚架构的定义，但架构应该能够描述软件的整体。架构包括了软件的各个方面，但是每一个设计细节总是需要单独考虑，这时候就会出现设计细节之间、以及设计细节和架构之间的不一致。架构设计的
阅读全文
posted @ 2011-06-06 20:20
摘要：简介：在定义了架构愿景之后，团队中的所有人员应该对待开发的软件有一定的了解了。但是，面对一个庞大的软件系统，接下来要做些什么呢？分而治之的思想是计算机领域非常重要的思想，因此我们也从这里开始入手。要进行应用软件的设计，分层是非常重要的思想，掌握好分层的思想，设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性，本章的内容分为上下两节，并不采取模式描述语言的方式。分层只是将系统进行有效组织的方式。本章特别针对于企业应用进行讨论，但其中大部分的内容都可以应用在其它的系统中，或为其它的系统所参考。在企业应用中，有两个非常重要的概念：业务逻辑和持久性。可以说，企业应用是围绕着业务逻辑进行开展的
阅读全文
posted @ 2011-06-06 20:20
摘要：简介：迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。Context在软件生命周期中，我们如何对待架构设计的发展？Problem架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？我们在简单设计模式中简单提到了"Planned Design"和"Evolutionary Design"的区别。XP社团的人们推崇使用"Evolutionary Design"的方式，在外人看来，似乎拥护者们从
阅读全文
posted @ 2011-06-06 20:19
摘要：简介：我们已经讨论了敏捷架构设计的4种过程模式，在这一章中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。四种模式的着重点我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义进行澄清：架构设计的框架并不是说你要严格的按照文中介绍的内容来进行架构设计，在文章的一开始我们就指出，模式能够激发思考。因此，这一框架是需要结合实际，进行改造的。实际，我们在这一个部分中介绍的，比较偏向于原则，我们花了很大的时间来讨论原则的来龙
阅读全文
posted @ 2011-06-06 20:19
摘要：简介：团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。Context谁来负责架构的设计？Problem在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码，就能够设计出理论上尽善尽美的架构，配有精美的图例。问题1：理论上设计近乎完
阅读全文
posted @ 2011-06-06 20:18
摘要：简介：XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这一章，我们就对简单性做一个全面的了解。Context架构应该设计到什么程度？Problem软件的架构都是非常的复杂的，带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中，我们提到了一些反对象牙塔式架构的一个原因，而其中的一个原因就是象牙塔式架构的设计者往往在设计时参杂进过多的自身经验，而不是严格的按照需求来进行设计。在软件开发领域，最为常见的设计就是"Code and Fix"方式的设计，设计随着软件开发过程而增
阅读全文
posted @ 2011-06-06 20:18
摘要：简介：通过上一章的介绍，我们对敏捷和方法有了一个大致的了解，从这一章起，我们开始对软件开发过程中架构设计的研究。记住一点，我们并不是为了架构设计而研究架构设计，我们的目的在于敏捷方法学的应用。架构设计是一种权衡（trade-off）。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复
阅读全文
posted @ 2011-06-06 20:17
摘要：简介：我们说，和重型方法偏重于计划、过程和中间产物不同，敏捷方法更加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产物，那只是保证沟通、实现目标的手段。这并不是说计划、过程、中间产物不重要，只是不能够本末倒置 注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模型、代码。例如设计文档、数据模型等。参考RUP的Artifact。 评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需求。做好需求的方法有很多（参见拙作需求的实践），但这并不是我们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发来设计架构，
阅读全文
posted @ 2011-06-06 20:17
摘要：简介：方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。在第一篇文章中，我们来了解标题中的一些词的含义。方法学是什么？ 敏捷是什么？ 为什么讨论架构？ 方法论方法论的英文为Methodology，词典中的解释为"A series of related methods or techniques"我们可以把它定义为软件开发（针对软件开发）的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题，我很赞同Alistair Cockburn的一句话，"方法论源于恐惧。"出
阅读全文
posted @ 2011-06-06 20:16
摘要：第4章描述了分类的重要性，以及经典的分类方法。而后就面向对象的分析与设计一般方法进行了描述：在分析时，关注的重点是分析面临的问题域，从问题域的词汇表中发现类和对象，实现对真实世界的建模。在设计时，我们在模型中发明一些抽象和机制，位要构建的解决方案提供设计。先看下Booch对面向对象分析和设计的经典论述：OOP：面向对象编程是一种实现方法，程序被组织成对象的协作集合，每一个对象代表某个类的实例，对象的类是通过继承关系联合在一起的类层次中的所以成员。OOD：面向对象设计是一种设计方法，它包含面向对象的分解过程，以及一种表示方法，用来描写设计中的系统的逻辑模型与物理模型，以及静态模型与动态模型。OO
阅读全文
posted @ 2011-06-01 11:11
