我个人认为,完整覆盖“需求进,架构出”的架构设计方法才是符合一线实践需要的。
Pre-architecture就是架构设计的最前期阶段,其工作目标包括:理解需求、建立需求大局观、确定架构设计方向等。
“磨刀不误砍柴工”,这是近乎常识的古训。整个ADMEMS方法包含Pre-architectureConceptual Architecture. Refined Architecture 3个阶段。如果说, Conceptual Architecture和RefinedArchitecture 阶段是“砍柴” (这两个阶段都对系统进行了某种程度的切分,系统已经不再是“黑盒子”了),那么最初的Pre-architecture阶段就是“磨刀”(此阶段未对系统进行切分,系统还是“黑盒子"。
需求理解的大局观
架构师常常面对相互矛盾的需求目标。如果对需求的理解缺乏大局观,那将如何进行需求的权衡取合?
重大需求塑造概念架构。如果对需求的理解缺乏大局观,那将如何识别重大需求、特色需求、高风险需求?
架构师必须在相对短的时间内设计架构。如果对需求的理解缺乏大局观,那将如何进一步运用“关键需求决定架构,其余需求验证架构”的策略?
Prearchitecture 段能帮助架构师建立需求理解的大局观。任何需求都可定位于业务级需求、用户级需求、开发级需求这3个需求层次的某一层,同时也必属于功能、质量、约束这3类需求的某一类。如此一来,就便于梳脉理络、把握关系。
建议架构师在参与需求分析工作时,不断运用ADMEMS矩阵等工具对需求进行大局的梳理,只要满足下列3个条件(如图3-3所示)就可以尽早开始架构设计工作:
1,有了明确的业务需求。必须保证甲、乙双方就建设系统的目标(可能不止一项)达成了共识, 《愿景文档》经过了正式评审,并且明确了投资、工期标准、整合等约束条件。试想,业务需求含糊不清,架构设计方向如何确定呢?
2,了解全面的用户需求。也就是说,系统能帮助用户干什么、不能干什么,这个“需求的Scope”已经非常明确了。如果采用了用例技术,则表现为“用例图”是比较完善的,没有明显的遗漏(注意用例图和用例规约在需求分析中的实践意义不同,可参考《软件架构设计》一书)。
3,有了典型的行为需求。这意味着,大量行为需求还未明确定义,离提交《软件需求规格说明书》还早。如果采用用例技术,则表现为核心功能的《用例规约》已定义。