软件架构是在软件需求出来之后，软件构建开始之前的工作
架构师应该确定的事情有：
1 程序组织
架构应该定义程序中的主要构造块。 根据程序规模不同，各个构造块可能是单个类，也可能是由多个类组成的系统。每个构造块实现一个高层功能。并且每个需求都至少有一个构造块覆盖它。
定义各个构造块之间的通信规则和依赖规则
2 主要的类
架构应该详细定义或写出所用的主要的类。并指出该类如何与其他类交互。
架构不需要对所有类进行说明，使用82法则：对构成系统80%功能的20%类进行说明
3 数据设计
架构应该说明清楚用到的数据表的设计，并且描述为何做出这样的选择
4 业务规则
对特定的业务规则（比如:客户信息的更新时间不能超过30秒）要有架构方面的描述（比如30秒内对客户端进行信息同步）
5 用户界面设计
架构应该有详细的用户界面，好的用户界面直接关系到功能的实现和软件的最终效果
6 资源管理
架构应该对稀缺资源有管理计划。比如数据库连接，线程，句柄等的使用。有可能需要设计一个“资源管理器”的模块
7 安全性
架构应该描述用户据输入数据，cookie，配置文件等的安全性说明
8性能
应该根据需求文档中对性能的描述来提供估计的性能数据，并且说明为什么架构师相信能达到性能目的。或者为什么有的性能指标无法达到
9 可伸缩性
架构应该说明系统如何应对以后用户数量，服务器数量，网络节点数量，数据库记录数，数据库记录长度，交易量等增长的需求。
10 互用性
如果系统与其他软件或硬件有共享资源，架构应该说明如何完成这项功能
11 国际化/本地化
系统式是否支持国际化，如何在与用户交互的模块中实现国际化
12 输入输出
架构应该详细定义读取策略
13 错误处理
有人估计程序中高达90%的代码是用来处理异常和错误的，意味只有10%的代码是用来处理常规情况的。
需要考虑的问题包括：
错误处理是进行纠正还是只进行检测
错误检测是主动还是被动
程序如何传播错误，是立刻丢弃还是通知一个地方
错误处理有什么约定
如何处理异常，什么时候能抛出异常，什么地方log，什么地方捕获
在什么地方处理错误，是传递到专门处理错误的地方还是沿着函数链往上传递错误
每个类的输入数据额有效性方面如何负责
是希望用运行环境内建的错误处理机制还是自定义一套机制
14 容错性
容错是增强系统可靠性的技术，如果出现了错误是转入“部分运转”还是“功能退化”?
15 架构的可行性
架构师应该论证自己这个系统设计的可行性
16过度工程
即健壮性。架构应该指出哪些类哪些模块需要进行过度工程（健壮性测试），哪些类或模块只需要做出最简单的工作性能
17 关于买还是造
一些软件，开源代码，处理程序，是使用现货采购还是自己定制开发
18 关于复用
如果使用业界已经存在的软件，开源代码等资源，应该说明清楚如何对这些东西进行加工。
19 变更策略
架构应该清楚描述处理变更的策略。架构应该列出已经考虑过的可能会有变更的需求或者可能增强的功能。
并提供处理情况，比如使用版本号进行控制，或者将代码设计成可动态添加新数据
20 架构的总体质量
架构应该清楚描述其做的所有主要决策的动机
明确指出有风险的地方
作者：yjf512（叶剑峰）
出处：http://www.cnblogs.com/yjf512/
本文版权归yjf512和cnBlog共有，欢迎转载，但未经作者同意必须保留此段声明
最新评论