如何选择合适的软件体系结构设计方法

A. 设计软件系统结构的具体办法有哪些

结构化程序设计的思路是：自顶向下、逐步求精；其程序结构是按功能划分为若干个基本模块；各模块之间的关系尽可能简单，在功能上相对独立；每一模块内部均是由顺序、选择和循环三种基本结构组成；其模块化实现的具体方法是使用子程序。结构化程序设计由于采用了模块分解与功能抽象，自顶向下、分而治之的方法，从而有效地将一个较复杂的程序系统设计任务分解成许多易于控制和处理的子任务，便于开发和维护。 虽然结构化程序设计方法具有很多的优点，但它仍是一种面向过程的程序设计方法，它把数据和处理数据的过程分离为相互独立的实体。当数据结构改变时，所有相关的处理过程都要进行相应的修改，每一种相对于老问题的新方法都要带来额外的开销，程序的可重用性差。由于图形用户界面的应用，程序运行由顺序运行演变为事件驱动，使得软件使用起来越来越方便，但开发起来却越来越困难，对这种软件的功能很难用过程来描述和实现，使用面向过程的方法来开发和维护都将非常困难

B. 在产品设计时，如何选择合适的软件进行设计

数据的逻辑结构、存储结构和操作（特别是基本操作）的实现这三者是密切相关的。一般地，在选择（或设计）数据结构时应该完成以下三步：
⑴ 确定表示问题所需的数据及其特性；
⑵ 确定必须支持的基本操作，并度量每种操作所受的时、空资源限制；
⑶ 选择（或设计）最接近这些开销的数据结构。

C. 软件设计化结构包括哪些设计方法

1数据流的类型

在需求分析阶段，用SA方法产生了数据流图。结构化的设计能方便地将数据流图（DataFlowDiagram，DFD）转换成软件结构图。DFD中从系统的输入数据流到系统的输出数据流的一连串连续变换形成了一条信息流。根据数据流类型不同，可分为变换型和事务型2类，事务型和变换型数据流的设计步骤基本是大同小异，它们之间主要差别就是从数据流图到软件结构的映射方法不同。因此，在进行软件结构设计时，首先对数据流图进行分析，然后判断属于那一种类型，根据不同的数据流类型，通过一系列映射，把数据流程图转换为软件结构图。基本流程见图1.

1.1变换型数据流

信息在沿着输入通路进入系统，同时由外部形式变换成内部形式进入系统的信息，通过变换中心经加工处理，以后再沿着输出通路变换成外部形式离开系统。当数据流具有了信息流的这种特征时这种信息流就叫作变换型数据流。变换型数据流的DFD可明显地分为三大部分：逻辑输入、变换中心（主加工）、逻辑输出。变换型数据流结构见图2.逻辑输入：可以从数据流图上的物理输入开始，一步一步向系统中间移动，一直到数据流不再被看作是系统的输入为止，则其前一个数据流就是系统的逻辑输入。可以认为逻辑输入就是离物理输入端最远的，且仍被看作是系统输入的数据流。变换中心：多股数据流汇集的地方往往是系统的中心变换部分。
逻辑输出：从物理输出端开始，一步一步地向系统中间移动，就可以找到离物理输出端最远，且仍被看作是系统输出的数据流。
图片 [转到图文版]
图1数据流程图转换为软件结构图基本流程
图片 [转到图文版]
图2变换型数据流结构

1.2事务型数据流

信息在沿着输入通路进入系统，由外部形成内部形式后到达事务中心。通常事务中心位于几条处理路径的起点，从数据流程图上很容易标识出来，因为事务处理中心一般会有“发射中心”的特征。因为事务流有明显的事务中心，所以各式各样活动流都以事务中心为起点呈辐射状流出。事务型数据流结构见图3.
图片 [转到图文版]
图3事务型数据流结构

事务中心主要完成下述任务：接收输入数据（输入数据又称为事务）；分析每个事务以确定它的类型；根据事务类型选取一条活动通路。通常，事务中心前面的部分叫作接收路径，发射中心后面各条发散路径叫作事务处理路径。对于每条处理路径来讲，还应该确定它们自己的流特征。
2映射过程

任何一个设计过程都不是统一、固定不变的，设计的要求越高，往往需要设计者在方法上不但具有超强的判断能力还要有规则性的创造精神。根据不同类型，分析其映射过程。
2.1变换型数据流到软件结构图映射

