1. Modellierung
   1. UML
   2. Prozesse/eGPM
      1. Arbeitsplatztypen
         1. Erste Abstraktion über die konkreten Arbeitsplätze
         2. Flexible erledigung vielfältiger Aufgaben
         3. Sachbearbeitungsplatz
         4. Funktionsarbeitsplatz
      2. Kooperative Arbeit
         1. Verschiedene Personen arbeiten geplant und koordiniert zusammen, um ein gemeinsames Ergebnis zu erreichen.
         2. Herstellung eines Produkte
         3. Verständigung was von wem wie gemacht wird
         4. Begrenzte Ressourcen
         5. Arbeitshandlungen müssen abgestimmt werden
      3. eGPM
         1. Exemplarische Geschäftsprozessmodellierung
         2. objektorientiert
         3. szenariobasiert
         4. ADONIS
         5. grafisch
         6. Prozesse
            1. Wer sind die Akteure?
            2. Was tun sie typischerweise in welcher Reihenfolge?
            3. Mit wem arbieten sie zusammen?
            4. Wann geben sie die Gegenstände an wen weiter?
            5. Bei welchen Tätigkeiten werden Sie von der EDV unterstüzt? Wie?
         7. Basiert auf:
            1. Aktueren
            2. Gegenständen
            3. Aktionen
         8. Metamodell
            1. Wer bearbeite was womit wazu
            2. 3+1 Modellierung
            3. Kooperationsszenarios
            4. mehrere Akteure , ein Geschäftsprozess
            5. Arbeitsplatzszenarios
            6. Arbeitsablauf
            7. IT - Interaktionsszenarios
            8. Akteur und IT Tätigkeit
         9. Kooperation durch
            1. wer gibt Gegenstand weiter -an
         10. Koordination durch
             1. wer informaiert mit Gegenstnad/Medium - wen?
             2. Unterscheidung
             3. IMpliziete Kooperation
             4. Zugriff auf gemeinsames Arbeitsmaterial
             5. Expliziete Kooperation
             6. Koordination ist Beschrieben und modelliert
             7. z.b. durch Laufzettel
   3. Modellierungsansätze
      1. Verhaltensorientierte Modellierung
         1. Einsatzkontext wird in der Dynamik betrachtet
         2. Frage: Was sind die Aufgaben des Systems? Welche Gegenstände werden bei den Aufgabe wie verwendet und bearbeitet?
         3. Herangehensweise: Szenarios erstellen und daraus Ober- und Unterbegriffe identifizieren und das Begriffsmodell daraus ableiten.
         4. Begriffmodell ist unmittelbar aus den Szenarios abgeleitet
         5. Daten werden in Klassen gekapselt und die Konsistenz dort sichergestellt
      2. Datenorientierte Moedellierung
         1. Einsatzkontext wird strukurell betrachtet
         2. Frage: welche Daten müssen im System verwaltet werden? Welche Daten charakterisieren die Gegenstände des Systems?
         3. Herangehensweise: Gegenstände modellieren, mit Vererbungshierachien
            1. nicht sehr Änderungsfreundlich
            2. fachlich schwer zu verstehen
         4. Begriffshierachien entsprechen nicht den des Anwendungsgebiets
         5. Konsistenzmodelle
            1. mehrfache überprüfung
            2. einmalige in Unteren Schichten und Exceptions für höhere
      3. Unabhängig von der Programmiersprache und der Vorgehensweise
      4. Objektorientiert
      5. Modell
         1. Projektion
         2. Reduktion
         3. pragmatisch
2. Qualität
   1. Software Qualität
   2. Kundenzufriedenheit
   3. Kano-Modell der Kundenzufriedenheit
   4. Qualitätsbegriffe
      1. transzendente Ansatz
      2. produktbezogene Ansatz
      3. benutzerbezogene Ansatz
      4. prozessbezogene Ansatz
      5. Der KostenNutzenbezogene Ansatz
      6. Unterscheidungen
         1. Externe und interne Qualität
   5. zuverlässigkeit
      1. korrektheit
      2. Robustheit
   6. wartbarkeit
      1. Bedingt durch
         1. Verständlichkeit
         2. Zuverlässigkeit
