Software Design vs. Software Architecture [geschlossen]

342

Könnte jemand den Unterschied zwischen Software-Design und Software-Architektur erklären?

Genauer; Wenn Sie jemandem sagen, er solle Ihnen das „Design“ präsentieren - was würden Sie von ihm erwarten? Gleiches gilt für "Architektur".

Mein derzeitiges Verständnis ist:

  • Design: UML-Diagramm / Flussdiagramm / einfache Drahtmodelle (für die Benutzeroberfläche) für ein bestimmtes Modul / einen bestimmten Teil des Systems
  • Architektur: Komponentendiagramm (zeigt, wie die verschiedenen Module des Systems miteinander und mit anderen Systemen kommunizieren), welche Sprache verwendet werden soll, Muster ...?

Korrigiere mich, wenn ich falsch liege. Ich habe darauf verwiesen, dass Wikipedia Artikel auf http://en.wikipedia.org/wiki/Software_design und http://en.wikipedia.org/wiki/Software_architecture hat, bin mir aber nicht sicher, ob ich sie richtig verstanden habe.

Mads Mobæk
quelle
War eine der folgenden Fragen hilfreich? ;)
Patrick Karcher
Denken Sie daran, dass die Unterscheidung (die sicherlich real ist) bis zu einem gewissen Grad oft aus Anmaßung erfolgt. Kein Architekt kann ohne ein anständiges Verständnis von Design und Konstruktion etwas Gutes sein, und kein Designer kann ohne ein vernünftiges Verständnis von Architektur etwas Gutes sein.
Hot Licks
Und ich habe einmal Architektur gesehen, die als "Design für einen bestimmten Zweck geeignet" beschrieben wurde. Das ist ein wenig banal, aber es enthält ein Nugget an Wahrheit, da gute Architektur letztendlich zweckorientiert und nicht implementierungszentriert sein muss.
Hot Licks

Antworten:

329

Du hast ja recht. Die Architektur eines Systems ist sein "Skelett". Es ist die höchste Abstraktionsebene eines Systems. Welche Art von Datenspeicherung ist vorhanden, wie interagieren Module miteinander, welche Wiederherstellungssysteme sind vorhanden. Genau wie bei Entwurfsmustern gibt es Architekturmuster: MVC, 3-Tier-Layered-Design usw.

Beim Software-Design geht es darum, die einzelnen Module / Komponenten zu entwerfen. Was sind die Verantwortlichkeiten, Funktionen des Moduls x? Von Klasse Y? Was kann es und was nicht? Welche Entwurfsmuster können verwendet werden?

Kurz gesagt, bei der Softwarearchitektur geht es mehr um das Design des gesamten Systems, während sich das Softwaredesign auf die Ebene der Module / Komponenten / Klassen konzentriert.

Razzie
quelle
116
Architektur befasst sich normalerweise auch mit dem, was (getan wird) und wo (es wird getan), aber niemals mit dem Wie. Das heißt, denken Sie, ist der Hauptunterschied - Design vervollständigt das, worüber diese Architektur nicht spricht (und nicht sprechen sollte).
Asaf R
2
Hallo @ AsafR! Das hat mich dazu gebracht, Architektur als Analyse zu betrachten, weil sich die Analyse mit dem befasst, was (getan wird) und das Design mit dem Wie. Denken Sie das?
Chriss
2
Heutzutage entwerfen, implementieren und warten die Backend-Server (wahrscheinlich Cloud-basiert) und das Front-End-Design (Web oder Mobile) alle selbst. Ich denke, sie werden Full-Stack-Entwickler genannt. Recht?
Maziyar
1
Architektur ist der Umriss eines Systems, einer Struktur, einer Blaupause für das Ganze. Design ist nur die Aktivität, einen Plan zu erstellen. Sie können eine Architektur entwerfen, Sie können ein Modul entwerfen, Sie können sogar eine Methode entwerfen.
Evan Hu
2
Das liegt daran, dass MVC ein architektonisches Design ist. MVC gibt keine Details an sich an. Die "Ansicht" kann eine Website, eine Winform, eine Konsolenanwendung sein. Das Modell kann fast alles sein, es gibt nichts darüber an, woher es kommt (Datenbankebene oder was auch immer).
Razzie
80

In einigen Beschreibungen des SDLC (Software Development Life Cycle) sind sie austauschbar, aber der Konsens ist, dass sie unterschiedlich sind. Sie sind gleichzeitig: verschiedene (1) Phasen , (2) Verantwortungsbereiche und (3) Entscheidungsebenen .

  • Architektur ist das Gesamtbild: die Auswahl von Frameworks, Sprachen, Umfang, Zielen und Methoden auf hoher Ebene ( Rational , Wasserfall , Agilität usw.).
  • Design ist das kleinere Bild: der Plan, wie Code organisiert wird; wie die Verträge zwischen verschiedenen Teilen des Systems aussehen werden; die fortlaufende Umsetzung der Methoden und Ziele des Projekts. Die Spezifikationen werden in dieser Phase geschrieben.

