Die Softwarearchitektur ist ein wesentlicher Bestandteil des Softwareentwicklungsprozesses und umfasst eine Vielzahl von Gebieten und Technologien. Wenn du fundierte Kenntnisse der verschiedenen Gebiete der Softwarearchitektur hast, kannst du eine effektive und robuste Softwarearchitektur entwickeln und implementieren.
Auf dieser Seite findest du umfassende Informationen zu den verschiedenen Gebieten der Architektur, einschließlich der Architekturmuster, -modelle und -prinzipien sowie der Tools, Werkzeuge und Frameworks, die bei der Erstellung und Überprüfung von Softwarearchitekturen verwendet werden können. Egal, ob du ein erfahrener Softwarearchitekt bist oder gerade erst in das Thema einsteigst. Hier findest du alles, was du wissen musst, um deine Kenntnisse und Fähigkeiten im Bereich der Softwarearchitektur zu erweitern und zu vertiefen.
„Architektur sind die Entscheidungen, die sehr kostspielig zu entwickeln sind.“
Das bedeutet, dass Architektur Entscheidungen beinhaltet, die sehr teuer und aufwendig sind, um sie später zu ändern oder zu korrigieren. Daher ist es wichtig, sich im Vorfeld sorgfältig Gedanken darüber zu machen, welche Entscheidungen getroffen werden müssen. So kann sichergestellt werden, dass die Architektur langfristig effektiv, nachhaltig und rentabel ist.
Das bedeutet auch, dass Architekten sorgfältig planen müssen, bevor sie Entscheidungen treffen. Sie müssen sich über die Bedürfnisse und Anforderungen der Nutzer und Stakeholder im Klaren sein, bevor sie Entscheidungen treffen, die langfristige Auswirkungen auf das Projekt haben werden.
Es ist wichtig, die verschiedenen Optionen sorgfältig zu evaluieren und die Vor- und Nachteile jeder Option abzuwägen, um sicherzustellen, dass die Architektur optimal gestaltet wird und den Bedürfnissen der Nutzer und Stakeholder entspricht. Dies kann helfen, teure Änderungen und Korrekturen später im Prozess zu vermeiden und sicherzustellen, dass das Projekt erfolgreich abgeschlossen wird.
Softwarearchitektur-Prinzipien sind grundlegende Regeln und Leitlinien, die bei der Entwicklung und Umsetzung von Softwarearchitekturen berücksichtigt werden sollten. Sie umfassen Aspekte wie Modularität, Skalierbarkeit, Wiederverwendbarkeit und Sicherheit und tragen dazu bei, eine effektive und robuste Softwarearchitektur zu entwickeln.
Es ist generell sinnvoll, die Softwarearchitektur nicht starr durch Regeln, sondern eher durch Prinzipien zu lenken. Diese Prinzipien dienen als Rahmen und Leitplanken für die Entwicklung der Softwarestruktur.
Die Umsetzung erfolgt durch das Entwicklerteam, was zu einer starken Identifikation mit der Architektur führt. Daher sollten alle Software-Entwickler und -Architekten sich intensiv mit der Architektur auseinandersetzen und die beste, oder zumindest passendste, Architektur finden.
Es ist zwar nicht immer möglich, Entscheidungen basisdemokratisch zu treffen, jedoch sollten sich die Werte und Grundregeln, die im Team anerkannt sind, in den Entscheidungen widerspiegeln. Dadurch wird die Akzeptanz der Architektur im Team erhöht.
Die SOLID-Prinzipien des amerikanischen Softwareentwicklers und IT-Beraters Robert C. Martin haben sich als Ausgangspunkt für eine gute Softwarearchitektur bewährt und bilden den Kern einer ganzen Reihe von Prinzipien.
Das Akronym „SOLID“ steht für fünf Prinzipien:
Single-Responsibility-Prinzip: Jede Komponente sollte nur für eine Aufgabe verantwortlich sein und auch die gesamte Funktionalität einer Aufgabe abdecken.
Open-Closed-Prinzip: Erweiterungen an Klassen sollten nicht durch Änderungen der Klasse selbst durchgeführt, sondern über Vererbung oder Delegation gelöst werden.
Liskovsches Substitutionsprinzip: Eine abgeleitete Klasse muss stets auch im Kontext ihrer Basisklasse eingesetzt werden können und darf das Verhalten der Basisklasse nur erweitern, aber nicht einschränken.
Interface-Segregation-Prinzip: Der Umfang eines Interfaces wird durch die Anforderungen des Clients bestimmt und nicht umgekehrt.
Dependency-Inversion-Prinzip: Module auf höheren Abstraktionsebenen sollten sich nicht von Modulen auf niedrigeren Abstraktionsebenen abhängig machen, sondern sich auf Interfaces beziehen.
Da diese fünf SOLID-Prinzipien eine wichtige Hilfestellung bei der Entwicklung von Software sind und zu einem guten objektorientierten Design führen, gehen wir im Folgenden ausführlicher auf sie ein:
Dieses Prinzip besagt, dass jede Komponente nur für eine Aufgabe verantwortlich sein und auch die gesamte Funktionalität einer Aufgabe abdecken sollte. Werden Änderungen an der Software vorgenommen, sollte es immer einen Grund dafür geben.
In der Praxis hat eine Komponente dann die richtige Größe, wenn sich die Änderungen aufgrund einer User Story nur auf eine Komponente auswirken.
Das Open-Closed-Prinzip lässt sich sowohl im kleinen sowie großen Rahmen anwenden. Erweiterungen an Klassen sollten nicht durch Änderung der Klasse durchgeführt, sondern über Vererbung oder besser durch Delegation gelöst werden.
Bei größeren Softwareeinheiten ist ein Plugin-Konzept sinnvoll, über das zusätzliche Klassen zur Erweiterung der Funktionalität hinzugefügt werden können.
Eine abgeleitete Klasse muss stets auch im Kontext ihrer Basisklasse eingesetzt werden können. Sie darf das Verhalten der Basisklasse nur erweitern, aber nicht einschränken. Der Entwickler oder die Entwicklerin darf bei der Verwendung keine Überraschung – das heißt, ob mit der Basisklasse oder einer abgeleiteten Klasse gearbeitet wird – erleben.
Der Umfang eines Interfaces wird durch die Anforderungen des Clients bestimmt und nicht umgekehrt. Ein Client darf nicht gezwungen werden, Funktionalität zu implementieren, die gar nicht benötigt wird. Damit wird der Zusammenhalt von Modulen gestärkt, deren Kopplung jedoch reduziert.
In einer geschichteten Architektur existieren Klassen und Module auf unterschiedlichen Abstraktionsebenen. In Klassen niedriger Ebenen werden Implementierungsdetails -beispielweise die Datenbankanbindung - gekapselt. Auf den höheren Ebenen geht es dagegen um die abstrakte Business-Logik.
Das Dependency-Inversion-Prinzip besagt, dass Module auf höheren Abstraktionsebenen nicht von Modulen niedrigerer Abstraktionsebenen abhängen, sondern sich jeweils auf Interfaces beziehen sollten. Interfaces hingegen sollten nicht von Details abhängen, sondern die Details müssen eine Abhängigkeit von den jeweiligen Interfaces aufweisen.
„Jede neue Situation verlangt eine neue Architektur.“
Jean Nouvel
Das Software-Architektur-Design ist der Prozess der Planung und Gestaltung einer Softwarearchitektur. Sie beinhaltet die Entscheidung über die Struktur und Organisation der verschiedenen Komponenten des Systems sowie die Festlegung der Beziehungen und Interaktionen zwischen ihnen. Dabei werden verschiedene Architekturmuster, -modelle und -prinzipien berücksichtigt, um eine effektive und robuste Softwarearchitektur zu entwickeln.
Das Softwarearchitektur-Design ist ein wichtiger Schritt im Softwareentwicklungsprozess, da es die Grundlage für die Implementierung und Umsetzung des Systems bildet.
Die Softwarearchitektur ist ein essenzieller Erfolgsfaktor für ein Projekt. Jedoch umfasst sie mehr als nur die Struktur des Systems, da auch andere Faktoren zu einem Architekturfehlschlag führen können. Die Menge aller wichtigen und schwer änderbaren Entscheidungen wird als Software-Architektur betrachtet.
Eine erfolgreiche Softwarearchitektur erfordert viele, teilweise überraschende Ansätze wie bspw. die Berücksichtigung von Qualitätsszenarien und die Nutzung der Expertise des gesamten Teams.
Das gesamte Softwarearchitektur-Design wird durch strategische Entscheidungen in Bezug auf die Software-Anforderungen bestimmt, was als Software-Strategie bezeichnet wird. Es ist wichtig, ein durchdachtes Systemdesign zu haben, da Änderungen an resultierenden Design-Artefakten innerhalb der Software-Architektur in der Regel schwierig und kostenintensiv sind.
Skalierbarkeit ist ebenfalls von großer Bedeutung, da alle relevanten Eigenschaften der Software-Architektur wie grundlegende Systemfunktionen, Performance und Sicherheit für absehbare Zukunftsszenarien berücksichtigt werden müssen.
Bei allen Entscheidungen zur Software-Architektur müssen die Anforderungen und Unternehmensziele beachtet werden. Es ist wichtig, keine Entscheidung ohne einen guten Grund zu treffen.
Es gibt mittlerweile weit verbreitete Möglichkeiten zur Darstellung von Architekturen und verschiedene Werkzeuge, die die Verständlichkeit verbessern. Eines dieser Werkzeuge ist der Qualitätsbaum, der in der ISO 25010 definiert und auch in Standards wie arc42 enthalten ist.
Der Qualitätsbaum listet verschiedene Qualitätsmerkmale wie Sicherheit oder Zuverlässigkeit auf und bietet für jedes Merkmal eine Liste von Teilmerkmalen an, die es ermöglichen, das Merkmal vollständig zu betrachten.
Ein Qualitätsbaum hilft dabei, zu überprüfen, ob alle wesentlichen Qualitätsmerkmale einer Software berücksichtigt wurden und welche Merkmale von der Software erfüllt werden können.
Ein Softwarearchitekt ist die Person, die für die Gestaltung und Planung der Softwarearchitektur eines Systems verantwortlich ist. Der Softwarearchitekt analysiert die Anforderungen des Systems und entwirft eine Architektur, die diese Anforderungen erfüllt und dabei verschiedene Architekturmuster, -modelle und -prinzipien berücksichtigt. Der Softwarearchitekt ist auch für die Auswahl von Technologien, Frameworks und Werkzeugen verantwortlich, die bei der Entwicklung und Umsetzung des Systems verwendet werden sollen.
Die Rolle des Softwarearchitekten hat sich im Laufe der Zeit stark verändert und umfasst heute nicht nur technologische Kompetenzen, sondern auch die Nutzung der Expertise des Teams und die Förderung der individuellen Entwicklung der Teammitglieder. In agilen Projekten kann die Architektur nicht einfach durchgesetzt werden, da das Team selbstorganisiert arbeitet. Stattdessen müssen Architekten mit dem Team zusammenarbeiten und die Architektur in enger Abstimmung mit den Teammitgliedern entwickeln.
Häufig wird die Rolle des Software-Architekten mit der eines Gebäudearchitekten verglichen, da es eine Analogie zwischen Entwurfsmustern und Gebäudemustern gibt. Allerdings ist dieser Vergleich bei der Betrachtung großer und komplexer Software-Architekturen, wie sie in betrieblichen Informationssystemen vorkommen, unzureichend. In solchen Umgebungen müssen viele heterogene Software Systems miteinander integriert werden, wie es im Enterprise Application Integration angestrebt wird.
Aus diesem Grund ist die Analogie zur Stadtplanung passender. Bei der Stadtplanung müssen viele unterschiedliche und manchmal auch konkurrierende Interessen berücksichtigt werden, wie zum Beispiel der fließende Straßenverkehr, der öffentliche Nahverkehr und ruhige Wohngebiete. Gleiches gilt auch für den Entwurf von komplexen betrieblichen Informationssystemen, bei dem viele verschiedene Interessen berücksichtigt werden müssen, die im Allgemeinen zahlreicher sind als bei der Konstruktion von einzelnen Gebäuden. Das bedeutet jedoch nicht, dass die Aufgabe des Gebäudeentwurfs einfach ist; der Hausbau ist nur eine anschauliche Analogie zur Konstruktion von einzelnen Softwaresystemen.
Eine oft unterschätzte Komponente der Architekturarbeiten ist die Rolle und Selbstwahrnehmung der Softwarearchitekten. Obwohl diese Tatsache nicht viel Beachtung findet, ist sie dennoch von großer Bedeutung. Traditionell war "Softwarearchitekt" ein Titel und oft auch eine Stufe auf der Karriereleiter. In der modernen Interpretation ist der Softwarearchitekt eine Person, die Architektur betreibt, unabhängig von seinem Titel oder seiner Position im Team.
Die Erstellung einer Softwarearchitektur ist ein wesentlicher Bestandteil des Softwareentwicklungsprozesses. Eine gut durchdachte Architektur stellt sicher, dass die Anforderungen des Kunden erfüllt werden und dass das System langfristig wartbar und erweiterbar ist. Hier sind einige Schritte, die bei der Erstellung einer Softwarearchitektur zu beachten sind:
Verständnis der Anforderungen: Bevor mit der Erstellung der Architektur begonnen werden kann, müssen die Anforderungen des Kunden klar verstanden werden. Es ist notwendig, die funktionalen und nicht-funktionalen Anforderungen zu analysieren, um die Komponenten des Systems zu identifizieren.
Identifikation von Bausteinen: Auf Basis der Anforderungen können die Bausteine des Systems identifiziert werden. Hierbei handelt es sich um die Komponenten, aus denen das System besteht, z.B. Datenbanken, Server, Clients usw.
Festlegung von Schnittstellen: Nach der Identifikation der Bausteine müssen deren Schnittstellen definiert werden, um sicherzustellen, dass sie miteinander kommunizieren können.
Definition der Architekturmuster: Anhand der Anforderungen und der identifizierten Bausteine können die Architekturmuster bestimmt werden, die am besten geeignet sind, um das System zu implementieren.
Erstellung von Prototypen: Um sicherzustellen, dass die Architektur richtig umgesetzt wird, sollten Prototypen erstellt werden, um das System zu testen und zu validieren.
Überprüfung der Architektur: Die Architektur sollte regelmäßig überprüft werden, um sicherzustellen, dass sie immer noch den Anforderungen entspricht und dass sie auf Änderungen und Erweiterungen vorbereitet ist.
Die Erstellung einer Softwarearchitektur erfordert ein fundamentales Verständnis der Anforderungen, eine klare Definition der Bausteine und Schnittstellen sowie eine sorgfältige Auswahl der Architekturmuster. Durch die Erstellung einer gut durchdachten Architektur, kann die Software langfristig gewartet und erweitert werden.
Eine bedeutende Phase für Entwickler Anwendungen ist die Erstellung eines Softwarearchitekturdiagramms. Es zeigt die grundlegende Struktur eines Softwaresystems und die Disziplin, Strukturen und Systeme wie diese zu erstellen. Dies umfasst Elemente des Programms, Beziehungen zwischen ihnen und die Eigenschaften aller Elemente und Beziehungen.
Das Diagramm verdeutlicht das grundlegende Layout der Software durch die Unterteilung von Funktionsbereichen in Schichten und zeigt, wie ein typisches Softwaresystem mit Benutzern, externen Systemen, Datenquellen und Diensten interagieren kann.
Es ist unzureichend, die Softwarearchitektur als bloße Sammlung von Vorlagen oder Konfigurationen zu betrachten. Sie sollte stattdessen die Entscheidungen enthalten, die zu bestimmten Strukturen beitragen, und die Gründe dafür erläutern.
Es gibt verschiedene Arten von Softwarearchitekturdiagrammen. Architekturdiagramme sind ein wichtiges Instrument für Systemarchitekten und Entwickler, um die allgemeine Struktur ihres Systems oder ihrer Anwendung zu visualisieren und sicherzustellen, dass das System den Anforderungen ihrer Anwender entspricht. Architekturdiagramme helfen auch bei der Beschreibung von Mustern, die im Entwurf eingesetzt werden. Man kann sie sich wie eine Blaupause vorstellen, die als Leitfaden für Diskussionen, Optimierung und Umsetzung mit Kollegen verwendet werden kann.
Um Architekturdiagramme zu erstellen, bietet z. B. die Edraw Architecture Diagram Software eine einfache Lösung im Softwaresystem-Entwicklungsprozess. Mit vielen vorgefertigten Zeichnungsformen und einer einfachen Benutzeroberfläche können Systemarchitekturdiagramme, Softwarearchitekturdiagramme, Anwendungsarchitekturdiagramme, Website-Systemarchitekturdiagramme, UML-Diagramme und vieles mehr erstellt werden. Eine Vielzahl von vorgefertigten Formaten steht zur Verfügung, darunter 2D-Shapes, 3D-Shapes, Volumengeometrie-Shapes, Pfeilformen und häufig verwendete Symbole. Mit nur wenigen Klicks kann ein perfektes und organisiertes Architekturdiagramm erstellt und die Arbeit fortgesetzt werden.
Es gibt verschiedene Tools und Frameworks, die bei der Erstellung und Überprüfung von Softwarearchitekturen unterstützen können. Hier sind einige der bekanntesten Tools und deren Funktionen:
Archi: Archi ist ein Open-Source-Tool, das bei der Erstellung von Architekturdiagrammen unterstützt. Es bietet eine einfache Benutzeroberfläche und kann verschiedene Architekturmuster wie TOGAF, ArchiMate und Zachman Framework unterstützen.
Visual Paradigm: Visual Paradigm ist ein Tool, das die Modellierung von Softwarearchitekturen unterstützt. Es bietet verschiedene Diagrammtypen, darunter Use-Case-Diagramme, Sequenzdiagramme und Klassendiagramme.
Enterprise Architect: Enterprise Architect ist ein Tool, das verschiedene Architekturmuster unterstützt, darunter TOGAF, Zachman und BPMN. Es bietet eine Vielzahl von Diagrammtypen, die bei der Modellierung von Systemen helfen können.
C4 Model: Das C4-Modell ist eine Methode zur Dokumentation von Softwarearchitekturen. Es bietet eine einfache Möglichkeit, eine Architektur hierarchisch zu gliedern und verschiedene Komponenten zu definieren.
Lucidchart: Lucidchart ist ein Online-Tool, das bei der Erstellung von Architekturdiagrammen unterstützt. Es bietet eine Vielzahl von Vorlagen und eine einfache Benutzeroberfläche.
Softwarearchitektur Patterns sind ein wertvolles Instrument für die Softwareentwicklung, um bewährte Lösungen für wiederkehrende Entwurfsprobleme zu nutzen und die Qualität und Wartbarkeit der Software zu verbessern.
Sie sind bewährte Vorgehensweisen und Modelle dar, die auf konkrete Probleme und Anforderungen zugeschnitten sind und dadurch Zeit und Ressourcen sparen können.
Softwarearchitektur Patterns sind in der Regel erprobte und dokumentierte Lösungen für Designprobleme, die in der Vergangenheit bereits aufgetreten sind. Es handelt sich um eine Sammlung von Wissen und Erfahrung, die von Architekten und Entwicklern über viele Jahre hinweg zusammengetragen wurden.
Der Einsatz von Softwarearchitektur Patterns kann dabei helfen, die Qualität und Wartbarkeit der Software zu verbessern, indem sie eine klare Struktur und Hierarchie schaffen und die Komplexität reduzieren. Zudem können sie auch die Zusammenarbeit im Team erleichtern, da sich alle Mitglieder auf gemeinsame Muster und Prinzipien einigen können.
Es gibt verschiedene Arten von Softwarearchitektur Patterns, wie beispielsweise Schichtenarchitekturen, MVC (Model-View-Controller), Pipes and Filters oder Microservices. Jedes Pattern hat seine eigenen Vor- und Nachteile, die je nach Kontext und Anforderungen berücksichtigt werden sollten. Diese Pattern sind die bekanntesten Modelle:
Schichtenarchitektur: Bei der Schichtenarchitektur wird das System in verschiedene Schichten aufgeteilt, die jeweils spezifische Funktionen und Aufgaben erfüllen. Die Schichten werden hierarchisch aufgebaut, wobei jede Schicht nur mit der unmittelbar benachbarten Schicht kommunizieren darf.
MVC (Model-View-Controller): Das MVC-Modell teilt das System in drei Komponenten auf: Model, View und Controller. Das Model enthält die Daten, die View definiert das Aussehen und der Controller kontrolliert die Interaktion zwischen Model und View.
Pipes and Filters: Bei Pipes and Filters wird das System in eine Reihe von Filtern aufgeteilt, die Datenströme bearbeiten und weiterleiten. Die Filter werden in einer Pipeline miteinander verbunden, wobei die Daten durch die Pipeline fließen und von jedem Filter entsprechend verarbeitet werden.
Microservices: Bei Microservices wird das System in kleinere, unabhängige Dienste aufgeteilt, die jeweils spezifische Funktionen erfüllen. Jeder Dienst ist eigenständig und kann unabhängig von den anderen Diensten entwickelt und bereitgestellt werden.
Event-Driven Architecture: Bei der Event-Driven Architecture werden Ereignisse und Zustandsänderungen als zentraler Bestandteil des Systems betrachtet. Das System reagiert auf Ereignisse und kann entsprechende Aktionen ausführen.
Jedes dieser Modelle hat seine eigenen Vor- und Nachteile und eignet sich für bestimmte Anwendungsfälle und Systeme. Es ist wichtig, das richtige Modell für das jeweilige Projekt auszuwählen, um eine effektive und robuste Softwarearchitektur zu entwickeln.
Der Job des Softwarearchitekten ist heute von immenser Bedeutung, da Softwareanwendungen in nahezu allen Branchen und Bereichen eine wichtige Rolle spielen. Die digitale Transformation hat die Nachfrage nach gut entwickelten und zuverlässigen Softwareanwendungen stark erhöht. Allerdings gibt es immer noch einen Mangel an qualifizierten und erfahrenen Softwarearchitekten, die in der Lage sind, komplexe Systeme zu entwerfen und zu implementieren.
Der Job des Softwarearchitekten ein wichtiger und vielversprechender Beruf, der in der eine hohe Nachfrage und Bedeutung hat.
Um Softwarearchitekt zu werden, gibt es verschiedene Wege und Qualifikationen, die du erwerben oder gehen kannst. Hier findest du einige Beispiele:
Ausbildung und Studium: Ein abgeschlossenes Studium oder eine Ausbildung im Bereich der Informatik oder Softwareentwicklung ist eine grundlegende Voraussetzung, um als Softwarearchitekt arbeiten zu können. Ein Bachelor- oder Master-Abschluss in Informatik, Software-Engineering oder einem verwandten Bereich sind meistens erforderlich.
Praktische Erfahrung: Um als Softwarearchitekt tätig zu sein, ist es wichtig, praktische Erfahrung in der Softwareentwicklung zu haben. Eine mehrjährige Berufserfahrung in der Softwareentwicklung und in der Umsetzung von komplexen Projekten kann dabei helfen, eine Karriere als Softwarearchitekt zu starten.
Weiterbildung und Zertifizierungen: Es gibt eine Vielzahl von Weiterbildungsangeboten und Zertifizierungen im Bereich der Softwarearchitektur, die dabei helfen können, das Wissen und die Fähigkeiten zu erwerben, die für die Arbeit als Softwarearchitekt erforderlich sind. Bekannte Zertifizierungen sind zum Beispiel TOGAF oder Certified Software Architect.
Technisches Verständnis: Ein fundiertes technisches Verständnis ist ebenfalls wichtig, um als Softwarearchitekt tätig zu sein. Hierzu gehören Kenntnisse in verschiedenen Programmiersprachen, Datenbanken, Softwareentwicklungsprozessen und -methoden sowie in verschiedenen Architekturmuster und -modelle.
Soft Skills: Neben den technischen Fähigkeiten sind auch Soft Skills, wie beispielsweise Kommunikationsfähigkeit, Teamfähigkeit und Problemlösungskompetenz, wichtig für eine erfolgreiche Karriere als Softwarearchitekt.
Wir sind ein Anbieter von Schulungen und Trainings im Bereich der Softwareentwicklung und -architektur, der auch Trainings und Schulungen vom iSAQB (International Software Architecture Qualification Board) anbietet. Der iSAQB ist eine unabhängige Organisation, die sich der Entwicklung und Zertifizierung von Standards im Bereich der Softwarearchitektur verschrieben hat.
Wir bieten verschiedene Trainings und Schulungen vom iSAQB an, darunter:
Certified Professional for Software Architecture (CPSA): Dieses Training bietet eine umfassende Einführung in die Grundlagen der Softwarearchitektur und vermittelt Kenntnisse in verschiedenen Architekturmuster und -technologien. Am Ende des Trainings kann eine Prüfung abgelegt werden, um das CPSA-Zertifikat zu erhalten.
CPSA-Advanced: Dieses Training baut auf dem CPSA-Grundkurs auf und vermittelt vertiefte Kenntnisse in verschiedenen Architekturthemen wie Softwarequalität, Business-Prozess-Management und IT-Sicherheit.
Alle Trainings und Schulungen bei tectrain werden von erfahrenen Trainern durchgeführt und bieten eine Kombination aus theoretischen Grundlagen und praktischen Übungen. Die Teilnehmer haben die Möglichkeit, ihre Kenntnisse und Fähigkeiten zu erweitern und ein anerkanntes Zertifikat im Bereich der Softwarearchitektur zu erwerben.
Lernen ist ein lebenslanger Prozess und spielt eine wichtige Rolle in der persönlichen und beruflichen Entwicklung. Auch oder gerade für Softwareentwickler ist es von großer Bedeutung, stets auf dem aktuellen Stand der Technologie zu bleiben. Neben praktischer Erfahrung und Online-Tutorials können Bücher eine ausgezeichnete Ergänzung darstellen, um dein Wissen zu erweitern und neue Inspirationen zu finden. In diesem Artikel über die spannendsten iSAQB Bücher werden fünf faszinierende Bücher über Softwarearchitektur vorgestellt, die du auf jeden Fall lesen solltest.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. und Angel, S.: A Pattern Language: Towns/Buildings/Construction. Oxford University Press, New York, 1977.
Bardram, J.E., Christensen, H.B., Corry, A.V., Hansen, K.M. und Ingstrup, M.: Exploring Quality Attributes using Architectural Prototyping. In: Proc. First International Conference on the Quality of Software Architectures (QoSA 2005), LNCS, Erfurt, Germany, September 2005. Springer-Verlag.
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R. und Stafford, J.: Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002.
Conrad, S., Hasselbring, W., Koschel, A. und Tritsch, R.: Enterprise Application Inte¬gration. Spektrum Akademischer Verlag, 2006.
Fowler, M., Rice, D., Foemmel, M., Hieatt, E., Mee, R. und Stafford, R.: Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
GI-Arbeitskreis: Software-Architekturen. se.informatik.uni-oldenburg.de GIAKSoftArch/.
Hasselbring, W.: Modelling Software Architectures. In: Paech, B. und Desel, J. (Hrsg.): Tagungsband zur Modellierung 2005, Seite 47, Heidelberg, März 2005. www.es.tu-darmstadt.de/gi-modellierung/archive/GesamtberichtMod2005.pdf. IEEE: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, 2000. IEEE Standard 1471-2000.
Jeckle, M., Rupp, C., Hahn, J., Zengler, B. und Queins, S.: UML 2 glasklar. Hanser Fachbuchverlag, 2005.
Jung, H.-W., Kim, S.-G. und Chung, C.-S.: Measuring Software Product Quality: A Survey of ISO/IEC 9126. IEEE Software, 21 (5):88-92, 2004.
Medvidovic, N. und Taylor, R.N.: A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engi¬neering, 26(1):70-93, Januar 2000.
Nückles, M., Gurlitt, J., Pabst, T. und Renkl, A: Mind Maps und Concept Maps: Visualisieren - Organisieren - Kommunizieren. Beck-Wirtschaftsberater im dtv, München, 2004.
Pfister, C. und Weck, W.: How to Fit the Architect into the Project Team? In: Balzer, B. und Obbink, H. (Hrsg.): Fourth International Software Architecture Workshop (ISAW-4), S. 27-30, Limerick, Ireland, Juni 2000.
Quibeldey-Cirkel, K.: Entwurfsmuster - Das aktuelle Schlagwort. Informatik Spektrum, 19(6):326-327, 1996.
Reussner, R. und Hasselbring, W. (Hrsg.): Handbuch Software-Architektur. Dpunkt Verlag, 2006.
Richter, J.-P., Haller, H. und Schrey, P.: Serviceorientierte Architektur - Das aktuelle Schlagwort. Informatik Spektrum, 28(5):413-416, 2005.
Steinmetz, R. und Wehrle, K.: Peer-to-Peer-Networking & -Computing - Das aktuelle Schlagwort. Informatik Spektrum, 27(1):51-54, 2004.
Du suchst nach einer Schulung für ein ganzes Team, aber keines unserer Trainings entspricht Deinen Anforderungen? Kein Problem! Gerne konzipieren wir gemeinsam mit dir ein maßgeschneidertes Inhouse-Training, das optimal auf die Bedürfnisse deines Unternehmens zugeschnitten ist. Wir freuen uns auf deine Anfrage!
