需求到架构映射的六大难点

不考虑软件需求就进行架构设计很可能导致失败，但从软件需求到软件架构存在六个天然难点：需求是频繁获取的非正规自然语言，架构规约却常是正式语言，两者表达形式本身就不兼容；非功能性需求通常很难在架构模型中形成规约（”要求高可用”这种描述无法直接翻译成一条架构决策）；需求理解和架构开发需要以迭代同步演化的方式进行，往往要基于不完整的需求先开发架构，有些需求甚至要到系统架构实现时才能被准确理解；保持映射的一致性和可追溯性很难且复杂度高，因为单一需求可能定位到多个架构关注点，单个架构元素也可能对应多个有意义的需求；现实中大规模系统要满足数以千计的需求，很难确定和细化包含这些需求的架构相关信息；从利益相关者角度看，需求和架构本就是在相互冲突的目标期望和术语中产生的，很难找到平衡点。面对这些难点，书中列举的近十种需求到架构的映射方法（如面向目标和场景的GRL/UCM方法、基于架构规约语言APL的方法、基于规则的架构决策诱导框架ADEF、基于全局分析的方法、面向模式的方法、CBSP方法等）虽然形式化程度和适用场景各不相同，但都共享同一个基本套路：先用某种结构化语言或模型把原本自然语言的需求”翻译”成带有明确语义的中间表示（如目标模型、需求分类维度、决策规则），再从这个中间表示推导出组件、连接件等架构元素。其中CBSP方法给出了一套颇具代表性的需求分类维度——组件（C）、连接件（B）、系统级功能（S）、数据/流程组件属性（CP）、总线属性（BP）、系统或子系统属性（SP）六个维度，用于对系统需求分类细化、捕获架构权衡问题，这套分类思路揭示了几乎所有映射方法的共同本质：把”需求”这种模糊的自然语言诉求，强制映射到一套有限的、可枚举的架构元素类别上，映射方法之间的差异主要在于这套类别体系的具体设计和形式化程度，而不在于映射的基本原理本身。