有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI)
架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信),要使用什么语言,模式……?
如果我说错了,请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章,但我不确定我是否理解正确。
我认为当我们讨论设计与架构时,我们应该使用下面的规则来确定:如果您创建的软件图的元素可以一一映射到编程语言的语法结构,那么就是设计,如果不是架构。
So, for example, if you are seeing a class diagram or a sequence diagram, you are able to map a class and their relationships to an Object Oriented Programming language using the Class syntactical construction. This is clearly Design. In addition, this might bring to the table that this discussion has a relation with the programming language you will use to implement a software system. If you use Java, the previous example applies, as Java is an Object Oriented Programming Language. If you come up with a diagram that shows packages and its dependencies, that is Design too. You can map the element (a package in this case) to a Java syntactical construction.
Now, suppose your Java application is divided in modules, and each module is a set of packages (represented as a jar file deployment unit), and you are presented with a diagram containing modules and its dependencies, then, that is Architecture. There isn’t a way in Java (at least not until Java 7) to map a module (a set of packages) to a syntactical construction. You might also notice that this diagram represents a step higher in the level of abstraction of your software model. Any diagram above (coarse grained than) a package diagram, represents an Architectural view when developing in the Java programming language. On the other hand, if you are developing in Modula-2, then, a module diagram represents a Design.
(摘自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)
建筑就是设计,但并非所有的设计都是建筑。因此,严格地说,尝试区分架构设计和非架构设计会更有意义。有什么区别呢?视情况而定!每个软件架构师可能有不同的答案(ymmv!)我们开发我们的启发式来提出一个答案,例如“类图是架构,序列图是设计”。有关更多信息,请参阅DSA书籍。
人们常说,架构比设计处于更高的抽象级别,或者架构是逻辑的,而设计是物理的。但这种观念虽然被普遍接受,但在实践中却毫无用处。在高抽象和低抽象之间,逻辑和物理之间,你的界线在哪里?视情况而定!
所以,我的建议是:
create a single design document.
name this design document the way you want or, better, the way the readers are more accustomed to. Examples: "Software Architecture", "Software Design Specification".
break this document into views and keep in mind you can create a view as a refinement of another view.
make the views in the document navigable by adding cross-references or hyperlinks
then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details.
you may want to take a look at an example of multi-view architecture document (here).
说了这么多……我们需要问的一个更相关的问题是:多少设计才足够?也就是说,我什么时候应该停止描述设计(用图表或散文),而应该转向编码?