Diese beiden Phasen scheinen aus verschiedenen Gründen miteinander zu verschmelzen.

  1. Kleinere Projekte haben oft nicht genug Spielraum, um die Planung in Phasen zu unterteilen.
  2. Ein Projekt kann Teil eines größeren Projekts sein, und daher sind Teile beider Phasen bereits entschieden. (Es gibt bereits vorhandene Datenbanken, Konventionen, Standards, Protokolle, Frameworks, wiederverwendbaren Code usw.)
  3. Neuere Denkweisen über die SDLC (siehe Agile Methoden ) ordnen diesen traditionellen Ansatz etwas neu. Design (in geringerem Maße Architektur) findet im gesamten SDLC statt absichtlich . Es gibt oft mehr Iterationen, bei denen der gesamte Prozess immer wieder abläuft.
  4. Die Softwareentwicklung ist ohnehin kompliziert und schwer zu planen, aber Kunden / Manager / Verkäufer erschweren dies normalerweise, indem sie Ziele und Anforderungen im laufenden Betrieb ändern. Design und sogar architektonische Entscheidungen müssen später im Projekt getroffen werden, ob dies der Plan ist oder nicht.

Selbst wenn die Phasen oder Verantwortungsbereiche miteinander verschmelzen und überall stattfinden, ist es immer gut zu wissen, auf welcher Ebene Entscheidungen getroffen werden. (Wir könnten ewig so weitermachen. Ich versuche, eine Zusammenfassung zu erstellen.) Ich werde mit folgendem Schluss kommen: Auch wenn es so aussieht, als ob Ihr Projekt keine formale Architektur- oder Entwurfsphase / AOR / Dokumentation hat, passiert es, ob es jemand ist bewusst tun oder nicht. Wenn sich niemand für Architektur entscheidet, passiert ein Standard, der wahrscheinlich schlecht ist. Das Gleiche gilt für das Design. Diese Konzepte sind fast wichtiger, wenn es keine formalen Stufen gibt, die sie repräsentieren.

Patrick Karcher
quelle
Gute Antwort. Ich mag die Betonung, wie das eine Teil des anderen zu sein scheint . Der vierte Punkt wirft eine interessante Frage auf: Ist Design in einem bestimmten Problembereich weniger gültig, wenn es noch keine Architektur gibt, in der es existieren kann? Die Erfahrung würde ja vorschlagen, aber theoretisch würde ich gerne denken, dass ein Design, das im angemessenen Rahmen bleibt (dh für eine bestimmte Komponente), gleichermaßen gültig sein sollte, unabhängig davon, wie es letztendlich verwendet wird.
Tom W
55

Architektur ist strategisch, während Design taktisch ist.

Die Architektur umfasst die Frameworks, Tools, Programmierparadigmen, komponentenbasierten Software-Engineering-Standards und Prinzipien auf hoher Ebene.

Während Design eine Aktivität ist, die sich mit lokalen Einschränkungen wie Entwurfsmustern, Programmiersprachen und Refactorings befasst.

Chris Kannon
quelle
Ich möchte weniger Verweise auf "Design" und "Architektur" in der Definition von "Design", um dies abzustimmen ...
Peter Hansen
1
Einverstanden .. es vielleicht: Architektur umfasst die Frameworks, Tools, Programmierparadigmen, komponentenbasierten Software-Engineering-Standards, Prinzipien auf hoher Ebene. Während Design eine Aktivität ist, die sich mit lokalen Einschränkungen wie Entwurfsmustern, Programmiersprachen und Refactorings befasst.
Chris Kannon
38

Ich fand dies, als ich selbst nach einer einfachen Unterscheidung zwischen Architektur und Design suchte;
Was halten Sie von dieser Sichtweise:

  • Architektur ist "was" wir bauen;
  • Design ist "wie" wir bauen;
George S.
quelle
4
Was wir bauen, sind die Anforderungen des Kunden. Wie wir es bauen, hängt sowohl von der Architektur als auch vom Design ab. Also nein, das ist völlig falsch.
Marek
1
@Marek Ich verstehe nicht, was daran falsch ist. Architektur ist das, was erstellt werden soll, was der Client möchte, wie es im Allgemeinen aussehen soll, aus welchen Komponenten es bestehen soll usw. Design ist, wie diese Dinge dann tatsächlich hergestellt werden: Die tatsächlichen Implementierungen von Komponenten, Algorithmen usw.
RecursiveExceptionException
21
  1. Architektur bedeutet die konzeptionelle Struktur und logische Organisation eines Computers oder eines computergestützten Systems.

    Design bedeutet einen Plan oder eine Zeichnung, die erstellt wurde, um das Aussehen und die Funktion oder Funktionsweise eines Systems oder eines Objekts zu zeigen, bevor es erstellt wird.

  2. Wenn Sie eine Komponente „architektonisieren“, definieren Sie, wie sie sich im größeren System verhält.

    Wenn Sie dieselbe Komponente „entwerfen“, definieren Sie, wie sie sich intern verhält.

