Die Softwarearchitektur eines Systems ist der Satz von Strukturen musste über das System vernünftig urteilen, die Softwareelemente, Beziehungen unter ihnen und Eigenschaften von beiden umfassen. Der Begriff bezieht sich auch auf die Dokumentation einer "Softwarearchitektur eines Systems." Das Dokumentieren der Softwarearchitektur erleichtert Kommunikation zwischen Miteigentümern, Dokumente frühe Entscheidungen über das Design auf höchster Ebene, und erlaubt Wiedergebrauch von Designbestandteilen und Mustern zwischen Projekten.

Übersicht

Das Feld der Informatik ist auf Probleme gestoßen, die mit der Kompliziertheit seit seiner Bildung vereinigt sind. Frühere Probleme der Kompliziertheit wurden von Entwicklern durch die Auswahl der richtigen Datenstrukturen, das Entwickeln von Algorithmen, und durch die Verwendung des Konzepts der Trennung von Sorgen behoben. Obwohl der Begriff "Software-Architektur" der Industrie relativ neu ist, sind die grundsätzlichen Grundsätze des Feldes sporadisch von Softwaretechnikpionieren seit der Mitte der 1980er Jahre angewandt worden. Frühe Versuche, Softwarearchitektur eines Systems zu gewinnen und zu erklären, waren ungenau und, häufig charakterisierte durch eine Reihe von Kasten-Und-Liniendiagrammen desorganisiert. Während der 1990er Jahre gab es eine gerichtete Bemühung, um grundsätzliche Aspekte der Disziplin zu definieren und zu kodifizieren. Anfängliche Sätze von Designmustern, Stilen, besten Methoden, Beschreibungssprachen und formaler Logik wurden während dieser Zeit entwickelt.

Die Softwarearchitektur-Disziplin wird auf die Idee in den Mittelpunkt gestellt, Kompliziertheit durch die Abstraktion und Trennung von Sorgen zu reduzieren. Bis heute gibt es noch keinen Konsens über die genaue Definition des Begriffes "Software-Architektur". Jedoch bedeutet das nicht, dass Personen ihre eigene Definition dessen nicht haben, wie Softwarearchitektur ist. Das führt zu Problemen, weil viele Menschen dieselben Begriffe gebrauchen, um sich unterscheidende Ideen zu beschreiben.

Weil eine reif werdende Disziplin ohne klare Regeln auf der richtigen Weise, ein System zu bauen, Softwarearchitektur entwerfend, noch eine Mischung der Kunst und Wissenschaft ist. Der "Kunst"-Aspekt der Softwarearchitektur entsteht weil eine kommerzielle Software Systembetreuungen etwas Aspekt eines Geschäfts oder einer Mission. Wie ein Systembetreuungsschlüsselgeschäft, das Fahrer, die über Drehbücher als nichtfunktionelle Voraussetzungen eines Systems, auch bekannt als Qualitätsattribute beschrieben sind, bestimmen, wie sich ein System benehmen wird. Davon konnte als eine Parallele zu einer Missionsbehauptung und Wertsystem in der Geschäftsstrategie gedacht werden. Jedes System ist zu den Geschäftsfahrern einzigartig, die es, deshalb die Qualitätsattribute jedes Systems wie Schuld-Toleranz, rückwärts gerichtete Vereinbarkeit, Dehnbarkeit, Haltbarkeit, Verfügbarkeit, Sicherheit, Brauchbarkeit unterstützt, und sich solcher anderer-ilities mit jeder Durchführung ändern wird.

