软件设计与软件架构

时间:2009-04-01 10:00:51

标签: architecture definition

有人可以解释软件设计和软件架构之间的区别吗?

更具体地说;如果你告诉别人告诉你“设计” - 你期望他们出现什么? “架构”也是如此。

我目前的理解是:

  • 设计:特定模块/系统部分的UML图/流程图/简单线框(用于UI)
  • 架构:组件图(显示系统的不同模块如何与其他系统和其他系统通信),要使用的语言,模式......?

如果我错了,请纠正我。我已经提到维基百科有http://en.wikipedia.org/wiki/Software_designhttp://en.wikipedia.org/wiki/Software_architecture的文章,但我不确定我是否理解它们。

41 个答案:

答案 0 :(得分:329)

你是对的。系统的架构是它的“骨架”。它是系统的最高抽象级别。存在什么样的数据存储,模块如何相互交互,哪些恢复系统到位。就像设计模式一样,有架构模式:MVC,3层分层设计等。

软件设计是关于设计各个模块/组件。模块x的职责和功能是什么? Y级?它能做什么,不做什么?可以使用哪些设计模式?

简而言之,软件架构更多的是关于整个系统的设计,而软件设计则强调模块/组件/类级别。

答案 1 :(得分:80)

SDLC (Software Development Life Cycle)的某些描述中,它们是可以互换的,但是consesus是它们是不同的。它们同时是:不同的(1)阶段,(2)责任范围,以及(3)决策水平

  • Architecture是一个更大的图景:框架,语言,范围,目标和高级方法的选择(Rationalwaterfallagile等。 )。
  • Design是较小的图片:如何组织代码的计划;系统不同部分之间的合同将如何看待;正在进行的实施项目的方法和目标。规范是在此阶段编写的。

由于不同的原因,这两个阶段似乎混合在一起。

  1. 较小的项目通常没有足够的空间将计划分为不同阶段。
  2. 项目可能是较大项目的一部分,因此两个阶段的部分已经确定。 (已有数据库,约定,标准,协议,框架,可重用代码等)。
  3. 有关SDLC的更新思考方式(参见Agile methodologies)稍微重新排列了这种传统方法。设计(架构在较小程度上)在整个SDLC 中有意地发生。通常会有更多iterations整个过程一遍又一遍地发生。
  4. 软件开发复杂且难以规划,但客户/经理/销售人员通常会通过改变流程中的目标和要求而变得更加困难。设计甚至架构决策必须在项目的后期制作,无论是否是计划。
  5. 即使责任的各个阶段或领域融合在一起并发生在各地,但总是很高兴知道发生了什么级别的决策。 (我们可以永远继续这一点。我正在努力保持它的总结。)我将结束:即使您的项目似乎没有正式的建筑或设计阶段/ AOR /文档,但无论是否有人,都会发生这种情况。有意识地做或不做。如果没有人决定做架构,那么可能会发生一个可能很差的默认架构。同样的设计。如果没有代表它们的正式阶段,这些概念几乎更重要

答案 2 :(得分:55)

架构是战略性的,而设计是战术性的。

架构包括框架,工具,编程范例,基于组件的软件工程标准,高级原则。

虽然设计是一种与局部约束相关的活动,例如设计模式,编程习惯用法和重构。

答案 3 :(得分:38)

我发现这是因为我在寻找建筑和设计之间的简单区别; 您如何看待这种看待它们的方式:

  • 建筑是我们正在建造的“什么”;
  • 设计是我们正在建设的“方式”;

答案 4 :(得分:21)

  1. 架构是指计算机或基于计算机的系统的概念结构和逻辑组织。

    设计是指制作一个计划或图纸,以显示系统或对象在制作之前的外观和功能或工作方式。

  2. 如果您正在“构建”某个组件,那么您将定义它在较大系统中的行为方式。

    如果您正在“设计”相同的组件,那么您将定义它在内部的行为。

  3.   

    所有架构都是设计,但并非所有设计都是架构。

    What部分是设计,How是具体实现,WhatHow的交集是体系结构。

    区分架构和设计的图像

    Design vs Architecture

    还有一些设计决策,这些决策在架构上并不重要,即不属于设计的架构分支。例如,某些组件的内部设计决策,如 - 算法选择,数据结构选择等。

    任何在组件边界之外不可见的设计决策都是组件的内部设计,并且是非架构的。这些是系统架构师在模块设计人员自行决定或实施团队留下的设计决策,只要他们的设计不会破坏系统级架构所施加的架构限制。

    提供good analogy

    的链接

答案 5 :(得分:15)