Alle Architektur ist Design, aber NICHT alles Design ist Architektur.

WhatTeil ist das Design, das Howist die konkrete Umsetzung und der Schnittpunkt von Whatund Howist Architektur.

Bild zur Unterscheidung von Architektur und Design :

Design gegen Architektur

Es gibt auch Entwurfsentscheidungen, die architektonisch nicht bedeutsam sind, dh nicht zum Architekturzweig des Entwurfs gehören. Zum Beispiel die internen Entwurfsentscheidungen einiger Komponenten, wie die Auswahl des Algorithmus, die Auswahl der Datenstruktur usw.

Jede Entwurfsentscheidung, die außerhalb ihrer Komponentengrenze nicht sichtbar ist, ist der interne Entwurf einer Komponente und nicht architektonisch. Dies sind die Entwurfsentscheidungen, die ein Systemarchitekt nach Ermessen des Moduldesigners oder des Implementierungsteams treffen würde, solange sein Entwurf nicht die durch die Architektur auf Systemebene auferlegten architektonischen Einschränkungen verletzt.

Der Link, der eine gute Analogie gibt

TryinHard
quelle
Diese Antwort gefällt mir nicht. Architektur ist die höchste Abstraktionsebene, daher sollten Sie sich nicht darum kümmern, wie es gemacht wird. Ich stimme zu, dass Design und Architektur irgendwie miteinander verbunden sind - Design ist eine Aktivität, die einen Teil der Architektur eines Systems erstellt, aber ich würde nicht sagen, was und wie Architektur ist, weil sie sehr verwirrend ist ...
Martin Čuka
15

Ich würde sagen, Sie haben Recht, in meinen eigenen Worten;

Architektur ist die Zuordnung von Systemanforderungen zu Systemelementen. Vier Aussagen zu einer Architektur:

  1. Es kann nicht funktionale Anforderungen wie Sprache oder Muster einführen.
  2. Es definiert die Interaktion zwischen Komponenten, Schnittstellen, Timing usw.
  3. Es soll keine neue Funktionalität einführen,
  4. Es ordnet die (entworfenen) Funktionen, die das System ausführen soll, Elementen zu.

Architektur ist ein wesentlicher technischer Schritt wenn eine Komplexität des Systems unterteilt wird.

Beispiel: Denken Sie an Ihr Haus. Sie benötigen keinen Architekten für Ihre Küche (nur ein Element), aber das gesamte Gebäude benötigt einige Interaktionsdefinitionen wie Türen und ein Dach .

Design ist eine informative Darstellung der (vorgeschlagenen) Implementierung der Funktion. Es soll Feedback einholen und mit Stakeholdern diskutieren. Dies ist möglicherweise eine gute Praxis, aber kein wesentlicher technischer Schritt .

Es wäre schön, das Küchendesign zu sehen, bevor die Küche installiert wird, aber es ist nicht wesentlich für die Kochanforderung :

Wenn ich darüber nachdenke, können Sie sagen:

  • Architektur ist für eine Öffentlichkeit / Ingenieure auf einer detaillierteren Abstraktionsebene
  • Design ist für die Öffentlichkeit auf einer weniger detaillierten Abstraktionsebene gedacht
user662182
quelle
+1 für Architektur ist die Zuordnung von Systemanforderungen zu Systemelementen. Virtuelle -1 zur Verwendung des Wortes 'a' in der endgültigen Liste. Ich gehe davon aus, dass Ihre (richtige) ursprüngliche Definition das Gegenteil von Abstraktion ist.
Chris Walton
Ich bin mir bei den Punkten 1 und 3 nicht sicher. Nichts sollte mehr Funktionen einführen, als zur Erfüllung der Anforderungen der Stakeholder erforderlich sind. Einschränkungen sind eher ein methodisches Problem. Die anderen Punkte sind hilfreich. Die Küchenanalogie ist nicht großartig; Sie brauchen keinen Architekten, aber das Küchendesign ist ein ziemlich spezialisiertes Gebiet, in dem etwas mit etwas modularen Komponenten entworfen wird. Ich kann nicht damit einverstanden sein, dass Design kein wesentlicher technischer Schritt ist. Ich bin mir nicht sicher, was die letzten beiden Punkte bedeuten.
Mike G
Wo passt die Implementierung hin? Ist die Implementierung nicht das Design?
Jwilleke
14