（1）设计软件结构的顶层和第1层。设计一个主模块，并用系统的名字为它命名，作为系统的顶层。第1层为每个逻辑输入设计一个输入模块，它的功能是为主模块提供数据；为每一个逻辑输出设计一个输出模块，它的功能是将主模块提供的数据输出；为中心变换设计一个变换模块，它的功能是将逻辑输入转换成逻辑输出。主模块控制和协调第1层的输入模块、变换模块和输出模块的工作。
（2）设计软件结构的下层结构。每个逻辑输入模块有2个下属模块：一个接收数据；另一个把数据变换成上级模块所需要的数据格式。而接收数据模块又是输入模块，又要重复上述工作。如此循环下去，直到输入模块已经涉及到物理输入端为止。同样，每个逻辑输出模块有2个下属模块：一个是将上级模块提供的数据变换成输出的形式；另一个是将它们输出。对于每一个逻辑输出，在数据流程图上向物理输出端方向移动，遇到物理输出为止。设计中心变换模块的下层模块没有通用的方法，一般应参照数据流程图的中心变换部分和功能分解的原则来考虑如何对中心变换模块进行分解。
变换型数据流转换后的初始软件结构图见图4.
图片 [转到图文版]
图4变换型数据流转换后的初始软件结构图

2.2事务型数据流到软件结构图映射

事务型数据处理问题的工作机理是接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。
（1）设计软件结构的顶层和第1层。软件结构图的顶层是系统的事务控制模块。第1层是由事务流输入分支和事务分类处理分支映射得到的程序结构。也就是说，第1层通常是由两部分组成：取得事务和处理事务。
（2）设计软件结构的下层结构。设计事务流输入分支的方法与变换分析中输入流的设计方法类似，从事务中心变换开始，沿输入路径向物理输入端移动。每个接收数据模块的功能是向调用它的上级模块提供数据，它需要有两个下属模块：一个接收数据；另一个把这些数据变换成它的上级模块所需要的数据格式。接收数据模块又是输入模块，也要重复上述工作。如此循环下去，直到输入模块已经涉及到物理输入端为止。
事务处理分支结构映射成一个分类控制模块，它控制下层的处理模块。对每个事务建立一个事务处理模块。如果发现在系统中有类似的事务，就可以把这些

D. 如何选择合适的软件体系结构设计方法

（1）软件体系结构的多视图建模
通过逻辑视图，开发视图、进程视图、物理视图、进程来描述的软件体系结构。
（2）基于评估与转换的软件体系结构设计
通过迭代的开发方式，直至满足客户的需求。
（3）模式驱动的软件体系结构设计
通过总结、记录、复用来实现的体系结构设计
（4）领域特定的软件体系结构设计
借鉴领域中已经成熟的软件体系结构来实现解决方案在某个领域内的复用。
（5）软件产品线方法
软件复用发展的一个更高阶段，它并不仅仅局限于以前人们在软件复用中考虑的对函
数、模块、类、体系结构甚至子系统的复用。
（6）其于目标推理的软件体系结构设计方法
功能需求和非功能需求皆被表达为要达到的目标。
（7）其于属性的软件体系结构设计方法
基于目标图推理的体系结构设计方法、基于属性的体系结构设计方法。
开发心得：
在这些具有系统化过程的软件开发方法中，体系结构设计师一个不可避免
的过程，它们也都有自己的一些设计方式。但这并不排斥前面讲到的软件体系结构设计
方法，反之，如果能把这些体系结构设计方法与开发方法学结合起来，将能起到更好的
效果。

E. 如何进行软件架构设计

软件架构设计的几个步骤 1、分析需求和理解业务模型（或领域建模），并选定关键Use case。 软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。 理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。 在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。 软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。 只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题 在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？ 当遇到确实是很困难的问题，可以去网络一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。 架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。 在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。 对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。 这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。 这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。 在交付给客户Review时，通常

F. 如何设计软件系统框架结构,功能模块,和数据库

摘要 数据结构 数据结构指的是数据之间的相互关系，即数据的组织形式。数据结构是计算机存储、组织数据的 方式。数据结构是指相互之间存在一 种或多种特定关系的数据元素的集合 。通常情况下，精心选择的数据结构 可以带来更高的运行或者存储效率。 数据结构往往同高效的检索算法和索 引技术有关。 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。 在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。 在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。 面向组件设计

G. 如何进行基于软件体系结构的软件设计

