• • • •
谢谢观看 2011-04-07 gsnidi
我们现在缺乏什么，何为治本的方法？
• • 场景1：一个项目里面的开发人员奋力的在不停的修改BUG，加班成为常态，但BUG 永远改不完。 场景2：系统上线后运行良好，但一个需求变更或者一个新来的需求，导致整个系统很 多地方都需要修改，业务人员不理解为什么一个简单的东西，开发人员要很久时间才 能做出来，而且还破坏了以前的正常的功能。 上面两个场景是不是经常在我们的工作中遇到，当发生了上述情况下，我们是不是是 在疲于奔命解决但问题依然存在，BUG依然每天都有，需求一旦变更，系统要大范围 的进行修改和测试，每天都在在数据库里面调整性能？ 根源在哪里？
•
• 根源分析： 1）我们的技术用的不对 2）数据库设计不正确 3）。。。。。。 是上面这些吗？那么是不是把技术提高了，数据库设计好了，这些场景中出现的问题就自 动消失？会消失一些但可能会有不断相同的问题重复涌现。
因为根源不在这里，根源在于【业务没有进行梳理，没有业务模型分析过程】， 才会导致后续的一系列的问题，业务梳理清楚后虽然也会有BUG出现，但会导致相同的问 题不会一而再再而三的出现，同时修改一个bug不会影响到其他正常的功能的使用。
开始设计
2 上图是在1图的基础上扩展而成的，从整个设计过程可以看出， 没有一步到位的设计，都是不断完善的过程，所以开始设计的时 候不完善不要紧，关键是要坚持这种设计方法去不断完善设计， 最后达到你所要的效果。 因此我一直强调，正确的方法+坚持 = 成功的要素。 在系统设计领域，你再刻苦再努力，如果没有正确的方式方法， 其实是事倍功半的。我一再强调正确的方法，何为正确的方式方 法？其实在本文档的前面已经在图上进行说明，这里再阐述一下。 我们很多系统开发人员在做一个系统的时候，常常忽视了业务 梳理的过程，这个过程其实是业务建模的基础，而这个业务梳理过 程和需求人员的需求分析调研的过程存在一定的差别，前者是系统 设计人员在脑海里面形成结构的过程，而后者是需求人员出需求分 析成果的过程。 我们很多系统开发人员尤其是很多设计人员并没有这个思考和 设计的过程，而是直接到达物理表层面和代码层面，思考如何应用 好的技术来提高系统的性能和效率，但很少去考虑业务层面的东西， 打个比方：地基都有问题，地基上面的东西全是浮云。
我们现在缺乏什么，何为治本的方法？
• 我们在进行系统设计的时候，常常根据需求就直 接到代码或者到数据库上去了，很少对需求文档 上面的东西进行梳理，进行归纳，去研究分析其 外延的关系，内在的关系，一句话总结就是忽略 了业务建模的过程，所以才会有大家经常口头上 的一句话：为什么需求到技术就走形了呢？理解 就偏差那么大呢？ • 因为我们缺了中间那步，没有有效的把需求语言 所表达的东西无歧义的转化为技术人员能够看的 懂的技术语言，导致了脱节，自然业务都是混乱 的谈何系统稳定？
如何进行架构设rchitectural Pattern 模块结构(From Mud to Structure)型
分散系统（Distributed Systems）型，为分散式系统 提供完整的架构设计
人机互动（Interactive Systems）型，支持包含有人 机互动介面的系统的架构设计
开始设计
1 简单描绘出如何去定义类/接口中的各种元素，以及类和接口间的关系 接口可以 多继承接 口
类只能单继 承类 可多继承 接口 类/接口的属 性指向类/接 口
开始设计
继续渐进设计，属性开 始添加数据类型 为了满足复杂数 据类型关联，添 加父亲类
不同的属性实体对应不同 的数据类型实体
完整的代码 生成器业务 模型架构图
例子 --基于实体的代码生成器的业务建模
• 需求分析 2）不需要数据库支持 ：必须是实体模型，能够进行序列化成二进 制文件，也可以放入数据库中进行存储 ：要设计的中间结构不能是数据库表，而是 可以进行序列化的实体对象
例子 --基于实体的代码生成器的业务建模
• 3）能够将结构中的元素自动组合生成相应的代码
重视业务建模，它的作用抵半只军队
• 业务建模是整个项目开发里面很重要的一个节点，但我们 常常忽略它，业务建模的位置居于需求分析和技术分析之 间，并且侧重于业务层面。它的核心价值就是作为需求和 技术的平滑过渡调节剂，那么业务建模人员自然就是平滑 过渡人员，不仅要能够对需求进行抽象，并且还需要技术 层面的支持，所以建模人员需要兼顾业务和技术两方面的 知识，脱离于具体语言和具体的技术细节，只是从业务角 度，以技术眼光来构建整个系统，构建出来的方案再根据 项目的具体要求去完成其他的技术设计细节比如物理表结 构，技术框架等。
Adaptable Systems型，支持应用系统适应技术的变 化、软件功能需求的变化。如Reflection（反射）模 式、Microkernel（微核）模式等
如何进行架构设计
• 架构的分类（我的理解）
如何进行架构设计
• 从以上两幅图中可以看出：架构设计是分层进行 的，从业务层面->技术层面，我认为任何割裂这 种层次顺序进行设计的东西都可能会存在问题。 • 为什么这么说？ 如果在业务模型上面没有将客户 的需求进行很好的抽象和分类，那么即使在技术 建模方面运用了大量的设计模式，代码也十分的 优美，但因为业务关系的不稳定性，软件仍然会 处于随时修改的风险阶段，优美的代码也会随时 因为不断的修改而逐渐变得混乱。
有效的架构设计
--帮助企业面对业务的不断扩展& 帮助开发人员的顺利转型
何为架构
• 人们对一个结构(或领域)内的元素及元素间 关系的一种主观映射的产物，是一种抽象 的过程。
架构设计的目的
• 在一个软件项目开发过程中，将客户的需 求转换为规范的开发计划及文本，并形成 特定的需求边界内的，规范的，经过抽象 的业务集合体结构。该结构中展示了业务 元素自身具有的属性特征，反映了业务元 素之间的相互关系。 • 能够使得团队成员，不管是开发人员还是 需求业务人员都能通过设计形成的规范文 本去探讨更深层次的东西，去把握在客户 需求中易变的部分，使得开发出来的软件 具有很好的整体性和扩展性。
要思索实体模型与物理模型的关系
在我们一般常识性的认识中，实体模型是什么结构其反映在物理模型上的表结 构也应该是一一对应的关系，那么这种说法对吗？ 这种说法不完整，上面提到的只是对应于实体映射模型中一种映射关系，其实 还对应其他两种实体映射关系，见下图：
要思索实体模型与物理模型的关系
• 从以上图形中可以看出，业务实体结构和物理结构之间的对应关系并 不是唯一的，而且根据对系统的不同应用所采取的映射策略也可能是 上图3种方式的变种，但不管怎么变，必须要遵循一定的原则： • 1）只有继承类才能在物理结构层面进行合并。 • 2）任何形式的变化都要不能破坏业务结构的划分，例如：为了提高 数据库的访问效率，在物理表层面把会员和会员卡属性进行合并，虽 然在数据访问上提高了效率，但其破坏了业务实体职责单一性的约束， 这会导致一系列的关联修改问题。 • 3）任何的变化都必须符合整体的业务架构的清晰，不能为了提高性 能而牺牲业务结构，破坏了业务结构的合理性，带来的影响就是系统 根本无法适应不断变化的业务需求和不断拓展的业务发展，而时常处 于风雨飘摇中。
例子 --基于实体的代码生成器的业务建模
• 需求要求： 1）要有一种结构能够容纳类/接口/枚举的标 示结构 2）不需要数据库的支持 3）能够将结构中的元素自动组合生成相应的 代码
例子 --基于实体的代码生成器的业务建模
• 需求分析 1）一种结构能够容纳类/接口/枚举等标志结构 ：类/接口/枚举如何保存到一个中间结构去，该中间结构能够将类/接口/ 枚举所具有的属性标志进行分解后存储在其中，这些属性标志包括： 访问修饰符(private/public/protected) 标示(class/interface/enum/flag enum) 类修饰符(abstract) 继承关系 属性 私有字段 数据类型 。。。。。。
如何改变自己的思维，成为合格的系统业务建模人员
• • 本文以上的篇幅通过介绍系统建模的整个思考过程和渐进改进过程，说明系统建模并 不是一个很复杂的东东，但如果你没有领悟，那么它就是一个很玄的东西。 何为领悟？技术人员常常会陷入一个误区，不停的追逐技术热点，在工作中也大谈技 术细节，殊不知这些东西却是阻碍开发人员思维转变的一个根源，那么技术细节你掌 握的再牛又如何，充其量就是一个程序牛人。所以开发人员要从围城里面脱离出来， 要认识到建立正确的思维方式比掌握多牛的技术要重要的多。 转变思维 --核心思想，如果你不能转变思维方式，那么你永远就是一个在技术里面打 转的程序牛人，最高成就就是系统分析员。 必须要看的书籍：建模的书籍（企业应用架构模式等） 减少看的书籍(不是不看是减少看)：各种技术书籍（C#核心技术揭秘等等） 在工作中：在做一个任务的时候，要整体考虑，不是为了完成而完成。以锻炼自己的 思维进行尽快转变。
例子 --基于实体的代码生成器的业务建模
市面上有很多提高工作效率的工具，称为代码自动生成器。这类工具能 够使用代码自动生成实体和实体所对应的数据库操作类，来代替开发人 员手工的录入，这样做的好处： 1）大大提高了开发效率 2）使得底层的代码风格趋于一致 3）底层代码不需要再进行测试 4）防止因为人员流失导致新来人员先要适应代码编写风格，然后再了 解业务的尴尬 因此本例以如何去设计一个代码生成器为开始点，阐述了如何进行业务 建模的过程，以帮助开发人员向系统架构师转型提供一定的参考意见。