谢老师，白老师，你们好！上次4天的团体培训中，我承担的内容主要是不涉及开发过程的软件架构和测试，在实现中侧重于.NET。

用设计模式和基于构件的软件设计方法，来搭建软件系统架构。

在培训中，发现引入生动、形象的实例更能获得学员的欢迎和认可。

所以我在这次的课程设计中，将把案例应用到讲述的每个知识点上，同时引入学员们在项目中普遍关心的选型、性能分析等问题。

另外的一个问题是，上次的培训内容有些“大而全”了，这次我做了调整，去除了一部分专题，设计了包含具体案例的专题进行细致讲授。

让用.NET而不用java的设计者，去体会到微软的技术是到底从哪来的。

这样的一份讲义，我还会进一步的把语言调整的煽情些，引起读者和听者的兴趣。

赵巍构架设计和体系创建(交流稿)一、设计模式培训示例 (2)什么是设计模式 (2)举例说明讲授设计模式的方法 (2)开源项目中的设计模式 (4)NUnit的结构与设计模式 (4)Log4net中的设计模式 (4)二、软件工程中业务模式的使用 (5)自底向上分析 (5)自顶向下分析 (5)混合分析方法 (5)功能分解实例 (6)业务构件 (7)三、.NET企业级模式 (8)四、构建分布式应用程序分布式计算的8项注意 (11)网络通常是不可靠的 (11)响应是有时间开销的 (11)网络是不安全的 (11)网络拓扑结构通常会改变 (11)网络中通常会有很多管理员 (11)传输是要付费的 (11)网络通常不是同构的 (11)这里还打算安排一个大型的分布式应用案例 (11)五、部署并运行应用程序 (11)要考虑的问题 (11)几个基本的规则 (11)系统配置 (12)硬件伸缩 (12)负载平衡 (13)群集 (13)运行需求 (13)六、开发安全的应用程序中相关的知识点介绍 (13)传统密码学（Cryptograph） (13)单钥制加密技术 (13)数字信封 (13)数字签名 (13)CA证书 (14)七、性能测试 (14)一、设计模式培训示例（因为设计模式较多，这里仅用一个例子来说明如何传授设计模式。

）什么是设计模式面向对象的设计中，开发者遇到了很多类似的问题，这些问题可以用一个被证明了的最佳实践来进行完成，这些被证明了的实践就是设计模式。

使用面向对象，我们获得了代码的重用。

使用设计模式，我们获得了经验的重用。

设计模式不是代码，但具体类库和框架是设计模式的实现。

变化是永恒的，设计模式为适应变化而存在。

系统架构师使用设计模式是会让程序员一开始多写很多代码，但是他的存在能帮助程序员在将来遇到变化时少写很多代码。

举例说明讲授设计模式的方法有一个动画制作公司，制作了一个关于鸭子的动画片。

片子里有各种各样的鸭子，有的会叫，有的会游泳，这些鸭子都会被显示在屏幕上。

于是程序员设计了如下了一个类：这个抽象的鸭子类被各种野鸭、家鸭和橡皮鸭继承。

子类都有了父类的行为，会叫、会游泳和能被显示。

一天经过一个会议，公司决定鸭子也能够飞起来。

于是抽象的父类被设计师修改为：可是，在测试中发现橡皮鸭开始飞的满屏幕都是，而橡皮鸭是不能飞的！让橡皮鸭包含会飞的代码是不必要的重复甚至是逻辑上的错误。

那么使用接口呢，让能飞的鸭子继承能飞的接口？但是这样给代码维护带来极大的麻烦，当有很多鸭子子类时，我们不能知道哪些实现了该接口，哪些没有。

新的需求仍然在不断地出现，鸭子有的会飞，有的能蹦跳着飞，有的不会飞；有的会嘎嘎的叫，有的不会叫，还有的会尖锐的叫。

