有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI)
架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信),要使用什么语言,模式……?
如果我说错了,请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章,但我不确定我是否理解正确。
当您需要将较高体系结构级别识别的业务和功能投射到应用程序中时,软件体系结构最好用于系统级。
例如,你的业务是关于交易员的“盈亏”,你的主要功能涉及“投资组合评估”和“风险计算”。
但是当软件架构师详细描述他的解决方案时,他会意识到:
“投资组合评估”不能只是一个应用程序。它需要在可管理的项目中进行细化,例如:
GUI
发射器
调度程序
...
(因为涉及的操作太大了,需要在几台计算机之间进行拆分,同时仍然可以通过一个通用的GUI随时监控)
软件设计将检查不同的应用程序,它们的技术关系和内部子组件。
它将产生最后一个体系结构层(“技术体系结构”)工作所需的规范(根据技术框架或横向组件),以及项目团队(更面向业务功能的实现)开始各自的项目所需的规范。
架构设计的基本原理来自于各种因素,其中最重要的是非功能性需求,比如可伸缩性,当然最重要的是经验。没有了理论基础,你就只剩下平淡的模式,或者怎么做。无论是在更高的层次上还是在类的层次上,它仍然是设计。
或者换句话说
架构是元设计,即设计设计。您有一些已知的模式适合某个解决方案空间,您会选择哪个,为什么?架构是当你回答“是哪个”和“为什么”时(“如何”已经在设计中给出了)。它当然不依赖于抽象级别,例如实现分布式会话不是一个类级别的任务,但是对于给定的体系结构有一些设计可供选择。
同样,体系结构也反映在类级设计中。在可伸缩的体系结构下,如果不考虑可伸缩性因素,类设计通常是不同的。为什么你必须有一个方法“BeginAsyncUpload”而不是“Upload”是一个架构决策。
有趣的是,当我们将注意力转移到更高层次的系统元素时,“哪个和为什么”问题变得更加重要,而“如何”变得不那么相关。从另一个方向来看,“如何”部分变得更加重要,这也是因为重复使用使得它变得很明显,例如,在抽象工厂和原型之间进行选择。