时间：2007-07-18
来自：http://www.anymobile.org

经常使用的数据一般都会缓存起来，提高效率。对于数据量比较大的，如图片、资讯类，可以采用缓存Cache＋索引的机制处理；而对于比较简单的数据，可以通过简单的数据容器进行缓存。当然，它们最终一般都存放在Hashtable 或 HashMap等容器中。

       Cache 应用的原理大致是：初始化时将原数据导入Cache中或惰性加载；经常被查询（点击率高）的置前；当数据总大小超过Cache容量后，调整容量大小或清理不经常使用（点击率低）的数据；数据超过有效期，及时清理；对于查询失败的数据，需CHECK一下。

        简单的数据容器，将需要缓存的数据保存至单独的容器，并在一定的条件下进行数据同步。同步的方法大致有2种：启用一个时间线程，定期集中检查、处理各个容器的周期同步操作；或者由各个容器单独维护自身的周期和同步操作。

        前者统一处理，不会有额外的开销，缺点是添加一个新的容器，都需要添加到同步线程中；后者单独处理，实现起来比较快捷、没有任何约束，而且互不影响，但使用的时候有额外的处理和对象开销。

        当然，单独处理并不代表就是所有的业务逻辑都在各容器中控制执行，可以使用代理机制来解决这个问题。

        静态代理：代理对象与被代理的对象都必须实现同一个接口，在代理对象中可以实现CHECK等服务，并在需要的时候再调用被代理的对象，这样代理对象就只保留业务相关职责。

       动态代理：JDK1.3以后开始支持动态代理，处理者的类实现java.lang.ref.InvocationHandler类，可以使用一个处理者（Handler）服务于各个对象。

       动态代理相对效率低些，集合静态代理机制，数据容器大致流程如下：

       所有的数据容器都实现Container接口，定义生命周期、同步数据时的时间戳，同步方法和读取数据的方法；定义一个静态代理类，在查询数据的时候，检查数据容器是否过期，过期则调用容器的同步方法。

类图如下：

序列图如下：

样例代码如下：

    Container container = new StaticProxy( EntityContainer.getInstance() );

    int[] arr = (int[]) container.getOne("025");

了解AOP的，很容易就会想到pointcut，advisor，MethodBeforeAdviced等等，原理类似，略。

 （全文完）

MVC ，即 Model-View-Controller ，“模型 - 视图 - 控制器”，是 Xerox PARC 在八十年代为编程语言 Smalltalk － 80 发明的一种软件设计模式，最初是用来构建用户界面。它包括三类对象：模型 Model 是应用对象（数据和应用规则），视图 View 是它在屏幕上的表示，控制器 Controller 定义用户界面对用户输入的响应方式。

2、  MVC 特征

       特征一：视图与模型分离，一旦模型的数据发生了变化，模型将通知它的视图，而视图将于模型通信以访问相关的数据；

       特征二：视图可以嵌套。

3、  MVC 中的设计模式

       3.1 View-Model 关系与观察者模式

        观察者（ Observer ）模式：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。

        MVC 通过建立一个“定购 / 通知”机制将视图和模型分离，一个模型可以有多个视图，当模型的数据改变后会通知它的所有视图。

       3.2 View-View 关系组合模式

        组合（ Composite ）模式：将对象组合成树形结构以表示“整体－部分”的层次结构，使得对单个对象和复合对象的使用具有一致性。

MVC 用 View 类的子类 CompositeView 类来支持嵌套视图。 MVC 将一些对象划为一组，并将该组对象当作一个对象来使用。

       3.3 View-Controller 关系与策略模式

        策略（ Strategy ）模式：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。算法的变化可以独立于使用者。

        MVC 将响应机制封装在 Controller 对象中， MVC 允许在不改变视图外观 View 的情况下改变视图对用户输入的响应方式。 View 使用 Controller 的某个实例来实现一个特定的响应策略，实行不同的响应策略需要用不同的 Controller 实例替换即可。

4、  MVC 框架

MVC 框架把一个应用的输入、处理、输出流程按照 Model 、 View 、 Controller 的方式进行分离，这样一个应用被分成三个层——视图层、控制层和模型层。

比较常见的 MVC 框架有： Struts 、 Webwork 、 Tapestry 、 JSF 、 Spring MVC 等。

资料：
《设计模式》 GOF
MVC在Web系统中的模式与应用 http://dev2dev.bea.com.cn/techdoc/20031194.html
MVC模式 http://www.itisedu.com/phrase/200604231324325.html

