软件架构设计

[b]软件需求：[/b]

软件需求 = 功能需求 + 质量属性 + 约束


约束是架构设计要解决的问题的上下文


[b]不同需求影响架构的不同原理，是架构设计思维的基础[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9756/3eb7cb25-a5fb-3e87-b040-beaf4587ecbb.png[/img]


五维三级需求法——业务分析、范围协商过程：


[img]http://dl2.iteye.com/upload/attachment/0114/9567/d62237d2-dad6-3f12-80d8-2ad1224c5578.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9780/59d2a1ec-8233-3e88-bea2-6a5dc30b6319.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9334/13359a90-bae8-3d4e-a4bc-5a6223eebc94.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9797/d3c338d3-feac-3d58-be5a-c14f6c56cba1.png[/img]


[b]软件架构[/b]是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

[b]软件架构设计就是从宏观上说明一套软件系统的组成与特性。[/b]

ADMEMS是Architecture Design Method has been Extended to Method System的简称，ADMEMS通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。其中“3个阶段”是指预备架构阶段（PA阶段）、概念架 构阶段（CA阶段）、细化架构阶段（RA阶段），“1个贯穿环节”是指对非功能目标的考虑。


[img]http://dl2.iteye.com/upload/attachment/0114/9547/4ada44fe-7907-3a1b-a143-6ffe84fa44c4.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9545/3107cfb2-fb5f-3245-8e8c-c8a4d35f917c.png[/img]


架构设计方法首先应当是多阶段的，其次才是多视图的；阶段是先后关系，视图是并列关系。


[img]http://dl2.iteye.com/upload/attachment/0114/9543/e5b47a19-6fec-31ac-97e5-a41fbee51ed3.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9595/6385a176-a969-3ebf-8408-4280c58996a6.png[/img]


PA阶段的任务是全面理解需求，从而把握需求特点，进而确定架构设计驱动力；
CA阶段必须考虑包括功能、质量、约束在内的所有方面的需求；
RA阶段的总体方法为5视图方法，涉及逻辑架构、物理架构、开发架构、运行架构和数据架构。

[b]PA阶段：ADMEMS矩阵法[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9762/6a9e8d60-0c01-31f7-aea5-a761525fa457.png[/img]


[img]http://dl2.iteye.com/upload/attachment/0114/9557/9e791608-9435-3bcd-ac54-b8a999fe7266.png[/img]


[b]CA阶段：重大需求塑造概念架构[/b]


概念架构满足“架构=组件+交互”的基本定义，只不过概念架构仅关注高层组件

概念架构对高层组件的“职责”进行了笼统的界定，并给出了高层组件之间的相互关系

概念架构不应涉及接口细节


[img]http://dl2.iteye.com/upload/attachment/0114/9559/7af8b61a-b199-3b9e-9870-d98a58b2c606.png[/img]


[b]RA阶段：落地的5视图方法[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9367/a73fd780-0cf7-33d0-969c-db71649a5868.jpg[/img]


[b]软件架构设计的方式方法：[/b]

[img]http://dl2.iteye.com/upload/attachment/0114/9365/40c3138b-1210-3354-9288-3a728a63c1ed.jpg[/img]

逻辑架构的重点是考虑软件功能性需求：


[img]http://dl2.iteye.com/upload/attachment/0114/9369/471a34b1-0e6f-3d2a-9f59-1001395c8cbf.png[/img]


开发架构重点关注的是开发编码实现方面的问题：


[img]http://dl2.iteye.com/upload/attachment/0114/9371/cb7c1025-1755-33c7-ad69-13655a478dcb.png[/img]


数据架构不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计：


[img]http://dl2.iteye.com/upload/attachment/0114/9373/04ff2427-23a3-35ff-813b-e269933e553c.png[/img]


运行架构关注的不再是全局而是局部，着重关注那些关键点与难点，常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行，同时也要考虑质量属性：


[img]http://dl2.iteye.com/upload/attachment/0114/9375/dbc37b7a-9632-37e6-a15f-c8833f2d687f.png[/img]


物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响：


[img]http://dl2.iteye.com/upload/attachment/0114/9377/6c49edd8-d335-3c2a-b845-c395b2c34bb5.png[/img]


[b]质疑驱动的逻辑架构设计的整体思路：[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9561/ae8b6ac6-0794-3b8b-bf8c-dab79c7ccc23.png[/img]


[b]逻辑架构设计的10条经验：[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9563/ed1404ce-570c-31d1-bbca-6b4052a02f00.png[/img]


[b]划分子系统原则：[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9565/44e8bd13-0a83-3f19-b6ea-b3b84388bb3e.png[/img]


为了得到客户经常性的反馈，快速迭代有个基本前提：开发应该“深度优先”，而不是“广度优先”。


广度优先极端情况下意味着对每一个功能进行定义，然后对每个功能进行设计，接着对每个功能进行编码，最后才对所有功能一起进行测试。而深度优先极端情况下意味着对每个功能完整地进行定义、设计、编码和测试，而只有当这个功能完成了之后，你才能做下一个功能。当然，两个极端都是不好的，但深度优先要好得多。对于大部分团队来说，应该做一个高级的广度设计，然后马上转到深度优先的底层设计和实现上去。


如何通过关注点分离来达到“系统中的一部分发生了改变，不会影响其他部分”的目标呢？

首先，可以通过职责划分来分离关注点。面向对象设计的关键所在，就是职责的识别和分配。每个功能的完成，都是通过一系列职责组成的“协作链条”完成的；当不同职责被合理分离之后，为了实现新的功能只需构造新的“协作链条”，而需求变更也往往只会影响到少数职责的定义和实现。

其次，可以利用软件系统各部分的通用性不同进行关注点分离。不同的通用程度意味着变化的可能性不同，将通用性不同的部分分离有利于通用部分的重用，也便于对专用部分修改。

另外，还可以先考虑大粒度的子系统，而暂时忽略子系统是如何通过更小粒度的模块和类组成的。


[img]http://dl2.iteye.com/upload/attachment/0114/9722/4b68bf1d-a158-3298-be5b-072751981ec8.png[/img]


[b]“分”是手段，“合”是目的[/b]


[b]协作决定接口[/b]


[img]http://dl2.iteye.com/upload/attachment/0114/9725/81a13e61-f261-3f06-b984-2162439d0086.png[/img]


架构是一种平衡手段，架构为特定的目标服务，通过平衡资源的分配从而达成有限的资源下实现特定的目标。

通常，我们做架构设计的目标是平衡空间、时间、可靠性、复杂度、可维护性、易用性、成本等等指标，选择应用更迫切需要满足的指标优先满足，同时尽可能的减少对其他指标的影响。简单说，架构就是要明确取舍。而且，我们选择的架构不能够影响应用本身的业务逻辑，也就是说架构对应用来说应该是透明的。