系统概要设计中的构架设计

《系统概要设计中的构架设计》由会员分享，可在线阅读，更多相关《系统概要设计中的构架设计（15页珍藏版）》请在金锄头文库上搜索。

1、3.2软件架构设计3.2.1软件架构及架构设计1. 什么是架构在IT业，软件的系统架构是指通过某种特定的技术平台，完成软件系统整体功能的开 发过程。也可以通俗地理解为：总体设计和总体结构布局。（1）架构架构普遍指通过某种特定的平台，而达到完成整体软件的功能。也即软件体系结构通常 被称为架构，指可以预制和可重构的软件框架结构。并最终产生出本软件系统的体系结构 设计报告的开发过程。（2）架构的英文 Architecture0其英文的本意来源于建筑行业的建筑艺术、建筑风格和结构。下面是摘录1EEE-Std-1471-2000 Recommended Practice for Architectura

2、l Description of Software-Intensive Systems中有关Architecture 一词的解释。Architecture： The fundamental organization of a system embodied in its components， theirrelationships to each other，and to the environment，and the principles guiding its design and evolution. IEEE Std 1471. 2000 （Architecture是一个系统的基本组织

3、，它蕴含于系统的组 件、组件之间的相互关系、组件与环境的相互关系中，以及呈现于其设计和演进的原则中）。软件架构可以有多种定义，不管对软件架构如何定义和说明，所有的定义都有一个共同 的主题，那就是必须考虑软件系统中诸如技术方向、开发平台的选择、组件的构建、设计风 格的确定、设计模式的具体应用、系统中各个模块职责的划分、协作、连接等问题。2. 架构是一组有关软件系统要素的重要决策（1）决定软件系统的组织结构。构成系统的结构化元素的选择，实现对目标软件系统从整体到部分的最高层次的 划分。接口和它们相互协作行为的选择。将结构化元素和行为元素再次组合成粒度更大的子系统方式的选择。（2）指导这一组织结构（

4、元素及其接口、协作和组合方式）架构风格的选择。即选择包括架构中的组成组件、组件之间的联结器等组成元素，同时还要决定建造本应 用系统采用的具体技术。（3）软件开发中的架构既可以是名词，也可以是动词。软件系统的架构实际上应该是两个层面的事情。将架构作为名词来理解时，是指为软件 系统设计并提供一个统一的共享框架（Framework），这种架构事实上是系统的一个层；而将 架构作为动词来理解时，则是指设计构造系统或者是框架（Architecture）。3. 软件架构重要性的体现强调软件架构最主要的目的是希望本软件项目能够实现可重用一一因为开发者希望系 统能够重用以前的代码和系统设计，从而提高本次项目开发

5、的效率，这也是分析设计人员在 进行架构实践时应该把握的原则：另一个目的则是希望能够实现可扩展一一同样开发者还希 望在系统保持结构稳定的前提下，能够很容易地扩充系统的功能和性能t这可以通过合理地 应用其他比较成熟的框架。好的架构一定易于理解，易于学习，易于维护，开发者希望通过 一个简洁的架构来把握系统。因为一个复杂的架构不论是测试还是维护都很困难，所以开发 者希望架构能够在满足目标的前提下尽可能地简单明了。（1）软件架构是软件各相关方联系的载体。软件系统开发涉及许多相关人员。它们包括软件系统的使用者、项目管理人员、分析和设计人员、编码人员、测试人员、 维护人员等。由于各类人员都有自己的独特见解和

6、思想，要求和技术水平也不同，因此他们 一般都会从自己的视角来了解和理解所要开发的软件系统。导致不同层次和不同角色的人员 对软件系统的了解和技术理解是不同的，这将给以后再开发过程中的沟通、交流带来一定的 困难。软件架构是沟通和联系各类人员的特殊载体。在各种要求和理解存在矛盾的情况下，软件架构又成为协调和沟通各相关方人员的共同 语言。因为各个方面的人员，都应该围绕系统架构开展各自的工作。（2）软件架构代表了软件系统设计早期阶段中一系列重要的决策。软件架构提供了如何满足软件系统各项功能的要求，并为各个部件的设计和其相互关系提供了必须遵守的约束。软件架构为后面的详细设计工作和系统维护工作的组 织、实施

