design - magazine - news in architecture




Software Design vs. Software Architektur (20)

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

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

Mein derzeitiges Verständnis ist:

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

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


  1. Architektur bedeutet die konzeptionelle Struktur und logische Organisation eines Computers oder eines computerbasierten Systems.

    Design bezeichnet einen Plan oder eine Zeichnung, die erstellt wurden, um das Aussehen und die Funktion oder Funktionsweise eines Systems oder eines Objekts vor der Erstellung anzuzeigen.

  2. Wenn Sie eine Komponente "entwerfen", 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.

What ist das Design, das How ist die konkrete Umsetzung und die Schnittmenge von What und How ist Architektur What

Bild für die Differenzierung von Architektur und Design :

Es gibt auch Designentscheidungen, die nicht architektonisch signifikant sind, also nicht zum Architekturzweig des Designs gehören. Zum Beispiel die internen Designentscheidungen einiger Komponenten, die Auswahl des Algorithmus, die Auswahl der Datenstruktur usw.

Jede Designentscheidung, die außerhalb ihrer Komponentengrenze nicht sichtbar ist, ist das interne Design einer Komponente und ist nicht architektonisch. Dies sind die Designentscheidungen, die ein Systemarchitekt dem Ermessen des Moduldesigners oder dem Implementierungsteam überlassen würde, solange deren Design die architektonischen Einschränkungen der Architektur auf Systemebene nicht verletzt.

Die Verbindung, die gute Analogie gibt


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

Ich denke, Design ist die Kreativität, die all dies zusammenbringt?


Architektur ist strategisch, Design ist taktisch.

Architektur umfasst die Frameworks, Tools, Programmierparadigmen, komponentenbasierte Softwareentwicklungsstandards, High-Level-Prinzipien.

Während Design eine Aktivität ist, die sich mit lokalen Einschränkungen beschäftigt, wie Design-Muster, Programmier-Idiome und Refactorings.


Architektur sind "die Design-Entscheidungen, die schwer zu ändern sind."

Nachdem ich mit TDD gearbeitet habe, was praktisch bedeutet, dass sich dein Design ständig ändert, habe ich mich oft mit dieser Frage herumgeschlagen. Die obige Definition wird von Patterns of Enterprise Application Architecture von Martin Fowler extrahiert

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


Darauf gibt es keine definitive Antwort, denn "Software-Architektur" und "Software-Design" haben eine ganze Reihe von Definitionen, und für beide gibt es keine kanonische Definition.

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

Meine leicht frivole Definition (auf der SEI-Definitionsseite zu finden ) ist, dass es sich um eine Reihe von Entscheidungen handelt, die, wenn sie falsch gemacht werden, dazu führen, dass Ihr Projekt abgebrochen wird.

Ein nützlicher Versuch, Architektur, Design und Implementierung als Konzepte zu trennen, hat Amnon Eden und Rick Kazman vor einigen Jahren in einer Forschungsarbeit mit dem Titel "Architecture, Design, Implementation" gemacht, die hier zu finden ist: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf . Ihre Sprache ist ziemlich abstrakt, aber vereinfachend sagen sie, dass Architektur ein Design ist, das in vielen Kontexten verwendet werden kann und systemübergreifend angewendet werden soll. Design ist (Err) Design, das in vielen Kontexten verwendet werden kann, aber in einem bestimmten Teil angewendet wird des Systems, und die Implementierung ist kontextspezifisch und wird in diesem Kontext angewendet.

Eine architektonische Entscheidung könnte also eine Entscheidung sein, das System über Messaging anstatt über RPC zu integrieren (es ist also ein allgemeines Prinzip, das an vielen Stellen angewendet werden könnte und das auf das gesamte System angewendet werden soll). Eine Designentscheidung könnte die Verwendung eines Masters sein / Slave-Thread-Struktur im Eingabeantragsabwicklungsmodul des Systems (ein allgemeines Prinzip, das überall verwendet werden könnte, aber in diesem Fall nur in einem Modul verwendet wird) und schließlich eine Implementierungsentscheidung könnte sein, Verantwortlichkeiten für die Sicherheit vom Anforderungs-Router 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!