Um eine Softwarearchitektur-Benutzerperspektive in die Softwarearchitektur zu bringen, kann es gesagt werden, dass Softwarearchitektur die Richtung gibt, um Schritte zu unternehmen und die Aufgaben zu erledigen, die am Spezialisierungsgebiet jedes solchen Benutzers beteiligt sind und z.B die Miteigentümer von Softwaresystemen, den Softwareentwickler, das Softwaresystem betriebliche Unterstützungsgruppe, die Softwarewartungsfachmänner, der deployer, der Prüfer und auch der Geschäftsendbenutzer zu interessieren. In diesem Sinn ist Softwarearchitektur wirklich die Fusion der vielfachen Perspektiven, die ein System immer aufnimmt. Die Tatsache, dass jene mehrere verschiedenen Perspektiven in eine Softwarearchitektur zusammengestellt werden können, steht als die Verteidigung des Bedürfnisses und Rechtfertigung der Entwicklung der Softwarearchitektur, bevor die Softwareentwicklung in einem Projekt Reife erreicht.

Geschichte

Die Softwarearchitektur als ein Konzept hat seine Ursprünge in der Forschung von Edsger Dijkstra 1968 und David Parnas am Anfang der 1970er Jahre. Diese Wissenschaftler haben betont, dass die Struktur eines Softwaresystems Sachen und die Struktur in Ordnung zu bringen, kritisch ist. Die Studie des Feldes hat in der Beliebtheit seit dem Anfang der 1990er Jahre mit der Forschungsarbeit zugenommen, die sich auf architektonische Stile (Muster), Architektur-Beschreibungssprachen, Architektur-Dokumentation und formelle Methoden konzentriert.

Forschungseinrichtungen haben eine prominente Rolle in der Förderung der Softwarearchitektur als eine Disziplin gespielt. Mary Shaw und David Garlan von Carnegie Mellon haben geschrieben, dass ein Buch Softwarearchitektur betitelt hat: Perspektiven auf einer Erscheinenden Disziplin 1996, die die Konzepte in der Softwarearchitektur, wie Bestandteile, Stecker, Stile und so weiter übertragen hat. Die Universität Kaliforniens, das Institut von Irvine für Softwareforschungsanstrengungen in der Softwarearchitektur-Forschung wird in erster Linie in architektonischen Stilen, Architektur-Beschreibungssprachen und dynamischen Architekturen geleitet.

IEEE 1471-2000, Empfohlene Praxis für die Architektur-Beschreibung von Softwareintensiven Systemen, war der erste formelle Standard im Gebiet der Softwarearchitektur. Es wurde 2007 durch ISO als ISO/IEC 42010:2007 angenommen. Im November 2011 wurde IEEE 1471-2000 durch ISO/IEC/IEEE 42010:2011, Systeme und Softwaretechnik — Architektur-Beschreibung (gemeinsam veröffentlicht durch IEEE und ISO) ersetzt.

Softwarearchitektur-Themen

Architektur-Beschreibungssprachen