3. Architekturstile
   1. SOA
      1. Service
   2. Quasar
      1. T/A
      2. Besteht aus
         1. Prinzipien
         2. Architektur
         3. Komponenten
      3. Trennen von Zuständigkeiten
         1. Blutgruppen
            1. 0
            2. Unabhängig
            3. A
            4. fachlich
            5. T
            6. technisch
            7. R
            8. Transformation
            9. AT
            10. C
            11. Konfiguration
      4. Komponente
         1. Klare Definition der angebotenen Dienste (Export-Schnittstellen) Semantik der Schnittstellen
         2. • Klare Definition der Abhängigkeiten von Diensten anderer Komponenten (Import-Schnittstellen).
         3. • Jede Komponente versteckt die Implementierung: Austauschbar
         4. • Die Komponente macht nur minimale Annahmen über die Umgebung, in der sie läuft: Wiederverwendung
         5. • Man kann neue Komponenten aus vorhandenen Komponenten zusammensetzen
         6. • Die Komponente ist neben der Schnittstelle die wesentliche Einheit des Entwurfs, der Implementierung und damit der Planung
      5. Datenhoheit
         1. exklusives Recht Daten anlegen, ändern oder löschen
   3. Vorlagen
   4. Definition
      1. eine prinzipielle Lösungsstruktur , die für ein Softwaresystem durchgänig und unter weitgehendem Verzicht auf Ausnahmen angewandt wird
   5. Merkmale
      1. Verständlich
      2. Realisierbar
      3. Erweiterbar
      4. Skalierbar
   6. WAM
      1. Kundenoritierung
         1. Unternehmensstruktur
         2. Unternehmenskultur
            1. Gelebte Kundenorientierung
         3. Geschäftsprozesse
         4. Ziele
            1. Kundenzufiriedenheit verbessern
            2. langfristige Kundenbindung
            3. Unternehmenserfolg sicherstellen
      2. Komponenten
         1. Materialien
            1. fachliche Funktionalität
            2. Konzeptionelle Einheit
            3. Materialzustand
         2. Automaten
            1. Formalisierbaren anteile einer Routine
            2. feste Abfolge
            3. festgeleges Ergebniss
            4. ohne Unterbrechungen
         3. fachlicher Service
            1. Fachliches Wissen wird zusammengefasst und allen Benutzungsschnittstellen unter einer Schnittstelle angeboten
            2. Topic
            3. oder Dienstleister
            4. bietet einer Zielgruppe ein Dienstleistungsbündel an
            5. synchron oder asynchron
            6. hierachiche Beziehungen zwischen fachlichen Services
            7. Schnittstelle
            8. ist individuell, weil fachlich motiviert
            9. Methoden werden als atomar angesehen sind zustandslos
         4. Werkzeuge
            1. Funktionalität
            2. Werkzeugzustand
            3. verkörpern das fachliche Prinzip, nach dem Aufgaben erledigt werden.
            4. Kriterien
            5. Automatisierung
            6. Kapselung technischer Schnittstellen
            7. Steuerung von Arbeitsprozessen
            8. Abbildung von technischen Prozessen
         5. Fachwerte
            1. Immutable
            2. Garantie der Wertesemantik
            3. benutzerdefinierte Werte, die Werte im Anwendungsbereich modellieren
            4. Definierter Wertebereich
            5. festgelegte Operationen
      3. Zyklisches Vorgehen mit Prototyping
      4. Architekturelemente
         1. Aus WAM Metaphern werden Entwurseinheiten
4. Architekturen
   1. Definition
      1. Die Struktur eines Software-Produkts. Diese umfasst Komponenten, die externe wahrnembaren Eigenschaften der Elemente und die Beziehung zwischen den Elementen.
   2. Sichten auf Software (Architekturen)
      1. Analogie Haus
         1. Jeder Handwerker benötigt einen eigenen Plan
      2. Arten von Sichten
         1. Verteilungs
            1. Rechner
            2. Prozesse
         2. Statische
            1. Schichten
            2. Subsysteme
            3. Verantworlichkeiten
         3. Dynamisch
         4. Fachliche
            1. Einsatzkontext
         5. Laufzeitschicht
            1. Interaktion
            2. Performanz
      3. Eigenschaften
         1. Abstraktion
         2. Komplexität wird handhabbar
         3. Verschiedene Sichten sind nicht völlig unabhängig
         4. Konsistenz
            1. Widerspruchsfrei
      4. Sichten und UML
   3. Sprachen
   4. Warum ist Architektur wichtig?
      1. Verstehen und Kommunikation
      2. Wiederverwendung
      3. Konstruktion
         1. Grober Bauplan für Entwickler
      4. Evolution
         1. Verstehen unterstützen (Wartung)
      5. Analyse
      6. Management
         1. Architektur ist Grundlage für Projektorganisation
   5. beschreibt nur Außensicht der Komponenten
   6. =Komponenten +ihre externen Eigenschaften +ihre Beziehungen