Meine Erinnerung:

  • Wir können das Design ändern, ohne jemanden zu fragen
  • Wenn wir die Architektur ändern, müssen wir sie jemandem (Team, Kunde, Stakeholder, ...) mitteilen.
Peter Gfader
quelle
6

Ich denke, wir sollten die folgende Regel verwenden, um zu bestimmen, wann wir über Design vs. Architektur sprechen: Wenn die Elemente eines von Ihnen erstellten Softwarebildes eins zu eins einer syntaktischen Konstruktion in einer Programmiersprache zugeordnet werden können, dann ist Design, wenn nicht Architektur.

Wenn Sie beispielsweise ein Klassendiagramm oder ein Sequenzdiagramm sehen, können Sie eine Klasse und ihre Beziehungen mithilfe der syntaktischen Konstruktion der Klasse einer objektorientierten Programmiersprache zuordnen. Das ist eindeutig Design. Darüber hinaus könnte dies dazu führen, dass diese Diskussion einen Bezug zu der Programmiersprache hat, die Sie zum Implementieren eines Softwaresystems verwenden. Wenn Sie Java verwenden, gilt das vorherige Beispiel, da Java eine objektorientierte Programmiersprache ist. Wenn Sie ein Diagramm erstellen, das Pakete und ihre Abhängigkeiten zeigt, ist dies auch Design. Sie können das Element (in diesem Fall ein Paket) einer syntaktischen Java-Konstruktion zuordnen.

Angenommen, Ihre Java-Anwendung ist in Module unterteilt, und jedes Modul besteht aus einer Reihe von Paketen (dargestellt als JAR-Datei-Bereitstellungseinheit). Anschließend wird ein Diagramm mit Modulen und ihren Abhängigkeiten angezeigt, dh Architektur. In Java gibt es keine Möglichkeit (zumindest nicht bis Java 7), ein Modul (eine Reihe von Paketen) einer syntaktischen Konstruktion zuzuordnen. Möglicherweise stellen Sie auch fest, dass dieses Diagramm einen höheren Abstraktionsgrad Ihres Softwaremodells darstellt. Jedes Diagramm über (grobkörniger als) einem Paketdiagramm stellt eine Architekturansicht dar, wenn es in der Programmiersprache Java entwickelt wird. Wenn Sie dagegen in Modula-2 entwickeln, repräsentiert ein Moduldiagramm ein Design.