我说你是对的,用我自己的话说;

架构是系统要素对系统元素的分配。关于架构的四个陈述:

  1. 它可以引入非功能性要求,如语言或模式。
  2. 它定义了组件,接口,时序等之间的交互。
  3. 它不会引入新功能,
  4. 它分配系统要对元素执行的(设计)函数。
  5. 当系统的复杂性被细分时,架构是必不可少的工程步骤

    示例:想想你的房子,你不需要厨房的建筑师(只涉及一个元素),但整个建筑需要一些交互定义,如门和屋顶。 / p>

    设计是函数(建议)实现的信息表示。它旨在引出反馈并与利益相关者讨论。这可能是一种很好的做法,但不是必不可少的工程步骤

    在厨房安装之前看到厨房设计会很好看,但这对于烹饪要求并不重要

    如果我考虑一下,你可以说:

    • 架构适用于更详细的抽象级别的公共/工程师
    • 设计适用于不太详细的抽象级别的公众

答案 6 :(得分:14)

我的提醒:

  • 我们可以在不问别人的情况下更改设计
  • 如果我们更改架构,我们需要将其传达给某人(团队,客户,利益相关者......)

答案 7 :(得分:6)

我认为我们应该使用以下规则来确定我们何时谈论设计与架构:如果您创建的软件图片的元素可以一对一地映射到编程语言的语法结构,那么就是Design,如果不是架构。

因此,例如,如果您看到类图或序列图,则可以使用Class语法结构将类及其关系映射到面向对象的编程语言。这显然是设计。此外,这可能会使讨论与您将用于实现软件系统的编程语言有关。如果使用Java,则前面的示例适用,因为Java是面向对象的编程语言。如果你想出一个显示包及其依赖关系的图表,那也就是Design。您可以将元素(在本例中为包)映射到Java语法结构。

现在,假设您的Java应用程序被划分为模块,并且每个模块都是一组包(表示为jar文件部署单元),并且您将看到包含模块及其依赖关系的图表,那就是架构。在Java中(至少在Java 7之前)没有办法将模块(一组包)映射到语法结构。您可能还注意到,此图表示软件模型的抽象级别更高一级。上面的任何图表(粗粒度比)包图,表示使用Java编程语言进行开发时的架构视图。另一方面,如果您使用Modula-2进行开发,则模块图表示设计。

(来自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段)

答案 8 :(得分:5)

我同意许多解释;基本上我们认识到架构设计和软件系统的详细设计之间的区别。

虽然设计师的目标是在规范中尽可能精确和具体,因为它对开发是必要的;架构师本质上旨在指定系统的结构和全局行为,就像开始详细设计所需的一样。

一个优秀的架构师会阻止超规范 - 架构不能过分指定,只需要足够,(架构)决策只针对处理成本最高的风险的方面建立,并有效地提供框架(“通用性”)可以在其中处理详细设计,即本地功能的可变性。

实际上,架构流程或生命周期恰好遵循这一主题 - 足够的抽象层次来概述(架构上)重要业务需求的结构,并在设计阶段留下更多细节以获得更具体的可交付成果。

答案 9 :(得分:5)

就个人而言,我喜欢这个:

“设计师关心当用户按下按钮时会发生什么,而建筑师关心当一万个用户按下按钮时会发生什么。”

Mark Cade和Humphrey Sheil的

SCEA for Java™EE学习指南

答案 10 :(得分:5)

架构是设计,但并非所有设计都是架构。因此,严格来说,尝试区分架构设计非更有意义 - 建筑设计。有什么区别?这取决于!每个软件架构师可能有不同的答案(ymmv!)。我们开发启发式算法来提出答案,例如“类图是架构和序列图是设计'。有关详情,请参阅DSA book

通常认为架构处于比设计更高的抽象级别,或者架构是逻辑的,而设计是物理的。但是这个概念虽然被普遍接受,却在实践中毫无用处。你在哪里绘制高或低抽象之间,逻辑和物理之间的界限?这取决于!

所以,我的建议是:

  • 创建单个设计文档。
  • 以您想要的方式命名此设计文档,或者更好地说明读者更习惯的方式。示例:“软件架构”,“软件设计规范”。
  • 将此文档分解为视图,请记住,您可以创建视图作为另一个视图的细化。
  • 通过添加交叉引用或超链接使文档中的视图可导航
  • 然后您将获得更高级别的视图,显示广泛但浅薄的设计概述,以及更接近实现的视图,显示更窄但更深的设计细节。
  • 您可能需要查看多视图架构文档(here)的示例。

