随笔 - 34  文章 - 0 评论 - 1130 trackbacks - 0

  我们知道,软件架构的过程是一个抽象的过程。通常的开发人员只是从开发的角度对业务需求进行抽象建模,力求对每一个细节进行把握。由于大多数架构师来自于当初的程序员,因此经常出现对某些细节过分关注而忽视建立整体概念架构。大多数情况下出现这种情况是因为架构师没有从开发视角转换到架构视角。

 

  在软件开发过程中,软件架构师处于非常特殊的地位。一方面,软件架构师需要与用户沟通,收集整理用户的需求;另一方面需要从整体上对软件项目进行架构设计;最后还要保证自己架构设计可行,并且能被开发人员所理解。虽然以上三点都是解决软件项目这同一个问题,但显然需要从不同角度出发。这就是对软件架构师的一个很重要也是很基本的要求——要求架构师能能够从不同的视角看待同一个问题。

 

  通常情况下,软件架构师需要从三个最基本的视角对项目进行抽象:概念视角,规范视角和实现视角。

  首先是概念视角:这要求架构师能够从用户的角度来定义系统,分析需求,建立模型。在这个模型中,一般不会指出每个需求是如何实现的,因为用户不关心具体过程,而是向用户阐明自己对需求的理解是否符合用户的预期,是否有误解,规避风险

  概念视角常用的方法是画用例图或数据流图(DFD);

 

  其次是规范视角:这个视角也可以认为设计视角,这时架构师只关系系统间的接口定义而不关注实现细节。架构师通过该视角系统进行划分,有整体系统划分为子系统,模块等,同时定义它们之间接口,而不会去关注每个模块是如何实现的,甚至不要关心项目开发使用的平台,如C#还是Java。通常情况下,通过对模块接口的定义和划分,再附以其他辅助手段,如TDD,可以对系统有一个更深刻的认识,发现首次设计时存在的不合理设计,隐藏的耦合,潜在的需求等,因此这是一个反复的过程。

  规范视角实现的方法多种多样,如用Excel列模块清单(包含模块名,输入,输入等),但是均与平台无关;

 

  最后是实现视角:我们知道,所有的设计最终都要付诸具体的代码开发。设计成果往往是UML类图,如同设计图纸,这与现实的开发环境通常没有关系。如果开发人员能力不足,看到设计时一定是一脸茫然,不知所措。并且,如规范视角中所说,在迭代设计过程中,仅有类图通常很难发现潜在的风险。因此,撰写能够体现设计思想的代码就显得非常有意义了。这一方面不至于使设计脱离与具体的开发环境,另一方面也可以帮助当前和未来的开发人员或维护人员更好的理解设计

  实现视角通常是指有用于验证设计的示例代码。

 

  小结:此篇随笔是对今天的高级软件架构师培训的一点总结,欢迎大家留下宝贵的意见!

posted on 2010-08-28 23:53 倪大虾 阅读(...) 评论(...) 编辑 收藏