(Ein Fragment von http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Enrique Molinari
quelle
Ich mag es sehr. Guter Beitrag. Ich bin mir nicht sicher, ob es so eindeutig ist, aber bei einer Frage wie dieser ist es ungefähr so ​​endgültig, wie Sie es bekommen werden. Ich würde dich wählen, aber ich habe keine Stimmen mehr für den Tag :(.
Mike G
5

Persönlich mag ich dieses:

"Der Designer befasst sich mit dem, was passiert, wenn ein Benutzer einen Knopf drückt, und der Architekt befasst sich mit dem, was passiert, wenn zehntausend Benutzer einen Knopf drücken."

SCEA for Java ™ EE-Studienhandbuch von Mark Cade und Humphrey Sheil

Tavi
quelle
Selbst wenn ich dieses Buch mehr als zweimal gelesen habe, macht diese Definition nach dem Lesen aller obigen Kommentare für mich keinen Sinn. Dies ist der Grund: Der Designer-Teil klingt gut, da Sie sich um jedes einzelne Detail kümmern, um sicherzustellen, dass die Schaltfläche das tut, was sie erwartet. Aber im Architektenteil geht es nicht um die Interaktion der Module oder das Gesamtbild, sondern um Leistung und ähnliches. Glaubst du, ich habe etwas aus dieser Definition falsch verstanden?
Rene Enriquez
5

Ich stimme vielen Erklärungen zu; Im Wesentlichen erkennen wir den Unterschied zwischen dem architektonischen Design und dem detaillierten Design der Softwaresysteme.

Während das Ziel des Designers darin besteht, die Spezifikationen so präzise und konkret zu gestalten, wie es für die Entwicklung erforderlich ist; Der Architekt zielt im Wesentlichen darauf ab, die Struktur und das globale Verhalten des Systems so genau zu spezifizieren, wie es für den detaillierten Entwurf erforderlich ist.

Ein guter Architekt wird Hyperspezifikationen verhindern - die Architektur darf nicht übermäßig spezifiziert werden, sondern nur genug, um die (architektonischen) Entscheidungen nur für die Aspekte zu treffen, die die teuersten Risiken darstellen, und um effektiv einen Rahmen ("Gemeinsamkeit") bereitzustellen, innerhalb dessen die Es kann an einem detaillierten Design gearbeitet werden, dh an der Variabilität der lokalen Funktionalität.

In der Tat folgt der Architekturprozess oder Lebenszyklus nur diesem Thema - eine angemessene Abstraktionsebene, um die Struktur für die (architektonisch) signifikanten Geschäftsanforderungen zu skizzieren und mehr Details der Entwurfsphase für konkretere Ergebnisse zu überlassen.

Ajay Shendye
quelle
5

Architektur ist Design, aber nicht alles Design ist Architektur. Streng genommen wäre es daher sinnvoller, zwischen architektonischem und nicht-architektonischem Design zu unterscheiden . Und was ist der Unterschied? Es hängt davon ab, ob! Jeder Softwarearchitekt kann eine andere Antwort haben (ymmv!). Wir entwickeln unsere Heuristiken, um eine Antwort zu finden, z. B. "Klassendiagramme sind Architektur und Sequenzdiagramme sind Design". Weitere Informationen finden Sie im DSA-Buch .

Es ist üblich zu sagen, dass Architektur auf einer höheren Abstraktionsebene liegt als Design, oder Architektur ist logisch und Design ist physisch. Aber dieser Begriff, obwohl allgemein akzeptiert, ist in der Praxis nutzlos. Wo ziehen Sie die Grenze zwischen hoher oder niedriger Abstraktion, zwischen logischer und physischer? Es hängt davon ab, ob!

Mein Vorschlag lautet also:

  • Erstellen Sie ein einzelnes Designdokument.
  • Benennen Sie dieses Designdokument so, wie Sie es möchten, oder besser so, wie es die Leser gewohnt sind. Beispiele: "Software-Architektur", "Software-Design-Spezifikation".
  • Teilen Sie dieses Dokument in Ansichten auf und denken Sie daran, dass Sie eine Ansicht als Verfeinerung einer anderen Ansicht erstellen können.
  • Machen Sie die Ansichten im Dokument navigierbar, indem Sie Querverweise oder Hyperlinks hinzufügen
  • Dann haben Sie übergeordnete Ansichten mit einem breiten, aber flachen Überblick über das Design und Ansichten, die näher an der Implementierung liegen und enge, aber tiefere Designdetails zeigen.
  • Vielleicht möchten Sie sich ein Beispiel für ein Architekturdokument mit mehreren Ansichten ansehen ( hier ).

Abgesehen davon ... ist eine relevantere Frage, die wir stellen müssen: Wie viel Design ist genug? Das heißt, wann sollte ich aufhören, das Design zu beschreiben (in Diagrammen oder Prosa) und mit der Codierung fortfahren?

Paulo Merson
quelle
1
Obwohl ich der ursprünglichen Definition zustimme, wäre es schön, die Quelle hinzuzufügen: "Paul Clements, Dokumentation von Softwarearchitekturen: Ansichten und darüber hinaus". Zu Ihrer letzten Frage: Sie hören nie auf zu entwerfen. Darauf versucht Clements in dem Buch, auf das verwiesen wird, hinzuweisen. Jeder Entwickler, der an dem System arbeitet, wird einen Teil davon entwerfen , aber die meisten dieser Entwürfe sind für die Architektur nicht relevant. Wenn Sie über die Softwarearchitektur sprechen oder diese dokumentieren möchten, hören Sie daher auf, sobald Sie Teile besprechen, die nicht mehr relevant sind.
Thomas Eizinger
1
@ ThomasEizinger. Ich habe einen Link zu unserem Buch hinzugefügt. Guter Vorschlag. Und Ihr Kommentar hilft auch dabei, die richtige Anerkennung zu geben. In Bezug auf die letzte Frage wollte ich mich auf den Aufwand für die Konstruktionsdokumentation beziehen. Ich habe den Absatz bearbeitet. Vielen Dank!
Paulo Merson
3

Ja, das klingt für mich richtig. Das Design ist das, was Sie tun werden, und Architektur ist die Art und Weise, wie die Teile des Designs miteinander verbunden werden. Es könnte sprachunabhängig sein, würde aber normalerweise die zu verwendenden Technologien angeben, z. B. LAMP v Windows, Web Service v RPC.

MrTelly
quelle
3

Die Softwarearchitektur eines Programms oder Computersystems ist die Struktur oder Strukturen des Systems, die Softwarekomponenten, die von außen sichtbaren Eigenschaften dieser Komponenten und die Beziehungen zwischen ihnen umfassen.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

Software-Design ist ein Prozess zur Problemlösung und Planung einer Softwarelösung. Nachdem der Zweck und die Spezifikationen der Software festgelegt wurden, entwerfen oder beschäftigen Softwareentwickler Designer, um einen Plan für eine Lösung zu entwickeln. Es enthält Probleme bei der Implementierung von Komponenten und Algorithmen auf niedriger Ebene sowie die Architekturansicht.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Hätte ich nicht besser sagen können :)

Larry Watanabe
quelle
3

Ich betrachte Architektur wie Patrick Karcher - das große Ganze. Sie können beispielsweise die Architektur eines Gebäudes bereitstellen, die strukturelle Unterstützung, die Fenster, Ein- und Ausgänge, die Wasserableitung usw. anzeigen. Sie haben jedoch die Grundrisse, Kabinenpositionen usw. nicht "entworfen".

Während Sie das Gebäude entworfen haben, haben Sie nicht das Layout jedes Büros entworfen. Ich denke, dasselbe gilt für Software.

Sie können das Entwerfen des Layouts jedoch als "Architektur des Layouts" anzeigen ...

mr-sk
quelle
3

Gute Frage ... Obwohl die Linie zwischen ihnen kaum eine helle, scharfe Linie ist, umfasst Architektur, wenn Sie beide Begriffe verwenden, eher technische oder strukturelle Entscheidungen darüber, wie etwas gebaut oder konstruiert werden soll, insbesondere solche Entscheidungen, die schwierig sein werden ( oder schwieriger) zu ändern, sobald sie implementiert sind, während Design diejenigen Entscheidungen umfasst, die entweder später leicht zu ändern sind (wie Methodennamen, Organisationsstruktur der Klassendatei, Entwurfsmuster, ob ein Singleton oder eine statische Klasse zur Lösung eines bestimmten Problems verwendet werden soll) usw.) und / oder solche, die das Erscheinungsbild oder die ästhetischen Aspekte eines Systems oder einer Anwendung beeinflussen (Benutzeroberfläche, Benutzerfreundlichkeit, Erscheinungsbild usw.)