5. Prinzipien
   1. Architekturprinzipien
      1. Hierachische Schichten
         1. Vertikale und horizontale
      2. Dienstleister / Vertragsmodell (Design by contract)
         1. Im Objektorientierten Modell fehlt die Spezifikation der Semantik
            1. der Kunde einer Klasse sieht nur die Schnittstelle
         2. erlaubt Operationen halbformal zu spezifizieren
         3. hilft Schnittstellen klar zu definieren
         4. hilft Entwurf und Konstruktionsfehler zu reduzieren
            1. damit wird die Korrektheit verbessert
         5. hilft die Verständlichkeit zu erhöhen
         6. Hoare Kalkül
            1. Verfahren um korrektes Verhalten einer Prozedur zuzusichern
            2. Vorbedingungen
            3. Nachbedingungen
            4. Invarianten die immer gelten
         7. Die Benutzbeziehung zwischen Klassen wird als Vertrag angesehen
            1. Eine Klasse bietet eine Dienstleistung an
         8. Der Vertrag definiert
            1. welche Vorbedingung erfüllt sein muss
            2. Dienstleistung wird garantiert
            3. wird in der Lieferantenklasse festgelegt
      3. Geheimnissprinziep
      4. Zyklenfreiheit
         1. Aus Zyklen folgt...
            1. Komponenten können nicht ausgetauscht werden
            2. Komponenten können nicht einzeln getestet werden
      5. HIgh Level
   2. Entwurfsprinzipien
      1. Entwurf nach Zuständigkeit
         1. Jedes Objekt sollte für eine klar definierte Ausgabe zuständig sein
         2. Separation of Concerns
      2. Geheimnisprinzip
         1. Verwand mit
            1. Lokalität
            2. Kapselung
         2. Nur relevante Merkmale sollten für Klienten sichtbar sein
         3. Details sollten verborgen bleiben
      3. Kohäsion / Zusammenhalt
         1. Anzahl und Verschiedenheit der Aufgaben , die eine Softwareeinheit zu erfüllen hat.
         2. Wenn eine Einheit für genau eine logische Aufgabe zuständig ist, dann sprechen wir von hoher Kohäsion
         3. Eine Klasse sollte genau eine klar umrissene Einheit repräsentieren
         4. Gott Klassen sind Zeichnen niedriger Kohäsion
      4. Lose Kopplung
         1. erleichtert die Wartung
         2. Unterscheiung
            1. impliziete
            2. schlimmer weil nicht nachweisbar. Entwickler implementiert Interna eines Dienstleisters in Klientenklasse
            3. expliziete
            4. formal Nachweisbar
         3. bezeichnet den Grad der Abhängigkeit zwischen den Einheiten
      5. Trennung Impl./Schnittstelle
      6. Modellierung anwendungsfachlicher Klassen
         1. Abstraktion der Domäne
         2. Nah am Anwendungsbereich
      7. Modellierung technischer Klassen
         1. Modellierung von
            1. Oberflächen
            2. Persistenz in Datenbanken
            3. Verteilung
      8. Kapselung
         1. Entscheidungen die sich mit hoher Wahrscheinlichkeit ändern können, sollten gekapselt werden um leicher austauschbar zu sein
      9. Law of Demeter
         1. Methode m eines Objektes o sollte nur Methoden von... aufrufen
            1. von o selbst
            2. von Parametern von m
            3. von Objekten, die m erzeigt
            4. von Exemplarvariablen von o
         2. Getter imd Setter als Verstoss
      10. SRP (Prinzip der einen Verantwortlichkeit)
      11. OCP(Offen-Geschlossen)
          1. Offen für Erweiterungen
          2. Geschlossen für Modifikationen
          3. Erweiterung sollen ohne Änderung des bestehenden Quellcodes möglich sein
      12. Liskov's Prinzip der Ersetzung
          1. Klassen sollen in jedem Fall durch alle Unterklassen ersetzbar sein
          2. Unterklassen haben keine...
             1. stärkeren Vorbedingungen
             2. schwächeren Nachbedingungen
      13. Dependency Inversion Principle
          1. Program to an Interface not an implementation
      14. Inversion of Control
          1. Don't call us, we'll call you
          2. Kontrollfluss geht vom Framework aus
      15. Dependency Injection
          1. Abhängigkeiten werden von außen gesteuert
          2. Typen
             1. Interface injection
             2. setter injection
             3. constructor injection
          3. Testgetriebene Entwicklung wird gefördert
          4. Abhänigkeiten reduziert
      16. Low Level
6. Entwurfsmuster
7. Vorgehensmodelle
   1. Wasserfallmodell
      1. Grundproblem der Kundenzufriedenheit