MVC是当前流行的Web应用设计框架的实施标准，是软件工程中的一种软件架构模式[ ]。它把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)，目的是实现一种动态和可持续的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的代码或功能重复利用成为可能。 在这种设计结构下，一个应用被分为三个部分：model、view和controller，每个部分负责不同的功能。根据用户界面（view）的操作完成对程序数据（model）的更新。将程序数据（model）改变及时反应到用户界面（view）上。也就是完成两个方向的动作。

H. 如何进行系统的架构设计

如何进行系统的架构设计

一个软件项目在需求确定后，就可以开始系统的架构设计了。架构设计不同于编写代码，需要遵循严格的语法和编程规范。它没有规范可遵循，存在即合理，适合系统开发和运行的架构就是最合理的系统架构。

系统的架构设计是在业务需求已经清晰的前提下进行的，假定在系统需求分析阶段已经确定了系统的功能和业务范围，也明确了系统运营需求。在上述需求还没有确定的情况下，不适宜开展系统的架构设计，需要回到需求分析阶段完善上述需求后再开展系统的架构设计。

系统架构就是一些模型图，模型图是人们用来理解系统和沟通的工具。这些模型图需要提供给系统相关干系人来理解系统，系统相关干系人有项目经理、产品经理、开发人员、系统运营维护人员、客户、项目投资人等。这些干系人有不同的知识背景，对同一架构模型图也会有不同的认知和理解：如果把开发架构模型图给产品经理或客户看，他们定然看不懂也不能理解；同样的道理，如果只把逻辑架构图给开发人员看，就不能正确地指导开发人员构建开发环境。

因此架构设计师在进行系统架构设计时，需要从系统的不同维度进行设计，以满足系统相关干系人理解系统架构的需求。架构设计模型主要有逻辑架构、开发架构、数据架构、物理架构和运行架构五种模型图。一般来说需要设计的系统架构模型有逻辑架构、开发架构和物理架构三种架构模型图。数据架构模型一般放在数据库中进行设计，运行架构和物理架构基本相近，只是在物理架构中加了数据的流向，因此一些系统设计使用物理架构代替了运行架构。

设计逻辑架构模型

逻辑架构模型主要是确定系统的功能范围和系统划分。在设计逻辑架构模型时，可以抓住两个关键点：一个关键点是对系统进行逻辑划分，将一个大系统划分为多个子系统；另外一个关键点是明确各子系统之间的协作和调用关系。

绘制逻辑架构的模型图有系统流程图和系统结构图：系统流程图描述了系统各子系统、相关文件和数据之间的关系，记录了整个系统的体系结构；系统结构图也称为层次图，它以层次方式描述了系统从顶层到最底层的功能分解。

下图分别是人脉系统的系统流程图和系统结构图。

上面的人脉系统流程图和人脉系统结构图就是依据人脉系统需求规格说明书给出的功能和业务范围绘制的。

设计开发架构模型

开发架构模型图是给开发人员看的，开发架构模型指导开发人员如何来架构系统的开发环境。开发环境包括系统开发框架的选型、开发工具和编程语言、模块划分等内容。下图是人脉系统开发架构模型图。

开发架构模型图给出了技术体系是B/S结构，开发框架选择SSM，开发语言是JavaEE。系统采用三层结构，分别是表示层、WEB应用层和数据层。表现层是JSP页面，在浏览器中运行，表现层是MVC的View。WEB应用层的控制层是MVC的Controller，业务逻辑层是MVC的Service，实体层是MVC的POJO。数据层由MyBaits数据库开发框架组成。

设计物理架构模型

物理架构模型是给系统部署人员和运营维护人员看的，主要给出系统的部署环境模型，包括网络环境、硬件环境和软件环境。下图是系统部署网络环境模型图。

从上面网络环境模型图中可以看出，系统部署只需要一台主机，要求支持HTTP协议和远程桌面协议。系统可以考虑部署到阿里云或腾讯云。

系统的架构设计主要涉及到三种模型图，分别是逻辑架构模型、开发架构模型和物理架构模型。逻辑架构模型一般采用系统流程图和系统结构图建模；开发架构模型没有标准的模型图，可以使用PPT或Visio绘图工具进行绘制；物理架构模型主要是由网路环境、硬件和软件环境组成。

I. 几种常见的软件体系结构及特点分析