Charles Bretana
quelle
3

Software - Architektur ist „mit Fragen besorgt ... über die Algorithmen und Datenstrukturen der Berechnung.

Bei Architektur geht es speziell nicht um… Details von Implementierungen (z. B. Algorithmen und Datenstrukturen). Architekturdesign umfasst eine umfangreichere Sammlung von Abstraktionen als dies normalerweise bei OOD der Fall ist “(objektorientiertes Design).

Design befasst sich mit der Modularisierung und den detaillierten Schnittstellen der Designelemente, ihren Algorithmen und Verfahren sowie den Datentypen, die zur Unterstützung der Architektur und zur Erfüllung der Anforderungen erforderlich sind.

"Architektur" wird oft nur als Synonym für "Design" verwendet (manchmal mit dem Adjektiv "High-Level"). Und viele Menschen verwenden den Begriff „Architekturmuster“ als Synonym für „Designmuster“.

Schauen Sie sich diesen Link an.

Definieren der Begriffe Architektur, Design und Implementierung

Tebo
quelle
3

Architektur:
Strukturentwurfsarbeiten auf höheren Abstraktionsebenen, die technisch signifikante Anforderungen an das System realisieren. Die Architektur legt den Grundstein für die weitere Gestaltung.

Design:
Die Kunst, das, was die Architektur nicht tut, durch einen iterativen Prozess auf jeder Abstraktionsebene auszufüllen.

Joshua Ramirez
quelle
3

Ich mochte dieses Papier wirklich als Faustregel für die Trennung von Architektur und Design:

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

Es heißt die Intension / Locality-Hypothese. Aussagen über die Art der Software, die nicht lokal und intensiv sind, sind architektonisch. Lokale und intensive Aussagen sind Design.

LindsayBradford
quelle
Ja genau. Das sind die gleichen Ideen (von denselben Autoren), die ich oben vorgeschlagen habe. Ich denke, das sind hilfreiche Ideen in diesem Bereich.
Eoin
3

... vor langer Zeit an einem weit entfernten Ort machten sich Philosophen Sorgen um die Unterscheidung zwischen dem einen und den vielen. In der Architektur geht es um Beziehungen, die viele erfordern. Architektur hat Komponenten. Beim Design geht es um Inhalte, die den einen erfordern. Design hat Eigenschaften, Qualitäten, Eigenschaften. Wir denken normalerweise, dass Design innerhalb der Architektur liegt. Dualistisches Denken gibt die Vielen als ursprünglich. Architektur gehört aber auch zum Design. Es ist alles, wie wir uns entscheiden, das zu sehen, was vor uns liegt - das eine oder die vielen.

