架构的典型组成部分

程序组织
1、系统架构首先要以概括的形式对有关系统做一个综述。
2、应该定义程序的主要构造块,根据程序规模不同各个构造块可能是单个类,也可能是由许多类组成的一个子系统。
3、应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情,并且对其他构造块负责的区域知道得越少越好。
4、应该明确定义每个构造块的通信规则。对于每个构造块,应该描述它能直接使用哪些构造块,能间接使用哪些构造块,不能使用哪些构造块。
主要的类
架构应该详细定义所用的主要的类,应该指出第一个类的责任,以及该类如何与其它类交互。
数据设计
架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案,并说明做出选择的理由。数据通常只应该由一个子系统或一个类直接访问。
业务规则
如果架构依赖特定的业务规则,那么它就应该详细描述这些规则,并描述这些规则对系统设计的影响。
用户界面设计
用户界面常常在需求阶段说明
资源管理
架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接,线程,句柄等。
安全性
架构应该描述实现设计层面和代码层面的安全性的方法。如建立威胁模型
性能
如果需要关注性能,就应该在需求中详细定义性能目标,如资源的使用以及速度,内存,成本之间的优先顺序。
可伸缩性
可伸缩性是指系统增长以满足未来需求的能力。
互用性
如果有与其他软件或硬件共享数据或资源,架构应该描述如何完成这一任务。
国际化/本地化
架构应该描述如何实现国际化。
输入输出
架构应该详细定义读取策略是先做、后做还是即时做,应该描述在哪一层检测I/O错误:在字段、流,或者文件的层次。
错误处理
应该定义错误处理的方式
容错性
架构还应该详细定义所期望的容错类。如果可能的话从错误中恢复,如果不能从错误中恢复,则包容不利影响。
架构可行性
是否能达到性能目标,能够在有限的资源下运转,实现环境是否有足够支持
过度工程
健壮性是指“系统在检测到错误后继续运行”的能力。
关于“买”还是“造”的决策
如果已经有符合项目的软件,尽量使用。如果架构不采用现货供应的组件,那么就 应该说明“自己定制的组件应该在哪些方面胜过现成的程序库和组件”
关于复用的决策
如果开发计划提倡使用业已存在的软件、测试用例、数据格式或其它原料,架构应该说明。
变更策略
架构应该清楚地描述处理变更的策略。列出已经考虑过的有可能会有所增强的功能,并说明“最有可能增强的功能同样也是最容易实现的”。
架构的总体质量
优秀的架构规格书的特点在于,讨论了系统中的类、讨论了每个类背后的隐藏信息,讨论了“采纳或排斥所有可能的设计替代方案”的根本理由。好的架构设计应该与待解决的问题和谐一致,在查看架构的时候,应该很愉快,因为它给出的解决方案看上去既自然又容易。架构的目标应该清楚地表述,应该描述所有主要决策的动机。谨防“我们向来这么做“这种自认为有理的说法。
架构应该踏在对系统”欠描述“和”过度描述“之间的分界线上。架构应该明确地指出有风险的区域。应该包含多个视角,最后,架构不应该包含任何对你而言很理解的东西,因为你就是那个实现架构的人,如果你自己都弄不懂,那怎么实现它?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值