软件架构设计指南一、软件架构设计当对象、类、构件、组件等概念出现并成熟之后，传统意义上的软件概要设计（或软件系统设计），就逐渐改名为软件架构设计。
所以说，软件架构设计就是软件概要设计。
软件架构设计工作由架构师来完成，架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色，他的具体职责为：领导与协调整个项目中的技术活动（分析、设计入实施等）推动主要的技术决策，并最终表达为软件构架描述确定和文档化系统中对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”确定设计元素的划分以及这些主要分组之间的接口为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现二、软件架构基本概念5.1软件架构定义系统是部件的集合，完成一个特定的功能或完成一个功能集合。
架构是系统的基本组织形式，描述系统中部件间及部件与环境音质相互关系。
架构是指导系统设计和深化的原则。
系统架构是实体、实体属性以及实体关系的集合。
软件架构是软件部件、部件属性以及客观存在们之间相互作用的集合，描述软件系统的基本属性和限制条件。
5.2软件架构建模软件架构建模是与软件架构的定义和管理相关的分析、设计、文档化、评审及其他活动。
软件架构建模的目的：a)捕获早期的设计决策。
软件架构是最早的设计决策，它将影响到后续设计、开发和部署，对后期维护和演变也有很大的影响。
b)捕获软件运行时的环境。
c)为底层实现提供限制条件。
d)为开发团队的结构组成提供依据。
e)设计系统满足可靠性、可维护性以及性能等方面的要求。
f)方便开发团队之间的交流。
5.3软件架构视图软件架构视图是指从一个特定的视角对系统或系统的一部分进行的描述。
架构可以用不同的架构视图进行描述，如逻辑视图用于描述系统功能，进程视图用于描述系统并发，物理视图用于描述系统部署。
常见的有RUP 的4+1视图；5.4软件架构设计需包括：a)软件系统中包含了哪些子系统和部件；b)每个子系统和部件都完成哪些功能；c)子系统和部件对外提供或使用外部的哪些；d)子系统和部件间的依赖关系，以及对实现和测试的影响；e)系统是如何部署的。
三、软件架构设计步骤3.1确定影响整体技术方案的因素a)考察用户界面的整体复杂度要求：识别重点模块的主要信息输入，和输入途径方法：通过重点模块画制的鲁棒图进行分析；技巧用户界面的复杂度可概括为以下几种：✓简单数据输入simple data input(例如登入界面)✓数据的表态静态视图static view(例如商品报价列表)✓可定制视图customizable view（例如可自定义查询报告界面）✓数据的动态视图dynamic view(例如实时运行监控视窗)✓交互式图形（例如CAD系统）b)考察用户界面部署的约束要求：识别系统的部署环境和客户端的使用环境；方法：主要通过访谈和观察，识别客户端环境；技巧用户界面的部署约束可概括为以下几种：✓经常要离线工作的移动电脑✓手持智能终端(如智能手机、MID、PAD)✓支持Interner网上的任何一种浏览器（老版本浏览器）✓支持Internet网上的较新版本浏览器✓支持内部网上的较新版本浏览器✓支持内部网上的特定浏览器✓内部网上的专用工作站（传统C/S架构的客户端软件）c)考察用户的数量和类型要求：需大致识别出本系统用户的数量级别和类型；方法：主要通过了解客户背景信息，识别根据不同角色所对应的人数和类型；技巧用户的数量和类型可概括为以下几种：✓少数的专业用户：关注功能强大，期望量身定制，乐于学习新特性，例如图形制作系统的用户；✓组织内的日常使用者：主流用户，关注便捷和易用，例如考勤系统用户；✓大量的爱好者：对系统的功能有执着的兴趣，有意愿克服使用时遇到的的各种困难，包括软件本身的缺陷，例如游戏软件的用户✓数量巨大的消费型用户：关注速度和服务感受，例如商业网站的用户d)考察系统接口类型要求：正确合理的识别系统中存在的接口和类型，本处重点的是识别外部存在的接口。
方法：协作决定接口，见第四章；技巧系统接口类型可概括为以下几种：✓数据传输：仅仅为了满足系统间交换数据的需要，例如电子数据交换EDI接口、数据库同步等✓通过协议提供服务：系统依照协议向外提供特定的服务，例如http 协议、SOAP(Web Service)协议等✓直接访问系统服务：按照类似于系统内部调用的方式，直接使用系统的方法，例如基于RPC远程调用等e)考察数据性能和可伸缩性要求：正确识别是否存在大量的并发数据处理;方法:技巧性能和可伸缩性方面可概括为以下几种：✓只读：只有对数据浏览和查询操作，例如股票行情分析系统✓独立的数据更新：对数据的修改操作，但各用户的修改完全隔离，相互间不存在任何潜在的冲突，例如网上商店各顾客对自己帐单的管理✓并发的数据更新：并发用户对数据的修改将相互影响，或者就是更改了同一数据，例如多个用户同时使用航班预定系统预定同一航班的座位3.2选择软件构架样式（风格）要求: 根据前期细致的需求分析，选择合理适用的软件架构样式；方法：最常用的是使用三层或四层架构；技巧软件架构样式的常见种类有：✓数据流构架：是实现可重用性和可更改性，它的特点是把系统看作是对相继输入数据的一系列变换；✓调用与返回构架：一直是中大型软件系统的主流构架样式，它的目标是实现系统的可更更改性和可扩展性。
✓独立组件构架：由许多通过发送消息进行通讯的独立进程或对象组成，它的目标是通过解除各运算部分之间的耦合实现可更改性，如股票机、各类短信预定等。
目前我们常用的是调用和返回构架中的分层构架模式，是一种将系统行为或功能通过以层为首要的组织单位来进行分配(划分)的结构模式。
✓展现层(UI):✧展现给用户的界面，即用户在使用一个系统的时候他的所见所得；✓业务逻辑层(BLL)：✧根据系统的大小，又可以拆分为：业务接口层、业务实现层、业务实体层✧它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计；✓数据访问层(DAL)✧有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档；✧实现对数据表的Select，Insert，Update，Delete的操作；如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
3.3利用可复用的资产要求：在需求及设计阶段，正确识别现有可被复用的资产方法：✓可复用的资产包括：✧工具、组件、Web Services、框架、模版、设计等；✓项目经理对项目设计中可能用到的资产情况进行评估，并向技术经理提出申请，将资源引入到本设计中；✓技术经理对项目中可能会用到的资产情况进行检查确认；3.4子系统的划分和接口的定义目的✓支持个人或团队进行独立的开发✓层次、包的划分，为团队的分工协作提供最直接的依据✓子系统的划分，使得团队成员之间的依赖关系最小化，从而支持并行开发（方便集成）✓为方便测试而进行划分，包、子系统及其接口的定义，应当支持被独立地加以测试要求和方法：见第四章内容3.5优化设计，包括去冗余和提高重用性方法✓通过划分而去冗余✧将系统划分为职责更为集中和明确的模块（例如，对象、子系统、子程序等），相同的行为将通过调用一模块来实现，从而避免重复的组成元素分散于系统各处；✧识别对象，并将职责分配给合适的对象，其它对象将委托它来完成对应的行为✧让对象通过组合来复用已有对象的服务✓通过泛化而去冗余✧将共性的行为抽取出来，专门在一处单独定义；所有类似行为的实现，将关注于那些个性方面，共性方面直接从前述之处继承，而不再重复实现✧面向对象范型下，父类实现共性的行为，并定义一些可重载的方法，在父方法中调用，然后让子类重载它们以便扩展个性行为（参考模板方法模式）✧泛化的去冗余途径，主要是避免重复实现一些较大粒度框架性的行为，小粒度的行为复用应当使用前述的划分途径✓通过模块化而去冗余✧使用模板来定义共性的结构和行为，并留出某些变量，这些变量对模板而言是行为敏感的；在具体的应用场景，通过引入不同的参数变量，从而导出众多个性化的行为组合✧面向对象范型下，主要有模板类、模板函数等方式✧模板化去冗余途径，形式主义是一种结构（引入变量）与（模板）行为的二元组合，其实质是避免行为的重复定义✓通过面向方面编程而去冗余✧将分散在系统代码之间的，行使类似职能的代码抽取出来，作为一个方面样子，集中到一块来处理（这些职能包括：日志记录、权限验证、资源的释放、异常处理等），避免类似代码的到处重复泛滥四、软件设计方法体系(ADMEMS方法，三个阶段，一个贯穿)4.1 需求进一步分析阶段：全面了解客户需求第1步，需求结构化✓从“不同层次的涉众提出需求所站的立场不同”的角度，把需求划分为三种类型，这就是需求的三个层次：✧业务需求：组织要达到的什么目标；✧用户需求：用户使用系统来做些什么事情；✧行为需求：开发人员需要实现什么；✓从“需求定义直接目标还是间接限制”的角度，把需求划分为三种类型，这就是需求的三个方面：✧功能需求：更多的体现各级直接的目标要求；✧质量需求：开发期的质量+运行期的质量；✧约束需求：业务环境因素+使用环境因素+构建环境因素+技术环境因素✓常用需求层次-需求方面二维矩阵图进行表示：图4.1 需求层次－需求方面二维矩阵第2步，分析约束影响✓来自客户组织的约束性要求✧必须充分考虑到客户上线时间的要求、预算的限制、以及集成需要等非功能需求；✧客户所处的业务领域为何？有什么业务规则和业务限制？✧是否需要关注相应的法律法规、专利限制？✓来自用户的约束性要求✧软件将提供给合阶层用户？✧主要用户的年龄段？使用偏好？✧使用的环境是否有影响系统的？✓来自开发者和维护人员的约束性要求✧开发团队的技术水平能力、磨合程度、是否分布在不同城市，有何影响?✧开发管理方面、源代码管理和保密方面、是否要顾及？✓来自业界本身技术环境的约束性要求✧技术平台、中间件、编程语言等的流行度、成熟度、认同度、优缺点等的考虑；✧所使用的技术发展的趋势如何，是否需要考虑？4.2 塑造概念架构阶段：通过关键功能，进行初步设计第1步，初步设计✓在第一阶段确定关键的功能子集✧对于关键的功能子集，需要在需求列表上进行标注；✓通过鲁棒图和职责协作链的原理，识别角色和他所对应的职责；✧从事件流开始，对关键功能画出用例图和用例描述；✧开始寻找边界对象，描述模外部环境和系统之间的交互进行建模，通常指的就是交互，如UI；✧寻找控制对象，对行为进行封装，描述用例中事件流的控制行为，也就是业务办法，负责控制；✧寻找实体对象，对需要存储的信息进行描述，通常指的就是我们的对象类，负责信息；第2步，高层分割✓对于功能不是太复杂的，可以直接将黑盒系统切分为子系统的；✓对于功能较为复杂的，需进行高级高层分割✧首先将黑盒系统切分为更小一级的系统，每个更小一级的系统都可以有单独的需求、设计、实现……✧之后，针对每个“更小一级的系统”进行“切系统为子系统”第3步，考虑非功能需求✓以场景技术为跳板的非功能设计思维✧发现场景●功能性的考虑，是否准确，是否安全等；●可靠性的考虑，安全性，容错性，稳定性；●易用性，用户体验方面；●效率的问题，页面载入时间，资源特性等；●维护性的考虑，安装便捷，功能修改方便；✧通过目标－场景－决策表，进行评估场景，并做出决策✧实例：图2：场景思维是方法核心图3：实例《项目管理系统》非功能性，目标－场景－决策表4.3 细化概念架构阶段合理的划分子系统✓三个策略✧分层的细化●如将系统分为展现层、业务层、数据访问层；●又可在三层架构中加入控制层，形成展现层、控制层、业务层、数据访问层，将三层架构转换为四层架构；●可以继续细化，将业务层细化为业务接口层、业务实现层、业务实体层；●通过不断的细化，来降低系统的复杂度，提高开发人员的并行开发能力；✧分区的引入●先做一个高级的广度设计，然后马上转到深度优先的底层设计和实现上去；●分层+分区，如图4所示，是支持迭代和并行开发的基础；图4：架构中引入分区，支持迭代和并行✧机制的提取●对于编程实现而言，在没有提取机制的情况下，机制是一种隐式的重复代码；●对于逻辑架构设计而言，机制是一种特殊的子系统，在划分子系统的时候不要遗忘；●在实现不同的最终功能时，可以重用一种机制，避免重复进行“组装”工作，如审批机制，权限机制，各个模块和子系统都可以进行调用。