说了所有...... 我们需要问的一个更相关的问题是:设计多少就足够了?那就是,我何时应该停止描述设计(在图表或散文中)和应继续编码吗?

答案 11 :(得分:3)

很久以前,在一个遥远的地方,哲学家们担心一个人和许多人之间的区别。建筑是关于关系,这需要很多。架构有组件。设计是关于内容,需要一个。设计具有属性,品质和特征。我们通常认为设计属于架构。二元思维使许多人成为原始人。但架构也在设计之内。这就是我们选择如何看待摆在我们面前的东西 - 一个或多个。

答案 12 :(得分:3)

我真的很喜欢这篇论文,从而将建筑与设计分开:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

它被称为内涵/局部性假设。关于非本地和内部软件性质的陈述是建筑学的。设计本地和内部的陈述。

答案 13 :(得分:3)

<强>架构:
结构设计在更高的抽象层次上工作,从而实现对系统的技术上重要的要求。该架构为进一步的设计奠定了基础。

<强>设计
在每个抽象层通过迭代过程填充体系结构的艺术。

答案 14 :(得分:3)

软件架构“关注的问题......超出了计算的算法和数据结构。

架构特别不是......实现的细节(例如,算法和数据结构)。架构设计涉及比OOD“(面向对象设计)通常提供的更丰富的抽象集合。

设计关注设计元素的模块化和详细界面,它们的算法和程序,以及支持架构和满足要求所需的数据类型。

“架构”通常仅用作“设计”的同义词(有时在形容词“高级”之前)。许多人使用术语“建筑模式”作为“设计模式”的同义词。

查看此链接。

Defining the Terms Architecture, Design, and Implementation

答案 15 :(得分:3)

非常主观,但我的看法是:

<强>建筑 系统的总体设计包括与其他系统的交互,硬件要求,整体组件设计和数据流。

<强>设计 整个系统中组件的组织和流程。这还包括用于与其他组件交互的组件API。

答案 16 :(得分:3)

我认为Patrick Karcher所做的建筑 - 大局。例如,您可以为建筑物提供建筑,查看其结构支撑,窗户,入口和出口,排水等。但您还没有“设计”地板布局,隔间位置等。

因此,当您构建建筑物时,您没有设计每个办公室的布局。 我认为软件也是如此。

您可以查看设计布局,但是“构建布局”虽然......

答案 17 :(得分:3)

程序或计算系统的软件体系结构是系统的结构或结构,其包括软件组件,这些组件的外部可见属性以及它们之间的关系。

(来自维基百科,http://en.wikipedia.org/wiki/Software_architecture

软件设计是解决问题和规划软件解决方案的过程。在确定软件的目的和规范之后,软件开发人员将设计或雇用设计者来制定解决方案的计划。它包括低级组件和算法实现问题以及架构视图。

(来自维基百科,http://en.wikipedia.org/wiki/Software_design

我自己不能说得更好:)。

答案 18 :(得分:3)

好问题......虽然它们之间的界限不是一条明亮的线条,但是如果你同时使用这两个术语,那么架构包含了关于如何构建或构建某些东西的更多技术或结构决策,尤其是那些将会一旦实现就很难(或更难)改变,而设计包含那些以后容易改变的决策(如方法名称,类&lt; - &gt;文件组织结构,设计模式,是否使用单例或静态类解决某些特定问题等)和/或影响系统或应用程序的外观或美学方面的问题(人机界面,易用性,外观和感觉等)

答案 19 :(得分:3)

是的,这对我来说是对的。设计就是你要做的,而建筑是将设计的各个部分连接在一起的方式。它可能与语言无关,但通常会指定要使用的技术,即LAMP v Windows,Web Service v RPC。

答案 20 :(得分:2)

架构“难以改变的设计决策。”

使用TDD后,这实际上意味着你的设计一直在变化,我经常发现自己在努力解决这个问题。上面的定义摘自企业应用程序架构的模式,作者:Martin Fowler

这意味着架构取决于系统的语言,框架和域。如果你可以在5分钟内从Java类中提取一个接口,那么它就不再是架构决策了。

答案 21 :(得分:2)

如果有人建造一艘船,那么发动机,船体,电路等将成为他的“建筑元素”。对他来说,发动机结构将是“设计工作”。

如果他随后将引擎的构造委托给另一个团队,他们将创建一个“引擎架构”......

所以 - 它取决于抽象或细节的级别。一个人的建筑可能是他人的设计!

答案 22 :(得分:2)

当您需要将业务和功能通过更高的架构级别标识到应用程序中时,最好在系统级别使用软件架构。

例如,您的业务是针对交易者的“盈亏”,您的主要职能涉及“投资组合评估”和“风险计算”。

但当Software Architect详述他的解决方案时,他会意识到:

“投资组合评估”不能只是一个应用程序。需要在可管理的项目中进行改进,例如:

  • GUI
  • 启动
  • 分派器
  • ...

(因为涉及的操作非常庞大,需要在多台计算机之间进行拆分,同时仍然通过通用GUI进行监控)

软件设计将检查不同的应用程序,它们的技术关系及其内部子组件 它将生成上一个 Architecture layer (“技术架构”)所需的规范(在技术框架或横向组件方面)以及项目团队(更具针对性)关于业务功能的实施),以开始各自的项目。