时间：2006/09/22

来自：http://www.anymobile.org

1、  何谓模式

“每个模式就是一条由三部分组成的规则，它表示了一个特定环境、一个问题和一个解决方案之间的关系。 ”－－《建筑的永恒之道 》 (Christopher Alexander)

模式，就是对特定场景中，不断重复发生的问题，以及该问题的解决方案的整体抽象描述。

2、  设计原则

²        开闭原则 (OCP ， Open-Closed Principle)

是面向对象可复用的基石。模块、方法和类应该对扩展是开放的，而对更改是封闭的；对可变性进行封装。

²        里氏代换原则 (LSP ， Liskov Substitution Principle)

是继承复用的基石。在任何父类出现的地方都可以用它的子类来替代。在实际设计类的阶层体系结构时，这是一条很重要的原则。

²        依赖反转原则 (DIP ， Dependence Inversion Principle)

针对接口编程，要依赖于抽象，不要依赖于具体的实现，也叫控制反转， IoC 。

²        接口隔离原则 (ISP ， Interface Segregation Principle)

使用多个专门的接口总是比使用单一的总接口要好。

²        合成 / 聚合复用原则 (CARP ， Composite or Aggregate Reuse Principle)

聚合：表示拥有或整体与部分的关系。

合成：更强的聚合关系。

尽量使用和成 / 聚合而不是继承来实现复用 , “ Has-A ”替代“ Is-A ”（继承）。   

²        迪米特法则 (LoD ， Law of Demeter)

一个对象应当对其他对象尽可能少的了解。降低各个单元的耦合，提高系统的可维护性。

3、  GOF 设计模式

“设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。”－－《 Design Patterns 》 ( Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides )

设计模式充分利用语言优势，站在更高的角度去审视我们的设计，但是不要为了模式而设计。

按照模式的目的和范围准则， GOF 将众多的设计模式分为 3 类，共 23 个设计模式。

3.1 创建型（ Creational ）

抽象工厂（ Abstract Factory ） O

生成器（ Builder ） O

工厂方法（ Factory Method ） O

原型（ Prototype ） O

单件（ Singleton ） O

3.2 结构型（ Structural ）

适配器（ Adapter ） C O

桥接（ Bridge ） O

组合（ Composite ） O

装饰（ Decorator ） O

外观（ Façade ） O

享元（ Flyweight ） O

代理（ Proxy ） O

3.3 行为型（ Behavioral ）

责任链（ Chain Responsibility ） O

命令（ Command ） O

解释器（ Interpreter ） C

迭代（ Iterator ） O

中介者（ Mediator ） O

备忘录（ Memento ） O

观察者（ Observer ） O

状态（ State ） O

策略（ Strategy ） O

模板方法（ Template Method ） C

访问者（ Visitor ） O

4、  如何使用设计模式

1)      学习模式，考虑设计模式是怎样解决问题以及相互的关联性；

2)      寻找合适的对象，决定对象的粒度，制定对象接口，描述对象之间的关系；

3)      使用设计模式进行优化，权衡性能和灵活性；

4)      只有当模式提供的灵活性真正需要时，才有必要使用；

5)      设计不能迁就模式，模式为设计服务。

参考：

《 Design Patterns 》 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

《 Java 与模式》阎宏

时间： 2006/09/22

来自： http://www.anymobile.org

1、软件过程

       随着软件系统的规模和复杂性的增加，其开发成本和风险随之增加，软件的质量问题已成为制约软件发展的关键因素之一。

       所谓软件过程，即软件项目的开发过程，是指软件生命周期中，用于开发和维护软件产品的一系列过程，它与团队的组织管理以及开发技能相辅相成，全面提升软件产品的质量。

       近年来，软件过程日益得到重视，国际软件界的敏捷、统一热也在持续升温。 与传统的开发过程相比，敏捷过程更强调快速灵活反应，主动迎接和适应变化，主张更紧密的客户与开发商协作，以人为本的可持续发展，典型的有 XP （极限编程）、 FDD （特征驱动开发）等；统一软件过程以 RUP 为代表，采用 OO 技术对软件开发过程本身进行业务建模，集成了迭代开发、用例驱动、 UML 可视化建模、 OOAD 、架构设计、项目管理等许多主流先进的当代软件工艺。

       在软件项目开发过程中，应该能够识别、分析不同软件项目的特点，采用相对适合的开发实践来适应软件开发过程，保证对软件开发的有效支持，如 RUP 与 XP 的融合。

