技术研究
springmarch
这个作者很懒,什么都没留下…
展开
-
开发框架的一点儿看法
中午上了趟医院,病好多了。在去医院的路上,脑子里一直在思考着一个问题,就是软件结构的变化,及带来的问题。早在90年代的时候,Foxbase这种数据库,就是应用开发的全部。一层的程序,数据库存在本地,作一个管理系统真是简单极了。现在随着网络的发展,从1层变到2层,又到3层,甚至多层,从应用开发的角度,是越来越复杂了。从技术的结构上来看,关系型数据库、中间件、Web应用服务器、浏览器,都需要去原创 2006-03-09 16:27:00 · 706 阅读 · 0 评论 -
框架工作的状态
按计划打算做一个框架,但最近工作比较忙,而且也接触了一些新的东西,希望重新整理一下再动手。不过不会太久了,前阶段了解了XUL,接下来,打算看看下面几个方面:1)Hibernate2)Spring3)ROR4)Eclipse 服务端那个框架,从E5发展过来的原创 2006-06-23 17:48:00 · 695 阅读 · 0 评论 -
脚本语言和开发工具的考虑
脚本语言和开发工具,好像不是能对比的两个概念,但是在RAD方面,我觉得这两个概念代表两个潮流。脚本语言代表的是类似Ruby一类的快速开发方案,而开发工具代表的是通过一体化的工具来构造程序的思路。这二者的共同之处都是要为快速构造系统,容易的构造系统提供解决方案。通过脚本语言构造的方案,非常轻量级,容易调整和修改,更加能够适应变化。而通过开发工具的方案,则需要非常大的投入,害怕变化,需原创 2006-04-28 19:12:00 · 941 阅读 · 0 评论 -
两个特性的概念
两个概念,最近算是刚刚弄清楚1)容错性2)健壮性这两个概念,很容易搞混,不健壮能容错吗?容错能不健壮吗?这就是汉语的歧义造成的,在架构语言里,这两个概念还是能分得比较清的。容错是指当异常发生时能够恢复到正常的处理状态的能力,例如,一个函数,当输入参数是NULL时,被自动当成空串来处理,这种设计,就是具备了容错性;容错性好的设计,可以让访问者很放心的调用,不必在调用前,对参数作过原创 2006-04-13 14:20:00 · 1719 阅读 · 0 评论 -
框架的结构
框架分为如下层次:1)数据持久化层:这一层次主要是完成数据的持久化,提供数据的存储和对存储数据的跨平台的访问2)业务逻辑层:这一层定义业务逻辑接口,实现业务逻辑,并提供业务逻辑接口和多种访问协议的绑定3)用户界面层:这一层提供界面,来完成和用户的交互分层结构有利于系统的企业级部署,有利于系统的开放性、可扩展性、可集成性。但增加了系统模型的复杂度。从设计的角度上来看,这种分层的模型和原创 2006-03-08 19:31:00 · 1222 阅读 · 0 评论 -
对软件系统的一点儿考虑
刚到新单位,接触的东西比较多,似乎这种总结思考的时间少了。刚刚简单研究了几个产品:wiki: jspwikilms: moodletest: LoadRunner感觉这些比较成熟的软件,从使用的角度上考虑得真是非常周全,但这不是我想说的话题。我感觉到,这些功能完善的软件,每增加一个特性,大体都包括两个部分:1)让使用者表达对这个特性的期望2)让系统实现使用者表达的期原创 2006-03-31 13:02:00 · 649 阅读 · 0 评论 -
为什么做这项工作
工作10年了,一直非常关注开发框架的研究和开发,但工作中往往屈从于时间等各方面的压力,成果往往都不是很满意。所以想利用自己的空闲的时间,重新总结自己的积累和认识,构建一个自己满意的开发框架。有时间就做一点儿,也不给自己太大的压力。原创 2006-03-07 13:56:00 · 637 阅读 · 0 评论 -
考虑一个关于需求特性的问题
特性,在产品研发里,应该算是包含在需求之中。没有明确的需求,就没有明确的产品。可是产品的需求,不可能是开始就是需求完善的,开始的时候,绝大多数的需求都是潜在的、隐含的、暗示的。在产品研发过程中,每个设计,每个问题的答案,每个问题的讨论和解决,其实都是和产品的需求紧密联系的。一旦我们思考,这是否是个问题?这个问题应该怎么解决?实际上最后都能概括为,这是个产品应该遵守的需求吗?走到原创 2006-03-31 17:51:00 · 987 阅读 · 0 评论 -
考虑一个小例子,抽象描述系统
本文通过一个小例子,试图抽象描述一个系统。考虑一个简化的计费系统,有如下一些实体:1)客户档案,记载客户基本情况2)电价档案,描述电价情况3)用电记录,描述客户在一段时间内的用电情况4)电费档案,描述客户每个月应收的电费5)收费档案,描述客户实际的缴费情况这个计费系统,包括如下用例:1)维护客户档案2)维护电价档案3)维护用电记录4)维护电费档案5)原创 2006-03-31 18:22:00 · 1874 阅读 · 2 评论 -
对信息处理的过程的一个抽象表述
一个信息处理过程,可以通过归纳成一个抽象的过程:源结构化对象结构化对象目标这里结构化是相对的,是指相对于研究的范围而言,广义上讲,源和目标也是对象。如果把源理解成输入,目标理解成输出,那就是个IPO模型这里要强调的是一个抽象归纳,解析过程和合并过程是一个逆过程,起到一个结构化适配器的作用。展开一下: 解析和合并原创 2006-03-16 09:56:00 · 775 阅读 · 0 评论 -
关于场景的认识
场景、环境、状态、前置条件,这些名词都是同义词。信息系统根本上是一个状态处理机,通过特定的处理改变系统的状态。对信息系统的描述不能只考虑处理流程,也要考虑基于的环境、状态、场景。关系数据库提供了一个相对简单的场景。无状态的业务逻辑过程一般也基于一个简单的、稳定的场景。而业务逻辑过程内部,以及UI交互过程中,场景就相对复杂。场景设计,决定了行为的设计。没有抽象的场景,就没原创 2006-03-10 09:20:00 · 878 阅读 · 0 评论 -
从Eclipse RCP想到的
Eclipse的结构提供了一个很好的开放的,可插拔的架构的典范,如果能够找到一个合适的开发环境(直接用Eclipse swt是不好的,在数据绑定方面难以形成高效的开发套路),那么,Eclipse RCP完全可以作为一个企业应用的技术架构。另一方面,B/S结构的应用就显得难以达到这种效果了。原创 2006-03-14 20:20:00 · 557 阅读 · 0 评论 -
可插拔的结构
先研究一下可插拔的结构,有两个可以参考的产品: 1 Eclipse 2 Xoops Eclipse实际是采用的OSGI 的规范,MANIFEST.MF文件来描述插件的基本内容,另外通过一个plugin.xml 来描述针对平台的扩展。Eclipse提出了扩展点的概念。要支持扩展点,系统本身应该是可扩展的。对一个应用系统来说,也可以定义一些扩展点:例如菜单、用户的扩展的字段,都可以认为是扩展点原创 2006-03-09 21:01:00 · 4642 阅读 · 0 评论 -
一个产品的研发过程
一个人做产品研发,和多个人协作不同,可以省去很多的交互和中间过程。概括起来,大概包括如下过程:1)确定产品基本功能需求2)确定产品非功能需求3)分析产品功能架构,确定组件模型4)确定产品运行模型5)确定产品的技术风险,进行技术实验,规避技术风险6)选择核心功能,开发产品原型7)开发产品所有功能8)确定产品发布方案9)编写使用手册原创 2006-06-23 23:21:00 · 3206 阅读 · 0 评论