答案 23 :(得分:1)

架构是构建系统的最终设计模式集合。

我猜设计是用来把所有这些放在一起的创造力吗?

答案 24 :(得分:1)

答案 25 :(得分:1)

建筑与设计密切相关;它们之间的主要区别在于我们面临的方式。 建筑面向战略,结构和目的,朝向抽象。 设计面向实施和实践,面向具体。

答案 26 :(得分:1)

架构是高级,抽象和逻辑设计,而软件设计是低级,详细和物理设计。

答案 27 :(得分:1)

对此没有明确的答案,因为“软件架构”和“软件设计”有很多定义,而且也没有规范的定义。

一个很好的思考方式是Len Bass,Paul Clements和Rick Kazman所说的“所有架构都是设计但并非所有设计都是架构”[Software Architecture in Practice]。我不确定我是否完全同意(因为架构可以包括其他活动),但它捕获了架构是处理设计的关键子集的设计活动的本质。

我稍微轻率的定义(在SEI definitions page上找到)是这些决定,如果做错了,会导致你的项目被取消。

Amnon Eden和Rick Kazman几年前在题为“建筑,设计,实施”的研究论文中完成了将建筑,设计和实施分离为概念的有益尝试,可在此处找到:http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf。他们的语言相当抽象,但他们简单地说, architecture 是可以在很多环境中使用的设计,并且意味着要在整个系统中应用, design 是(错)设计可以在许多上下文中使用,但是应用于系统的特定部分,实现是特定于上下文的设计,并在该上下文中应用。

因此,架构决策可能是通过消息而不是RPC来集成系统的决定(因此它是可以在许多地方应用并且旨在应用于整个系统的一般原则),设计决策可能是在系统的输入请求处理模块中使用主/从线程结构(可以在任何地方使用的一般原则,但在这种情况下仅在一个模块中使用),最后,实现决策可能是从请求路由器到请求管理器模块中的请求处理程序(仅与该上下文相关的决策,在该上下文中使用)。

我希望这有帮助!

答案 28 :(得分:1)

我喜欢Roy Thomas Fielding关于软件架构的定义和解释: Architectural Styles and the Design of Network-based Software Architectures

  

软件体系结构是软件系统运行时某些阶段的运行时元素的抽象。系统可以由许多抽象级别和许多操作阶段组成,每个操作阶段都有自己的软件体系结构。

他强调“运行时元素”和“抽象层次”。

答案 29 :(得分:1)

Cliff Notes版本:

设计:根据所需产品的规格实施解决方案。

架构:支持您设计的基础/工具/基础架构/组件。

这是一个非常广泛的问题,会引发很多回复。

答案 30 :(得分:1)

软件设计的历史较长,而软件架构这个术语只有20年的历史。因此,它正在经历成长的痛苦。

学术界倾向于将架构视为更大的软件设计领域的一部分。虽然人们越来越认识到Arch是一个独立的领域。

从业者倾向于将Arch视为具有战略意义的高级设计决策,并且在要撤消的项目中成本高昂。

Arch与设计之间的确切界限取决于软件领域。例如,在Web应用程序领域,分层体系结构目前正在获得最流行(Biz Logic Layer,Data Access Layer等)。此Arch的低级部分被认为是设计(类图,方法签名等)。 )这将在嵌入式系统,操作系统,编译器等领域中进行不同的定义。

答案 31 :(得分:1)

设计:要了解模块,模块之间的关系,每个模块的功能,类及其成员函数,每个模块之间相互通信的接口。

架构:架构是软件系统的整个结构。所有模块,类和组件执行不同的任务,并将给出独特的结果。

例如:有一个有5个房间的房子。还有连接浴室。厨房也在家里。所以家里有不同的东西,这些东西彼此之间有不同的关系。所以这就是“设计”的全部内容。一个家。