Buzzcoda
quelle
Ich mag diese Antwort nur wegen dieses Satzes "Aber Architektur gehört auch zum Design." Ich würde sagen, dass "Architektur im Design liegen kann". - Es liegt an dir. Sie sind nicht getrennt.
Miroslav Trninic
3

Ziemlich subjektiv, aber meine Meinung:

Die Architektur Das Gesamtdesign des Systems, einschließlich Interaktionen mit anderen Systemen, Hardwareanforderungen, Gesamtkomponenten-Design und Datenfluss.

Design Die Organisation und der Ablauf einer Komponente im Gesamtsystem. Dies würde auch die API der Komponente für die Interaktion mit anderen Komponenten einschließen.

Jesse Vogt
quelle
2

Die Softwarearchitektur wird am besten auf Systemebene verwendet, wenn Sie das Geschäft und die Funktionen, die durch höhere Architekturebenen identifiziert werden, in Anwendungen projizieren müssen.

In Ihrem Unternehmen geht es beispielsweise um "Gewinn und Verlust" für Händler, und Ihre Hauptfunktionen umfassen "Portfolio-Bewertung" und "Risikoberechnung".

Aber wenn ein Software-Architekt seine Lösung detailliert beschreibt, wird er Folgendes feststellen:

"Portfolio-Bewertung" kann nicht nur eine Anwendung sein. Es muss in überschaubaren Projekten wie:

  • GUI
  • Startprogramm
  • Dispatcher
  • ...

(Da die damit verbundenen Vorgänge so umfangreich sind, müssen sie auf mehrere Computer aufgeteilt werden, während sie jederzeit über eine gemeinsame Benutzeroberfläche überwacht werden.)

Ein Software-Design untersucht die verschiedenen Anwendungen, ihre technische Beziehung und ihre internen Unterkomponenten.
Es werden die Spezifikationen erstellt, die für die letzte Architekturschicht (die "Technische Architektur") erforderlich sind (in Bezug auf technische Rahmenbedingungen oder transversale Komponenten) und für den Beginn der Projektteams (stärker auf die Implementierung der Geschäftsfunktionen ausgerichtet ) ihre jeweiligen Projekte.

VonC
quelle
2

Wenn jemand ein Schiff baut, sind Motor, Rumpf, Stromkreise usw. seine "architektonischen Elemente". Der Motorenbau wird für ihn "Konstruktionsarbeit" sein.

Wenn er dann den Aufbau des Motors an ein anderes Team delegiert, wird eine "Motorarchitektur" erstellt ...

Also - es kommt auf die Ebene der Abstraktion oder des Details an. Die Architektur einer Person könnte das Design einer anderen Person sein!

Gernot Starke
quelle
2

Architektur sind "die Entwurfsentscheidungen, die schwer zu ändern sind".

Nachdem ich mit TDD gearbeitet habe, was praktisch bedeutet, dass sich Ihr Design ständig ändert, hatte ich oft Probleme mit dieser Frage. Die obige Definition wurde aus Patterns of Enterprise Application Architecture extrahiert von Martin Fowler

Dies bedeutet, dass die Architektur von der Sprache, dem Framework und der Domäne Ihres Systems abhängt. Wenn Sie in 5 Minuten nur eine Schnittstelle aus Ihrer Java-Klasse extrahieren können, ist dies keine Entscheidung mehr für die Architektur.

ekeren
quelle
1

Cliff Notes Version:

Design: Implementierung einer Lösung basierend auf den Spezifikationen des gewünschten Produkts.

Architektur: Die Grundlage / Tools / Infrastruktur / Komponenten, die Ihr Design unterstützen.

Dies ist eine ziemlich breite Frage, die viele Antworten hervorrufen wird.

Ta01
quelle
1

Architektur ist die resultierende Sammlung von Entwurfsmustern zum Aufbau eines Systems.

Ich denke, Design ist die Kreativität, die verwendet wird, um all dies zusammenzustellen?

Mark Redman
quelle
Ich muss nicht zustimmen. Es scheint, dass Sie (wie ich und die meisten anderen Antworten) die Architektur auf ein "großes Bild" setzen, während es beim Design mehr um Methoden und Problemlösungen geht. Aber wenn Ihre Architektur das ist, was aus den Entwurfsmustern "resultiert", haben Sie sie nicht wirklich entworfen, sondern sie einfach wachsen lassen!
Javier
... es sei denn, Sie haben es nicht einfach wachsen lassen, das heißt :-) Es erfordert etwas Wissen und Erfahrung, um die Kreativität zu haben, die verfügbaren Techniken zu verwenden, um eine elegante Architektur zu schaffen. ... es ist offensichtlich zu subjektiv, um etwas Bestimmtes zu finden ... aber ja, Sie haben Recht, wenn man bedenkt, dass es einige schlechte Systeme ohne Gesamtsystemdesigns (Architekturen) gibt
Mark Redman
1

