软 件 架 构 设 计 指 南
一、 软件架构设计
当对象、类、构件、组件等概念出现并成熟之后，传统意义上的软件概要设计（或软件系统设计），就逐渐改名为软件架构设计。所以说，软件架构设计就是软件概要设计。软件架构设计工作由架构师来完成，架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角，他的具体职责为：
    领导与协调整个项目中的技术活动（分析、设计入实施等）
    推动主要的技术决策，并最终表达为软件构架描述
    确定和文档化系统中对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”
    确定设计元素的划分以及这些主要分组之间的接口
    为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定
被有效传达和贯彻
    理解、评价并接收系统需求
    评价和确认软件架构的实现
二、 软件架构基本概念
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) 考察用户界面的整体复杂度
要求：识别重点模块的主要信息输入，和输入途径
方法：通过重点模块画制的鲁棒图进行分析；
技巧手机app设计模板
用户界面的复杂度可概括为以下几种：
✓ 简单数据输入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)

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。