2、 XP ，极限编程

极限编程（ eXtreme Propgramming ， XP ）是由 Kent Beck 在 1996 年开创，是一种演进式的原型化方法，以最大化发挥人的能量为核心目标，以“小步快走”的逻辑指导开发，具有沟通高效、设计简单、反馈迅速等特点，是一种轻量级、敏捷的过程方法。

极限编程基于四个价值目标：沟通（ communication ）、简化 (simplicity) 、反馈 (feedback) 和勇气 (courage) ，由 12 个最佳实践为这四个价值提供支持。

极限编程的生命周期包括 4 个基本活动：编码 (coding) 、测试 (testing) 、聆听 (listening) 、设计 (designing) 。

2.1 4 个价值目标

       沟通：让开发人员集体负责所有代码并结队工作，鼓励与客户及团队内部保持沟通。

简化：鼓励只开发当前的功能，避免过多的文档，专注于最小化解决方案，做好为为新特性改变设计，在系统隐喻和代码规范下不断重构的准备。

反馈：通过单元测试和功能测试获得快速反馈。

勇气：提倡积极面对现实和处理问题的勇气，拥抱变化。

2.2 12 个最佳实践

 
（图片1 XP最佳实践）

              有计划的开发：通过结合使用优先级“故事”和技术估算，确定下一版本的功能。

小型发布：以小的增量版本经常向客户发布软件。

系统隐喻：隐喻是一个高层次的系统构想；需要不断的细化架构，来指导全部开发。

简单设计：通过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立刻进行移除。

测试驱动：“先测试，后编码”。用户编写测试内容以对 " 故事 " 进行测试。程序员编写测试内容来发现代码中的任何问题。在编写代码前先编写测试内容。

重构：这是一项简化技术，用来移除代码中的重复内容和复杂之处。

结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一个人编写代码或者驱动，另一个人同时审查代码的正确性和可理解性。

集体代码所有权：任何人都拥有所有的代码。提高代码透明度，增强团队合作精神。

持续集成：每天按任务多次创建和集成系统，随着需求变化，进行不断的回归测试。

每周 40 小时工作制：程序员在疲劳时无法保证最高效率。连续两周加班是绝对不允许的，否则会影响工作效率。

现场客户：至少有一名真实的客户全天候工作于开发环境中，帮助定义系统、编写测试内容并回答问题。

编码规范：程序员采用统一的编码规范。

总体来说， XP 部分满足了 CMM2~3 级关键过程域 (KPA) 的要求， XP 侧重与过程和技术， CMM 更注重组织和管理。

3、   FDD ，特征驱动开发

特征驱动开发（ Feature Drive Develop ， FDD ）， Together 创始人 Peter Coad 所创。通过特征来制定开发计划，以每日构建为核心，强调按特征分步开发和交付。一个特征就是一个小的、具有客户价值的功能，通常表示为 <action><result><object> 。

4、   RUP ， Rational 统一过程

迭代软件开发的发展背景：软件的不确定和高风险等特性，使得传统的瀑布式开发力不从心；迭代有助于尽快发现和解决风险；迭代有助于控制项目的节奏，加快反馈，增强项目的控制力度，实现过程的有序化；迭代符合人们对事物的认识逐步加深，解决问题的能力随经验逐步提高。

       Rational 统一过程（ Rational Unified Process ， RUP ），是用例驱动、以体系结构为中心，迭代、增量的软件开发过程。适合大、中型项目。

RUP 强调采用现代软件开发的一些最佳实践，作为一种降低开发新软件所带来的内在风险的方式。这些最佳实践包括：

1) 迭代开发；

2) 管理需求；

3) 使用基于组件的构架；

4) 可视建模；

5) 持续的质量验证；

6) 控制变更。

RUP 是一个迭代过程，确定了任何软件开发项目的四个阶段：初始阶段、精化阶段、构建阶段和交付阶段。每个阶段包括一次或多次迭代；每一次迭代都会生成更加接近最终产品的可执行版本。 

a 、初始阶段：识别和规避项目的主要风险，建立用例模型框架，并制定里程碑日期的阶段计划；

b 、精化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素，完成部分优先级最高的用例开发；

c 、构建阶段：分为多个迭代，逐步完成不同优先级的用例开发，核心 Case-> 高风险 Case-> 次核心 Case-> 其它 Case ；

d 、交付阶段：进行各种功能、性能测试，进行产品化、部署，完成整个系统的开发工作。

（图片2 RUP概述图）