Software-Design hat eine längere Geschichte, während der Begriff Software-Architektur kaum 20 Jahre alt ist. Daher leidet es gerade unter wachsenden Schmerzen.

Akademiker neigen dazu, Architektur als Teil des größeren Bereichs des Software-Designs zu betrachten. Obwohl zunehmend anerkannt wird, dass Arch ein eigenes Feld ist.

Praktiker neigen dazu, Arch als Entwurfsentscheidungen auf hoher Ebene zu betrachten, die strategisch sind und deren Rückgängigmachung in einem Projekt kostspielig sein kann.

Die genaue Linie zwischen Arch und Design hängt von der Software-Domäne ab. Beispielsweise gewinnt im Bereich der Webanwendungen die Schichtarchitektur derzeit am meisten an Beliebtheit (Biz-Logikschicht, Datenzugriffsschicht usw.). Die untergeordneten Teile dieses Bogens werden als Entwurf betrachtet (Klassendiagramme, Methodensignaturen usw.). ) Dies würde in den Bereichen eingebettete Systeme, Betriebssysteme, Compiler usw. unterschiedlich definiert.

LeWoody
quelle
1

Architektur ist ein hohes, abstraktes und logisches Design, während Software-Design ein detailliertes und physisches Design auf niedriger Ebene ist.

imran
quelle
1

Ich mag Roy Thomas Fieldings Definition und Erklärung der Softwarearchitektur in seinem Artikel: Architekturstile und das Design netzwerkbasierter Softwarearchitekturen

Eine Softwarearchitektur ist eine Abstraktion der Laufzeitelemente eines Softwaresystems während einer bestimmten Phase seines Betriebs. Ein System kann aus vielen Abstraktionsebenen und vielen Betriebsphasen mit jeweils einer eigenen Softwarearchitektur bestehen.

Er betont "Laufzeitelemente" und "Abstraktionsebenen".

Jacky
quelle
Laufzeitelemente, die auch auf Komponenten oder Module der Anwendung bezogen sind, und jedes Modul oder jede Komponente enthalten ihre eigene Abstraktionsebene. Richtig?
Ankit Rana
1

Es gibt keine endgültige Antwort darauf, da "Softwarearchitektur" und "Softwaredesign" eine Reihe von Definitionen haben und es auch keine kanonische Definition gibt.

Eine gute Denkweise ist die Aussage von Len Bass, Paul Clements und Rick Kazman, dass "jede Architektur Design ist, aber nicht alles Design Architektur" [Software Architecture in Practice]. Ich bin mir nicht sicher, ob ich damit einverstanden bin (weil Architektur andere Aktivitäten umfassen kann), aber es erfasst die Essenz, dass Architektur eine Entwurfsaktivität ist, die sich mit der kritischen Teilmenge des Entwurfs befasst.

Meine leicht flippige Definition (auf der Seite mit den SEI-Definitionen) ) lautet, dass es sich um eine Reihe von Entscheidungen handelt, die bei falscher Entscheidung dazu führen, dass Ihr Projekt abgebrochen wird.

Ein nützlicher Versuch, Architektur, Design und Implementierung als Konzepte zu trennen, wurde vor einigen Jahren von Amnon Eden und Rick Kazman in einem Forschungsbericht mit dem Titel "Architektur, Design, Implementierung" unternommen, der hier zu finden ist: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Ihre Sprache ist ziemlich abstrakt, aber vereinfacht gesagt sagen sie, dass Architektur Design ist, das in vielen Kontexten verwendet werden kann und systemweit angewendet werden soll. Design ist (err) Design, das in vielen Kontexten verwendet werden kann, aber in einem bestimmten Teil angewendet wird des Systems und Implementierung ist ein kontextspezifisches Design, das in diesem Kontext angewendet wird.

Eine Architekturentscheidung könnte also eine Entscheidung sein, das System über Messaging anstelle von RPC zu integrieren (es ist also ein allgemeines Prinzip, das an vielen Stellen angewendet werden kann und auf das gesamte System angewendet werden soll). Eine Entwurfsentscheidung könnte darin bestehen, einen Master zu verwenden / Slave-Thread-Struktur im Eingabeanforderungsbehandlungsmodul des Systems (ein allgemeines Prinzip, das überall verwendet werden kann, in diesem Fall jedoch nur in einem Modul verwendet wird) und schließlich könnte eine Implementierungsentscheidung darin bestehen, die Sicherheitsverantwortung vom Anforderungsrouter zu verschieben an den Request Handler im Request Manager-Modul (eine Entscheidung, die nur für diesen Kontext relevant ist und in diesem Kontext verwendet wird).

Ich hoffe das hilft!

Eoin
quelle