7、提供了一定的依据。软件架构应该提出软件系统应该实现的质量目标和性能指标，根据这些质量目标， 开发者也能够预测出软件系统的某些质量属性和等级。软件架构为开发人员的技术培训提供了基础，因为，当开发人员在对系统架构中应 用的技术或者应用的某种形式的框架不熟悉的情况下，技术培训是一个比较快捷的 方 法。（3）一个成熟的软件架构可以为今后开发类似的软件产品或者软件项目提供一定的参 照。4.软件系统架构的主要工作内容（1）架构调研（架构分析）。面向对象的设计并不只是简单地把需求分析中的领域分析模型转换成软件系统的设计 模型，系统架构师在进行软件系统的架构设计之前，还必须从需求分析的结果中获取架构因 素。架

8、构调研的本质是识别出可能会影响系统架构的各种因素，并了解它们的易变性和优先 级，最终解决这些问题。架构调研是对系统的重大设计决策有特别影响的需求进行分析，从而识别出对系统存在 或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求），例如市场趋势、系 统性能、开发的成本、维护和系统演进等方面的内容。其主要的重点在于应该了解提出了什 么问题，并权衡这些问题，和掌握解决影响架构重要因素的众多方法。（2）架构设计。架构设计主要包括体系结构设计和各个层中的模块设计，是指对软件、硬件、网络、运 营、政策等软件设计中的需求和要素进行决策。在统一过程中，架构调研和架构设计统称为 架构分析。5.统一过程

9、(RUP)中的架构视图(Architecture View)(1) 4+1 View 模型。1995 年，Philippe Kruchten 在 IEEE Software 上发表了题为 The 4+1View Model of Architecture的论文，引起了业界的极大关注，并最终被RUP (Rational Unified Process )采 纳。逻辑视图、实现视图、进程视图、部署视图，再加上用例视图，这些视图在RUP中被 称为架构视图(Architecture View).即通过这几种视图可以完整地展示系统的架构。软件系统 中的架构结果同样也可以组织成各种不同的视图，并且需要从不

10、同的视角来了解系统。图 3.6所示为Rational Rose2003支持的各种视图。图3.6 Rational Rose2003支持的各种视图逻辑架构主要描述系统中的各个层、包、主要框架、类、接口和子系统的概念组织方式： 而部署架构则描述系统的进程如何分配给处理单元和网络配置。同时不同的视图面对的人员 也不同，如分析设计人员一般比较关注逻辑视图，而程序员则更多地关注实现视图。(2) 用例视图。用例视图描述系统应该交付的功能，也就是外部参与者所看到的功能：用例视图的使用 者是客户、设计人员、开发人员以及测试人员。(3) 逻辑视图。逻辑视图描述如何实现用例视图中提出的系统功能，它的使用者主要是设

11、计人员和开发 人员。与用例视图相比，逻辑视图关注系统的内部，它既描述系统的静态结构(类、对象以 及它们之间的关系)，也描述系统内部的动态协作关系。这种协作发生在实现既定功能的各对象之间进行消息传递时。(4) 组件(实现)视图。组件视图描述系统的实现模块以及它们之间的依赖关系。它的使用者主要是开发人员。(5) 进程(并发)视图。并发视图将系统划分为进程和处理器。这是系统的非功能特性，该视图主要考虑资源的 有效利用、代码的并行执行以及系统环境中异步事件的处理。除了将系统划分为并发执行的 控制线程以外，并发视图还必须处理这些线程之间的通信和同步。并发视图的使用者是开发人员和系统集成人员，并且该视图由