那怎么办，设计人员已经从面向对象的角度考虑了问题，可是他还是体会到了来自问题的压力，他是不是该上51job上去转转了呢？在这种情况下，使用如下一个设计原则：识别出应用程序中变化的方面(aspects)，然后将它们从稳定的部分中独立出来。

我们可以将飞和叫的行为独立到鸭子类的外面来定义。

如下图：PerformFly调用接口FlyBehavoir中的Fly方法。

接着涉及到下一个设计原则：面向接口进行编程，而不是面向实现编程。

飞有很多种飞法，定用飞的接口，具体的飞法放在具体的子类中实现。

对鸭子的叫也用同样的方法处理。

如下图：在具体的鸭子类构造时，用具体的实现了IFlyBehavior接口的子类来设置其FlyBehavoir 属性，决定具体是那种飞法。

甚至我们还可以在具体的鸭子对象中改变鸭子飞的行为。

从上面的例子，我们可以看出，使用组合而不是继承更能解决问题。

认识到这点，那么恭喜你，你学会了策略模式，如下图所示：从这里可以看出，设计模式，带来了很大的灵活性，另外，设计模式也是设计师之间交流的语言。

很多场景用一个简单的设计模式就能描述其解决方案。

其他的设计模式讲授方法也参照以上方法。

开源项目中的设计模式NUnit的结构与设计模式NUnit作为xUnit家族中.NET成员，是.Net的单元测试框架。

NUnit中使用的设计模式如下表所示，因准备时间关系，本讲义尚能不详述，将在未来的几天内完善。

Log4net中的设计模式Log4net来源于Log4j，是.NET版本的日志组件。

Log4j是APACHE组织提供的一个日志组件，利用它可以在不改变程序的情况下，通过修改配置文件来监控日志的输出。

Log4net中的设计模式如下表所示，因准备时间关系，本讲义尚不详述，将在未来的几天内完善。

二、软件工程中业务模式的使用一个业务模式描述了一个可重用方法来解决一个特别的商业问题。

一个业务模式可以被形容为一个“商业方案的架构模型”。

稳定关系●商业功能在商业数据上执行事务（典型的，创建，读取，修改，和删除）。

●商业功能被包括在商业组件中。

●数据被包括在商业组件中。

关联关系●商业功能被按照商业过程执行。

●商业过程使用商业组件提供的服务。

●商业组件在应用系统中被执行。

我们实际追求的业务模式是将业务功能定义在一种可以分解的层次，这些层次间有紧密联系。

业务功能定义通常可以和数据层实体间形成CRUD关系。

业务功能可以采用自底向上或者自顶向上或者二者混合的方式来分析和定义。

自底向上分析架构师使用这种方法，聚焦用户典型业务领域，去分析他们的业务过程。

用例图或者任何能表达业务过程中执行顺序和并行任务的方法，将会被采用，随后，分类、分析过程。

从业务模式的角度考虑，自底向上的分析方法存在一些问题：1. 对于包含许多用户的庞大过程，自顶向下地分析过程工作量非常大（为了减轻工作量，一种折衷的办法是，采用过程分析和用例分析相结合的方法来提炼过程）2. 过程的本质在于对“像-是”的情况的分析，只要这种分析足够清晰，它的结果就可以接受。

3. 为了确保业务模式的正确性，必须在相同的领域范围内进行反复的分析验证。

在这个过程中就会发现很多实际的问题。

自底向上的分析方法的好处在于，基础分析为驱动业务模式方案奠定了基础，验证业务模式的关键在于成功地实践，一旦选好了实例，自底向上的分析方法的这些优势就会有明显体现。

自顶向下分析自顶向下方法首先假定最上层的结构，然后逐步填充下面的层次，直到充分详细为止。

自顶向下的分析方法从描述最抽象的业务问题领域开始，然后逐步分解，直到最原始层为止，以此来验证结果的正确性。

