免费智能真题库 > 历年试卷 > 系统架构设计师 > 2009年下半年 系统架构设计师 下午试卷 论文
  第1题      
  知识点：   DSSA的基本活动   软件架构   软件重用   架构设计   软件架构设计

 
论基于DSSA的软件架构设计与应用
软件架构设计的一个重要课题是如何解决软件重用问题。特定领域软件架构 (Domain Specific Software Architecture, DSSA)是一种有效实现特定领域软件重用的手段。按照Tracz的说法，DSSA就是一个特定的问题领域中由领域模型、参考需求、参考架构等组成的开发基础架构，其目标就是支持一个特定领域中多个应用的生成。
DSSA的基本活动包括领域分析、领域设计和领域实现。领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息。
 
问题：1.1   请围绕“基于DSSA的软件架构设计与应用”论鞞，依次从以下三个方面进行论述。
1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2. 就你所熟悉的领域，请给出针对该特定领域，在基于DSSA的软件设计开发中所涉及的领域模型、参考需求和参考架构以及相应的支持环境或设施。
3. 具体阐述你参与管理和开发的项目中使用DSSA的情况，包括领域分析、领域设计和领域实现等活动是如何具体实施的，最终实际效果如何。
 
 
 

   知识点讲解    
   · DSSA的基本活动    · 软件架构    · 软件重用    · 架构设计    · 软件架构设计
 
       DSSA的基本活动
        实施DSSA的过程中包含了一些基本的活动。虽然具体的DSSA方法可能定义不同的概念、步骤、产品等，但这些基本活动是大体上一致的。以下将分3个阶段介绍这些活动。
        （1）领域分析。这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求。我们称领域模型所描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界，从而明确分析的对象；识别信息源，即领域分析和整个领域工程过程中信息的来源。在此基础上，就可以分析领域中系统的需求，确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。领域分析的机制如下图所示。
        
        领域分析机制
        （2）领域设计。这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA。由于领域模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示多选一的、可选的解决方案等来做到这一点。由于重用基础设施是依据领域模型和DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的规约。
        （3）领域实现。这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。
        ：以上过程是一个反复的、逐渐求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。
        如上图所示，参与DSSA的人员可以划分为4种角色：领域专家、领域分析师、领域设计人员和领域实现人员。
 
       软件架构
        随着嵌入式技术的发展，特别是在后PC时代，嵌入式软件系统得到了极大的丰富和发展，形成了一个完整的软件体系，如下图所示。这个体系自底向上由3部分组成，分别是嵌入式操作系统、支撑软件和应用软件。
        
        嵌入式系统的软件架构
        嵌入式操作系统（Embedded Operating System，EOS）由操作系统内核、应用程序接口、设备驱动程序接口等几部分组成。嵌入式操作一般采用微内核结构。操作系统只负责进程的调度、进程间的通信、内存分配及异常与中断管理最基本的任务，其他大部分的功能则由支撑软件完成。
        嵌入式系统中的支撑软件由窗口系统、网络系统、数据库管理系统及Java虚拟机等几部分组成。对于嵌入式系统来讲，软件的开发环境大部分在通用台式计算机和工作站上运行，但从逻辑上讲，它仍然被认为是嵌入式系统支撑软件的一部分。支撑软件一般用于一些浅度嵌入的系统中，如智能手机、个人数字助理等。
        嵌入式系统中的应用软件是系统整体功能的集中体现。系统的能力总是通过应用软件表现出来的。
 
       软件重用
        可重用性（可复用性）是指系统和（或）其组成部分能在其他系统中重复使用的程度。软件开发的全生命周期都有可重用的价值，包括项目的组织、软件需求、设计、文档、实现、测试方法和测试用例，都是可以被重复利用和借鉴的有效资源。可重用性体现在软件的各个层次，通用的、可重用性高的软件模块往往已经由操作系统或开发工具提供，如通用库、标准组件和标准模板库等，它们并不需要程序员重新开发。
        软件重用（软件复用）是使用已有的软件产品（如设计、代码、文档等）来开发新的软件系统的过程。软件重用的形式大体可分为垂直式重用和水平式重用。水平式重用是重用不同应用领域中的软件元素，如数据结构、排序算法、人机界面构件等。标准函数库是一种典型的原始的水平式重用机制。垂直式重用是在一类具有较多公共性的应用领域之间重用软件构件。由于在两个截然不同的应用领域之间进行软件重用潜力不大，所以垂直式重用受到广泛关注。
        垂直式重用活动的主要关键点在于领域分析：根据应用领域的特征和相似性，预测软件构件的可重用性。一旦根据领域分析确认了软件构件的可重用价值，即可进行软件构件的开发，并对具有可重用价值的软件构件做一般化处理，使它们能够适应新的类似的应用领域。然后将软件构件和它们的文档存入可重用构件库，成为可供未来开发项目使用的可重用资源。
        软件重用的范围不仅涉及源程序代码，Caper Jones定义了10种可能重用的软件要素，分别是项目计划、成本估计、架构、需求模型和规格说明、设计、源程序代码、用户文档和技术文档、用户界面、数据结构和测试用例。
        有一个组织叫做基于面向对象技术的重用（Reuse Based on Object-Oriented Techniques，REBOOT）开发了支持重用的两种过程模型，分别是为重用开发和利用重用进行开发。该组织还开发了一系列工具，称为REBOOT环境。他们强调的一个原则是“未来重用者的需求，就是对可重用构件的信心”。开发者的倾向是抵制重用，因为他们缺乏这种信心。为了克服这种状态，REBOOT推荐一种文档结构，包括测试信息和重用者的经验。
        美国国防部的一项称为可适应、可靠性的软件技术（Software Technology for Adaptable，Reliable Softeware，STARS）关注过程、架构和重用三者的集成。STARS认为软件产品线开发的软件周期应该包括过程驱动、软件架构、领域工程、可重用构件库这4个概念。
        系统的软件重用由可重用的资产（构件）的开发、管理、支持和重用4个过程组成。工作在重用资产开发过程中的是构件开发者和领域工程师，工作在应用项目开发过程中的是应用工程师。如果要系统地实施软件重用，需要遵循以下原则：
        （1）需要高层领导的支持，并需要有长期的经费支持。
        （2）为了渐进地推行系统的重用，需要规划和调整系统的架构、开发过程、组织结构，并以小规模的先行项目为典型示范，而后再铺开。
        （3）为了重用，先规划架构及其逐步实施的过程。
        （4）过渡到明确的重用组织机构，将可重用构件的创建工作与重用工作分离开，并且提供明确的支持职能。
        （5）在真实的环境中，进行可重用构件的创建和改进工作。
        （6）要将应用系统和可重用构件作为一个经济核算的产品整体进行管理，应当注重公用构件在应用系统及其子系统领域中的高盈利作用。
        （7）要认识到单独的对象技术或者单独的构件技术都是不够的。
        （8）采用竞赛和更换负责人的办法，进行开发单位的文化建设和演化。
        （9）对基础设施、重用教育、技巧培训，要投资和持续地改进。
        （10）要采用度量方法测量重用过程，并要优化重用程序。
 
       架构设计
        WebApp描述了使WebApp达到其业务目标的基础结构，典型使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容层或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。模型-视图-控制器（Model-View-Controller，MVC）结构是WebApp基础结构模型之一，它将WebApp功能及信息内容分离。
 
       软件架构设计
        软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。
        
        架构的形成过程概要
        软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。
        软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。
        在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。
        （1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。
        （2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。
        （3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。
        （4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。
        以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。
        软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。
        类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。
        架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。
        一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。
        在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。
        模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。
        下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。
        
        架构的多维度分析
        在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。
   题号导航      2009年下半年 系统架构设计师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题