RUP 迭代开发过程：

a 、第一次迭代

1)   捕获需求

2)   建立初始的领域模型

3)   建立用例模型框架

4)   制定开发计划

b 、第二次迭代

1)   关键用例的 Robustness 分析与交互建模

2)   体系结构设计

3)   建立类模型

4)   关键用例的开发与测试

5)   完善用例模型

c 、第 n 次迭代

完成所有用例的分析、设计与开发。

d 、最后的迭代

1)   整体测试：进行各种功能、性能和压力测试。

2)   部署与安装：生成相应的部署图。

3)   产品化：进行一些产品化的包装。

注：每一次迭代之后，都应该交付一个可以运行的中间版本。

（图片3 RUP迭代流）

5、  SPP ，精简并行过程

精简并行过程（ Simplified Parallel Process ， SPP ），对 CMMI 3 级以内各过程域的内容和要求作了“精简”处理，包括 19 个过程域、 40 余个规程和近 60 个文档模板 。强调在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。

（图片4 SPP）

软件过程改进解决方案（ SPIS ）――林锐发明。

核心组成部分

1) 软件过程改进咨询服务；

2) 软件工程与项目管理培训；

3) 基于 Web 的集成化项目管理工具， Future 。

Future 采用 CMMI 和 SPP 为参考标准。主要功能包括项目规划、项目监控、质量管理、配置管理、需求管理、日常工作管理等。

网站： http://www.chinaspis.com

从公司的长远发展出发，通过对公司内员工展开针对性的培训，以使他们不断获取新的知识和相关技能，提升整体研发能力，于 2006 年 6 月 3 日 至 6 月 6 日 ，参加中科院计算所职业培训中心在上海举办的高级系统架构师培训。

二、 培训目的和内容

通过培训，掌握目前常用的体系结构设计方案，并能够灵活应用；掌握影响软件体系结构设计的各种目标和应对策略；熟练掌握一个真实的软件开发过程，并能够具体地将 RUP 的规范过程应用到实际的系统实现中。

培训分为四天，第一天讲解软件架构，第二天讲解设计模式和商业机密，第三天讲解 RUP ，第四天讲解架构设计中的技术问题。

四天中培训的主要内容有：

1、  软件架构设计的理论与实践；

2、  设计模式和体系创建；

3、  商业机密；

4、  RUP 的构件实现与管理；

5、  架构设计中的技术问题分析。

三、 培训日程

四、 体会和计划

在四天的培训课程中，集合讲师的案例，深入学习了软件架构设计、统一过程和设计模式三个方面的综合应用技术。

这次培训的内容多、时间紧，让我获益匪浅。我感受很深的主要有以下几点：

1 、软件的架构设计是对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策（在统一过程里面，架构调研和架构设计统称为架构分析）。软件架构设计是一个系统工程，它需要系统构架师有很宽的知识面，从需求分析、架构设计到类设计甚至代码实现都需要有透彻的理解。架构的关键是拥抱变化而设计。

2 、软件架构师是技术负责，是解决方案的提供者；与项目经理合作，制定计划，决定成员，组织团队；保证项目按计划完成。架构师最重要的素质是把握重点。

3 、 Rational Unified Process （ RUP ， Rational 统一过程），是用例驱动、以体系结构为中心，迭代、增量的软件开发过程。

RUP 的软件开发分为四个阶段：

a 、初始阶段：识别和规避项目的主要风险，建立用例模型框架，并制定里程碑日期的阶段计划；

b 、精化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素，完成部分优先级最高的用例开发；

c 、构建阶段：分为多个迭代，逐步完成不同优先级的用例开发，核心 Case-> 高风险 Case-> 次核心 Case-> 其它 Case ；

d 、交付阶段：进行各种功能、性能测试，进行产品化、部署，完成整个系统的开发工作。

每次迭代之后，都应该交付一个可以运行的中间版本 。

4 、软件设计中存在不断重复出现，可以用某种相同方式解决的问题，也可以按照某种模式进行识别，并且可以在这个模式的基础上创建特定的解决方案。设计模式是充分利用语言优势，站在更高的角度去审视我们的设计，但是不要为了模式而设计。

5 、合理、规范的文档很重要，也很必要，如术语表，对功能性需求形成的用例模型和系统特性列表文档，技术备忘录（记录设计动机和原理），问题卡等等。
 

最后，计划×月×日 14:00 ~ 18:00 在大会议室对R&D部门开展主题为“面向对象的软件开发”的内部培训，目录如下：