摘要: 1 概述 这篇文章只是我在近期开发的一个小系统里应用LINQ TO SQL的其中一个总结。 我做的系统是一个奖金核算系统，其中有许多基础数据需要用户去维护，有些简单数据，如支出项目的维护，费别项目维护，部门信息维护其实都是一个个单独的数据表，只要提供类似于SQL SERVER里查看表数据的模式就可以满足用户的需求。2 思路 其实在.NET2.0时，就可以用绑定DataTable的方式来实现这个功能... 阅读全文

     摘要: Creation Method不属于Gof在《设计模式》一书提到的23种模式的任何一种，是作者自己定义的模式，他给其做的定义是：“创建并返回对象实例的一个静态或者非静态的方法”，他特别提到之所以要自定义这个模式，就是为了和工厂方法区分开来，启用工厂方法的动机在于用多态的特性来实现在晚期绑定，使创建对象更加灵活，而Creation Method的动机是什么呢？请继续往下看……  阅读全文

     摘要: 书中前五章主要介绍重构和设计模式是存在联系的，而不是对立的，我在三年前先后接触模式和重构，有时重构代码的时候自然而然的就形成了一种设计模式的类结构，而重构本质也是改善设计，当时就想，是否有一种或者多种特定的方法使代码通过重构最终形成一种设计模式，现在好了，这本书恰恰就是在讲述这些方法。  阅读全文

      今天上午开了一个信息化协调会，正院长主持，医务、护理、人事、药剂、财务、检验、影像以及正在实施住院系统的相关科室都参加了，会议内容主要是总结前段时间的实施的情况，以及明确各部门的职责，总之到最后都是在互相推卸责任，老是把一些数据的维护错误归结于我们信息科或者是HIS。
      现在虽然说医院在搞信息化建设，但实际上很多职能部门的思想还是停留在以前的运作模式上，很多管理方式都是沿用未进行信息化时的思路，这样导致HIS实施后，管理模式不适应信息化。今天开会就有一个非常搞笑的例子，护理部提出，现在护士人不够，可能护士流动比较大，有可能这个星期在内一上班，下星期就要到内二，但现在上了电脑系统后，无法及时赋予她权限，所以要求我们派专人接他们护理部的电话，一接到变更电话就要马上修改那个护士的权限，我晕，我直接说了一句，：“X主任，这样吧，我们装一台专用电脑，你们直接在那里维护全院护士的上班科室”，但那个主任却说什么没位置放电脑，而且要上网之类的话来推托，唉，我们科长也说不过她，最后还是勉强答应她的建议，我无语……
       

      上个星期整个星期在值班，真是辛苦，正值上线初期，一线操作人员不熟悉操作，更重要的是软件不成熟带来的诸多问题，弄得我疲于奔命，好在，总算过去，可以好好休息一下。
      今天星期一，上午是业务最繁忙的时候，但很不幸，坏事还是发生了，9点半左右，内科打电话过来说系统运行速度极慢，医生保存一条医嘱要等1-2分钟，这个不是夸张，我自己试过，需要1分钟左右的时间，于是马上打电话到收费处问问速度，结果一打过去，对方就说，正想打电话给我们说速度很慢，病人已经排到楼梯口了……。其实这个问题在上星期已经出现，一直以来，客户端的运行速度不断的在下降，于是查找原因，起初还是在数据库上做文章，加索引，加大临时表空间，可是收效甚微。
      今天，公司告诉我，他们查到原因了，他们在他们的数据访问类里面加了调试输出，结果发现，医生有可能在接诊病人开医嘱的几分钟时间里发出上百条SQL执行请求，然后我自己跟了下程序，发现的确很多SQL请求，而且大多数都是重复的，太可怕了，我就是选择一条已经开立的医嘱，也有16条SQL语句出现，这下明白了，就算服务器处理能力再强，也无法抗的住如此浪费的SQL请求狂潮，系统是C/S两层结构，没有中间的应用服务器，不能做缓冲，那么解决问题的关键只能在客户端程序里建立一些缓存机制，减少频繁查询数据库，但这个工作非常繁杂，而且风险很大，我准备找医生站程序作为试点。

   最近医院的住院系统开始实施，但本身那个程序处于半成品状态，但偏偏它又很复杂，可以说HIS是最复杂的信息系统，比ERP还要复杂，需求太多太细，而且多变。
    这几天问题集中在住院药房上，有个问题还惊动了院长，其实就是药品计费时段问题，一个患者入院，可能在下午，然后医生开了一些长期的医嘱，比如说2片感冒通，bid，现在的程序处理是直接生成6片到药房，它把当日入院下午那2片也一同当长期医嘱发出去了，这时药房就不认了，他们认为应该是4片，因为bid、每次两片这就应该是4片，然后他们居然还按4片发给护士，这样帐就乱了；其实一开始，程序是这样处理的：如果医嘱没有在规定的医嘱生效的起始时间段开出，那么自动生成一条临时医嘱，然后此条长期医嘱第二天生效，这样避免了频次和总量的不对应，但后来又不知道怎么回事把这个模式改了，现在回查需求变更，居然查不到更改的原因，唉，这又带出了一个问题，需求变更没有规范管理。药房还有个问题就是打印格式的问题，发药的模式是走请领单的模式，也可以说是申请单，就是护士在护士工作站发申请单到药房，但药房又根据其工作的需要，把请领单分成9大类：长期口服、长期针剂、临时医嘱、出院带药、贵重药、毒麻药、大输液、营养液、退请领，噢，哦的神呀，这还不算，还要有些请领单要明细，有些要汇总即可，有些要现打明细再打汇总，有些则反过来……还有，有些请领单格式还不是统一的，这些经过1个多月的磨合才基本搞完，现在又遇到数量不符，还得继续磨合。
   

