软件架构设计指南

软件架构设计指南

一、软件架构设计

当对象、类、构件、组件等概念出现并成熟之后，传统意义上的软件概要设计（或软件系统设计），就逐渐改名为软件架构设计。所以说，软件架构设计就是软件概要设计。软件架构设计工作由架构师来完成，架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色，他的具体职责为：

领导与协调整个项目中的技术活动（分析、设计入实施等）

推动主要的技术决策，并最终表达为软件构架描述

确定和文档化系统中对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”

确定设计元素的划分以及这些主要分组之间的接口

为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效传达和贯彻

理解、评价并接收系统需求

评价和确认软件架构的实现

二、软件架构基本概念

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：架构中引入分区，支持迭代和并行

?机制的提取

●对于编程实现而言，在没有提取机制的情况下，机制是

一种隐式的重复代码；

●对于逻辑架构设计而言，机制是一种特殊的子系统，在

划分子系统的时候不要遗忘；

●在实现不同的最终功能时，可以重用一种机制，避免重

复进行“组装”工作，如审批机制，权限机制，各个

模块和子系统都可以进行调用。

?一个原理

?关注点分离的原则

●通过职责划分来分离关注点；

●利用系统各部分的通用性不同进行关注点分离；

●根据不同颗粒度级别进行关注点分离；

?示意图：

图5：关注点分离原理示意图

?四个原则

?职责不同的单元划归不同的子系统；

?通用性不同的单元划归不同的子系统；

?需要不同开发技能的划归不同的子系统；

?兼顾工作量的相对均衡，进一步切分太大的子系统；

合理的接口设计

?把模块放在协作的上下文中进行考虑，接口设计才有意义；

?需要考虑的是“为了实现一系列的功能，这个软件单元要和

其它单元如何协作？”

?协作决定接口，以此作为原则，依次在单元之间识别接口；

细化初步设计中的鲁棒图，形成鲁棒顺序图；(见案例附件)

五、软件设计经验之谈

5.1设计模式

a)工厂模式

工厂模式一般用于创建一类对象，而不用每次在使用时通过new()对象才能使用对象，而是通过工厂来完成对象的创建，这样不但提供了

统一创建对象的入口，而且对于程序的可维护和可测试性都有很大的提

高。常用的场景有：

1.工厂负责创建某一类对象的时候，或者说工厂的职责比较单一时，如果说

多个类型的对象时候，用工厂模式就不如使用抽象工厂了；

2.一般比较少的积累对象，可以通过类型的判定创建不同的对象时，也是可

以通过工厂模式来完成，例如多数据库的支持，我们在设计数据访问层时，

利用简单对象工厂，通过枚举或者配置文件的形式，来动态的创建数据访

问层实例。

3.一般来说类型单一的对象，或者类型比较少的时候，使用工厂模式来创建

对象可以解决一类问题。还可以通过一个总的工厂，来创建多个工厂，然

后多个工厂负责创建相应的实例，有点类似我们平时说的目录结构似的。

b)代理模式

Proxy代理模式是一种结构型设计模式，“增加一层间接层”是软件系统中对许多负责问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的proxy对象便是解决此类问题。常用的场景有：

1.在我们日常的工作中也常常用到代理模式，比如对于三层结构中DAL数据

访问层，它把对数据库的访问进行封装。BLL业务层的开发者只是调用DAL

中的方法来获得数据；

2.具体proxy设计模式的实现方法、实现粒度都相差很大，有些可能对单个

对象作细粒度的控制，有些可能对组件模块提供抽象代理层，在架构层次

对对象作proxy；

3.proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候

损及一些透明性是可以接受的。

c)单例模式

保证一个类只有一个实例，并提供一个访问它的全局访问点。它的应用场景比较广：

1.比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些

配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这

个单例对象获取这些配置信息；

2.可以使用它创建一个连接池，每次程序需要往数据库中写入内容时才创建

一个新连接的做法并不明智；相反，一个或一组已经在池中的连接就可以