12、动态图(状态图、协作图， 以及活动图）和实现图（组件图和部署图）组成。（6）部署视图。部署视图显示系统的物理部署，例如计算机和设备（节点），以及它们之间是如何连接 的。部署视图的使用者是开发人员、系统集成人员和测试人员。（7）对系统的架构设计要采用多视图来表达。由于系统的架构涵盖的内容和决策太多，并且还涉及不同方面的内容，不能采用某一种 单一形式的图来描述，而且也不能表达完整的内涵。因此系统的架构设计需要从不同的层次 和不同的视角分别设计：同时，由于在系统开发过程中还将涉及不同方面的开发人员，多视 图表达也为开发人员之间的交流提供了方便。应用架构视图的核心问题是要展示应用系统中重要的设计元素，

13、而屏蔽次要的设计元 素。因此，统一过程的架构视图给系统的开发者提供了这样的设计原则：“选择一小组有意 义的设计元素来传达主要的设计思想”。6. 系统架构设计应明确的问题（1）何时开展架构设计工作。架构设计一般应该在应用系统的需求分析和域建模完成后开展。当然，这需要项目经理 以具体的经验来判断是否合适开始构建软件架构的工作。（2）架构设计工作不仅要依据静态的系统目标，还要考虑动态的开发过程。静态的系统目标：一般为系统的功能性青求、非功能性需求和变化的用例等。动态的开发过程：一般为如人力资源的情况，开发进度的要求，开发环境的满足。（3）没有统一的“万能”系统架构。由于软件的系统架构设计是和千差万别

14、的具体软件系统的功能要求、应用的技术和具体 的开发平台等实现因素密切相关的，因此没有通用的系统架构设计解决方案；尽管存在上述 的原因，但在一般系统架构设计中还是会有一些共性的内容可以参考，以及需要考虑因素的 说明。对于每个因素的设计策略和具体的解决方法还需要软件系统的架构设计师在具体开发 实践中灵活把握。但要注意的是，不同的因素之间有时是相互矛盾的，架构设计师需要根据 具体情况进行平衡和统筹协调。7. 架构设计的基本依据（1）架构设计的主要依据首先是应用系统中的需求。应用系统的设计人员主要根据需求规格说明书中的功能性需求和非功能性需求来进行 系统的架构设计工作。比如在系统的体系架构设计中为什么

15、要应用B/S体系架构，为什么要 应用轻量级的J2EE框架而不应用重量级的框架，在每一层中为什么要用这种技术实现以及 各种设计模式等策略的考虑。设计人员对于这些问题的思考，其实都是为了能够更好地满足 应用系统中的“需求”，同时也是为了很好地实现需求和适应今后的需求变化；另外，系统 的架构设计不仅要满足功能性的需求，还应该满足非功能性的需求，如性能等方面的要求： 还应该权衡各种性能指标的优先级别，否则系统架构设计的结果也会很复杂，系统实现的总 体代价将会很高。（2）其次，在进行架构设计的同时还应该遵循J2EE平台中倡导的两个主要设计原则 多层架构、松耦合。采用分层设计方案后，系统中各个模块的功能相

16、互独立并被封装，同时层与层之间的关 联性也大大地减弱了，并能够保持松耦合的关联；另外系统的稳定性也得到进一步提高，也 便于系统今后的扩展和维护管理。通过系统架构可以把一个复杂的系统划分为一些简单的子 系统，这些子系统之间又能够保持相互独立，并与整个系统保持一致。8.如何验证系统架构设计的正确，性很多看似完美的架构，往往会在实现时出现问题。通过写代码来验证，还是开发出原型 来验证？在影响系统性能的各种因素中，架构是否合理是最重要的一个因素；糟糕的架构设 计几乎无法通过代码优化或者其他的方式得以根本性的改进，软件系统的开发者需要首先证 明现在的系统架构是否合理。对于系统架构是否合理这一问题，开发者可以首先采用设计评审的方式由同