1、如果有超过一屏的数据，想通过关键字查找到相关记录，然后再定位之，做法如下：
遍历所有行，把某单元格的值和关键字对比，找到后清除所有选择行，然后把当前行设为选择，然后把grid的CurrentCell设置为当前行的某个可见单元格即可，效果就会自动跳到定位好的行上。
示例代码：

2、数据绑定
其实很简单，只要实例化一个BindingSource对象，然后把BindingSource对象的DataSource属性设置为DataTable或者DataSet,然后再将DataGridView的DataSource设置为BindingSource对象即可。

     摘要: 最近在看CodeDom，发现其类层次很多，而且很复杂，所以写了一个Farade模式的类，希望在以后的开发中简化使用CodeDom，但由于时间有限，所以功能不够完善，也许要在以后使用中不断完善。  阅读全文

1、完整正式的用例格式：（1）单列文字（不是一个表格）（2）步骤编号（3）没有条件语句（4）扩展部分的编号规则是数字和字母的组合

完整正式的用例模板<名字>

<用例名应该是一个用主动语态动词短语来表示的用例目标> 使用语境：<目标较长的描述，如果需要，还包括触发事件> 范围：<设计范围，在设计时将系统作为一个黑盒来考虑> 级别：<概要、用户目标、子功能三者之一> 主执行者：<主执行这的角色名称或主执行者的描述> 项目相关人员和利益：<用例中项目相关人员和关键利益的列表> 前置条件：<我们所希望的，周围环境已经达到的状态> 最小保证：<在所有退出操作前，如何保证得到必须的信息> 成功保证：<目标完成时环境的状态> 触发事件：<什么引发了用例，可能是时间事件> 主成功场景： <在这里写出从触发事件到目标完成以及清楚的步骤> <步骤编号#><动作描述> 扩展： <在这里写出扩展，每次写一个扩展，每一个扩展都指向主场景中的特定步骤> <被改变步骤><条件>：<动作或子用例> <被改变步骤><条件>：<动作或子用例> 技术和数据变化列表： <在这里写出场景中因技术或数据变化而引起的可能分支> <步骤或变化编号#><变化列表> <步骤或变化编号#><变化列表> 相关信息 <项目所需要的所有附加信息>

2、图形符号有两个可用性方面的问题，第一，最终用户和业务执行者不可能熟悉这些符号，也不会有耐心来学习这些符号；第二，图形不能完全表示你所需要的意思。用例本身就是文字的，任何图形都只是为了帮助读者找到他们所要阅读的文字。

3、影响用例书写格式的因素

（1）矛盾的因素：业务环境、社会作用、不同文化

这个列为第一因素真的不为过，特别在中国，地大物博，很多项目可能是北方公司的人到南方做项目，文化背景不同，语言也不是很一致，这个会直接影响需求获取的精确度

（2）理解层次

本来开发人员和业务人员就存在理解层次不一致的问题，开发人员没业务人员懂业务知识，业务人员没开发人员懂软件开发知识，所以要降低这个因素的影响必须找到一个共同的具有标准格式的“语言”（如通用的用例格式）和很好的分工与协作方式。

（3）项目相关人员的要求

