软件架构设计是软件开发过程中的一项重要工作。（24）不属于软件架构设计的主要工作内..

2015年下半年上午试卷综合知识

第 24 题


知识点	信息系统开发方法架构设计开发过程软件架构软件架构设计
关键词	软件架构软件开发过程开发开发过程软件开发
章/节	信息系统及其技术和开发方法

软件架构设计是软件开发过程中的一项重要工作。（24）不属于软件架构设计的主要工作内容。

A. 制定技术规格说明

B. 编写需求规格说明书

C. 技术选型

D. 系统分解

相关试题信息系统的设计和开发方法

第3题

2009年下半年

结构化系统分析和设计的主导原则是（3）。

第1题

2014年上半年

结构化法是信息系统开发的常用方法之一，它将信息系统软件生命大致分为系统规划、系统分析、系统设计、系统实施和系统维护5个阶段，每个阶段都有明确的工程任务，各阶段工作按顺序展开。下列任务..

第2题

2014年上半年

（2）不属于信息系统项目的生命周期模型。

知识点讲解

· 信息系统开发方法

· 架构设计

· 开发过程

· 软件架构

· 软件架构设计

信息系统开发方法

信息系统常用的开发方法有结构化方法、原型法和面向对象方法。

1．结构化方法

结构化方法是应用最为广泛的一种开发方法。按照信息系统生命周期，应用结构化系统开发方法，把整个系统的开发过程分为若干阶段，然后一步一步依次进行。

结构化方法具有如下特点：

.遵循用户至上的原则。

.严格区分工作阶段，每个阶段有明确的任务和取得的成果。

.强调系统开发过程的整体性和全局性。

.系统开发过程工程化，文档资料标准化。

结构化方法的优点有：

.理论基础严密，它的指导思想是用户需求在系统建立之前就能被充分了解和理解。

.注重开发过程的整体性和全局性。

结构化方法的缺点有：

.开发周期长。

.文档、设计说明烦琐，工作效率低。

.要求在开发之初全面认识系统的信息需求。

.如果用户参与系统开发的积极性没有充分调动，可能造成系统交接过程不平稳，系统运行与维护难度加大。

结构化分析（Structured Analysis，SA）方法

结构化分析方法由美国Yourdon公司在20世纪70年代提出，是一种简单实用、使用很广的方法。该方法通常与系统设计阶段的结构化设计（SD）方法衔接起来使用，适用于大型信息系统的开发。

结构化分析方法是一种单纯的自顶向下、逐步求精的功能分解方法，是一种面向数据流的分析方法。其核心特征是“分解”和“抽象”，下层是上层的分解，上层是下层的抽象。

结构化系统分析和设计方法的基本思想是用系统的思想、系统工程的方法，按用户至上的原则，结构化、模块化、自上而下对信息系统进行分析与设计。

2．原型法

原型法在很难全面准确提出用户需求的情况下，本着对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求。

原型应当具备的特点如下：

.实际可行。

.具有最终系统的基本特征。

.构造方便、快速，造价低。

原型分类如下：

.抛弃型原型：此类原型在系统真正实现以后就放弃不用了。

.进化型原型：此类原型的构造从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化成最终系统。

原型法的特点如下：

.对用户的需求是动态响应、逐步纳入的，相互之间并无明显界限，也没有明确分工。

.系统开发计划是一个反复修改的过程。

.适用于用户需求开始时定义不清、管理决策方法结构化程度不高的系统开发。

.如果用户配合不好，盲目修改，就会拖延开发过程。

3．面向对象方法

面向对象方法的基本思想如下：

.客观事物是由对象组成的，对象是在原事物基础上抽象的结果。

.对象是由属性和操作组成的，其属性反映了对象的数据信息特征，而操作则用来定义改变对象属性状态的各种操作方式。

.对象之间的联系通过消息传递机制来实现，而消息传递的方式是通过消息传递模式和方法所定义的操作过程来完成的。

.对象可以按其属性来归类，借助类的层次结构，子类可以通过继承机制获得其父类的特征。

.对象具有封装的特性，一个对象就构成一个严格模块化的实体，在系统开发中可被共享和重复引用，达到软件复用的目的。

在系统开发实际工作中，往往根据需要将多种开发方法进行组合应用，具体组合形式可以分为如下几种：

.结构化方法与原型法的结合使用。

.结构化方法与面向对象方法的组合使用。

.原型法与面向对象方法的组合使用。

架构设计

WebApp描述了使WebApp达到其业务目标的基础结构，典型使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容层或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器（Model-View-Controller，MVC）结构是WebApp基础结构模型之一，它将WebApp功能及信息内容分离。

开发过程

嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。

项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。

：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。

程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。

最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。

软件架构

随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。

嵌入式系统的软件架构

嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。

嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。

嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。

软件架构设计

软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。

架构的形成过程概要

软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。

软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。

在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。

（1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。

（2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。

（3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。

（4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。

以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。

软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。

类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。

架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。

一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。

在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。

模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。

下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。

架构的多维度分析

在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5