err

软件开发唯一不变的是变化，变化的来源于客户的需求还有市场的变化。我们辛辛苦苦的做需求调研再根据调研成果做软件设计，完了再实现设计，最后发现客户需求变了，可想而知有多痛苦。解决变化的方式是跟客户经常的沟通和设计灵活的架构。如何加强沟通那在需求阶段需要通过用例图等方法跟客户沟通，在架构设计阶段就需要原型法做沟通，在开发阶段就需要迭代式开发来加强沟通。原型法是软件经常用的方式，通过原型让客户尽早接触到我们要开发的软件，让客户看一个大概，这样客户就能够在这上提出自己的意见或建议还有可能提出新的需求，根据意见我们修改我们的设计。下面我们就说说原型法以及分类。

1.水平原型：这种原型是实现最简单的，只涉及到用户界面层的简单流转操作，界面的样式，一般不包括数据库操作。这种原型经常在开发阶段抛弃。

2.垂直原型：垂直原型法是实现系统的一个完整的功能，包括后台数据库的访问，这种方式也用来验证架构，和技术可行性。这种原型在开发阶段一般不会被抛弃，开发就在这个原型上做演进式开发，所以如果决定了不抛弃原型那原型的代码质量需要得到保证。

3.抛弃原型：抛弃原型正如他表达的一样就是做的原型在开发阶段不再采用，也就是被抛弃。

4.演进原型：演进原型就是原型在开发阶段不抛弃继续使用，在此原型的基础上迭代开发，一步步实现功能。

验证架构还可以使用框架法，框架法就是选择先架构一个开发框架，再在框架上添加我们的功能。比如java经常用的：Structs+Spring+Nhibernate。垂直演进型原型一般与框架法一起使用。

为什么要定义关键需求？因为关键需求能够决定架构，如果一开始就分析所有需求那可能对需求分析的不够细也有可能造成分析瘫痪，而且也有工期的压力，而通过分析关键需求对关键需求进行架构设计，再通过非关键需求来验证架构，这样做是最佳的方式。下面说说关键需求分类。

1.关键功能需求：功能需求就是软件必须实现的功能，功能需求是否是关键需求要通过客户的指定，通过跟客户配合来定关键需求，并且分析要实现此关键功能需要协助的其它功能。

2.关键质量需求：对架构影响很大的质量需求，持续可用性，互操作性等。

3.关键商业需求：商业需求也叫业务需求，一般是组织或客户的高层次的目标，比如我们以后要拓展外国市场，这样架构就要考虑多语言的问题。

在完成“概念性架构”设计下一步就进行对概念性架构做细化，我们用五视图方法对概念性架构进行细化。五视图设计的来源或者说是输入是：领域模型，关键需求，概念架构，约束，经验，通过以上的输入条件最终我们会输出五视图架构方案。 下面介绍一下五视图方法具体的原则。

1.逻辑架构：逻辑架构设计着重考虑功能需求，关系行为职责的划分，包括功能需求的和为了实现功能需求提供的辅助功能。

一般而言逻辑架构设计应完成下列工作：

(1).细化功能单元。

(2).发现同样机制。

(3).细化领域模型。

(4).确定子系统接口和交换机制。

2.开发架构：开发架构着重考虑开发期质量属性，比如：可扩展性，可重用性，可移植性，易理解性，易测试性等。开发架构主要关注点是软件模块的实际组织方式，包括：源程序包，配置文件，编译后的目标文件，第三方库等。

一般而言开发架构设计应完成下列工作：

(1).确定要开发或直接利用的程序包之间的依赖关系。

(2).确定采用的技术。

(3).确定采用的框架等。

3.数据架构：软件就是对数据的操作，所以数据在软件中非常重要，设计数据架构的时候主要使用ER图和数据流图。如果需要不同系统集成还要求对数据格式的转换，还有数据的复制和缓存。

一般而言数据架构设计应完成的工作：

(1).持久化数据存储方案。

(2).数据传递，数据复制，数据同步等策略。

4.运行架构：运行架构的设计主要考虑运行期质量属性，例如性能，可伸缩性，持续可用性等。运行架构关注进程，线程，对象等运行时概念，以及相关的并发，同步，通信等问题。工作流和多线程并发等用运行架构描述价值比较大。

一般而言运行架构设计应完成的工作：

(1).确定引入哪些进程与线程。

(2).确定主动对象，被动对象，以及控制流关系。

(3).处理相关问题：进程线程的创建，销毁，通信机制，资源征用等。

(4).协议设计。

5.物理架构：物理架构的设计着重考虑“安装和部署需求”。物理视图描述运行软件的计算机，网络，硬件设施等情况，还包括如何将软件包部署到这些硬件资源上，以及他们运行时的配置情况。

一般而言物理架构设计应完成的工作：

(1).确定物理配置方案(可能是网络方案，也可能是单片机等的分布，或者二者兼有)。

