摘要：
软件架构的历程 计算机科学的发展历程可以追溯到第一代电子管计算机（1945年~1956年）。1946年2月15日世界上第一台重达30顿的计算机ENIAC（Electronic Numerical Integrator and Computer）正式在费城公布于世，它标志着现代计算机科学的诞生。 相比来说，计算机软件架构的发展就更晚。从20世纪80年代晚期开始，整个计算机科学界为了应对大规模系统设计所带来的复杂度，才逐渐开始了软件架构的研究工作。因为先前的系统架构和设计是严重依赖相关人员各不相同的实践经验和观察，并不能客观地衡量和控制架构活动的质量。 历经了十几年的不懈努力，软件架构的研究逐步走 阅读全文
摘要：
由塔科马大桥事件 谈软件架构 经常，我们会涉及系统架构、面向对象的架构（SOA）、软件架构等词，那么到底什么是“架构”？什么是“软件架构”？“系统架构”与“软件架构”有着怎样的区别和联系？“系统架构构建”和“系统设计”之间有什么区别和联系？ 本章带着这些问题，追本溯源，对于架构及软件架构的一些基本概念及发展历程做一番说明。同时对一些人们认识上的误区进行分析，以还原事物的真实面目。1.1 引子 时间就像一条奔腾不息的大河，大浪淘沙，方显金石。翻开人类的建筑工程史，遍布世界各地，跨越几千年的时空，我们可以看到许多辉煌成功的工程。但是，人们 往往最容易遗忘那些被历史长河所淹没的惨痛失败。而实际上，人 阅读全文
摘要：
好的开始是成功的一半，要充分认识需求分析对项目过程的重要意义。需求分析是项目的开始，其质量如何对整个项目的进展与最终结局都会起到重要作用。这里介绍的只是需求分析过程中一些常见的应对策略，正确理解与恰当运用这些经验将会有助于效率的提高与质量的改善。 阅读全文
摘要：
需求分析与对象 关于对象的需求分析是另外一种完全不同的设计方式，它已脱离了业务需求的原始概念，更多的是从某一类特定的视角或某个专用的独立场景来集中构造某个事物单元的模型。实际上这部分构思经常被归结到架构设计中，其表现方式仍然是对象级的需求分析，而且是更加具备创造性的需求分析。在需求规格说明书中应当对主要对象的构思给出方案，至少也要给出原则性的提示。 创建对象的起源在于业务过程中的操作逻辑、场景、功能等某个环节上的可重复性。在透彻分析了某个事物在整个系统的特性之后，从中抽象出最本质的规律性，然后再对其规律、变化等因素进行综合构思，最终形成一个完整的事物结构体，这就是所谓的业务对象。 在一个业务系 阅读全文
摘要：
需求规格 为设计过程中的需要而撰写的需求规格说明书是三种文体中要求最高的一种，因为它的用途在于为设计实现提供一个可以用来作为参照的基本约束。在有些情况下，它可能会包括需求报告的全部内容，并在此基础上进行扩充。 在这里有一个职责上的划分，原则上来说，需求分析只对用户需求的真实性负责，并不需要考虑数据设计与功能框架，后续工作会由专职的数据库工程师与架构设计师来完成。这种说法只有在具备规模的软件企业中才有可能做得到，对于中小企业的有限投资这并不是一个能够付诸实现的操作过程。从需求到实现设计到代码实现大约是这类项目的基本过程，有些项目干脆就是从需求直接到设计实现。 基于这种客观的项目状况，要求需... 阅读全文
摘要：
面向对象之软件需求中的体系构造 这里需要一种特定的思维方式与特有的方法论，正确地理解与恰当地运用经典的需求分析理论是必要的。 1．在思想方式上尽快建立起一个系统的整体框架，大体定位各种具体目标在系统框架中所处的位置及其对总体的作用，同时要分析各个部分之间的相互作用与内在 联系。在这个阶段中，往往重视交流过程而忽视真实的操作过程。实际上，通过亲临现场的走访过程来了解需求所要达到的目的往往会更快地了解命题，同时也能够 更准确地把握设计目标。 2．在总体框架的基础上，分别剖析每个应用节点上所要产生或应用的数据集合与表现方式，尽早搭建各个业务节点之间在数据体系上的内在联系，而不是单纯地从业务层面上理解 阅读全文
摘要：
写软件的 需求分析全方位考虑 需求总是在回答“需要什么”的问题，而实现总是在解决怎样才能做到的问题。需求是所要达到的目的，就是要在事先确定出到达目的地的路径与方法。为了避免误入歧途，就要避免由于需求分析误差产生的误导。 首先要明确，“分析”是一个主动思维的过程，而不是一个总结归纳的过程。很多需求调研人员认为，只要把用户提出的原始需求归纳在一起就是需求分析了，这是一个误区。 针对不同的用途，需求文档可能会表现为不同的撰写方式。 1．售前方案书：在项目签约之前为用户提供的重点功能描述。 2．需求分析报告：为项目双方约定设计任务的基本内容，限定设计任务的边界。 3．需求规格说明书：对系统的设计目标与 阅读全文
摘要：
面向对象之封装的成本价值 本章对一些具有代表性数据控件实现了自定义封装，其内容已经足够翔实精细，同样还有一些控件被封装，比如： • 自定义“TabControl”到“TC_”类； • 自定义“RichTextBox”到“RTB_”类等。 因为它们在需求把握与设计构思上没有太多值得强调的特点，所以就不再一一列出。只要把握了自定义封装的一般理念与实现方式，在任何必要的时候随时可以对一些必要的命题实现自定义封装。 对操作逻辑的封装有益于全面提升操作员对系统的评价，这一点是基本可以肯定的结果。实际上，我们从操作逻辑上实现控件封装只是浅层次的目的，这种封装在更 深层次上的意义是为容器、窗体及业务模式的封 阅读全文
摘要：
自定义“TB_定位访问”子类 在很多应用中，经常需要通过某个“特征值”从给定的数据对象（前台的数据集或后台的物理表）中得到一条（或一组）满足约束的记录，并在此基础上实现某种给定的后续功能，“TB_定位访问”就是要以最简洁的操作并经过标准化的封装设计实现这一系列的连续动作。4.3.1.1 命题提出 对数据库的访问是实现过程中必不可少的实现过程，由于物理表可能是个庞大的记录集... 阅读全文
摘要：
自动绑定数据源 实现数据控件与原始数据的绑定是实现数据展示与编辑的基本前提。在常规的设计模式下实现数据绑定有两种方式： 1）第一种方式：在窗体上引用数据对象→逐个拖放控件→分别设置控件与字段的绑定关系。这无疑是个不厌其烦的重复过程，是个没有任何创造性的过程，也是一个容易出现隐性bug的设计过程。 2）另一种方式：通过生成器指定物理表与控件的关系，由生成器完成控件与数据源的绑定。... 阅读全文