Architektur-Beschreibungssprachen (ADLs) werden verwendet, um eine Softwarearchitektur zu beschreiben. Mehrere verschiedene ADLs sind von verschiedenen Organisationen, einschließlich AADL (SAE Standard), Wright (entwickelt von Carnegie Mellon), Gipfel (entwickelt von Carnegie Mellon), xADL (entwickelt durch UCI), Darwin (entwickelt von der Reichsuniversität London), DAOP-ADL (entwickelt von der Universität von Málaga), und ByADL (Universität von L'Aquila, Italien) entwickelt worden. Allgemeine Elemente eines ADL, sind Stecker und Konfiguration bildend.

Ansichten

Softwarearchitektur-Beschreibungen werden in Ansichten allgemein organisiert, die den verschiedenen Typen von im Gebäude der Architektur gemachten Entwürfen analog sind. Eine Ansicht ist eine Darstellung von einer Reihe von Systembestandteilen und Beziehungen unter ihnen.

Innerhalb der Ontologie, die durch IEEE 1471-2000 gegründet ist, folgen Ansichten der durch ihre Gesichtspunkte gegründeten Vereinbarung, wo ein Gesichtspunkt eine Spezifizierung ist, die die Notationen beschreibt, in einer Ansicht zu verwendende Techniken modellierend, die fragliche Architektur von der Perspektive eines gegebenen Satzes von Miteigentümern und ihren Sorgen auszudrücken. Der Gesichtspunkt gibt nicht nur die Sorgen gerichtet, aber die Präsentation, Musterarten verwendet, Vereinbarung verwendet und jede Konsistenz (Ähnlichkeit) Regeln an, eine Ansicht im Einklang stehend mit anderen Ansichten zu halten.

Einige Beispiele von Arten von Ansichten (Gesichtspunkte in der 1471/42010 Ontologie) sind:

• Funktioneller/logischer Gesichtspunkt
• Gesichtspunkt des Codes/Moduls
• Entwicklungsgesichtspunkt / struktureller Gesichtspunkt
• Gesichtspunkt der Parallelität/Prozesses/Durchlaufzeit/Fadens
• Gesichtspunkt der ärztlichen Untersuchung/Aufstellung/installieren
• Benutzergesichtspunkt der Handlung/Feed-Backs
• Datenmodell der Ansicht/Daten

Mehrere Sprachen, um Softwarearchitekturen (Architektur-Beschreibungssprache in ISO/IEC/IEEE 42010 (IEEE 1471) Fachsprache) zu beschreiben, sind ausgedacht worden, aber keine Einigkeit besteht, auf dem Zeichensatz oder Sprache an für jeden Architektur-Gesichtspunkt gewöhnt sein sollten. Der UML ist ein Standard, der "für die Analyse, das Design und die Durchführung von softwarebasierten Systemen verwendet werden kann sowie um Geschäft und ähnliche Prozesse zu modellieren." So ist der UML eine Sehsprache, die verwendet werden kann, um Softwarearchitektur zu schaffen.

Architektur-Fachwerk

Mit dem Gebiet der Softwarearchitektur verbundenes Fachwerk ist:

• 4+1
• RM-ODP (Bezugsmodell der offenen verteilten Verarbeitung)
• Service-Oriented Modeling Framework (SOMF)

Anderes Architektur-Fachwerk wie das Zachman Fachwerk, DODAF und TOGAF bezieht sich auf das Feld der Unternehmensarchitektur.

Die Unterscheidung vom funktionellen Design

Der IEEE Std 610.12-1990 Standardwörterverzeichnis der Softwaretechnikfachsprache definiert die folgenden Unterscheidungen:

• Architektonische Planung: Der Prozess, eine Sammlung der Hardware und Softwarebestandteile und ihrer Schnittstellen zu definieren, um das Fachwerk für die Entwicklung eines Computersystems zu gründen.
• Ausführliches Design: Der Prozess der Raffinierung und Erweiterung des einleitenden Designs eines Systems oder Bestandteils im Ausmaß, dass das Design genug abgeschlossen ist, um Durchführung zu beginnen.
• Funktionelles Design: Der Prozess, die Arbeitsbeziehungen unter den Bestandteilen eines Systems zu definieren.
• Einleitendes Design: Der Prozess, Designalternativen zu analysieren und die Architektur, Bestandteile, Schnittstellen zu definieren, und Schätzungen für ein System oder Bestandteile zeitlich festlegen/nach Größen ordnen.

Softwarearchitektur, die auch als strategisches Design beschrieben ist, ist eine mit der globalen Voraussetzungsregelung betroffene Tätigkeit, wie eine Lösung wie Programmierung von Paradigmen, architektonischen Stilen, teilbasierten Softwaretechnikstandards, architektonischen Mustern, Sicherheit, Skala, Integration und gesetzgeregelter Regelmäßigkeit durchgeführt wird. Funktionelles Design, das auch als taktisches Design beschrieben ist, ist eine Tätigkeit, die mit der lokalen Voraussetzungsregelung betroffen ist, was eine Lösung wie Algorithmen, Designmuster tut, Idiome, refactorings, und auf niedriger Stufe Durchführung programmierend.

Gemäß der Hypothese der Verstärkung/Gegend wird die Unterscheidung zwischen dem architektonischen und ausführlichen Design durch das Gegend-Kriterium definiert, gemäß dem eine Behauptung über das Softwaredesign (architektonisch) nichtlokal ist, wenn, und nur wenn ein Programm, das es befriedigt, in ein Programm ausgebreitet werden kann, das nicht tut. Zum Beispiel ist der Client/Server-Stil (strategisch) architektonisch, weil ein Programm, auf das auf diesem Grundsatz gebaut wird, in ein Programm ausgebreitet werden kann, das nicht client/Server-ist; zum Beispiel, durch das Hinzufügen von Gleicher-zu-Gleicher-Knoten.

Architektur ist Design, aber nicht das ganze Design ist architektonisch. In der Praxis ist der Architekt derjenige, der die Linie zwischen Softwarearchitektur (architektonische Planung) und ausführlich berichtetem Design (nichtarchitektonische Planung) zieht. Es gibt nicht Regeln oder Richtlinien, die alle Fälle passen. Beispiele von Regeln oder Heuristik, die Architekten (oder Organisationen) einsetzen können, wenn sie zwischen Architektur und ausführlich berichtetem Design unterscheiden wollen, schließen ein:

• Architektur wird durch nichtfunktionelle Voraussetzungen gesteuert, während funktionelles Design durch funktionelle Voraussetzungen gesteuert wird.
• Pseudocode gehört im ausführlichen Designdokument.
• UML Bestandteil, Aufstellung und Paket-Diagramme erscheinen allgemein in Softwarearchitektur-Dokumenten; UML Klasse, Gegenstand und Verhaltensdiagramme erscheinen in ausführlichen funktionellen Designdokumenten.

Beispiele von architektonischen Stilen und Mustern

Es gibt viele allgemeine Weisen, Computersoftwaremodule und ihre Kommunikationen, unter ihnen zu entwerfen:

• Wandtafel
• Client/Server-Modell (2-Reihen-, N-Reihe, Gleicher-zu-Gleicher, Wolke, den ganzen Gebrauch dieses Modell schätzend)

,

• Datenbankzentrische Architektur (kann breite Abteilung für Programme gemacht werden, die Datenbank an seinem Zentrum und Anwendungen haben, die sich auf Datenbanken, Z.B Tischanwendungsprogramme, Dienstprogramme usw. nicht verlassen müssen)
• Verteilte Computerwissenschaft
• Ereignis-gesteuerte Architektur
• Vorderende und Rücken beenden
• Implizite Beschwörung
• Monolithische Anwendung
• Gleicher-zu-Gleicher-
• Pfeifen und Filter
• Einfügefunktion, (rechnend)
• Vertretungsstaatsübertragung
• Regel-Einschätzung
• Suchorientierte Architektur (Führt ein reiner SOA einen Dienst für jeden Datenzugriffspunkt durch.)
• Dienstorientierte Architektur
• Geteilt nichts Architektur
• Software componentry
• Raum hat Architektur gestützt
• Strukturiert (Modul-basiert, aber gewöhnlich monolithisch innerhalb von Modulen)
• Drei-Reihen-Modell (Eine Architektur mit der Präsentation, den Geschäftslogik- und Datenbankreihen)

Siehe auch

• Architektonisches Muster (Informatik)
• Antimuster
• Architektur zentrische Designmethode
• Architecture Tradeoff Analysis Method (ATAM)
• Schicht (objektorientiertes Design)
• Allgemeine Schichten in einem Informationssystem logische Architektur
• Computerarchitektur
• Abhängigkeitsstruktur-Matrix
• Unternehmensarchitektur
• IFIP Arbeitsgruppe 2.10
• Prozess-Architektur
• Softwarearchitekt
• Software architektonisches Modell
• Softwaredesign
• Softwaredesignmuster
• Softwarefachwerk
• Softwaresystem
• Standarddatenmodell
• Systemarchitekt
• Systemarchitektur
• Systemdesign
• Technische Architektur
• Softwarearchitektur-Analyse-Methode

Weiterführende Literatur

• Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Rohr Wenig, Paulo Merson, Robert Nord, Judith Stafford: Das Dokumentieren von Softwarearchitekturen: Ansichten und Darüber hinaus, die Zweite Ausgabe. Addison-Wesley, 2010, internationale Standardbuchnummer 0-321-55268-7. Dieses Buch beschreibt, was Softwarearchitektur ist und zeigt, wie man es in vielfachen Ansichten, mit UML und anderen Notationen dokumentiert. Es erklärt auch, wie man die Architektur-Ansichten mit dem Verhalten, der Softwareschnittstelle und der Grundprinzip-Dokumentation ergänzt. Das Begleiten des Buches ist ein wiki, der ein Beispiel der Softwarearchitektur-Dokumentation enthält.
• Len Bass, Paul Clements, Rick Kazman: Softwarearchitektur in der Praxis, die Zweite Ausgabe. Addison Wesley, am 5/9/2003 internationale Standardbuchnummer 0-321-15495-9 Lesend (Bedeckt dieses Buch, jetzt in der zweiten Ausgabe, beredt die grundsätzlichen Konzepte der Disziplin. Das Thema wird um das Erzielen von Qualitätsattributen eines Systems in den Mittelpunkt gestellt.)
• Amnon H. Eden, Rick Kazman. Architektur, Design, Durchführung. Auf der Unterscheidung zwischen architektonischer Planung und ausführlich berichtetem Design.
• Garzás, Javier, und Piattini, Mario. Eine Ontologie für Kenntnisse der mikroarchitektonischen Planung, IEEE Softwarezeitschrift, Volumen: 22, Problem: 2, März-April 2005. Seiten 28 - 33.
• Philippe Kruchten: Architektonische Entwürfe - das 4+1 Ansicht-Modell der Softwarearchitektur. In: IEEE Software. 12 (am) (6.) November 1995, Seiten 42-50 (auch verfügbar online an der Vernünftigen Website (PDF))
• Tony Shan und Winnie Hua (2006). Lösungsbauen-Mechanismus. Verhandlungen des 10. IEEE Internationalen EDOC Unternehmens, Konferenz (EDOC 2006), Oktober 2006, p23-32 Schätzend

Links

• Ausgezeichnete Erklärung auf IBM Developerworks
• Sammlung von Softwarearchitektur-Definitionen an Software Engineering Institute (SEI), Carnegie Mellon University (CMU)
• Softwarearchitektur gegen das Softwaredesign: Die Hypothese der Verstärkung/Gegend
• Internationale Vereinigung von Softwarearchitekten (IASA)
• SoftwareArchitecturePortal.org — Website der IFIP Arbeitsgruppe 2.10 auf der Softwarearchitektur
• Softwarearchitektur — praktische Mittel für Softwarearchitekten
• SoftwareArchitectures.com — unabhängige Quelle der Information über die Disziplin
• Microsoft Architecture Journal
• Architektonische Muster
• Softwarearchitektur, Kapitel 1 der REST-Doktorarbeit von Roy Fielding
• DiaSpec, eine Annäherung und Werkzeug, um ein verteiltes Fachwerk von einer Softwarearchitektur zu erzeugen
• Wenn gute Architektur schlechter geht
• Softwarearchitektur und Zusammenhängende Sorgen, Was ist Softwarearchitektur? Und Was Softwarearchitektur Nicht Ist
• Handbuch der Softwarearchitektur
• Die Spiralförmige Architektur Gesteuerte Entwicklung - der auf dem Spiralförmigen Modell gestützte SDLC soll die Gefahren der unwirksamen Architektur reduzieren
• Grundprinzip hat Softwarearchitektur-Dokumentationsmethode eingestellt