有人可以解释软件设计和软件架构之间的区别吗？
进一步来说; 如果你告诉别人告诉你"设计" - 你期望他们出现什么？"架构"也是如此.
我目前的理解是:
设计:特定模块/系统部分的UML图/流程图/简单线框(用于UI)
架构:组件图(显示系统的不同模块如何与其他系统和其他系统通信),要使用的语言,模式......？
如我错了请纠正我.我已经提到维基百科有关于http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture的文章,但我不确定我是否正确理解它们.
你是对的.系统的架构是它的"骨架".它是系统的最高抽象级别.存在什么样的数据存储,模块如何相互交互,哪些恢复系统到位.就像设计模式一样,有架构模式:MVC,3层分层设计等.
软件设计是关于设计各个模块/组件.模块x的职责和功能是什么？Y级？它能做什么,不做什么？可以使用哪些设计模式？
简而言之,软件架构更多的是关于整个系统的设计,而软件设计则强调模块/组件/类级别.
在SDLC(软件开发生命周期)的一些描述中,它们是可互换的,但是consesus是它们是不同的.它们同时是:不同的(1)阶段,(2)责任领域,(3)决策水平.
架构是一个更大的图景:框架,语言,范围,目标和高级方法的选择(Rational,瀑布,敏捷等).
设计是一个较小的图景:如何组织代码的计划; 系统不同部分之间的合同将如何看待; 正在实施的项目方法和目标.规范是在此阶段编写的.
出于不同的原因,这两个阶段似乎融合在一起.
较小的项目通常没有足够的空间将计划分为这些阶段.
项目可能是较大项目的一部分,因此两个阶段的部分已经确定.(已有数据库,约定,标准,协议,框架,可重用代码等)
关于SDLC的更新思考方式(参见敏捷方法论)稍微重新排列了这种传统方法.设计(架构在较小程度上)是故意在整个SDLC中进行的.通常会有更多的迭代,整个过程一次又一次地发生.
无论如何,软件开发都很复杂且难以规划,但客户/经理/销售人员通常会在流程中改变目标和要求.无论是否是计划,设计甚至架构决策都必须在项目的后期制定.
即使责任的各个阶段或领域融合在一起并发生在各地,最好知道发生了什么级别的决策.(我们可以永远继续这一点.我正在努力保持它的总结.)我将结束:即使你的项目似乎没有正式的建筑或设计阶段/ AOR/documentaiton,它是否正在发生,无论是否有人有意识地做或不做.如果没有人决定做架构,那么可能会发生一个可能很差的默认架构.同样的设计.如果没有代表它们的正式阶段,这些概念几乎更重要.
建筑是战略性的,而设计是战术性的.
架构包括框架,工具,编程范例,基于组件的软件工程标准,高级原则.
设计是一种涉及局部约束的活动,例如设计模式,编程习语和重构.
我发现这是因为我在寻找建筑和设计之间的简单区别;
您如何看待这种看待它们的方式:
建筑是我们正在建设的"什么";
设计是我们正在建设的"方式";
架构意味着计算机或基于计算机的系统的概念结构和逻辑组织.
设计意味着生成的计划或图纸,用于显示系统或对象在制作之前的外观和功能或工作方式.
如果您正在"构建"组件,那么您将定义它在较大系统中的行为方式.
如果您正在"设计"相同的组件,那么您将定义它在内部的行为方式.
所有架构都是设计,但并非所有设计都是架构.
What部分是设计,How是具体落实和的交集What,并How为架构.
用于区分架构和设计的图像:
还有一些设计决策,这些决策在架构上并不重要,即不属于设计的架构分支.例如,某些组件的内部设计决策,如算法选择,数据结构选择等.
任何在组件边界之外不可见的设计决策都是组件的内部设计,并且是非架构的.这些是系统架构师在模块设计者自行决定或实施团队时留下的设计决策,只要他们的设计不会破坏系统级架构强加的架构限制.
这个链接给出了很好的比喻
用我自己的话说,我说你是对的;
架构是系统要素对系统元素的分配.关于架构的四个陈述:
它可以引入非功能性需求,如语言或模式.
它定义了组件,接口,时序等之间的交互.
它不应该引入新的功能,
它分配系统要对元素执行的(设计)函数.
当系统的复杂性被细分时,架构是必不可少的工程步骤.
示例:想想你的房子,你不需要一个厨房的建筑师(只涉及一个元素),但整个建筑需要一些交互定义,如门和屋顶.
设计是函数(建议)实现的信息表示.它旨在引出反馈并与利益相关者讨论.这可能是一种很好的做法,但不是必不可少的工程步骤.
在厨房安装之前看到厨房设计会很好看,但这对于烹饪要求并不重要:
如果我考虑一下你可以说:
体系结构适用于更详细的抽象级别的公共/工程师
设计适用于不太详细的抽象级别的公共
我的提醒:
我们可以在不问别人的情况下更改设计
如果我们改变架构,我们需要将其传达给某人(团队,客户,利益相关者......)
我认为我们应该使用以下规则来确定我们何时谈论设计与架构:如果您创建的软件图片的元素可以一对一地映射到编程语言语法结构,那么设计,如果不是架构.
因此,例如,如果您看到类图或序列图,则可以使用Class语法结构将类及其关系映射到面向对象的编程语言.这显然是设计.此外,这可能会使讨论与您将用于实现软件系统的编程语言有关.如果使用Java,则前面的示例适用,因为Java是面向对象的编程语言.如果你想出一个显示包及其依赖关系的图表,那也就是Design.您可以将元素(在本例中为包)映射到Java语法结构.
现在,假设您的Java应用程序分为模块,并且每个模块都是一组包(表示为jar文件部署单元),并且您将看到包含模块及其依赖关系的图表,然后是架构.在Java中(至少在Java 7之前)没有办法将模块(一组包)映射到语法结构.您可能还注意到,此图表示软件模型的抽象级别更高一级.上面的任何图表(粗粒度比)包图,表示使用Java编程语言进行开发时的架构视图.另一方面,如果您使用Modula-2进行开发,则模块图表示设计.
(来自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段)
我个人喜欢这个:
"设计师关注当用户按下按钮时会发生什么,而建筑师关心当一万个用户按下按钮时会发生什么."
Mark Cade和Humphrey Sheil撰写的 SCEA for Java™EE学习指南
我同意许多解释; 基本上我们认识到架构设计和软件系统的详细设计之间的区别.
虽然设计师的目标是在规范中尽可能精确和具体,但对于开发来说是必要的; 架构师本质上旨在指定系统的结构和全局行为,与开始详细设计所需的一样多.
一个好的架构师会阻止超规范 - 架构不能过度指定,只是足够,(架构)决策只建立在处理成本最高风险的方面,并有效地提供一个框架("共性"),其中可以对详细设计进行处理,即本地功能的可变性.
实际上,架构流程或生命周期恰好遵循这一主题 - 足够的抽象层次来概述(架构上)重要业务需求的结构,并将更多细节留给设计阶段以获得更具体的可交付成果.
架构是设计,但并非所有设计都是建筑.因此,严格地说,尝试区分建筑设计和非建筑设计会更有意义.有什么区别？这取决于!每个软件架构师可能有不同的答案(ymmv!).我们开发启发式算法来提出答案,例如"类图是架构和序列图是设计'.有关更多信息,请参阅DSA书.
通常认为架构处于比设计更高的抽象级别,或者架构是逻辑的,而设计是物理的.但是这个概念虽然被普遍接受,却在实践中毫无用处.你在哪里绘制高或低抽象之间,逻辑和物理之间的界限？这取决于!
所以,我的建议是:
创建单个设计文档.
按照您想要的方式命名此设计文档,或者更好地说明读者更习惯的方式.示例:"软件架构","软件设计规范".
将此文档分解为视图,请记住,您可以创建视图作为另一个视图的细化.
通过添加交叉引用或超链接使文档中的视图可导航
然后,您将获得更高级别的视图,显示广泛但浅薄的设计概述,以及更接近实现的视图,显示狭窄但更深入的设计细节.
您可能想看一下多视图架构文档的示例(此处).
说了这么多...... 我们需要问的一个更相关的问题是:设计多少就足够了？也就是说,我何时应该停止描述设计(在图表或散文中)并继续编码？
京公网安备 11010802040832号 | 京ICP备19059560号-6 