每个涉众（即项目相关人员）都有自己关心的方面，所以他们的要求也不相同，所谓众口难调，在这里体现的淋漓尽致。

（4）经验与格式

（5）覆盖面

（6）一致性

（7）复杂度

（8）完整性

（9）目标与任务——完成什么与怎样完成

（10）资源

（11）其他因素

存在着这么多因素，所以需求调研就不能以一种固定的模式推广，只能在一个比较大的框架上，通过调研人员发挥主观能动性与涉众一起完成需求的调研，但这些因素是提醒人们在需求调研过程中应该注意的问题。

4、五种项目类型的标准，五种情况：

（1）了解需求，甚至包括用例根本不在最后的需求文档中使用的情况（模板见p108）

你的用例通常作为一个黑盒，大多数都是用户目标级别。你可以用一个较高层的用例来描述语境，但是你最好不要经常使用海平面级别以下的用例。

（2）业务过程建模（模板见p108）

阅读这些用例的人往往是一些高层人员、部门经理和高级执行官，因此尽量使这些用例可读性强，减少细节的内容。步骤的编号突出了活动的时间顺序。一定要在扩展中描述错误的处理，这样才能揭示重要的业务规则。

（3）设计和量化系统需求（模板见p109）

当你为估计系统大小和结构而分析需求时，使用这个模板。以后，你可以细化需求知道完成这个完整的用例。

（4）在一个短期、高强度的项目中编写功能需求（模板见p110）

由于时间和经济的原因，需要避免编码的开销和编写完整模板；因此你可以使用非正式的格式。但你还是必须了解前置条件、保证条件和扩展。

（5）在一个长期、大型项目中，在增量式开发开始时编写详细的功能需求。（模板见p110）

当你收集行为需求，并且需要完整正式的用例格式中的所有信息时，可以使用上述模板。这种模板可能应用在大型、关键、昂贵的项目中；或者应用在有固定预算的项目中；或者应用在开发组分步在不用地方，在增量式开发的开始阶段需要扩充和检查以前设计的量化用例时；或者这样做时你的习惯（最后一句有意思，呵呵，“我就是喜欢”）

 

这一章其实是总结这本书第一部分，把之前10章所阐述的用例体各个部分汇总起来，然后根据不用的项目提出不同的用例模板，这样是科学的，因为每个项目都不同，不能用一种不变的用例格式来对付，要因项目而异。到这章为止，这本书的第一部分——用例体部分，已经结束，通过仔细阅读这十一章，使我更深入的了解了用例，结合以前做的项目，发现以前写的用例很多问题都没有考虑到，在以后的项目的需求调研中，我把这本书所强调的一些观点运用到调研中去。

1、子用例：一个执行步骤可以是一个简单的步骤或者是另外一个用例的名称。

一般的，步骤如果用下划线或楷体字区别开写的话，这个步骤就是子用例，UML用例图的表示就是用<<include>>来表示

2、扩展用例

两个用例之间需要另外一种连接，这种连接很像扩展机制。其具有以下特征：

（1）       有一个主活动，主活动可以被中断

（2）       主活动可以被多种方式中断，并且不能控制中断

可以考虑使用与描述场景扩展相同的机制，但这里是创建新用例。新用例称为扩展用例（extension use case）它除了是独立的用例之外，其他都与场景扩展相同。扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件部分中。请看以下例子

用例：编辑文档

主执行者：用户 范围：Wapp 级别：用户目标 触发事件：用户打开应用程序 前置条件：无 主成功场景： 1．  用户打开文档并编辑 2．  用户输入或修改文本 …… ……用户保存文档并退出应用程序

用例：检查拼写

主执行者：用户 范围：Wapp 级别：子功能！ 前置条件：一个文档被打开 触发事件：当文档被打开并且用户选择了打开拼写检查程序的情况下，在编辑文档中的任何时候。 主成功场景： ……等等……

注意“检查拼写”用例的斜体部分，在基用例（编辑文档用例）中并没有提及检查拼写用例，但在检查拼写用例中通过编写触发事件来引出基用例，基用例没有依赖扩展用例，对于以后的扩展具有很好的灵活性，但相反，扩展用例依赖基用例，基用例改变的话有可能影响扩展用例。

3、在必须的情况下才创建扩展用例，第一种情况是当有很多的用户可能使用的异步服务或中断服务的时候，并且这些服务不应该影响基用例。另一种情况是为一个已经锁定的需求文档编写附加文档的时候。在基用例没有锁定的情况下，扩展是脆弱。

 

这一章其实是说明了UML用例关系中的include和extend关系。