Die Softwarearchitektur "beschäftigt sich mit Fragen ... jenseits der Algorithmen und Datenstrukturen der Berechnung.

Bei der Architektur geht es insbesondere nicht um ... Details von Implementierungen (z. B. Algorithmen und Datenstrukturen). Architektonisches Design beinhaltet eine umfassendere Sammlung von Abstraktionen, als sie normalerweise von OOD bereitgestellt wird ("objektorientiertes Design").

Design befasst sich mit der Modularisierung und den detaillierten Schnittstellen der Entwurfselemente, ihren Algorithmen und Verfahren sowie den Datentypen, die zur Unterstützung der Architektur und zur Erfüllung der Anforderungen benötigt werden.

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

Überprüfen Sie diesen Link.

Definieren der Begriffe Architektur, Design und Implementierung


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

In Ihrem Geschäft geht es zum Beispiel um "Gewinn und Verlust" für Händler, und Ihre Hauptfunktionen umfassten "Portfolio-Bewertung" und "Risiko-Berechnung".

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

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

  • GUI
  • Startprogramm
  • Dispatcher
  • ...

(Da die beteiligten Operationen so groß sind, müssen sie auf mehrere Computer verteilt werden, während sie immer noch über eine gemeinsame GUI überwacht werden)

Ein Softwaredesign wird die verschiedenen Anwendungen, ihre technischen Beziehungen und ihre internen Teilkomponenten untersuchen.
Es werden die Spezifikationen erstellt, die für die letzte Architekturschicht (die "Technische Architektur") erforderlich sind, um daran zu arbeiten (im Sinne eines technischen Rahmens oder transversaler Komponenten) und für die Projektteams (mehr an der Implementierung der Geschäftsfunktionen orientiert ) zu beginnen ihre jeweiligen Projekte.


Du hast recht, ja. 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 Designmuster gibt es architektonische Muster: MVC, 3-Tier-Schichtdesign usw.

Beim Softwaredesign geht es um die Gestaltung der einzelnen Module / Komponenten. Was sind die Verantwortlichkeiten, Funktionen, von Modul x? Von Klasse Y? Was kann es tun und was nicht? Welche Designmuster können verwendet werden?

Kurz gesagt, geht es bei der Software-Architektur mehr um das Design des gesamten Systems, während das Software-Design auf der Ebene von Modulen, Komponenten und Klassen liegt.


Ich betrachte Architektur wie Patrick Karcher - das große Ganze. Zum Beispiel können Sie die Architektur für ein Gebäude bereitstellen, seine strukturelle Unterstützung, die Fenster, Ein- und Ausgänge, Wasserabfluss usw. sehen. Aber Sie haben nicht die Grundriss-, Kabinenpositionen usw. "entworfen".

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

Sie könnten das Design des Layouts sehen, als "das Layout erstellen" aber ...


Ich denke, wir sollten die folgende Regel verwenden, um zu bestimmen, wann wir über Design vs. Architecture sprechen: Wenn die Elemente eines von Ihnen erstellten Softwarebildes einer syntaktischen Konstruktion einer Programmiersprache eins zu eins 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 eine Beziehung zu der Programmiersprache hat, mit der Sie ein Softwaresystem implementieren. 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 anzeigt, ist das auch Design. Sie können das Element (in diesem Fall ein Paket) einer syntaktischen Java-Konstruktion zuordnen.