20世纪60年代的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上，然而随着软件系统规模越来越大，对总体的系统结构设计和规格说明变得异常重要。随着软件危机程度的加剧，软件体系结构(software architecture)这一概念应运而生。软件体系结构着眼于软件系统的全局组织形式，在较高层次上把握系统各部分之间的内在联系，将软件开发的焦点从成百上千的代码上转移到粒度较大的体系结构元素及其交互的设计上。与传统软件技术相比，软件体系结构理论的提出不仅有利于解决软件系统日益增加的规模和复杂度的问题，有利于构件的重用，也有利于软件生产率的提高。面向方面软件开发(AOSD)认为系统是由核心关注点(corn concern)和横切关注点(cross-cutting concern)有机地交织在一起而形成的。核心关注点是软件要实现的主要功能和目标，横切关注点是那些与核心关注点之间有横切作用的关注点，如系统日志、事务处理和权限验证等。AOSD通过分离系统的横切关注点和核心关注点，使得系统的设计和维护变得容易很多。
Extremara大学的Navasa等人［1］在2002年提出了将面向方面软件开发技术引入到软件体系结构的设计中，称之为面向方面软件体系结构(aspect oriented software architecture，AO-SA)，这样能够结合两者的优点，但是并没有给出构建面向方面软件体系结构的详细方法。
尽管目前对于面向方面软件体系结构这个概念尚未形成统一的认识，但是一般认为面向方面软件体系结构在传统软件体系结构基础上增加了方面构件(aspect component)这一新的构成单元，通过方面构件来封装系统的横切关注点。目前国内外对于面向方面软件体系模型的研究还相对较少，对它的构成单元模型的研究更少，通常只关注方面构件这一构成单元。方面构件最早是由Lieberherr等人［2］提出的，它是在自适应可插拔构件(adaptive plug and play component，APPC)基础之上通过引入面向方面编程(AOP)思想扩展一个可更改的接口而形成的，但它关于请求接口和服务接口的定义很模糊，未能给出一个清晰的方面构件模型。Pawlak等人［3］提出了一个面向方面的框架，该框架主要包含了一个方面构件模型———Java方面构件(Java aspect component，JAC)，但该方面构件模型仅包含了切点(pointcut)，并把AOP中装备(advice)集成到了切点的表达式中，它主要从实现的角度进行了阐述，并没有给出详细的方面构件模型。本文没有只关注面向方面软件体系结构中方面构件这一构成单元模型，还详细分析了它的另外两个构成单元，即构件和连接件，因为面向方面软件体系结构各部分之间是相互关联的。
1面向方面软件体系结构相关概念
面向方面软件体系结构涉及诸多概念，以下将分别介绍。软件体系结构在软件工程领域有着广泛的影响，但当前仍未形成一个统一的、标准的定义。目前国内外普遍认可的看法是软件体系结构包含构件、连接件和约束［4］。其中约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系。这样就可以把软件体系结构写成
软件体系结构(software architecture)=构件(components)+
连接件(connectors)+约束(constraints)
构件是软件体系结构的基本元素之一。一般认为，构件是指具有一定功能、可明确辨识的软件单位，并且具备语义完整、语法正确、有可重用价值的特点，然而目前对于构件的具体结构及构成并没有一个统一的标准［5］，而且一些主要的构件技术也没有使用相同的构件类型。另外，当前被广泛接受的构件定义并不包含具体的软件构件模型(software component model)。例如，Szyperski等人［6］给出了软件构件一个很有名的定义:软件构件是一个仅带特定契约接口和显式语境依赖的结构单位，它可以独立部署，易于第三方整合。但是关于软件构件模型有一个被普遍接受的观点是:软件构件是一个具有服务提供和服务请求功能的软件单元［7］。
连接件是软件体系结构另一个基本的构成元素，是用来建立构件间交互以及支配这些交互规则的构造模块。连接件最先是由Shaw［8］提出来的，她建议把连接件作为软件体系结构中第一类实体，用来表示普通构件之间的交互关系。目前对于连接件尚未形成统一的认识，尽管在软件体系结构中强调了连接件存在的必要性，但是关于连接件模型的研究还很少，连接件的实际应用还不成熟。
面向方面软件体系结构在传统软件体系结构的基础上增加了方面构件单元。通常认为，方面构件是封装了系统横切关注点的一类特殊的构件。目前关于方面构件模型的研究还处于起步阶段。
2面向方面软件体系结构模型
由于传统软件体系结构模型包含构件、连接件和约束，而面向方面软件体系结构是在传统软件体系结构的基础之上扩展了方面构件，所以面向方面软件体系模型结构包含构件、连接件、方面构件和约束。其中约束描述了面向方面体系结构配置和拓扑的要求，确定了体系结构的构件、连接件和方面构件之间的连接关系，而构件、连接件、方面构件是它的三个基本的构成单元。以下对这三个构成单元的模型进行详细的设计。