这种方法能够通过一种标准方法来实现，就是用于功能建模的IDEF0，或者用于业务过程建模的扩展UML也可以。

事实上，很多前因后果决定了自顶向下的分析方法不需要详述业务过程。

自顶向下的分析方法在模式定义中的好处是由行业顾问做这项工作，这些顾问们往往有和许多客户在某个问题领域打交道的许多经验，因此有他们来完成这项工作将会既准确又迅速。

本质上，这种分析方法一方面执行了和专家进行知识挖掘的任务，另一方面，它也减少了必须直接分析的实例数目，改变了架构师的角色——不再是以前的工作人员而是现在的浏览者。

混合分析方法实际上，我们经常把自顶向上和自底向上的分析结合使用，在过程综合到层次结构低层次分解之间反复的变换。

这样做的好处是，可以用自底向下获取的现实世界功能来验证假设的自顶向下的分解。

实践证明，这是最快、最可靠的方法。

功能分解实例以下是关于病人医疗情况的实例，使用上述方法来进行业务分析，从而演示了核心业务模式的形成过程。

首先，分析问题领域的功能性需求。

以肿瘤治愈为例，得出40多个过程，参与的角色有病人、医生、系统管理者和机密保管员等。

其中机密保管员这个角色会随着信息的机密性改变而改变。

这些过程是用UML用例来文档化的。

它们在许多用例中都有相同或者相似的子活动高度地重复。

因此，我们抽取并整理了这些活动，形成以下功能清单：●病人登陆（用户检查）●病人注销（核查）●搜索申请的病人●管理病人详细信息●管理病人权利●查看私人区域●查看个人GP详情●管理个人一般健康数据●管理捐赠人明细●管理病人明细●管理家庭成员●查看采取的免疫措施和种痘●管理个人权利●查看病人病厉●查看病人私人区域●申请病历●复查病历●创建病人事件●管理病人个人事件●建立病人疗程●查看病人疗程●查看个人病历●定义普通协议●管理个人协议●维护医疗项目●执行医疗代码翻译●获取其它医疗代码●编制其他医疗代码●维护医疗路径●管理预约●改变预约●访问事件明细●访问系统索引●维护临床过程●维护角色定义●维护组/队结构●维护组/队成员●维护许可证授权●维护医生注册●医生登陆（身份鉴定）●医生注销（核查）●查看医生许可●维护具体许可●定义普通许可上图表达了医疗实例功能分解过程。

利用主题和功能的相似性把各个分散的功能归纳到更高的层次上去。

数据模型医疗实例有综合的数据模型。

经过对同一个问题领域的数据进行分析，共定义了31个主要的实体，如病人、医生、病人事件、医疗路线等等。

数据模型需要识别实体的候选码和它们的主要属性，描述实体之间的相互关系，分解所有的多对多的关系。

并且这些操作就是在功能分析时并行地得到的。

在实体之间的相互关系和聚合的基础上，上述31个实体已经分配给8个数据项。

这些项分别是：病人，病人协议，医疗路线，医疗项目，临床过程，角色、团队和组织，医生和许可。

这些数据项是目标数据库和动态内容定义的第一步。

采用传统的E-R图可以描述数据实体以及实体间的关系，并且标出了每个实体的主键。

映射关系功能分解的层次结构定义了需求功能，关系数据模型定义了需求数据。

此后，我们通过比较功能和数据二者之间的关系，能够得出一个初步的构件体系结构。

具体的做法是建立一个矩阵，行表示功能，列表示识别的实体，行列交叉处的值有C、R、U、D四种：C代表“创建”数据实体实例的功能，R代表“读取”数据实体实例的功能，U代表“修改”数据实体实例的功能，Ｄ代表“删除”数据实体实力的功能。

业务构件一般来说，要开发一些基于业务的.Net应用程序，应该首先从了解业务的特性开始，因为业务构件是业务所需要的数据和功能的IT代表，这是比较关键的一步。