记得刚接触Java的时候，项目经理告诉我他的理想是成为架构师，架构师就是做系统架构的师傅。接着我问他架构是什么？他告诉我，就是对系统分层，解决层与层之间的通讯，划分每个层的职责。由此我接触到了MVC和J2EE的四层结构，后来又了解了MS的DNS三层结构。直到现在，我以为系统架构的核心就是层。
我理解的开发过程是，需求捕获阶段，需求分析阶段，框架设计阶段，详细设计阶段，实现阶段，测试阶段，部署阶段和维护阶段。
在需求获取阶段，搜集客户对系统的目标，识别使用者（系统边界）。用客户观点捕获需求，理解业务流程，将完成某个目标的活动划分成大的事件（Use Case）。撰写需求文档并记录下非功能需求。需要的话，写些（界面）原型供客户验证。
对大的事件分类（package），如销售的事情都放在销售管理folder中；对事件做排序，分轻重缓急。
在需求分析阶段，将需求文档中的名词和动词找出来。对关键类进行识别，即将属于复杂概念的名词找出来；识别属性，将简单概念找出来；依照BCE模式将动词划分给类。
在设计阶段有两个工作要做，一个是框架设计，一个是功能设计。框架要么选现成的要么自己定义，基本上不外乎MVC，DAO再加上IOC/AOP。
而功能设计就是界面设计、细化关键类的过程和数据库设计。界面设计会用到需求文档中非功能需求那部分，而在需求阶段与客户达成界面风格的一致是关键。细化关键类就是将类影射到不同的层上，不同的框架就会有不同的影射方式。
设计阶段结束我们会得到几份文档，类图，时序图/活动图/流程图，界面设计，数据库设计。接下来也可以选择两条腿走路，开发去Coding，测试去写Testing Case。
那么系统架构是设计阶段的框架设计这一部分。
当看《Code Complete》时发现作者定义的系统架构涵盖了很多内容，而有些点是以往忽略的。文章说软件的架构也称系统架构（System architecture），高层设计（High-level design）或顶层设计（Top-level design）。“也有人说系统架构是适用于整个系统范围的设计约束，而高层设计指的是适用于子系统层次或多个类层次上的（非整个系统范围）”，有点像我所理解的功能设计的概要。（以下双引号中为从原文摘抄）
按前者的说法，系统架构有不少的内容：
1．
程序组织/Program Organization
需要对系统做概括的描述。应该定义程序的主要构造块，子系统、模块或类视系统大小而定。
“每个需求中定义的feature都有至少一个构造块对应”。如果是按概念模型推导过来的，应该不会存在漏feature的情况；而按功能列表的方式，需要检查。
“应该明确定义各个构造块的责任”，也就是划分依据。
“应该明确定义每个构造块的通信规则”，需要好好考虑，很大一部分的扩展就源自这里的规划，需要定义什么时候怎么样访问，可以采用如ESB，OSGI，AOP等。
需要描述曾经考虑过的替代方案，未采用理由。
2．
主要的类/Major Class
思路是一致的，瞄准80/20法则，也就是UML中强调的关键类和方法。
J，这里作者引的UML方法。
3．
数据设计/Data Design
主要文件和数据库表的设计，还有需要描述曾经考虑过什么方案，没有选择的理由。
4．
业务规则/Business Rules
“如果架构依赖于特定的业务规则，那么它应该描述这些规则。”
5．
用户界面设计/User Interface Design
“用户界面常常在需求阶段详细说明”？对这点我持质疑态度。系统架构阶段应该可以确定的是界面风格、或者界面原型。
“架构应该模块化，以便在替换为新用户界面时不影响业务规则和程序的输出部分”。用老L式的反问，这样是不是过度设计？此类问题有时很难回答。但毫无疑问，这样的结构带来的好处是毋庸置疑的。
6．
资源管理/Resource Management
“架构应该描述一份管理缺稀资源的计划。缺稀资源包括数据库连接，现程、句柄等。”
“架构应该估算在正常或极端情况下的资源使用量。在简单情况下，估算数据应该说明预期的实现环境/运行环境有能力提供所需的资源；在更复杂的情况下，也许需要程序更主动地管理资源。”
这个部分我们还需要改进。比如对Session的管理，还没有统一的要求；在我们的项目中似乎还没有看到有关连接池或缓存的设计考虑。
7．
安全性/Security
“应该描述实现设计层面和代码层面的安全性的方法。如果此前尚未建立威胁模型（threat model），那么在架构阶段应该建立。”一般会考虑Web安全，用户权限，SQL注入，配置文件，还有什么呢？
8．
性能/Performance
对应于需求文档中定义的非功能需求部分定义的性能目标。“性能目标包括资源的使用，也应该详细描述资源之间的优先顺序。”资源：速度，内存，成本。
“架构应该提供估计的数据，用以说明为何架构师相信能达到性能目标。为了满足性能目标，需要在部分使用特定的算法或数据类型，架构应明确描述。”
9．
可伸缩性/Scalability
“可伸缩性是指系统增长以满足未来的能力。架构应该明确描述系统如何对用户数量、服务器数量、网络节点数量、数据库记录数、数据库记录的长度、交易量的增长。如果预计系统不会增长，应该明确列出这一假设。”
10．
互用性/ Interoperability
描述与其它软件或硬件共享数据或资源。
11．
国际化、本地化/ Internationalization, Localization
描述处理字符串（提示、状态显示、帮助信息、错误信息）和字符集的处理，架构应该明确选用哪种方案（hardcode，资源文件，类封装）及原因
12．
输入、输出/Input、Output
“架构应该详细定义读取策略（reading schema）是先做（look-ahead）、后做（look-behind）还是即时做（just-in-time）而且应该描述在那一层检测I/O错误：在字段、记录、流或者文件的层次。”
13．
错误处理/Error processing
架构中应该描述一致的错误处理方式。
需要考虑的问题：
a.
是需要纠正，还是仅仅需要检测？发生错误后尝试恢复，还是继续运行或退出？
b.
是主动的还是被动的？主动检查输入有效性，还是截获数值溢出异常？
c.
程序如何传播错误？发现错误后，丢弃，还是等待用户处理，抑或在程序处理完毕后留给客户处理。
d.
错误消息的处理有什么约定？用户界面部分格式的统一。
e.
如何处理异常？什么地方抛，什么地方截，什么地方log。
f.
每个类在验证其数据输入的有效性方面需要负什么责任？是每个类负责，还是由专门的类负责；是否某层上的类可以认为接受的都是干净的数据。
g.
用运行环境自带的，还是自定义错误处理机制。
14．容错性/Fault Tolerance
应该定义所期望的容错种类。与错误处理的问题a有些类似，就是遇到问题后系统如何对待错误。
15．
架构的可行性/ Architecture Feasibility
应该论证系统的技术可行性。
16．
过度工程/Over-engineering
即健壮性，与错误处理有关。
17．
关于“买”还是“造”的决策/Buy-vs.-Build Decisions
“如果架构不采用现货供应的组件，那就说明自己定制的组件应该在哪些方面胜过现成的程序库和组件”。
18．关于复用的决策/Reuse Decisions
复用不仅仅在程序层面，在测试用例、文档等方面也可以复用。
19．
变更策略/Change Strategy
架构应该列出已经考虑的有可能增强的功能。
20．架构的总体质量/General Architectural Quality
“优秀的架构规格书的特点在于，讨论了系统中的类、讨论了每个类背后的隐藏信息、讨论了‘采纳或排斥所有可能的设计替代方案’的根本理由”。这点我比较赞同，不理解业务的人是做不好贴近业务的架构。
架构应该定义目标，比如以拓展性为目标和性能为目标的架构肯定是不相同的。应该定义主要决策的动机，比如我们在Mxxxx项目中用到的决策表应该记录在架构中。
优秀的架构很大程度上是和编程语言和机器无关的。
架构应该在系统“欠描述/underspecifying”和“过度描述/overspecifying”之间。这个尺度有时很难衡量，只有凭借架构师的经验把握了。
看到这里，我想架构的核心是层。而当设计团队选择了适合的层次框架后，还有更多的内容需要考虑。
按照我对开发的理解，架构会涉及需求分析部分和框架设计两个部分。而按照日方的要件定义、概要设计、详细设计、实现、测试、部署和维护来说，架构设计应该对应的是概要设计阶段。
PS，补充一份架构检查表
架构的检查表：针对各架构主题l
程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）？
l
是否明确定义了主要的构造块（包括每个构造块的职责范围及其他构造块的接口）？
l
是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？
l
是否描述并论证了那些最关键的类？
l
是否描述并论证了数据设计？
l
是否详细定义了数据库的组织结构和内容？
l
是否指出了所用的关键的业务规则，并描述其对系统的影响？
l
是否描述了用户界面设计的策略？
l
是否将用户界面模块化，使界面的变更不会影响程序其余部分？
l
是否描述并论证了处理I/O的策略？
l
是否估算了稀缺资源（如现程、数据库连接、句柄、网络带宽等）的使用量，是否描述并论证了资源管理的策略？
l
是否描述了架构的安全需求？
l
架构是否为每个类、每个子系统、或每个功能域（functionality area）提出空间与时间预算？
l
架构是否描述了如何达到可伸缩性？
l
架构是否关注互操作性？
l
是否描述了国际化/本地化的策略？
l
是否提供了一套内聚的错误处理策略？
l
是否规定了容错的办法（如果需要）？
l
是否证实了系统各个部分的技术可行性？
l
是否详细描述了过度工程的方法？
l
是否包含了必要的“买 vs. 造”的决策？
l
架构是否描述了如何加工被复用的代码，使之符合其他架构目标？
l
是否将架构设计得能够适应很可能出现的变更？
架构的总体质量l
架构是否解决了全部需求？
l
有没有哪个部分是“过度设计”或“欠设计”？
l
整个架构是否在概念上协调一致？
l
顶层设计是否独立于用作实现它的机器和语言？
l
是否说明了所有主要的决策的动机？
你，作为一名实现该系统的程序员，是否对这个架构感觉良好？ |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图