文章写到这里，我一直在犹豫是继续写针对中小型框架的设计还是写些框架设计上的进阶方面的内容？对于中小型系统来说，只要将前面的内容进行一下细化，写上二三十章具体开发上的细节，来说明这个通用框架怎么开发的就已完全足够了，因为对于中小型系统来说，并不是很复杂，简单的了解三层架构就已经够用了，而使用太多的设计反而有点罗嗦，因为基本上没有什么人会为中小型系统花费太多的设计工作。而对于设计大型平台的框架设计，又深深感到自己的积累还远远不够，写出来怕会误导大家。但不换个思维来讲述也很难说清框架的设计思想，别人拿到一个框架源码后，也很难让人能清晰的理解这个框架到底是什么东东，怎么去改造它。所以只能抱着和大家共同学习的心态，来抛砖引玉，希望能更好的总结一下自己的学习成果，当然有些观点并不一定是正确的，也希望大家能直接拍砖指出来。
前言
很多朋友看到标题可能会很奇怪，为什么弄一个开发框架首先要做的是建模？建模就能做一个框架出来吗？直接的人可能会说，这个2B，设计一个开发框架讲解的核心应该是三层、五层架构，每个层应该有什么用处，他们之间该如何解耦如何协作调用......
如果以前有人告诉我设计一个框架这样做的话，我也会觉得弄一个开发框架搞得这么复杂做什么，直接弄几个层和工具类出来，然后写一些常见功能不就行了。
实际上写本系列以来，理论部分一直在琢磨怎么才能用更通俗易懂的方式讲解出来，像前面章节一样直接从三层架构去讲，只能很简单的说明他们之间的关系，但为什么设计出来的是这样的框架而不是那样的？前面章节所做出来的框架能直接用在网站后端管理上，但如果作为电商平台、OA、CRM、供应链......等软件框架时行不行？会不会存在问题？要如何去改善？如果开发的框架用于电商平台，当访问流量增大，想要增加服务器做分布式、负载均衡进行数据分流时，是在现有框架上改造令它支持还是设计一个新的架构呢？要如何改造或如何设计？设计好的架构支持什么样的业务？如何让需求提供者（未技术人员）能更早的参与到架构设计进来？如何尽早发现系统框架的瓶颈？怎么从设计层就能解决众多的问题？如何让新入职人员快速理解并掌握整个框架知识，快速加入开发的队列中？如果避免核心技术只把握在某一个或几个人员手中，当这些人中有人离职后其他人员无法快速接手的问题？设计的系统能否根据业务拆分为一个个独立的模块，让测试人员提前加入到项目中，提升项目的质量？拆分的模块如何统一起来？......越想问题就越多，怎么去描述都讲不到点上。
经过知识的不断积累，慢慢意识到一直以来使用的都是面向过程的方法来分析需求，在做项目或设计架构时，都是为了功能而设计，为了设计而设计，并不知道其所以然。如果想做出的框架对于项目来说能做到适用，刚好合适，那就需要真正的去分析需求，根据用户实际的需求以及发展方向来设计架构，它是面向对象的，使用用例或领域来驱动设计，为特定需求而定制设计出来的系统，而不是做出来的架构功能过多或未达到设计要求，或者用上一段时间后整个架构甚至数据表都得推倒重来。
当然上面所说的都是理想状态下设计出来的系统，而实际工作中大家开发中的架构或平台，面对每一次大版本的更新都是欲仙欲死的，呵呵......很多时候都得大动手术，进行大改造。
UML、架构与框架的关系
度娘上说：
Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
对于框架来说，就是已做好的钢筋混凝土结构建筑物，里面可以建各个功能的停车场、商场、酒店、饭店、商住房......
架构对于框架来说，它就是绘出好的建筑图纸，它描述建筑物的外部形状、内部布置、结构构造、内外装修、材料做法以及设备、施工等各种图样。而UML就是在这些图纸上所绘制的各种形状的图形（符号）。
有很多朋友会说，我不用UML、不懂架构一样开发出一套套不同功能的框架，干码要学这么多，能做出来不就行了呗。的确是这样的，对于功能简单、中小型的项目，或自己已做过很多类似框架的架构来说，直接编码是一个不错的选择。而对于一个大型的，或复杂程度很高的，或高风险的，或你完全不熟悉的领域的项目来说，开发前先做好相关的设计工作，能帮助你降低项目失败的风险。
框架不是万能的，不是什么系统都适用，就算是通用的管理权限框架，也有它的局限性。就比如本系列前面章节所开源的框架代码，权限管理模块相对来说比较强大，但也存在着各种弊端。比如说将它用于一个简单的企业Web站，它属于过渡设计了，多了很多不必要的功能，让开发变得复杂；而对于一个企业管理软件来说，它的权限粒度还不够细，比如需要实现对于不同角色的人需要展示不同的内容列表就没有实现到；底层应用的ORM框架也限制了只能使用MsSql数据库；UI层执行效率慢......所以我们在设计时，要有针对具体的需求来设计不同的架构，合适才是最好的，而不是无论何时都追求最强大的。
架构好比一个软件的骨架，不同的设计适合不一样的领域，就好像小鸟的骨架适合飞翔，豹子的骨架适合奔跑一样，如果设计好的架构要强硬的去改变它适合其他领域，不是不可以，这会增加很大的难度，就好像想让小鸟变得像豹子一个可以奔跑，又可以飞翔一样。
在实际的开发过程中，很多项目不是你一个人就能单独完成的，在团队协作开发中，如何能让大家都明白你的意图，能配合你将项目开发出来，就需要借助相关的工具（UML或其他建模语言），简单的绘制出业务用例、各种视图和模型，来帮助大家理解与配合。
对于大中小型不同的项目来说，花费在架构设计上的时间都是不同的，据巴利·玻姆（Barry W. Boehm——软件工程估算模型COCOMO模型之父、软件过程螺旋式模型之父）所计算，对于小项目只需投入5%左右的时间；大中型项目需要点总时间的33%~37%的时间；而超大型项目，则需投入40%的时间。
建模应用在实际开发中所带来的好处
1、让非技术人员提前理解所开发出来的系统能处理的业务内容
对于非技术人员来说，他们看不懂各种代码，而业务用例则可以让他们提前理解将要实现的功能是什么，是不是他们想要的内容。
2、让测试人员能提前参与到项目中
当模型创建完成并讨论通过后，相关的测试人员就可以开始编写测试用例，以及相关的自动化测试接口，让开发人员提交了解测试的内容与思路，可以提前参与到测试当中，并为测试提供更多的意见与角度，提升程序的质量，另外当程序完成开发后，也能马上运行自动化测试代码，加快测试进度。
3、让开发人员对所要开发的项目有更深入的了解
对于大多项目来说，除了架构的设计者这外，其他开发人员对于软件框架了解只是一知半解，只熟悉自己那一块的工作，对其他模块了解并不太深。这就造成很多沟通上的障碍，就算让他负责更多的功能模块开发，也只是让他了解太更多一点而已，当软件架构的功能限制对业务扩展的支持，需要改造软件架构时，几乎没几个开发人员敢去随便修改底层框架代码，这主要原因就是对自己架构并不了解，怕改动后影响其他模块的正常运行。而有成熟的架构文档，这将帮助开发人员了解软件框架的运行机制，各模块、组件之前的关系，让他们有能力有条件有信心去对软件框架进行改造。
还有其他很多好处这里就不一一诉说了。
版权声明：
本文由AllEmpty原创并发布于博客园，欢迎转载，未经本人同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。如有问题，可以通过[email protected] 联系我，非常感谢。
发表本编内容，主要是为了和大家共同学习共同进步，有兴趣的朋友可以加加Q群：327360708 ，大家一起探讨。
在佛山工作的朋友也可以加入：佛山IT朋友群 263767221，大家可以共享资源共同进步，有空大家可以约出来认识一下，交流一下技术，哈哈
更多内容，敬请观注博客：http://www.cnblogs.com/EmptyFS/