当你从房子外面看时,你所看到的整个结构都是关于建筑的。

答案 32 :(得分:0)

我认为架构是关于人和/或系统的接口。对于网络服务合同,包括协议等,是架构。如何组成一个屏幕,而不是颜色等,但是有哪些领域是建筑。

设计是如何构建的。什么框架,语言,技术等。当然,这必须与考虑平台,安全性等的企业准则和限制保持一致。

答案 33 :(得分:0)

正如其他人也指出的那样,制定一个软件的体系结构实际上是在做出主要的设计决策,这些决策对软件开发或执行生命周期有着全面的影响;如此简单的架构只是高级设计。

即使架构决策不影响所有组件(因此是本地的),它仍然必须是全局相关的,即它以某种方式影响整个系统;否则只是一个本地设计决定。

我想指出的是,与建筑相关的更相关的问题可能是由Hennessy&amp; Sn定义的建筑与组织。 Patterson在计算机体系结构。基于此,我们可以将架构视为系统和组织的数据模型(输入/输出,状态)抽象,作为实施(软件开发)过程中的典型设计决策。

答案 34 :(得分:0)

架构: - 架构在构造的各个阶段创建计划布局                按照规范。

DESINER: - 一个desiner是一个活动,它满足了结构计划的所有基本要求与功能,asthetectic&amp; amp;对布局的了解。

答案 35 :(得分:0)

架构更像是集成系统的各种功能以实现整个系统的一个目标,而设计则解决了每个功能需求。

例如,以MVVM为例,这是一种架构模式。对于通知功能,MVVM使用观察者模式,而模式又是一种设计模式,

答案 36 :(得分:0)

在我看来,建筑只不过是一个愿景,收集需求并以正确的方式构建构建块

在设计方面,要构建特定的块,可以使用100种解决方案,但为了满足确切的要求,我们需要选择正确的方法,因此选择正确的方法或算法只不过是设计

答案 37 :(得分:0)

架构识别系统的基本组件,描述它们的组织以及它们与为系统创建框架的相关性。

设计描述了各种组件以及如何开发它们以在系统架构提供的框架中提供所需的功能。

答案 38 :(得分:0)

架构设计的基本原理来自各种因素,其中最重要的是非功能性需求,例如可扩展性,当然不是经验。没有理由,你会留下简单的图案,或者怎么做。无论是在更高层次还是在班级设计,它仍然是设计。

或换句话说

架构是元设计,即设计设计。您有一些已知适合某个解决方案空间的模式,您会选择哪个以及为什么?建筑就是当你回答“哪个”和“为什么”时(设计已经给出“如何”)。它当然不依赖于抽象级别,例如,实现分布式会话不是类级别任务,但是有一些设计可以从中选择给定的体系结构。

同样,即使在班级设计中也体现了架构。在可扩展的体系结构下,如果您在没有考虑可伸缩性因素的情况下进行类设计,则通常会有所不同。为什么必须有一个方法“BeginAsyncUpload”与“Upload”是一个架构决策。

有趣的是,随着我们将注意力转向更高层次的系统元素,“哪个和为什么”变得更加重要,“如何”变得不那么重要。向另一个方向移动“如何”部分变得更加重要,也因为重复使用使得很明显,例如,在抽象工厂或原型之间进行选择。

答案 39 :(得分:0)

http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns

该架构告诉您系统的布局方式。一个传统的体系结构模式示例是3层系统,您的系统可以分解为表示层,业务层和数据层。

域驱动设计促进了4层架构。演示文稿,应用程序,域和基础架构层。存储库模式位于域层和基础结构层之间。您的域模型不应该对基础结构有任何了解,也应该保持纯粹且独立于它。这就是为什么我们有存储库来调解这两层。

存储库模式仍然是一种模式,因为它是一种可重用的解决方案,可以处理重复出现的问题。但是,当我们讨论架构时,存储库模式才变得相关。它在域驱动的设计架构中扮演着角色和责任。它不是数学类型的通用解决方案,例如可以应用于系统中任何位置的抽象工厂模式。

答案 40 :(得分:-1)

以下是可以更详细地解释架构的参考资料以及软件架构的UML图表列表。 (我找不到软件设计的UML图表列表)

Grady Booch

UML 2 Diagram use for Architectural Models

Classification of UML diagrams

Classification of UML diagrams

即使在发布这个答案之后,我自己也不清楚哪个图表用于架构,哪个图表用于设计:)。 Grady Booch在他的幻灯片#58中指出,类,接口和协作是设计视图的一部分,这个设计视图是架构视图之一!