Nehmen wir nun an, Ihre Java-Anwendung ist in Module unterteilt, und jedes Modul besteht aus einer Gruppe von Paketen (dargestellt als JAR-Datei-Deployment-Unit), und Ihnen wird ein Diagramm mit Modulen und seinen Abhängigkeiten angezeigt, also Architektur. Es gibt in Java (zumindest bis Java 7) keine Möglichkeit, ein Modul (einen Satz von Paketen) einer syntaktischen Konstruktion zuzuordnen. Möglicherweise stellen Sie auch fest, dass dieses Diagramm eine höhere Stufe der Abstraktion Ihres Softwaremodells darstellt. Jedes Diagramm oberhalb (grobkörniger als) eines Paketdiagramms repräsentiert eine Architekturansicht bei der Entwicklung in der Java-Programmiersprache. Auf der anderen Seite, wenn Sie in Modula-2 entwickeln, dann repräsentiert ein Moduldiagramm ein Design.

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


Ich mag Roy Thomas Fieldings Definition und Erklärung dessen, was Softwarearchitektur ist, in seiner Arbeit: Architekturstile und das Design netzwerkbasierter Softwarearchitekturen

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

Er betont "Laufzeitelemente" und "Abstraktionsebenen".



Ich würde sagen, du hast Recht, in meinen eigenen Worten;

Architektur ist die Zuordnung von Systemanforderungen zu Systemelementen. Vier Aussagen über eine 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 weist die (entworfenen) Funktionen zu, die das System für Elemente ausführen soll.

Architektur ist ein wesentlicher Entwicklungsschritt, wenn eine Komplexität des Systems unterteilt wird.

Beispiel: Denken Sie an Ihr Haus, Sie brauchen 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 geben und mit Stakeholdern diskutieren. Es ist vielleicht eine gute Übung, aber kein wesentlicher technischer Schritt .

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

Wenn ich darüber nachdenke, kann man sagen:

  • Architektur ist für ein Publikum / Ingenieure auf einer detaillierteren Abstraktionsebene
  • Design ist für die Öffentlichkeit auf einer weniger detaillierten Abstraktionsebene gedacht

In einigen Beschreibungen des SDLC (Software Development Life Cycle) sind sie austauschbar, aber der Unterschied liegt darin, dass sie verschieden sind. Sie sind gleichzeitig: verschiedene (1) Stufen , (2) Verantwortungsbereiche und (3) Ebenen der Entscheidungsfindung .

Diese beiden Phasen scheinen sich aus verschiedenen Gründen zu vermischen.

  1. Kleinere Projekte haben oft nicht genug Spielraum, um Planung in Etappen zu trennen.
  2. Ein Projekt könnte Teil eines größeren Projekts sein, und daher sind Teile beider Phasen bereits beschlossen. (Es existieren bereits Datenbanken, Konventionen, Standards, Protokolle, Frameworks, wiederverwendbarer Code usw.)
  3. Neuere Denkweisen über den SDLC (siehe agile ) ordnen diesen traditionellen Ansatz etwas um. Design (Architektur in geringerem Maße) findet absichtlich im gesamten SDLC statt. Es gibt oft mehrere iterations denen der ganze Prozess immer wieder passiert.
  4. Die Softwareentwicklung ist kompliziert und schwierig zu planen, aber Kunden / Manager / Vertriebsmitarbeiter erschweren es normalerweise, Ziele und Anforderungen in der Mitte zu ändern. Entwerfen und sogar architektonische Entscheidungen müssen später im Projekt getroffen werden, ob das der Plan ist oder nicht.

Auch wenn die Phasen oder Verantwortungsbereiche sich überlagern und überall stattfinden, ist es immer gut zu wissen, auf welchem ​​Niveau Entscheidungen getroffen werden. (Wir könnten damit für immer fortfahren. Ich versuche es kurz zu halten.) Ich werde damit enden: Auch wenn es scheint, dass Ihr Projekt keine formale Architektur- oder Designphase / AOR / Dokumentation hat, geschieht es, ob jemand es ist bewusst es tun oder nicht. Wenn sich niemand dafür entscheidet, Architektur zu machen, dann passiert ein Fehler, der wahrscheinlich schlecht ist. Dito für Design. Diese Konzepte sind fast wichtiger, wenn es keine formalen Stufen gibt, die sie repräsentieren.


Meine Erinnerung:

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

Persönlich mag ich diesen:

"Der Designer ist damit beschäftigt, was passiert, wenn ein Benutzer eine Taste drückt, und der Architekt ist besorgt, was passiert, wenn zehntausend Benutzer eine Taste drücken."

SCEA für Java ™ EE Study Guide von Mark Cade und Humphrey Sheil


Software-Design hat eine längere Geschichte, während der Begriff Software-Architektur kaum 20 Jahre alt ist. Daher durchläuft es gerade jetzt wachsende Schmerzen.

Akademiker neigen dazu, Architektur als Teil des größeren Bereichs des Software-Designs zu sehen. Obwohl die Erkenntnis wächst, dass Arch ein eigenes Feld ist.

Praktizierende neigen dazu, Arch als hochrangige Designentscheidungen zu sehen, die strategisch wichtig sind und bei einem zu löschenden Projekt kostspielig sein können.

Die genaue Linie zwischen Arch und Design hängt von der Softwaredomäne ab. Im Bereich der Web-Anwendungen gewinnt die geschichtete Architektur derzeit am meisten an Popularität (Biz Logic Layer, Datenzugriffsschicht usw.). Die unteren Teile dieses Archs werden als Design betrachtet (Klassendiagramme, Methodensignaturen usw.). ) Dies würde in den Domänen von eingebetteten Systemen, Betriebssystemen, Compilern usw. anders definiert sein.


Vor langer Zeit an einem weit entfernten Ort sorgten sich Philosophen um die Unterscheidung zwischen dem Einen und dem Vielen. In der Architektur geht es um Beziehungen, die viele erfordern. Architektur hat Komponenten. Design ist über Inhalt, der den einen erfordert. Design hat Eigenschaften, Qualitäten, Eigenschaften. Wir denken typischerweise, dass Design innerhalb der Architektur liegt. Dualistisches Denken gibt den Vielen das Ursprüngliche. Aber Architektur ist auch im Design. Es ist alles, was wir wählen, um zu sehen, was vor uns ist - das Eine oder das Viele.


wenn jemand ein Schiff baut, dann werden Motor, Rumpf, Stromkreise usw. seine "architektonischen Elemente" sein. Der Motorenbau wird für ihn "Design-Arbeit" sein.

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

Also - es hängt von der Ebene der Abstraktion oder Detail ab. Die Architektur einer Person könnte ein Design anderer sein!


Architektur ist Design, aber nicht alles Design ist architektonisch. Streng genommen wäre es daher sinnvoller, zwischen architektonischem Design und nicht-architektonischem Design zu unterscheiden . Und was ist der Unterschied? Es kommt darauf an! Jeder Softwarearchitekt kann eine andere Antwort haben (ymmv!). Wir entwickeln unsere Heuristiken, um eine Antwort zu finden, wie zum Beispiel "Klassendiagramme sind Architektur und Sequenzdiagramme sind Design". Siehe DSA-Buch für mehr.

Es ist üblich zu sagen, dass Architektur auf einer höheren Abstraktionsebene als Design ist, oder Architektur ist logisch und Design ist physikalisch. Aber diese Vorstellung, obwohl sie allgemein akzeptiert wird, ist in der Praxis nutzlos. Wo zeichnen Sie die Grenze zwischen hoher oder niedriger Abstraktion, zwischen logisch und physisch? Es kommt darauf an!

Also, mein Vorschlag ist:

  • Erstellen Sie ein einzelnes Design-Dokument.
  • Benennen Sie dieses Designdokument so, wie Sie es möchten, oder besser, wie es die Leser gewohnt sind. Beispiele: "Software Architecture", "Software Design Specification".
  • brechen Sie dieses Dokument in Ansichten und beachten Sie, 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 Ansichten auf höherer Ebene, die einen breiten, aber flachen Überblick über das Design und engere Implementierungsansichten mit engen, aber tieferen Designdetails bieten.
  • Vielleicht möchten Sie sich ein Beispiel für ein Multi-View-Architekturdokument ansehen ( here ).

Nachdem wir all das gesagt haben, 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?







definition