【正确答案】正确答案：[答案要点] 本题相当于选择题，但要获得好的成绩，仍需要仔细构思。 1)逻辑视图表述系统的功能需求。系统分解为一系列的关键抽象，这些抽象(大多数)来自于需求分析中所提出功能要求，以对象或类的形式来表示(采用抽象、封装和继承)。分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。系统的功能需求来自于最终用户，最终用户是逻辑视图对应的风险承担者。 2)进程视图表述系统的运行特性。利用进程视图可解决系统的并发性、分布性、系统完整性、容错性等问题。另外，它还可以表达逻辑视图的主要抽象在哪个控制线程上被实际执行。风险承担者主要是系统集成人员，组件元素是任务。 3)物理视图表述系统的拓扑、安装和通信需求。用来表达软件系统中的各种元素 (元素可以理解为组件或过程)被映射或部署至不同的网络计算机节点上。风险承担者主要是系统实施工程师。 4)开发视图表述软件开发的内部需求。开发视图关注软件开发环境下实际模块的组织(程序库或子系统)，它们可以由一位或几位开发人员来开发。子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。风险承担者主要是编程人员和软件项目管理人员。 5)场景用来说明重要的系统活动，是其他四个视图在用例(Use Case)驱动下的综合。在某种意义上场景是最重要的需求抽象。该视图是其他视图的冗余(因此“+1”)，但它起到了两个作用：首先场景可用来发现架构设计过程中的架构元素，其次场景可作为架构设计结束后的功能验证。它可作为架构原型测试的出发点。风险承担者是最终用户和开发人员，组件元素是步骤。

【答案解析】解析：本题主要考查软件架构“4+1”视图的有关知识和实施方法，熟悉以下关于软件架构的知识是回答本题的前提。 首先要准确把握软件架构的定义。架构(Architecture)原意为建筑学设计和建筑物建造的艺术与科学。软件架构(Software Architecture，或称为软件架构)是软件系统的高层描述，它给出了关于软件系统组织结构的一系列高级的、重要的抽象，包括：系统组成的结构性构件；组成构件之间的接口：构件相对系统其他部分的可视行为：构件之间所采取的交互和协作关系。软件架构在RUP 中的定义是指系统核心构件的组织或结构，这些核心构件通过接口与不断减小的构件与接口所组成的构件进行交互。 人们在软件开发过程中积累了丰富的架构知识，形成了的特定的架构风格，这些架构风格为高层次的软件复用技术建立了坚实的基础：例如，C/S架构、管道/过滤器架构、分层架构、解释器架构、黑板架构等等，而各种分布式组件技术如DCOM，EJB， Web-Services 也都和软件架构密切相关。 长期以来，人们一直在努力软件架构更加精确的形式化描述，力图用一种类似于某种编程语言的形式来描述软件架构，如Rapide，Wright，Aesop，UniCon，ACME 等。XML描述与软件建模UML 技术的发展为软件架构描述语言注入了新的发展思路，新一代的架构描述语言(如xArch，xADL 等)充分应用了这些新的描述手段的特点。同时，伴随着架构描述技术的进步，架构评估等研究也在不断的深入。 其次，要正确理解软件架构的重要作用。 .软件架构能够指导整个系统的设计和演进，它是软件需求分析的结果，同时是下一步进行软件设计的规格和蓝图。对于复杂软件系统而言，在架构阶段，系统的结构和规格说明非常重要，而在软件设计阶段，算法和数据结构更重要。 .软件架构对系统的描述，借鉴了建筑工程设计的思想，通过各种视图从不同角度以规范、一致、易理解的“语言”来表达系统的各种规格和行为。以某一特定角度看到的系统架构之规格、行为，主要是结构、核心构件和主要控制流等。 .软件架构是风险承担者进行交流的手段。所谓风险承担者是指对软件系统某个方面(或层次)负责或(关注)的人员。也可以这样来理解风险承担者：软件系统的某个方面(或层次)如果存在缺陷或问题，对此负责任或受影响的人员。风险承担者包括最终用户、系统设计师、程序员、经理、项目管理师等。 .软件架构是可传递、可重用的模型。 .软件架构是软件工程早期设计决策的体现，而且在整个开发周期中不断演进，软件架构对于软件质量(功能属性、非功能属性)都有重要影响。 “4+1”视图模型是最重要软件架构模式，由Philippe Kruchten 在1995年提出。如下图所示。

【正确答案】正确答案：[答案要点] 系统大多数关键的功能以场景(或用例)的形式被捕获。所谓关键是指系统最重要的功能(或系统存在的理由)，或使用频率最高的功能，或其应用减轻了一些重要的技术风险。基于场景驱动的迭代式设计过程如下。 1)开始阶段。基于风险和重要性为某次迭代选择一些场景。场景可能被归纳为对若干用户需求的抽象；对场景进行“描述”，以识别主要的抽象(类、机制、过程、子系统)；将所发现的架构元素分布到4个视图中；然后实施、测试、评估该架构，这个过程中可能检测到一些缺点或潜在的增强要求；捕获经验教训。 2)循环阶段。重新评估风险，选择能减轻风险或提高结构覆盖的额外的少量场景，然后试着在原先的架构中描述这些场景，发现额外的架构元素，或找出适应这些场景所需的重要架构变更，更新4个主要视图；根据变更修订现有的场景；升级实现工具(架构原型)以支持新的、扩展了的场景集合。 3)测试。如果有可能(比如，在已有可重用的组件下快速实现系统)，在实际的目标环境和负载下进行测试。 4)评审这5个视图，检测架构在简洁性、可重用性和通用性方面可能存在的潜在问题。 5)更新设计准则和基本原理。 6)捕获经验教训。 对于实际的系统，初始的架构原型需要不断进行演化。一般的情况是在经过两次或三次迭代，当找到了主要的抽象，子系统和过程都已经完成并且已经实现所有的接口，系统架构可认为趋向于稳定。

【答案解析】解析：考查“4+1”视图架构的场景驱动实现方法。

【正确答案】正确答案：[答案要点] 软件内部需求是指任何一个软件都要满足的一些非功能方面的需求，大部分情况下，开发视图架构考虑的内部需求与以下几项因素有关：开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制与约束。开发视图是项目管理的基础，通过开发视图对系统功能、模块的层次性分解，能够预估开发工作量、安排开发任务，编制开发计划，进而监控进度，即开发视图是需求分解、团队工作的分配(或任务管理)、成本评估和计划(或成本管理)、项目进度的监控(或进度管t111)等方面的基础。

【答案解析】解析：考查开发视图的表述内容及其与实施项目管理的关系。 第二步；根据问题要点，仔细阅读正文，找出相应段落。 (1)在题目的说明中给出了软件架构是“指大型、复杂软件的系统结构的设计、规格说明和实施”和“4+1”视图模型的基本概念。 (2)题目的说明中进一步指出，软件架构“描述出系统的主要功能和性能需求，同时表述其他非功能性需求(如可靠性、可扩展性、可移植性和可用性等)”，认真体会，结合项目管理方面的基础知识，不难回答问题3 (3)在问题1的说明中限定了视图涉及的组件包括：任务、类、模块、节点、步骤等，风险承担者包括最终用户、系统设计师、程序员、经理、项目管理师等，问题的答案应在这个范围内选择。正确地理解视图组件和给定的风险承担者角色概念，很容易回答问题1。 第三步：分析试题的内容，构思答案的要点。