使用Singleton模式实例化；

3.比如有互策的订票机制，我们可以采用单例模式，只实例化一次来操作订

票；

d)建造者模式

建造者模式可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象。常用的场景有：

1.需要生成的对象有复杂的内部结构。

2.需要生成的对象的属性相互依赖，建造者模式可以强迫生成顺序。

3.在对象创建过程中会使用到系统中的一些其它对象，这些对象在对象的创

建过程中不易得到。

e)观察者模式

在一对多依赖的对象关系中, 如果这个'一'对象状态发生了变化,那

么它所有依赖的'多'对象都应该被通知,然后做相应的变化,这就是观察者模式，它的常用场景有：

1.当一个对象的改变需要通知或同时需要改变其它对象的时候；

2.比如我们要建一个网上购物商城，对于用户订购的商品信息，如果该商品

的价格、促销活动等发生变换，系统将会自动发生邮件通知到用户，则就

是典型的观察者模式；

3.在现实生活中，拍卖行拍卖物品也是一个典型的观察者模式，拍卖师拍卖

时，他观察是否有牌子举起出价。每次接受一个新的出价都会改变拍卖的

当前价格，并广播通知给所有竞标人，竞标人则进行新的出价和退出。

f)装饰模式

能动态的将职责附加到对象上去，若要扩展功能，装饰者提供了比继承更具弹性的代替方案。

装饰模式提供了一个非常好的解决方案，它把每个需要装饰的功能放在单独的类中，并让这个类包装它所装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序的使用装饰功能来包装对象了。它的常用场景有：

1.需要扩展一个类的功能，或给一个类增加附加责任。

2.需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

3.需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继

承关系变得不现实

5.2常见设计问题

a)Session管理

1.Session又称会话状态,是Web系统中最常用的状态,用于维护

和当前浏览器实例相关的信息;

2.我们可以写一个SessionSate的管理类,通过静态属性直接来进

行访问；

3.同时在管理类中，我们还要考虑服务器的性能，对需要记录的属

性到底是采用Session 还是Cookies 做出合理的决策。

4.如下图所示：

public class SessionState

{

private SessionState()

{

}

///

/// 用户姓名

///

public static string UserName

{

get

{

return HttpContext.Current.Request.Cookies["UserName"].Value;

}

set

{

HttpContext.Current.Response.Cookies["UserName"].Value=value;

}

}

///

/// 用户工号

///

public static string UserWorkNo

{

get

{

return Convert.ToString(HttpContext.Current.Session["UserWorkNo"]);

}

set

{

HttpContext.Current.Session["UserWorkNo"]=value;

}

}

}

图六：SessionSate管理类

b)日志管理

1.对系统中常用的事件处理，需要进行日志记录，日志记录中必须

包括的字段有：时间、IP地址、登陆ID、模块名、操作事件

2.日志管理需要通过机制提取为通用方法类，供各个模块调用，且

所有数据记录都存放在公共的数据表内；

c)权限管理

1.权限的管理，要有基本的权限概念，要从职位/角色上进行区分，

常见的有：本人可以修改/删除自己的，不可删除他人的；小组

组长可以修改/删除本小组的，不可跨小组处理；（客户特殊说明

除外）

2.权限管理需要通过机制提取为通用方法类，供各个模块进行调研，

且所有的数据记录都应该存放在公共的数据表内；

d)审核管理

1.未审核期间，审核发起人都应该能修改和删除审核内容；

2.审核过程中，审核人员都应该能看到该内容的审核信息，包括已

经审核的和还未审核的；

3.审核管理需要通过机制提取为通用方法类，供各个模块进行调研，

且所有的数据记录都应该存放在公共的数据表内；

e)系统配置

1.对于主要用于下来列表/单选框/复选框等的实体数据，要做成

可配置型，切勿直接写死在代码中；

2.如果多个模块均有配置项的内容，可以考虑对所有配置项单独做

一个后端配置发布，与前端业务操作进行分离。