摘要：
在前几篇文章中，我们分别进行了域模型和用例建模，并使用 Robustness工具进一步分析验证了相应用例的处理流程，并在相应模型（域模型）的基础上，通过Robustness方法引入相关的边界对象，控制对象（控制器），并更新了相应域模型中类的属性（字段）。下面就可以进入到交互建模阶段了。如下图:
作为交互建模本身，就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配。
正所谓“只有在所有的用例为所有事件进程建立了交互建模式之后，才可以确定已经发现系统所需的每个对象所扮演的角色，以及它们的责任。” ----Ivar Jacobson
而上面的那句话换言之就是仅当为每一个用例的所有基本流程和所有分支流程绘制时序图后，才能确保发现了每一个对象的所有职责。 阅读全文
摘要：
这一篇文章的内容有些对不住大家了。因为公司正在准备发布新产品(Discuz!NT2.0)，大家的心思全在产品上，本人构思内容和写作的时间几乎没有了，因此就偷了个懒，把书中认为很有必要让大家了解的内容简单的抄上来。同时因为这一章主要的内容都是进行相应的用例文本和健壮性图的检查，以及更新域模型（使之逐步向详细类图逼进），所以如果大家感兴趣的话，可以找几个人一起研究一下，相信大家一定会有所收获的。最后我也希望在产品正式发布之后能够回过头来有时间进一步完善和补充相应的内容。再次向大家致歉了:(
好了，开始正文吧。
阅读全文
摘要：
在前三章中通过（问题域）建模和用例分析之后，在许多的UML书中可能接下来就要进行时序图和协同图的绘制了。但是问题好像还没那么简单，因为这里有一条鸿沟还没有跨过去，正如下图所示：
在我刚学开始学习 UML时，在拿到用例文本时要去画时序图总感觉有些别扭，不知如何才能将文本中的意思完全用图的形式表达出来，总是感觉分析出来的文本中缺了一些很重要的东西, 而这些被丢掉的对象最终可能会导致无法绘制时序图，但又找不出用例文本中到底还有什么东西被遗漏，最终导致设计瘫痪。后来从网上搜索到的一些文章里发现了这种方法(robustness), 在看了半天之后感觉找到了方向和窍门:)
阅读全文
摘要：
可能最近听易中天的“品三国”听得有些“走火入魔”，再加上本是对三国一直是个“门外汉”，一直以来只知道三国谋士里的诸葛亮，鲁肃，陆逊，庞统。所以才会在听到诸如：郭嘉，陈宫，贾诩（易中天非常欣赏的一位谋士）田丰，荀彧，徐庶，沮授，许攸，张昭等人的“事迹”之后深受感染。才能想应该写点什么以回味一下这些人的“功德”和“品行”。
另外因为这些人都自知非常聪明，而IT人员（特别是程序员）也基本上是一群自认为“聪明”的家伙。所幸就让这些人在IT行业来一次再就业，看看他们到底能够有何作为。
1. 鲁肃 诸葛亮 应聘 软件架构师
阅读全文
摘要：
需求复核旨在确保用例和域模型同时满足客户的功能性需求。同时确保客户知道开发小组将根据这些需求做何种设计。同时它也是系统分析阶段的一个里程碑(milestone)。
这一阶段在ICONIX方法中的位置如下图： 阅读全文
摘要：
在上一篇文章中我们了解并进行了域建模，换言之我们有了一个好的开始，起码开发人员对自己要开发的软件已有了初步的认识，且也得到了进行交流时可以使用的术语表。
本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模，同样在文章的最后还会有在这个阶段最容易犯的10个错误，以给大家提醒或在分析过程中进行参照。
本文在ICONIX方法中所处的位置如下图（红圈标记的地方） 阅读全文
摘要：
ICONIX过程的规模大概在重量级Rational Unified Process (RUP)和轻量纺的极限编程之间(XP)。同时这种方法也是用例驱动，但不需要RUP使用记录延续到表中带来的大量开销。和XP一样，它相对较小，不像XP那样摒弃了分析和设计过程。因此，有助于使用UML，同时对需求进行跟踪。该过程遵循Ivar Jacobson的用例驱动思想，能够获得有形，具体，易于理解的用例，开发小组可以使用这个用例来驱动开发工作。
该方法是迭代，循序渐进同时足够的轻量级。因为它遵循20%原则，即用UML中20%的图表来完成设计中80%的需求。从这个角度讲倒是满符合中国国情的，因为具我观察不少国内软件公司都不是肯花心思和时间在设计架构上。 阅读全文
摘要：
最近园子里的book.save()讨论已让我看的有些厌恶了。同时也希望大家不要再在这个问题上火上浇油了。有关这个问题在别的技术社区早就有过讨论(不要吃人啃过的馍)，最后又怎么样呢？ 还是希望大家务实点好（干好手头的事等）。
从这些计论中发现大家在不厌其烦的寻找所谓的银弹，但具我了解这个问题可能无解。必定软件开发设计要有一定的行业背景（应用场景）。而离开这些条件的话，空谈这个问题犹如盲目人摸象（如果把上面的问题放到不同背景下都会有不同的解答）。
另外我担心的是争论到背后，不仅没找到所谓银弹，可能大家倒学会扯蛋了。当然如果是在春晚赵本山小品中的 "扯蛋" 的话，倒还说的过去，必定那位秘书找到了解决问题（用户需求）的方法，因为王八蛋确实不好用筷子夹。所以这种"扯蛋"可以被看成是解决方案。但不是这样的话，就太浪费大家的精力和时间了。
最后还是希望大家正确对待这个问题，不要给它过多不该有的关注:)
希望DUDU暂实不要将该贴从首页移走!!!
而那些想 阅读全文
摘要：
在7月份中我曾经写过一篇文章，叫".NET2.0 框架中的 AbstractFactory 模式 " 链接如下：http://www.cnblogs.com/daizhj/archive/2007/07/23/828249.html
里面主要说了在2.0框架下的数据库链接工厂中新增的几个类，而这几个类采用的就是 抽象类工厂模式 （Abstract Factory）。因为在Discuz!NT 2。0中使用了这些新的类，所以导致我们的产品dbhelper.cs可以支持几种数据库（目前官方实现的有sqlserver ,access ,mysql）。但同时因为1。0框架下没有这些类，所以我们采用自已简单实现其中主要的类代码来解决这个问题。这就有了今天文章的内容！ 阅读全文
摘要：
设计前提：早在RC1之前聚合功能还比较弱化时，系统结构比较简单，只用了一个website页面就聚集了大部分的功能调用。因为快速完成之后陆续又加入了不少新特性，导致类的名称(website) 与所聚合提供的功能已完全不相符 (代码已过度膨胀) ，所以重构的任务已变得非常紧迫了。但用什么方式，因为系统聚合时是按内容类型聚合功能页面并决定显示方式的。而这里的内容类型在大概可分为（论坛主题，相册，图片，空间文章（及最新回复）等）。为了尽量简化系统设计时的复杂度，这里只按内容所属的大类（论坛，空间，相册, 图片）来进行简单的初步规划，这就产生出来上面图片所说的类AggregationData,SpaceAggregationData,
AlbumAggregationData.cs,ForumAggregationData.cs ...... 阅读全文
摘要：
在文章的开始,我先举一个例子
美国M4谢尔曼坦克 VS德国的虎式坦克(相关资料如下http://mil.eastday.com/m/20070515/u1a2833237.html)
5：1 在五一期间，电视节目中的二战武器大对决吸引了我，其中当美国大兵说他们在用5辆坦克的代价来换德国人的一辆虎式(I）型坦 克时，我们可以得出一个结论。蒙哥马利和艾森豪威尔是在用二三十人的生命去换德军的一辆坦克（而因为德军坦克装甲厚重，里面的架驶员得以逃生）。这是怎么一种自杀式的进攻呀！也许这么高的伤亡率在最终的胜利面前可能无所谓，但对于士兵([拯救大兵瑞恩])却不完全是这么一回事了。而这里公司的CEO，或高层无疑也可以被视为这两位伟人的化身。为了开发进度和用户，他们可以强迫思维活越的程序员丧失创造力，因为他们需要的是能生成代码的工人（相当于打仗的美国大兵）。而培养这些大兵的军事训练所（软件培训中）也就成为源源不断制造这种产品的工厂了。
阅读全文
摘要：
继上篇文章之后（链接），大家给了一些反馈和意见，有些BUG和不当之处我已修正,将会在2.0正式版本中提供给大家。希望大家能继续支持我们这个开源项目。
好了，开始今天的话题，首先需要说明的是因为这两个控件都比较简单所以放在一起给大家说一下。
先说一下 ColorPicker 控件 ,贴一张运行效果图让大家看一下：
阅读全文
摘要：
今天公司同事在聊silver light时，把它的名字按字面直译过来叫做"银光"
本人给这个“银光”的解释为“把公司的银子都花光”
而这时我旁边的同事SUN语出惊人 “淫贼田伯光” ，我一听不禁喷饭。太可乐了
不知道园子里有什么人还有什么搞怪的想法，不妨贴出来让大家也乐乐。
望DUDU先不要删除该文章（明天再删），必定作为程序员找个乐不容易:(
阅读全文
摘要：
大约还是去年12月份，当时项目中遇到了一个很棘手的问题，就是管理员（或站长）在后台设置了邮箱信息之后，使用注册邮件发送激活验证码时，总有用户反映不能收到激活信息的邮件。
虽然不能收到邮件的情况有很多，甚至我已通过这个邮件发送程序测试过国内大多数知名网站的邮箱（如126，sina ,sohu ,gmail等），但还是有站长或用户隔三差五反映这个问题。甚至到今天我偶尔还会得到技术支持部门有关这方面问题的报怨。因此，今天这篇文章虽然说到了一个有关这个问题的解决方案（但不完善），但还是希望园子里以前处理过这方面问题或有成功经验的朋友指点一二。
好了，不费话了，开始今天的话题。
阅读全文
摘要：
继上篇文章之后（链接），大家给了一些反馈和意见，有些我已动手进行了部分修改,将会在2.0版本中提供给大家。希望大家能继续支持我们这个开源项目。
好了，开始今天的话题，今天就说一下 Tab 控件。
先贴一张运行效果图让大家看一下：
阅读全文
摘要：
作为一个社区类型软件，大并发支持和高效稳定运行永远是“硬道理”，而有效安全的使用缓存恰恰能起到事倍功半的效果。而.NET本身所提供的缓存机制又显得过于“单薄”，比如说订制不太灵活方便, 缓存对象之间层次感不强, 使用时缺乏统一的管理等等。
Discuz!NT缓存产生背景：
在去年五月份我加入Discuz!NT项目组时，发现这个项目当时还未使用缓存机制。主要原因是项目还处于起步阶段，很多东西还只是有想法，但未付诸实施，或还没找到合适的方案， 而缓存就是其中一个到底该不该使用，如果使用的该到底能多大程度缓解数据库压力以及开发成本的东西。
阅读全文
摘要：
继上篇文章之后（链接），大家给了不少的反馈，其中有肯定也有否定的，必定程序设计有很多个性化的东西，因此就会有不同的意见产生。我会从中找出合理化的意见并纠正以往认识和设计思路上的错误。希望大家能一如既往的支持我们的这个开源项目。
好了，开始今天的话题，今天就说一下 TextBox 控件。
阅读全文
摘要：
应用场景：net 框架下的HttpModule (.net2.0 代码)
先看一下 Observer 模式结构图:
阅读全文
摘要：
Discuz!NT在开源之后，还没什么文章来说明 Discuz!NT项目的一些特点。作为这个控件库的设
计者，本人将在接下来的时间里用连载的方式来向大家解释其中一些控件的设计思想，实现功能以及
一些未曾使用过的功能展示（因为管理后台只使用控件的部分功能）。同时因为这组控件开发的周期
很短（当时仅用一个半月，后不断增强功能），有不少思路和控件设计的规范相驳，但当时只考虑为
后台程序开发和订制方便，因此就暂且开发成了这个样子，但本人日后会不断完善和规范这些代码:) 阅读全文
摘要：
应用场景：net 框架下的TextWriter，HtmlTextWriter，CssTextWriter,IndentedTextWriter 等
先看一下Decorator 模式结构图:
阅读全文