问题 问答题

阅读以下系统架构文档化的叙述,根据要求回答问题。
[说明]
软件架构(software Architecture)用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配,从而满足系统主要功能和性能需求,并满足其他非功能性需求。软件架构为软件系统提供了一个结构、行为和属性的高级抽象模式,可以使用一个公式来表达:
软件架构=构成系统的元素,指导元素集成的形式,关系和约束
“4+1”视图模型用5个视图组成的模型来描述软件架构,如图3—15所示。


[问题3]
软件架构在软件需求与设计之间架起一座桥梁,也是风险承担者进行交流的手段,允许不同的风险承担者找出他们所关心的软件架构问题。假设采用面向对象的设计方法,各个视图涉及的组件(元素)包括类(或对象)、模块、节点、任务和步骤等,风险承担者包括最终用户、系统架构师、程序员、系统实施工程师和项目经理等。请在表3-9中的(1)~(10)空缺处填入恰当的内容。

表3—9各软件架构视图组件及风险承担者表
逻辑视图 进程视图 物理视图 开发视图 场 景
组件(元素) (1) (3) (5) (7) (9)
风险承担者 (2) (4) (6) (8) (10)

答案

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

多项选择题
单项选择题