SWEN2
swen2
swen2
Fichier Détails
| Cartes-fiches | 100 |
|---|---|
| Utilisateurs | 24 |
| Langue | Deutsch |
| Catégorie | Informatique |
| Niveau | Université |
| Crée / Actualisé | 21.05.2019 / 09.06.2021 |
| Lien de web |
https://card2brain.ch/cards/20190521_swen2?max=40&offset=80
|
| Intégrer |
<iframe src="https://card2brain.ch/box/20190521_swen2/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
ARCHITEKTUR: Sie haben den Artikel «Evolutionary architecture and emergent design: Investigating architecture and design, by Neal Ford» gelesen und können den Inhalt in groben Zügen erklären.
https://www.ibm.com/developerworks/java/library/j-eaed1/index.html
Über Architektur wird viel gesprochen, wenige verstehen es aber. Im Artikel wird zwischen Enterprise und Applikationsarchitektur unterschieden. Applicationarchitektur kümmert sich darum, wie eine Software aufgebaut ist. Enterprisearchitektur hingegen wie die Software innerhalb einer Firma läuft.
Viele Personen haben versucht den Begriff Softwarearchitektur zu definieren. Allerdings gibt es viele verschiedene Meinungen.Der Autor findet folgende Definition am besten: "Stuff that's hard to change later". Darum wird auch evolutionäre Architektur bevorzugt. (Schwierige Designentscheidungen so spät wie möglich vornehmen).
Jedes neue Feature erzeugt "technical debt". Neue Features hinzuzufügen ist einfach, sie wieder zu entfernen hingegen schwer.
Software besitzt notwendige Komplexität und versehentliche Komplexität. (accidental komplexity). Diese wird vor allem durch drei Dinge hervorgerufen: Hacks im Code, Code Duplikation, und technical debt.
Software ist häufig overengineert weil sie zu generisch ist. Man muss das perfekte Mittelmass finden.
JPA: ORM
Objektrelationale Abbildung ist eine Technik, mit der ein in einer OO geschriebenes Programm seine Objekte in einer relationalen Datenbank ablegen kann. Dem Programm erscheint die DB dann als Objektorientierte Datenbank.
Es ist ein umstrittenes Thema da der relationale und der OO Ansatz unterschiedlich sind und es zum OR Mismatch führt
JPA: O/R Mismatch
Objekt-Relation Mismatch folgt aus konzeptionellen Unterschieden der zugrundeliegenden Technologien.
Designziele:
- DB: Speichern und Abfrage von Daten unabhängig von Businesslogic
- OO: Abstraktion, Kapsleung, modellierung der konkreten Businesslogic
Architekturansätze:
- DB: Verteiltes System
- OO: Objekte sind lokal und nicht verteilt
Zugriff:
- DB: Deklarative Abfragesprache. Beziehung zwischen Daten nicht explizit definiert
- OO: Imperativ. Beziehung zwischen Daten müssen definiert sein
JPA: Domain Model
Zentralisierung und lokalisierung von Business Logik (DRY).
Modell der Objekte welche benötigt werden um diese Businesslogik zu erreichen.
JPA: POJO
Plain Old Java Object
Beinhaltet mehr als nur getter und setter (logik)
Sollte nicht bestehende Javaklassen erweitern, bestehende interfaces implementieren oder bestehende Annotationen benutzen.
JPA: Location Transparency
Alle Daten immer verfügbar. Für die Applikation soll es egal sein ob die Daten im Cache oder in der DB sind.
JPA: Entity Mapping
Beim Entity Mapping geht es darum, einem Objekt aus dem System eine ID aus der Datenbank zuzuweisen. So weiss das System, welche ID im zugrundeliegenden RDBMS zu einem Objekt gehört. Dies mittels Annotations passiert wie folgt:
SOLID: Dependecy Injection
Dependencies werden zur Runtimes injected und nicht von den Objekten selber initialisiert. Dies erlaubt bessere Testbarkeit und einfache Austauschbarkeit einzelner Komponenten wie DB, Logger etc
Java Spring ist ein Beispiel.
SOLID: Nenne die Namen aller 5 Solid Prinzipien
- Single responsibility
- Open closed principle
- Liskovsche Substitution
- Interface Segregation Principle
- Dependency Inversion
SOLID: Single Responsibility
Jede Klasse und Methode sollte nur eine einzige Verantwortung haben. Eine Klasse / Methode sollte sich in einem Satz ohne "und" beschreiben lassen.
Errorhandling und Logging sind auch verantwortlichkeiten!
SOLID: Open Closed Prinzip
Eine Modul sollte offen für Erweiterungen und geschlossen für Veränderungen sein.
Einfaches Beispiel: Eine Methode die immer "Hello World" printet. Will man diese Nachricht nun ändern, muss man das direkt im Code machen. Übergibt man die Message hingegen als Argument erfüllt diese Methode das OC Prinzip
SOLID: Liskovsches Substitutionsprinzip
Falls S ein Subtyp von T ist, dann sollten alle Objekte vom Typ T mit dem Typ S ersetzt werden können.
Dieses Prinzip kann leicht verletzt werden. Daher sollte komposition statt vererbung bevorzugt werden.
SOLID: Interface Segregation Prinzip
Dient dazu grosse Interfaces aufzuteilen. Klassen sollten nur die Interfaces implementieren die sie auch wirklich benötigen. Damit wird die Software stärker entkoppelt und besser refaktorisierbar.
SOLID: Dependency Inversion
Soll die Kopplung reduzieren. Module hoher Ebenen sollten nicht von Modulen niedriger Ebenen abhängen. Beide sollten von Abstraktionen abhängen.
Business Logik sollte z.B: nicht abhängig von der Datenbank sein.
KANBAN: Limited WIP
Limit Work in Progress. Maximalanzahl von erlaubten Tasks pro Spalte des Kanbanboards.
KANBAN: Visualize the workflow (Kanban Board)
Kanban Board wie Trello. Tasks in verschiedene Aufgaben wie Todo, Dev, Testing etc unterteilen
KANBAN: Cumulative Flow Diagramm
Visualisiert die stabilität des Prozesses über Zeit.
KANBAN: Lead Time
Lead time startet wenn ein Request gemacht wurde und endet wenn dieses Feature ausgeliefert wurde. Lead Time ist das, was der Kunde sieht.
KANBAN: Cycle Time
Durchschnittliche Zeit um ein Item fertigzustellen.
KANBAN: Waste in Software Development
Drei Arten von Waste:
- Waste in code development (defekter code, keine tests suites)
- Waste in project management (unnötige dokumentation, sitzungen etc)
- Waste in workforce potential (multitasking, entwickler können nicht arbeiten weil sie auf infos warten etc.)
Das Ziel ist es möglichst alles zu entfernen was kein Business Value bringt.
