【正确答案】软件架构是软件系统的高层描述，给出了关于软件系统组织结构的一系列高级的、重要的抽象，包括：①系统组成的结构性构件；②组成构件之间的接口；③构件相对系统其他部分的可视行为；④构件之间所采取的交互和协作关系。
“4+1”视图模型用5个视图组成的模型来描述软件架构。该模型包含以下5个主要的视图。
(1)逻辑视图(Logical View)，描述了设计的对象模型(使用面向对象的设计方法时)，支持系统的功能需求，即在为用户提供服务方面系统所应该提供的功能。
(2)进程视图(Process View)，描述了设计的并发和同步特征，支持系统的运行特性。
(3)物理视图(Physical View)，描述了软件到硬件的映射，反映了分布式特性，支持系统的拓扑、安装和通信需求。
(4)开发视图(Development View)，描述了在开发环境中软件的静态组织结构，支持软件开发的内部需求。
(5)场景(Scenario)，用来说明重要的系统活动，是其他4个视图在用例(Use Case)驱动下的综合。该视图是其他视图的冗余(因此为“+1”)，但它起到了两个作用：①作为一项驱动因素来发现架构设计过程中的架构元素；②作为架构设计结束后的一项验证和说明功能，既以视图的角度来说明，又作为架构原型测试的出发点。
软件内部需求是指任何一个软件都要满足的一些非功能方面的需求。大部分情况下，开发视图架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制与约束等。开发视图是项目管理的基础，通过开发视图对系统功能和模块的层次性分解，能够预估开发工作量，安排开发任务，编制开发计划，进而监控进度，即开发视图是需求分解、团队工作的分配(或任务管理)、成本评估和计划(或成本管理)、项目进度的监控(或进度管理)、软件重用性、移植性和安全性等。它是建立产品线的基础。
物理架构主要关注系统非功能性的需求，如可用性、可靠性(容错性)、性能(吞吐量)和可扩展性等。软件在计算机网络或处理节点上运行，被识别的各种元素(网络、过程、任务和对象)，需要被映射至不同的节点；架构师希望使用不同的物理配置：一些用于开发和测试，另外一些则用于不同地点和不同客户的部署。因此软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。

【正确答案】进程架构考虑一些非功能性的需求，如性能和可用性等。它解决并发性、分布性、系统完整性和容错性的问题，以及逻辑视图的主要抽象如何与进程结构相配合在一起，即在哪个控制线程上，对象的操作被实际执行。
进程是构成可执行单元任务的分组。进程代表了可以进行策略控制过程架构的层次(即开始、恢复、重新配置及关闭)。另外，进程可以就处理负载的分布式增强或可用性的提高而不断地被重复。
主要任务是可以唯一处理的架构元素；次要任务是由于实施原因而引入的局部附加任务(如周期性活动、缓冲和暂停等)。它们可以作为轻量线程(或Ada Task)来实施。主要任务的通信途径是有着良好定义的交互任务通信机制：基于消息的同步或异步通信服务、远程过程调用及事件广播等。次要任务则以会话或共享内存来通信。在同一过程或处理节点上，主要任务不应对它们的分配做出任何假定。

【正确答案】依题意，本问题的题干说明中给出了“视图涉及的组件包括任务、类、模块、节点和步骤等，风险承担者包括最终用户、系统设计师、程序员、经理和项目管理师等”等关键信息。可见，本试题的答案应在正确地理解视图组件和给定的风险承担者角色概念的基础上这个范围内选择。
所谓风险承担者是指对软件系统某个方面(或层次)负责或(关注)的人员。也可以这样来理解风险承担者，即软件系统的某个方面(或层次)如果存在缺陷或问题，对此负责任或受影响的人员。风险承担者包括最终用户、系统设计师、程序员、经理和项目管理师等。
逻辑视图描述了设计的对象模型，支持系统的功能需求，即逻辑视图表述系统的功能需求。系统分解为一系列的关键抽象，而大多数这些抽象来自于需求分析中所提出功能要求，以对象或类的形式来表示(采用抽象、封装和继承等机制)。分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。系统的功能需求来自于最终用户，最终用户是逻辑视图对应的主要风险承担者。因此，(1)空缺处应填入“类(或对象)”这一组件(元素)，(2)空缺处的风险承担者应填入“最终用户”。
进程视图描述了设计的并发和同步特征，支持系统的运行特性，即进程视图表述系统的运行特性。利用进程视图可解决系统的并发性、分布性、系统完整性及容错性等问题。另外，它还可以表达逻辑视图的主要抽象在哪个控制线程上被实际执行。其风险承担者主要是系统集成人员(如系统架构师)，组件元素是任务。因此，(3)空缺处的组件(元素)应填入“任务”，(4)空缺处的风险承担者应填入“系统架构师”。
物理视图描述了软件到硬件的映射，反映了分布式特性，支持系统的拓扑、安装和通信需求，即物理视图表述系统的拓扑、安装和通信需求，用来表达软件系统中的各种元素(元素可以理解为组件或过程)被映射或部署至不同的网络计算机节点上。其风险承担者主要是系统实施工程师，组件元素是节点。因此，(5)空缺处的组件(元素)应填入“节点”，(6)空缺处的风险承担者应填入“系统实施工程师”。
开发视图描述了在开发环境中软件的静态组织结构，支持软件开发的内部需求，即开发视图表述软件开发的内部需求。其关注软件开发环境下实际模块的组织(程序库或子系统)，它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。其风险承担者主要是编程人员和软件项目管理人员。因此，(7)空缺处应填入“模块”这一组件(元素)，(8)空缺处的风险承担者应填入“程序员和项目经理”。
场景用来说明重要的系统活动，是其他4个视图在用例(Use Case)驱动下的综合。在某种意义上场景是最重要的需求抽象。该视图是其他视图的冗余(即“+1”所体现的含义)，但它起到了两个作用：①是可用来发现架构设计过程中的架构元素；②是可作为架构设计结束后的功能验证。它可作为架构原型测试的出发点，其主要风险承担者是最终用户和开发人员，组件元素是步骤。因此，(9)空缺处的组件(元素)应填入“步骤”，(10)空缺处的风险承担者应填入“最终用户、系统架构师和程序员”。