8. Wie soll die Lücke zwischen Anforderungen und dem lauffähigen System überwunden werden?
9. Architekturanalysen
   1. Architureller Zerfall
   2. Kosten durch Architektur-Erosion
   3. Maßnahmen gegen Degeneration
      1. Refactoring
      2. Portierung auf neue Technologien
      3. Weiterbildung der Entwickler
      4. Regelmäßige Analysen
   4. Werkzeuge
      1. Sotograph
      2. SonarJ
   5. Zyklenanalye
   6. Analyse auf Unterschiedlichen Abstraktionsniveau
   7. Metriken
      1. Bildet Softwareeinheiten in einen Zahlenwert ab
   8. Architekturvermessung
      1. Konkrete Refaktorisierungsmassnahmen
      2. Schrittweise Näherung an die Zielarchitektur
10. Integration
    1. Funktionalität, die über mehrere Applikationen verteilt ist zusammenführen.
    2. Ansätze
       1. File Transfer
          1. Vorteile
             1. Einfach zu realisieren
             2. Auf allen Plattformen und in allen Sprachen verfügbar
             3. Asynchron,
             4. Lose Kopplung
             5. Kaum Eingriff in die Applikation, um den Export zu realisieren
             6. Internas der Applikation bleiben verborgen
          2. Nachteile
             1. Inkonsistenz zwischen Applikationen wegen großer Zeitintervalle zwischen den Updates
             2. Semantik der Daten wird in jeder Applikation festgelegt
             3. Absprachen zwischen den Entwicklern
       2. Shared Database
          1. Vorteile
             1. Zeitgleiche Updates
             2. Transaktionsmanagement
             3. Hohe Verbreitung von sql
             4. Datenbestand ist konsistent und synchron
             5. weniger semantische Dissonanz
             6. Zwang zu guter Datenmodellierung über Applikationsgrenzen hinaus
          2. Nachteile
             1. Deisgn eines universellen DatenbankSchemas ist schwierig
             2. Bei verteilten Applikationen wird die Datenbank zum PerformanzProblem
             3. Daten werden ungekapselt ausgetauscht
             4. Hohe Kopplung
       3. Remote Procedure Invocation
          1. Vorteile
             1. Funktionalität wird wiederverwendet
             2. Daten sind lokal gekapselt
             3. Potentiell weniger Codeverdopplung
          2. Nachteile
             1. Enge Kopplung
             2. Performanz und Ausfallsicherheit muss beachtet werden
             3. Sich gegenseitig aufrufende Applikationen knnen Verwirrung stiften
       4. Messaging
          1. synchron vs asynchron
    3. Enterprise Integration
       1. Anforderungs Landschaften
       2. Patterns
       3. Problem: Alt und Fremdsysteme haben softwaretechnisch nicht zueinander passende Schnittstellen
          1. oder Unterschiedliche Abstraktionsgrade in Alt- und Fremdsystemen
       4. Lösung: Enterprise Integration Patterns als gemeinsame Konvention
11. IT - Landschaften
    1. Die Anwendungslandschaft eines Unternehmens ist die Gesamtheit seiner betrieblichen INformationssysteme.
    2. Unternehmensarchitektur
       1. Gesamtes UNternehmen mit Architektur beschreiben
    3. Software Kartographie
       1. Konzeote aus Kartographie und Praxis großer Unternehmen
12. Software Architekt
    1. Gestalter
       1. Entwurf
    2. Berater
    3. Konstrukteur
       1. Planung und Organisation
    4. Manager
       1. Bauüberwachung
    5. Ausbildung
    6. Aufgaben
       1. Vorstellungen des Bauherren mit Bauvorschriften in Einklang bringen
       2. füllen der Lück zwischen fachlichen Anforderungen und technischer Realisierung
    7. Hohe Abstraktion
13. Architekturzentrierte Softwareentwicklung
    1. Evolution (Änderungen)
       1. Anforderungen des Anwenders
       2. Voraussetzung der Systemtechnik
    2. Konsequenz
       1. System und Architektur werden während des gesamten Entwicklungsprozesses weiterentwickelt
    3. Mechanik von Refactorings
       1. knappe präzise schrittweise Beschreibung, wie das Refactoring ausgeführt werden soll
       2. nach jedem Schritt soll ein konsistenter Zustand herrschen
       3. möglichste kleine Schritte
       4. danach: automatisierte Tests
    4. Anforderungen
       1. Kenntnisse über Architekturstile, entwurfsmuster und Entwurskriterien
       2. Wissen über Entwicklungstechniken wie Testen Refoctoring und dem Umgang mit ungetestetem Code
       3. muss vom Anfang des Wntwicklungsprozesses an durch Strategien unterstützt werden