系统设计
讲述系统设计的感想、思想、工具、步骤和方法等。
摘要: 个人觉得设计人员可以分为四种类型：模块设计人员、框架设计人员、专业领域设计人员、系统设计人员，这四种类型的设计人员并没有什么绝对的谁强谁弱，只能说各有千秋吧，但一定程度上来讲，四种类型之间还是存在着一些关联，来看看这四类设计人员的专注点和关联吧：
阅读全文
摘要: 每个系统中都会有需要配置的属性，而通常这些属性的配置都会是分散式的管理，而且很多时候都是不支持动态，在实现这些属性的管理(新增、编辑、删除、保存等)时总是要不断的做重复的工作，如果框架中能提供一个这样的基础设施那么对于系统的配置属性管理来说就会比较好了，这样的话系统中所有的属性配置就可以采用统一的方式进行配置、获取、管理和动态的更新了，如果能动态的管理系统配置属性的话，简单的动态改变系统行为也就自然的可以实现了。
阅读全文
摘要: C/S结构的软件的可维护性一直就认为是较大的问题，当然，在引入了自动升级这样的小功能就好很多了，这里谈谈C/S结构软件的可管理性，意思就是指Server对Client端的管理，在大多数C/S结构的软件中，并没有很强的管理性的概念，更多的面都是关注Server的业务处理、数据存储这些功能，当然，不一定所有的C/S结构软件都强调Server对Client的管理功能，来说说自己看法中的Server对Client的管理功能吧。
阅读全文
摘要: 在进行系统设计时，采取的通常都是逐级分解的策略，无论是分层、分模块都是典型的分而治之的策略，而系统在通过逐步分解形成架构、详细设计时，输入、输出以及扩展都是考虑的重点。
阅读全文
摘要: 早上上班，就听闻用户评价系统代码写的很烂，作为programmer，听到这句话估计都有很不服的心理，但从用户评价系统的观点去看，就可以表示理解，在这个项目中尤其突出，用户最为看重的是系统漂不漂亮，操作起来是否方便，最后才是系统功能实现是否和需求一样，而事实证明，很多时候其实系统功能是已经实现了的，为什么他们还觉得和他们的需求不一样呢，问题出现在交互上，操作上他们按照他们的想法去进行，发现没法用，在这种情况下，他们就认为系统是不可用的，在系统设计的可用性上要引起足够的重视，这种看起来的小事往往容易造成客户对于系统的不信任和抵触。
阅读全文
摘要: 动态产生的持久模型和数据存储，这个词语感觉挺晦涩的，不过估计在实际的项目中或者研发的产品中大家都碰到过这样的场景：
例如在一个简单的考试系统中，出题人在系统中出题，答题人进行相应的答题。
希望能发起讨论，总结出一个这样的设计模式，^_^，顺便还发起对于另外一个场景的设计模式的讨论，需要动态的扩展目前已有的PO或表，不知道在这个场景中大家会采用什么样的解决方案，预留字段？动态修改表？关联属性扩展表？抑或别的..........
阅读全文
摘要: 系统的不断抽象形成的接口实现与配置实现，系统的简易性、复杂性、可维护性到底是增强了还是降低了呢？...
阅读全文
摘要: 在设计时会碰到两种类型的设计，一种是框架级产品的设计，一种是项目产品的设计，在面向这两种进行设计时觉得还是非常不同的，框架级产品的设计强调一种通用性的抽象上，在这点上通常依赖开发或设计经验来进行抽象，难度不仅在此，通常框架级产品的设计都会面对技术性的问题，也就是说在设计阶段根本就是无法进行细化的一些部分，这种现象在框架级产品中通常出现，这时在进行设计时就要慎重考虑，通常按照敏捷工程的方法的话是先进行spike，spike后再进行相应的设计；对于项目产品的设计强调的是对项目需求的实现，这个时候通常需要的是业务角度的抽象，当然，这点也是具有难度的，通常来说项目产品上不会出现太多的技术难度，也不希望出现。
阅读全文
摘要: 一直以来对于Acegi实现Domain Object Instance的权限控制就比较感兴趣，今天抽空大致的看了一下，感觉和我以前提出的数据权限那部分的实现是大致相同的。
阅读全文
摘要: 一直以来，各种行业都宣传要本着用户是上帝来服务，确实，真正做的成功的企业其实都取胜于这个原则上，软件行业其实同样如此，要把用户真正的当成上帝才行，就像MS，MS从很多方面都是在为用户考虑，不论是面向最终用户还是面向开发人员的产品。
阅读全文
摘要: 女娲造人，耳熟能详的神话，作为一个技术人员，不得不佩服女娲的系统设计和实现能力，^_^，人是一个极度复杂的系统，需要实现N多的功能，其系统的分解和设计需要有极强的抽象能力，女娲就像是一个伟大的架构师，同时又不仅仅如此，还是一个伟大的程序员，将系统实现的如此完美。
阅读全文
摘要: 界面对象化是指以对象的思想去描述页面元素以完成UI的集成和开发，以使UI原型能够映射或转化为可运行的系统原型，提升系统开发的效率，避免大量的花费时间在UI的集成、维护上。
阅读全文
摘要: 回顾自己所经历的两个项目，来对设计阶段进行了总结，自己也算是个XPer，经历过的这两个项目也基本都是采用XP的方式进展，大家都知道，XP在设计阶段推崇的是群体设计，通过CRC来完成，在这里就对两个项目执行的情况做做总结。
阅读全文
摘要: 就设计文档的编写、意义来探讨设计文档。
阅读全文
摘要: 数据集表现层组件暴露对外的接口，组件可通过参数设置等方式来达到对组件的如下控制：
阅读全文
摘要: 担任系统设计师的职位一年了，尽管自己到现在为止仍然是个不合格的设计师，虽然这一年以来也不是完全从事设计的工作，但毕竟站在这个岗位上，主要从事的还是系统设计方面的工作，加上自己也有志于在这个方向发展，所以做一个年度总结是有必要的，也希望能对希望进入设计岗位的朋友们有些帮助，同时也希望得到在设计岗位上有经验的同行们的指点。
这也是自己真正担任系统设计师这个岗位的第一年，尽管在以前的工作中也曾经负责过设计部分，但现在回顾起来，觉得如果不在这个职位上，很多时候是无法了解到这个职位应该做的事的，自然也就无法去做了，在整个一年的工作中学到了很多的东西，同时也暴露了自己很多的不足，但总体而言自己是觉得已经踏入了系统设计的大门，但还需要不断的提高。
阅读全文
摘要: 前天那篇blog更多的是讲了下数据驱动、模型驱动的大致概念，今天更多的是讲数据驱动以及模型驱动在进行系统实现时的方法、过程以及自己的一些思考。
阅读全文
摘要: 数据驱动、模型驱动作为如今软件设计中两种不同的模型驱动方法，应该说各有各的优缺点以及适用的场合，不能就一概的去认为哪种必然就是更好的。
阅读全文
摘要: 软件建设需要考虑的重要的两点我觉得是：
1、客户的功能需求以及非功能需求。
2、软件的维护性。
软件的技术架构就是为了满足以上重要的两点而诞生的，同时由于软件的技术架构决定了使用它的开发人员所需的水平以及开发的难易，此时又要尽量做到降低对使用者素质的要求以及开发的门槛，以保证开发的高效性，但这个相对上两点来说更没那么重要。
阅读全文
摘要: 插件架构体系是我一直就非常关注的内容，其实插件架构体系的发展已经有很久的背景了，插件架构体系的优点我们也是能看的非常明显，象硬件一样的即插即用、无论对于公司还是业界而言的良好的积累方式、为公司或业界提供统一而规范的开发方式以及稳定的内核架构等等，这些优点无论对于公司还是业界来说都是非常重要的。
插件架构体系基本的一个概念就是基于松散的模块积累方式，通过新增插件以及扩展原有插件的方法来完成系统的实现，凡事有利必有弊，在看到插件架构体系的这些优点的同时，在实现和使用插件架构体系的时候仍然会碰到不少的问题，在本文中大概的整理了一些也相应的提出了一些自己的看法。
阅读全文
摘要: 几乎在所有的系统中对于权限控制都有直接的需求，而这类需求往往有其相似性，综合常见的对于权限系统的需求构成了本文档，文档主要从功能复用以及模型复用的角度来对权限系统进行总结，以便在各种系统中可对照此篇文档来进行权限系统的实现，考虑到文档的关注点在复用度，在文档中不会过多的去描述功能点到模型产生的过程，而是采用直接通过产生的模型来说明基于此模型如何实现功能点的需求。
阅读全文
摘要: CMS中缓存显的至关重要，CMS中的缓存主要有静态缓存和动态缓存两种技术，但看下来现在觉得这两种也只是对于最终信息页面的缓存，现在的需求是：
1、站点、栏目、信息列表的缓存。
2、信息页面的缓存。
阅读全文
摘要: Domain Model对于大多数的人来说都不怎么的陌生，Domain Model作为实现业务层的两种重要方法之一，在PoEAA(企业应用架构模式)中得到Martin Fowler的大力推广，但个人觉得在Domain Model上的应用并不是那么的理想，这个还得从业务层实现的两种模式谈起，分别为Domain Model和Transaction Script，Domain Model的原则为采用Domain Object的方式来实现业务逻辑，使得业务逻辑得以聚合到对象本身，从本质上提升业务对象的可复用性，其优点就在于提升了业务对象的复用性和代码的整洁性，缺点则在于实现的难度较高，有一定的学习曲线；Transaction Script则为采用Script的方式编排业务逻辑，其优点在于实现起来简单，缺点在于代码中出现较多重复的业务逻辑块，在业务逻辑一旦变动时需要修改很多地方，降低了业务逻辑的复用性。
阅读全文
摘要: 本篇为漫谈权限系列之结尾篇，涉及到权限系统的开源产品、个人观点以及其知识体系的描述。
阅读全文
摘要: 本文描述了基于ACL模型实现权限系统需求的方案以及优缺点！
阅读全文
摘要: 按照目录完成实现方案中的技术策略和基于RBAC的实现两部分。
阅读全文
摘要: 按目录结构完成的漫谈权限系统系列的概述、目的和需求部分。
阅读全文
摘要: 昨天没什么条理的写了昨天那篇文档后，今天想想觉得权限系统还是挺值得写写的，今天先大概的整理了下思路，准备按照以下的目录结构系统的对权限系统的实现进行描述和分析。
阅读全文
摘要: 本文作为漫谈权限系统的开篇，主要描述了权限系统的一般需求、实现方法以及实现时的难点。
阅读全文
摘要: 架构设计，一直就是软件业界中显得高深的名词之一，会造成很多的人对于它都充满了神秘感，但接触过几年软件业的人很多时候又会觉得软件架构原来不过如此，特别是看到一些架构设计文档后更是得出如此的感想，但真的是如此吗？也许是因为那些架构设计文档并没有起到它们真正的作用，只是拿来糊糊人的吧，架构设计文档最重要的是要能对系统的软件设计做出指导，做出规范性的约束，不谈这些，重点还是谈架构设计。
阅读全文
摘要: 这是在这次写架构设计文档后的一些感想，总体来说我觉得最重要的仍然是需要明确的知道架构设计文档的目的，何谓架构，架构设计的过程，架构对于需求的满足，在这之后可进行模块的概要设计，模块的概要设计其实同样是一个由繁化简的过程，产生出关键类以及类的接口设计，详细设计则是具体的对象设计以及接口实现。
阅读全文
摘要: 在一个Web文档管理系统中，用户通过管理界面可增加新的目录分类，并且目录下既可包含子目录又可直接包含文档，同时用户可对目录以及文档分别授予访问、编辑、删除的权限，并且权限均为继承的，意思也就是比如有A目录，A目录下有B子目录和C文档，如用户未对B子目录进行权限设置，那么B子目录的权限控制是和A目录相同的，如用户对C文档已单独授权，那么则取其和A目录权限的交集；同时对于目录以及文档的权限都可分别授予给角色、组织机构、用户或三者的合集。
阅读全文
摘要: 对于B/S结构的权限控制，有N多种实现方式的权限模型，但很多都是非常的复杂，以前在做这块时一直就做的不是很好，考虑的过于复杂，其实应该遵循Simple原则先做出自己能想到的最简单的方案，再逐渐的重构，一种基于URL方式的权限模型就非常简单，很容易理解，也是非常的有效。
阅读全文
摘要: 国内的软件公司来说仍然以行业化公司居主，而这其中大部分是做中小型的应用系统的，在这些公司中或多或少的存在着自己的一些多年项目积累形成的技术体系，但由于行业化公司来说，毕竟其优势在于行业化软件上，有想法的公司嘛就会自己去搞一套框架，使得自己的行业化软件均可在此之上进行快速、有积累的搭建，尽管这样，但毕竟其是行业化公司，在这方面自然不如专业做此类中间件的软件厂商来得强，虽然很多行业化软件也许根本就不需要一个强大的中间件，但毕竟专业做此类中间件的软件厂商可以从技术上、稳定性上、延续性发展上保证中间件的有利，而行业化软件公司应该发挥本身在行业业务的特长，基于此快速的搭建出适合行业的业务软件，这个我觉得就是双方互相发挥彼此的优势，何必以己之短对他人之长呢。
阅读全文
摘要: 系统设计师做为软件开发过程中的一个重要的角色，承担着系统的架构设计、概要设计的重要职责，对整个系统的技术负责，为整个系统开发过程中出现的技术问题负责。
阅读全文
摘要: 粒度这个词对于设计人员来说也不是什么陌生的词，粒度上通常称为粗粒度和细粒度，而这里讲的粒度控制主要指的是在系统设计的过程中如何根据需求去控制设计的范围。
阅读全文
摘要: 架构设计这个词听的非常的多，但真正何谓架构设计呢？？可能要你真的来讲还真的讲不太清楚，很多人都知道架构设计是对系统进行分层、分模块进行设计，但又有多少人知道这步应该怎么去做呢，往往很多的programmer在刚进入架构设计这个领域的时候，受到以前做模块的那种影响，把自己的眼光限定到了具体的模块实现上去了，并没有站在系统的高度上来把握系统的架构，这都是些理论性的话，来讲点实际的，^_^，具体架构设计指的是什么呢？目的是什么呢？如何去做呢？下面来讲讲我的体会。
阅读全文
摘要: 虽然这些文档一般来说公司都是有模板的，但我写这些文档以来基本上是每写一次就把目录结构给改一次，应该说这是因为自己对这些文档的理解开始加深，慢慢的越来越明白这些文档的作用和其中需要阐述的东西，觉得这三份文档主要阐述了一个系统的设计和实现过程，从系统分解为层次、层次内的模块以及相互的接口、模块分解为对象以及对象的接口、实现这些对象接口的方法。这次又整了一份，^_^，欢迎大家指正。
阅读全文