标签：
热爱编程才能做优秀的软件设计师！
软件设计有一些方法可以参考。但更重要的是要有好的需求分析、丰富的技术知识和设计经验（多动手！）不断追求更好的精神（多动脑！）。
遇到别人的系统想一下自己能否实现，如何实现？
一、优秀设计的标准：性价比高的设计。
1）优秀的设计都是需求驱动的，不熟悉需求就做出来的设计是不靠谱的；
2）优秀的设计应该是当前团队能理解能实现的，太超前的设计项目团队做不出来，这个设计只能是摆设；
3）优秀的设计应充分考虑当前各种限制条件，适当做出平衡，能保证达成项目的目标；
4）优秀的设计能尽量降低项目的整体工作量，让真个项目更加可控。
二、优秀的设计从需求开始
案例挑战：考勤系统的软件设计：
某公司要做一个内部的考勤系统，希望达成以下目标：
1）规范员工的上下班、请假、外出工作等行为。
2）方便计算员工的薪金。
3）方便管理各种带薪假期。
该如何设计本系统呢？
先做需求分析，确保需求分析没有问题。
分析需求，先从业务角度分析，再从软件设计的角度分析（5步走）：
1）谁会用本系统？（列出所有可能的用户）
2）不同的人分别用哪些功能？（用例图）
3）还有哪些不确定或不具体的需求点？（用户场景）
4）哪些需求对技术提出了怎样的需求？（具体问题的解决方案）
5）系统的大致架构该如何考虑？（部署图、组件图、包图）
需求分析不但要做到第1）2）步还要深入分析业务（业务流程、业务数据...）
三、软件系统不是木桶型的（软件设计一般都是要整体考虑的）
用户场景之间是有关系的，如基础数据。不同的用户场景可能用到的基础数据是相同的，不能把系统做成木桶型的（每多一个用户场景就添加一份表现层、逻辑层、数据库表)，这样会很恶心。
软件常见内部架构：
此图说明：
1）各个用户场景之间是有关联的，不是独立的。软件设计应该多从业务概念、业务流程的角度考虑；
2）各个用户场景的界面之间可能有重用和共享的部分（共用基础信息）；
3）业务逻辑中的一些类本来就是一个整体。
四、软件设计的“大道理”
1、软件设计思路：
1）由顶而下：先假设软件已经做出来了，想好软件的外在表现，由此倒推软件的实现方法；
2）由底而上：思考程序的数据结构，先设计数据库，然后再搭建软件的上层建筑；
3）有中间至上下。
N层架构：以4层为例
UML包图，包与包之间的虚箭头表示依赖关系。
上图意思如下：
1）四层架构包括：表现层、逻辑层、数据访问层、数据层；
2）表现层依赖逻辑层，逻辑层依赖数据访问层，数据访问层依赖数据层。
依赖可以使一下情况之一：
1）A需要调用B的方法，A依赖于B；
2）A的方法中某些参数的类型是B，A依赖于B；
3）A的某些方法的返回值类型是B，A依赖于B。
各层之间是怎么传递数据的（传参数？）No！将数据保存到实体类中，各层均依赖实体类！：
。
实体类：通常是只有属性没有方法的类，通常我们将一些业务对象的数据放在一个实体类中。如：请假条的实体类（请假人姓名、请假起止日期、请假类别、请假事由等）。
2、由顶而下：先想清楚表现层，再思考逻辑层、数据访问层、数据层实现。
“需求驱动设计”哪部分需求驱动了什么设计？看图：
。
本图表达的意思：1）软件设计首先要有正确的需求分析，需要将需求分解为 用例、业务流程图、业务概念图。
2）设计不同的层时主要依赖的需求不一样。
3、由底而上：
。
4、有中间到上下：（使用情况：表现层不动，数据层变动。如：将SQLServer换为Oracle）
定义实体类和数据层接口，在数据库操作层实现接口功能。接口对于逻辑层是一样的。
从中间到上下的软件架构如图：
。
这样做也不是没有缺点的,这样会不能使用数据库的特性，如禁止在数据库中邪存储过程、触发器、视图等。增加了程序的复杂度和工作量。
五、规划系统的骨架——架构设计
1、软件设计至少需要4方面的设计：架构设计、数据库设计、模块设计、用户体验设计。
架构设计：通盘考虑需求后，从宏观上规划系统的各部分及各个部分的关系；
数据库设计：对需求中的业务概念进行系统分析后，设计出表和表关系、视图等数据库元素；
模块设计：架构设计将系统划分成多个模块，模块设计驾驶针对某些或某个模块的具体设计；
用户体验设计：需要考虑软件的整体假面规划、界面先后关系、文字表达、软件与用户如何交互等。由顶而下设计。
2、不要“放之四海而皆准”的架构设计
想一下架构设计的作用，下边的软件架构设计有相当于没有，就是废话:
没有体现出需求，没有体现出该系统的特殊性！
下边的系统架构犯了同样的毛病：
。
3、架构设计 是考虑“全部需求”后做出来的。
1）、先通过用例图列出全部需求：
，分析图中需要重点关注的地方。
。
从关注点中发现问题，提出解决方案。
4、逐步拆解架构设计
不以解决需求为目的的软件设计就是耍流氓！
想说明一下工作流：
1）、死的工作流：代码是死的，数据库设计也是死的，流程或表单由任何变化，都可能需要改代码和数据库设计。
2）、半死不活的工作流：部分地方写死，部分地方是灵活的，能适应部分需求变化。
3）、全活的工作流：代码和数据库设计等都是灵活的，能基本适应流程及表单的变化，不需要修改代码或数据库设计，只要配置一下就可以搞定。
开发设计最好由易到难。
初步架构设计——第一层拆解
针对一个具体的项目做架构设计时，不能脱离具体的技术框架，要先确定你的开发语言、数据库种类等。架构设计要从物理设计的深度来思考，而不能仅仅是理论设计或逻辑上的设计，否则又会犯太空洞的毛病（“放之四海而皆准”的毛病）。
。
小结初步架构设计的要点：
1）、系统涉及到客户端和服务器，我们要考虑系统需要客户端和服务器做哪些事？这需要客户端和服务器具备哪些配置属性：系统属性、软件属性、硬件属性等。
2）、客户端和服务器见得物理联系方式：局域网？互联网？还是？
3）、客户端和服务器上需要我们开发什么软件？相当于第一条的软件属性。第一条更侧重于硬件及其性能。
图中需要我们开发的东西有：WebApplication、工作流定义用的客户端软件、三个数据库。
第一次架构设计就是划分系统分了几部分及各部分的关系。
继续深入拆解——第二层拆解（进入第一次划分出的每一部分再次划分）
以Web Application为例，深入设计。
分析Web Application的内部架构分几部分及他们之间的关系时，也要考虑有哪些食欲外部交互的。
这张图凸显的是Web Application模块内部的模块与外部模块的的连接关系，没有与外部模块连接的模块被隐藏了。
细分到这一步，开始发现需要解决的问题：
，一一列出每一个问题的可行的解决方案，及方案需要考虑的具体问题。
架构设计拆解小结：
1）、第一层拆解：解决“整个系统分为几块，需要开发什么软件和数据库”的问题。
2）、第二层拆解：深入到系统的一个模块，再次划分能分成几个子模块，考虑他们之间的关系，哪些子模块是和外部模块有联系的。可以参考分层架构。
3）、“第二层拆解”的结果有可能是组件、代码包、某个分层等等，可能是“物理拆分”，也可能是“逻辑拆分”。
拆分到什么程度才算合适呢？：如果在拆解下去，下一步的拆解就到类了，那么就可以认为目前的拆解粒度比较合适了。细化到类的拆解，可以在模块设计中再进一步考虑。
“物理拆分”和“逻辑拆分”：
物理拆分：解释物理上独立的部分，有可能是EXE、dll、数据库文件等。该系统可以物理拆分成5部分：Web Application、流程定义用的客户端软件、3个数据库。在对Web Application进一步进行拆分时,日历控件是物理拆分，这个控件将通过二进制的方式供程序他部分调用，二这个控件将来也可以供其他系统使用。
逻辑拆分：代码包、某个分层这些往往是逻辑拆分，物理上他们不会编译成单独的一部分，而是被整体变异近软件当中。
“第二层拆解”的目的除了更加方便我们设计出系统，另外一个重要目的是做系统的重用设计。物理拆分——二进制重用；逻辑拆分——源代码重用。这些重用会为以后其他软件开发提供便利。
5、分布式系统与单机系统的架构设计
分布式系统往往需要我们在多台设备上部署，个部分需要联调后，整个系统才能正常工作。
本文前边的系统架构就是分布式架构。
标签：
原文地址：http://www.cnblogs.com/760044827qq/p/4564640.html