(2).确定如何将目标程序映射到物理节点。

上面介绍的五视图方法不一定每个项目都要实现这几种架构视图，根据项目的实际情况来使用相应的架构视图，还是那句老话不要为了设计而设计，应看项目的情况。

概念性架构设计是对架构的一个概览，下面写一下生成概念性架构的过程。

1.鲁棒性分析：鲁棒性分析是对用例的分析，分析出实现用例用到的哪些对象每个对象的职责对象间的调用关系，是业务到技术的一个转变过程。

2.引入架构模式：根据项目的现实情况分析需要用到的架构模式，大部分都用分层的架构，也有可能在某层上运用其它的架构模式比如在数据访问层ORM用元数据架构模式。把鲁棒分析的对象放到分析完的架构里。

3.质量属性分析：质量属性分析也是对架构设计影响很大的，如果架构漏掉了关键质量属性则会对架构设计带来很大的风险，通常使用“属性-场景-决策”表的形式带分析质量属性。比如业务人员在不同地方办公这种要求就是一个场景，这样就需要用B/S架构的决策来支撑这个场景。

1.业务目标到特性列表：根据客户的业务需求描述整理特性列表。

2.特性列表到用例图：根据特性列表分析出实现此特性的用例和执行者，并对每个用例进行简述。

3.用例图到用例规约：对关键用例进行行为描述(用例规约)，记得关键用例，不要把所有用例都做用例规约这样会带来分析瘫痪(小项目除外)。

4.需求启发与需求验证：设计原型界面或者可运行的原型系统跟客户交流，挖掘客户新需求。对需求进行变更。

注：软件在用例分析阶段如果用例不是很复杂就不要写用例规约尽量只写用例描述，因为用例规约维护很麻烦，如果用例很复杂则需要写用例规约来描述用例的实现步骤。还有用例一般很少变化，但是用例的实现步骤就会经常改动，比如你对业务了解的越深的时候你就会修改用例规约使其更合理化，如果用例涉及到国家或地方政策则也会经常变动用例规约。

1.需求分析：整理需求，对需求进行分类，按照“功能性需求”“非功能性需求”分类，并且非功能性需求还要按照“约束”“运行期质量属性”“开发期质量属性”。

2.领域建模：根据需求，分析领域的核心领域对象(可以通过名词动词法)，这些核心对象在此领域中相对稳定比如拿银行来说：银行账户，银行卡，存单等都是核心领域对象。通过分析这些对象了解此领域，并根据分析的领域对象(可以用类图和状态图)跟客户交流来更一步的丰富领域模型，领域建模是根据项目的进程不断精华的。

3.确定关键需求：关键需求（包括功能和非功能）决定架构，我们做项目不能眉毛胡子一把抓应该缩小范围确定重点不至于迷失方向。如果所有需求都一起开始分析设计的话这样就有可能分析的不够深入(项目的时间压力)，也可能迷失在繁杂的需求当中（项目大需求多）。

4.概念性架构设计：分析关键用例的用例规约，运用鲁棒图构造系统理想化的职责模型。确定架构模式，确定交换机制，考虑非功能性需求设计出概念性架构。

5.细化软件架构：在上面分析的基础之上通过五视图的方法对概念架构进行细化，使概念架构落到技术层面。

6.验证软件架构：架构如果没有经历过验证就不能称为好的架构，所有我们在架构设计完成的时候需要通过原型法实际做来验证架构。可以先设计一个框架来验证架构（垂直演进型），也可以设计一个垂直抛弃原型来验证架构。

注：

约束：约束是项目必须满足的必要条件，比如：用户电脑操作水平低，必须能够跑在某个操作系统上等等。

运行期质量属性：运行期质量属性是在软件的运行过程中运行的好坏，比如：持续可用性，易用性，高性能等等。运行期质量是用户比较关心的，用户评价软件的好坏就是根据运行期质量来看。

开发期质量属性：开发期质量是指软件内部质量属性，比如：易理解性，模块间的松散耦合，模块的可重用性等等。开发期质量对软件的维护有很大的影响，如果质量比较高则维护成本就很低。还有就是要说如果开发期质量不高运行期质量也很难上去。

架构：是对系统不同层面的决策集合，比如从架构风格来说：分层架构,消息总线，基于组件架。基于不同的架构视图来说：逻辑架构，物理架构，数据架构，部署架构，运行架构。架构属于分析设计阶段的成果，拿人来比喻软件架构就像人的灵魂，不同的人有自己的思维架构，软件架构解决如何能够符合软件的需求，而灵魂解决如何能生活的幸福。

框架：是我们开发复用的构件比如:Spring,Hibernate等，他解决了某一方面的问题，使得我们遇到这方面的问题就可以用现成的框架解决，比如Hibernate就是解决数据持久化的问题。框架在构建的过程中也存在架构设计，每个框架都有自己的架构，通过架构解决如何更好实现松耦合可扩展安全性效率等问题。