Software Architecture

Questions about general software architecture.

Questions about general software architecture.


Subhan Waizi
This flashcard set covers university-level software architecture concepts. It delves into quality attributes, OSI model layers, agile methodologies like Kanban and Scrum, and traditional models such as the V-Model and Waterfall. The flashcards also explore security principles, software qualities, and design patterns. Ideal for computer science students and professionals, this flashcard set provides a comprehensive overview of software architecture principles and practices, enhancing understanding and application in real-world scenarios.
Karten
33
Lernende
1
Sprache
Englisch
Kategorie
Informatik
Stufe
Universität
Erstellt / Aktualisiert
06.01.2021 / 09.01.2021

Lernkarten

What does S.O.L.I.D. stand for? What are its principles?

S.O.L.I.D ist eine Abkürzung für die ersten five objektorientierten design Prinzipien, die don Robert C. Martin definiert wurden.

  • S - single-responsibilility principle - Eine Klasse sollte wenn überhaupt max. einen Grund haben sich zu ändern. In anderen Worten ... eine Klasse sollte nur für eine Aufgabe verantwortlich sein.
  • O - Open-closed principle - Objekte sollten Erweiterungen erlauben (open) aber Modifikationen (closed) nicht zulassen. 
  • L - Liskov substitution principle - Das Prinzip definiert, dass Objekte einer "Superklasse" ersetzbar sein sollten, durch die Objekte dessen Subklassen, ohne das System zu brechen bzw. zum Einsturz zu bringen. Das erfordert natürlich, dass die Objecte der Subklassen sich genauso verhalten, wie die Objekte der Superklasse. "Let q(x) be a property provable about objectx of x of type T. Then q(y) should be provable for objecty y of type S where S is a subtype of T."
  • I - Interface segregation principle - Ein Client sollte nicht gezwungen werden, interfaces zu implementieren, die es nicht verwendet. Weiterhin sollte ein Client nicht gezwungen werden sich von Methoden abhänging zu machen, die es nicht verwendet. 
  • D - Dependendy Inversion Principle - Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

What is the CAP theorem?

  • The CAP theorem for distributed computing was pusblished by Eric Brewer
  • Das CAP theorem sagt aus, dass es innnerhalb eines verteilten Rechnersystems nicht möglich ist alle drei Garantien des CAP theorems zu erfüllen. 
  1. Consistency - alle Knoten sehen die selben Daten und bei einem Update, bleibt diese Eigenschaft bestehen 
  2. Availability - jede Anfrage erhält eine Antwort - unabhängig ob diese positiv oder negativ ist
  3. Partition tolerance - das System ist verfügbar trotz Fehler (Nachrichtenverluste) oder Fehler in (Teil-)system(en)
  • Das CAP Acryoknym korrespondiert zu diesen drei Garantien und hat sich als Grundlage etabliert für verteilte Rechnersysteme
  • Firmen, die das höchste Verkehrsaufkommen haben (Amazon, Google, Facebook) verwenden das CAP theorem, um ihre Entscheidung bzgl. Architektur des CAP Theorems zu treffen.

What is BASE property of a system?

BASE Eigenschaften sind die generellen Eigenschaften von "kürzlich" entstandenen noSQL Datenbanken. Nach dem CAP Theorem, garantiert ein BASE System keine Konsistenz. BASE ist ein zusammengesetztes Akronym, dass sich auf folgende Eigenschaften eines Systems in Zusammenhang mit dem CAP Theorem bezieht:

  • Basically available besagt, dass das System zu allen Zeitpunkten "verfügbar" ist
  • Soft state besagt, dass der Zustand des Systems sich über die Zet hinweg ändern kann - auch ohne neue Eingaben. Das ist hauptsächlich wegen des "eventual consistency" Modells.
  • Eventual consistency besagt, dass das system über die Zeit hinweg konsistent wird, vorausgesetzt es erhält keine neuen Eingaben. 

What are Heuristic Exceptions / Decisions?

Eine Heuristisce Exception bezieht sich auf die Entscheidung einen Teilnehmers einer Transaktion. Es wird eine Entscheidung getroffen, ohne den Konsens des Transaktion Managers - meistens als Folge eines katastrophalen Fehlers zwischen dem Teilnehmer der Transaktion und dem Transaktion Manager.

In einem verteilen Rechnersystem können Kommunikationsfehler auftreten. Wenn die Kommunikation zwischen dem Participant / der involvierten Resource innerhalb einer bestimmten Zeit nicht möglich ist, kann die involvierte Resource entscheiden, die Veränderung durch die Transaktion entweder anzunehmen oder einen Rollback der Transaktion durchzuführen. Diese Entscheidung wird heuristic decision genannt und ist eine der schwerwiegendsten Fehlern, welche in einem Transaktionssystem auftauchen kann, da einige Teile der Transaktion durchgegangen sein könnten und andere durch Rollback wieder zurückgesetzt wurden. Dadurch wird das Gebot der "Atomizität" von Transaktionen gebrochen und Daten können korrupt sein bzgl. ihrer Integrität.  

Wegen der Gefahr von heuristic exceptions sollte die Resource, welche die heuristic Decision macht, die Informationen in einem stabilen (remanten) Speicher speichern und darauf warten, dass der Transaktion Manager diese freigibt oder einen Rollback fordert. Gelöst werden kann das durch eine Syten Managment Komponente, welche sich die Daten anschaut und bei Inkonsistenz Integritätsprobleme löst.

What is a shared nothing architecture? How does it scale?

Eine shared nothing (SN) Architektur ist ein Ansatz in verteilten Rechnersystem, bei dem jeder beteiligte Node in sich sich geschlossen (autark) und unabhängig von anderen Nodes ist. Es gibt keine Abhängigkeit zwischen den Nodes.

  • Nodes arbeiten selbstständig / unabhängig ohne abhängig zu sein von anderen Nodes im Netzwerk
  • Es werden keine Resourcen geteilt zwischen den Nodes (Speicher, File Storage, Caches, etc.)
  • Eine Störung auf einer Node hat nur Konsequenzen auf die Benutzer dieser einen Node - die anderen Nodes arbeiten weiter ohne jegliche Störung.

Dieser Ansatz ist höchst Skalierbar, weil Bottlenecks im System vermeidet. Die SN Architektur wird immer beliebter vor allem im Webkontext - eben wegen der Skalierbarkeit. Bei Firmen wie Google z.B. ist das schon sein einiger Zeit Stand der Dinge.

In theory, A shared nothing system can scale almost infinitely simply by adding nodes in the form of inexpensive machines.

What Does Eventually Consistent Mean?

 

  • Strict consistency stellt sicher, dass Transaktionen in einer Datenbank konsistent sind für alle Benutzer der Datenbank - der Zustand ändert sich sofort von einem validen Zustand zum nächsten.
    • Strict consistency wird gebraucht, für Use-Cases, wie z.B. Bankingsysteme. Hier muss der aktuelle Zustand der Datenbank bei allen Knoten valide und konsistent sein.
  • Im Gegensatz dazu verspricht eventual consistency, dass sich der Zustand der Datenbank nach einer Transaktion zu von einem validen Zustand zum nächsten validen Zustand wechselt - aber nicht sofort und nicht für jeden Knoten. Es gibt also Zwischenzustände, bei denen Knoten zwischnzeitliche Datensätze sehen, die sich voneinander unterscheiden können.
    • Eventual consistency können nützlich sein, wenn strict / absolute Konsistenz nicht erofderlich ist. Ein Bespiel hierfür wäre z.B. Facebook / Twitter. Wenn einige Nutzer Statusupdates anderer Nutzer nicht gleich sehen können sondern erst Sekunden später, wäre das kein schwerwiegendes Problem.

What is the definition of software architecture? - Maybe multiple different definitions?

Eine allgmeine Definition der Software Architektur, ist der Prozess, Software Charateristica, wie z.B. Usability, Skalierbarkeit, Wartbarkeit, Security, Erweitbarkeit, Portierbarkeit, etc. in eine strukturierte Lösung zu überführen, welche sowohl die Anforderungen und Erwartungen an die technischen als auch die Business Herausforderungen erfüllt. 

Another definition used by "Software Architecture in Practice - 3rd edition"

Die Architektur eines Systems ist das Set an Softwarestrukturen, die gebraucht werden, um das System zu erörtern. Das System an sich besteht dabei aus Software Elementen, Beziehungen zwischen diesen und Eigenschaften der Elemente und der Beziehungen.

What is a Load Balancer?

Ein Load / Last Balancer ist ein Gerät, welches Netzwerk- bzw. Applikationstraffic aufteilt auf ein Cluster von Servern. Load Balancing optimiert die System Responsivität und erhöht die Verfügbarkeit von Applikationen.

Ein Load Balancer sitzt zwischen dem Client und der Server Farm / Cluster, welche die einkommenden Anfragen an die bestehenden Server hinter dem Load Balancing System verteilt. Individuelle Serverlast wird dadurch vermieden und die Verfügbarkeit wird erhöht, da wir bei Ausfalls eines Servers immer noch die restlichen Server des Clusters haben.

See CDN

What are web application servers?

  • servers that accept client requests and answer them
  • client requests could be in form of data, files, pictures, html pages, etc.
  • in most cases the client is a browser
  • both client request and server response take the HTTP form (hypertext transfer protocol)

Database Servers?

  • ein Computer einem LAN mit der Aufgabe Speicher zur Verfügung zu stellen
  • der Datenbankserver besteht aus der eigentlich Datenbank (Speicher) und dem Database Management System (DBMS)
  • der Datenbankserver nimmt Anfragen von Clients entgegen und speichert ode liefert Speicher
  • Mechanismen wie Authentifizierung oder Authorisierung meistens nötig

What is a caching service?

 

  • hochperformanter Datenspeicher
  • nahe an der CPU gelegen
  • verschiedene Level (und entsprechend auch Geschwindigkeiten)
  • dafür ausgelegt Daten, die oft verwendet werdn oder Daten, die wsl. bald verwendet werden der CPU schnell zur Verfügung zu stellen
  • Nachteil: Determinismus bei einem Echtzeitsystem schwer einzuschätzen (Cache-Hits, Cache-Misses)

What are Job Queues?

“In system software, a job queue, is a data structure maintained by job scheduler software containing jobs to run. Users submit their programs that they want executed, “jobs”, to the queue for batch processing. The scheduler software maintains the queue as the pool of jobs available for it to run.”

  • Datenstruktur die on einer Job Scheduler Software kontrolliert wird
  • Enthält Speicher (eine Speicher Queue), die verschiedene Applikationen mit Jobs (Funktionen) füllen können
  • Applikationen können somit asynchron laufen und blockieren das System dadurch nicht
  • Batch / bulk processing einer großen Zahl an Jobs auch möglich (z.B. Verschlüssel mit Daten a - z mit Schlüssel x)

What is data?

  • heutzutage sind Daten digitales Gold
  • Firmen baseren teilweise darauf, ob und wie viel Daten sie aufgreifen, speichern und analysieren können
  • Wichtigkeit sieht man auch an den aufstrebenden Feldern wie Data Science und AI bei der die Daten zum Einsatz kommen
    • Beispiel: Data Science / Predictive Maintenance / Achse zieht zu viel

What is CDN?

  • Ein CDN (Content Delivery Network) bezieht sich auch auf eine geographisch verteilte Grupppe von Servern
  • Server arbeiten zusammen, um schnell Anfragen von Clients abhandeln zu können
    • files, images, HTML pages, javascript files, etc.
  • heutzutage läuft der Größteil des Datenverkehrs durch CDNs
    • Amazon, Netfix, Google, ...

See Load Balancer

What is cloud storage?

“Cloud storage is a cloud computing model that stores data on the Internet through a cloud computing provider who manages and operates data storage as a service. It’s delivered on demand with just-in-time capacity and costs, and eliminates buying and managing your own data storage infrastructure. This gives you agility, global scale and durability, with “anytime, anywhere” data access.” according to AWS.

  • Daten werden im "Internet" gespeichert - meistens durch einen Cloud Service Provider
    • im Internet heißt hier eig. genauso wie bei einem lokalen Datastorage Server, der aber einfach aus dem Internet erreichbar ist
  • Cloud Storage ist also eine Art Dienst des Cloud Storage Providers
  • Vorteil
    • Firmen mit Erfahrung in den Feldern (Serverausfälle selten!)
    • keine eigenen Anstrengungen nötig, eine eigne Infrastruktur aufzubauen und zu betreiben
    • "anytime, anywhere" data access
    • Bsp: AWS, Azure, etc.

What are the three most common types of sw Architektue problems you could face in an Interview. 

  • How would you design system X from scratch
  • How would you refactor system X
  • How would you debug/profile and fix application X

Goal:

  • have a systematic approach to the system (don't jump into solving the problem)
  • gather as much information as possible and ask as many questions before even start doing anything
  • get a clear picture of the problem with all the requirements - ask if they are broad or not clear

Welche Arten von Projektmanagement kennen Sie?

 

Projektmanagement Techniken haben allle die selbe Aufgabe - nämlich ein Projekt zu Ende zu bringen. Aber es gibt verschiedene Möglichkeiten und Projektmanagement und einzelne haben sich heutzutage durchgesetzt.

  1. Wasserfallmodell
  2. V-Modell
  3. Scrum
  4. Kanban
  5. ...

What are general methods of conceptioning and displaying Software- and Systemarchitectures?

UML am weitesten verbreitet:

Behavioural:

  • Aktivitätsdiagramm
  • Use Case Diagramm
  • Zustandsdiagramm
  • Seqenzdiagramm

Struktural:

  • Klassen- und Objektdiagramme
  • Komponentendiagramme
  • Deploymentdiagramme

https://tallyfy.com/uml-diagram/

Was ist funktionale Sicherheit?

  • definiert in der Normenreihe IEC 61508
    • bietet Grundlage für Vielzahl von Branchen und Anwendungsfeldern
  • als funktionale Sicherheit abgekürzt (FuSi) bezeichnet man die zuverlässige Erbringung der Sicherheitsfunktionen eines Systems
    • Erbring seiner Funktion selbst im Ernst- / Fehlerfall
  • funktionale Sicherheit kommt immer dann zum Einsatz, wenn Produkte, Anlagen oder Prozesse so kompex sind, dass deren Sicherheit auf einfachem Weg nicht mehr ausreichend getestet werden kann
  • Branchen:
    • Automobiltechnik
    • Kernkraft
    • Medizingeräte
    • Prozessindustrie
    • Haushaltsgeräte
    • Bahntechnik
    • Luftfahrt
    • Maschinen
    • Explosionsschutz

Beschreiben Sie kurz das Wasserfall Modell.

Das Wasserfallmodell erfreut sich heute immer noch großer Beliebtheit. Dabei werden große Projekte in mehrere Stufen / Phasen unterteilt:

  • Aufteilung großer Projekte in mehrere Stufen / Phasen (5-6), die aufeinander aufbauen und in einer bestimmten Reihenfolge durchgeführt werden
  • Gut planbar da klare feste Ziele für jede Phase (Meilensteine) 
  • Bei stabilen Anforderungen, ist das Budget meistens gut abschätzbar

Folgende Phasen:

  • Anforderungsanalyse
  • Systemdesign
  • Implementierung und Modultests
  • System- und Integrationstests
  • Auslieferung und Wartung

Nachteile:

  • großer Aufwand wenn Fehler erst später gefunden werden z.B. während des System- und Integrationstests
    • Wiederholung der einzelnen Phasen
  • Rückschritte und Iterationen können hier als Veränderung / Verbesserung das Problem beheben (Stichwort kaskadiertes Wasserfallmodell)
    • allerdings sinkt dadurch der Vorteil der Planbarkeit, wofür das Wasserfallmodell eigentlich steht

What are the differences between continuous integration, continuous delivery, and continuous deployment?

 

  • Entwickler, welche continuous integration praktizieren, mergen ihre (getestesten) Änderungen direkt in den main branch so oft wie möglich (bzw. sobald es Änderungen gibt). Dadurch wird das Chaos vermieden, dass Entwickler bis kurz vor Release Day warten, bis sie ihre Änderungen einchecken.
  • Continuous delivery ist eine Erweiterung der continuous integration, die sicherstellt, dass man Änderungen den Kunden so schnell wie mögiich auf eine kontinuierliche Weise zur Verfügung stellt. Das heißt, dass man neben der Automatisierung der Tests auch einen automatisierten release Prozess haben sollte (wenn möglich auf einem unabhängigen zentralen Server - z.B. Technologie Jenkins). Vereinfacht gsagt kann man dann durch einen Klick den Test- und Release Prozess anstoßen.
  • Continiuous deployment geht einen Schritt weiter als continious delivery. Mit dieser Methode, wird jeder erfolgreich getestester Release direkt dem Kunden bereitgestellt - ohne Interaktion eines Mitarbeiters.

What are acid transactions?

 

In computer science, ACID is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc. In the context of databases, a sequence of database operations that satisfies the ACID properties is called a transaction.

  • ACID Transaktionen ist ein Satz an Eigenschaften für Datenbank Transaktionen, die Validität und Konsistenz garantieren sollen, selbst im Falle von Fehlern, Spannungseinbrüchen, etc.
  • Im Rahmen von Datenbanken, definiert man die Sequenz von Datenbankoperationen, welche die ACID Eigenschaften erfüllen, als "Transaktion.

What is DDD (domain driven development)?

  • DDD (domain-driven design) ist ein Ansatz in der Softwareentwicklung für komplexe Anforderungen, indem die Entwicklung sich an ein "kopmlexes" Themengebiet anpasst / sich darauf vorbereitet.
  • Um gute Software und Softwarearchitektur generieren zu können, sollte man auf jeden Fall das Thema des Projektes kennen - bzw. worum es in der Software geht.
  • Z.B. ist es unmöglich als Softwareteam ein Bankingsystem zu entwickeln, wenn man vorher noch nie Bankingsoftware geschrieben hat

 

You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.

Which are the three basic design patterns you know?

  • structural
    • strukturelle Muster kümmern sich im allgemeinen um die Beziehung zwischen Entities
    • Aufgabe ist es, das Interfacing zwischen diesen Entities zu erleichtern
  • creational
    • creational Muster kümmern sich um Instantiierungsmechanismen
    • Aufgabe ist es, das Instantiieren von Objekten dem Use-Case entsprechend so effektiv und einfach zu gestalten, wie möglich
  • behavioural
    • behavioural Muster werden verwendet bei der Kommunikation zwischen Entities
    • Aufgabe ist es, due Kommunikation "effizienter / einfacher" aber auch flexibler zu gestalten

What are examples of design patterns?

Vijini Mallawaarachchi

  1. Layered pattern
  2. Client-server pattern
  3. Master-slave pattern
  4. Pipe-filter pattern
  5. Broker pattern
  6. Peer-to-peer pattern
  7. Event-bus pattern
  8. Model-view-controller pattern
  9. Blackboard pattern
  10. Interpreter pattern

 10 Common Software Architectural Patterns in a nutshell:

https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013

What are the Software-ilities?

Be able to explain them.

UMSAESP

  • Usability
  • Maintainability ( or Flexibility / Testability)
  • Scalability
  • Availability (or Reliability)
  • Extensibility
  • Security
  • Portability

What are the three main principles of security?

  • Integrity
  • Authenticity
  • Confidentiality

Beschreiben Sie das OSI-Modell. Beschreiben Sie eine Kurzzusammenfassung der einzelnen Schichten und deren Aufgaben.

Das ISO/OSI (Open Systems Interconnect Model) ist ein Referenzmodell für Netzwerkprotokolle als Schichtenarchitektur. Seit 1984 ist es ISO standardisiert.

Zweck des OSI-Modells ist, Kommunikation über unterschiedlichste technische Systeme hinweg zu beschreiben und die Weiterentwicklung zu begünstigen. Dazu definiert dieses Modell sieben aufeinanderfolgende Schichten (engl. layers) mit jeweils eng begrenzten Aufgaben.

Kurzzusammenfassung

7. Schicht / Anwendung: Funktionen für Anwendungen sowie die Dateneingabe und -ausgabe.

6. Schicht / Darstellung (Presentation): Umwandlung der systemabhängigen Daten in ein unabhängiges Format.

5. Schicht / Sitzung: Steuerung der Verbindungen und des Datenaustauschs.

4. Schicht / Transport: Zuordnung der Datenpakete zu einer Anwendung.

3. Schicht / Vermittlung (Network Layer): Routing der Datenpakete zum nächsten Knoten.

2. Schicht / Sicherung (Data Link Layer): Segmentierung der Pakete in Frames und Hinzufügen von Prüfsummen.

1. Schicht / Bitübertragung (Physical Layer): Umwandlung der Bits in ein zum Medium passendes Signal und physikalische Übertragung.[9]

Erläutern sie das V-Modell.

Ähnlich dem Wasserfallmodell wird das Projekt auch hier in Phasen aufgeteilt.

  • es gibt verschiedene Phasen und jeder Phase besitzt eine "komplementäre" Phase, welche diese Phase testen soll
  • linke Seite (Spezifikationsphase) - rechte Seite (Testphasen)
    • Systemanforderungsanalyse < > Abnahme und Nutzung
    • Funktionaler Systementwurf < > Systemtest
    • techn. Systementwurf < > Integrationsttests
    • Softwarearchitektur < > Komponentets
    • Software-Entwurf < > Unit/Modultests
  • Es wird also die Spezifikation ggn. die Testphasen getestet
  • Unterschied Wasserfall: Die Spezifikation von Testes wird bereits frühzeitig gefordert, und nicht, erst wenn die entsprechende Phase errreicht worden ist
    • z.B. Unit-Tests müssen bei der Spezifikation der Softwarearchitektur definiert werden

Vorteile:

  • erweiterbar und anpassbar
  • integriert viele Aspekte eines Projektentwicklungsprozesses

Nachteile:

  • nicht für kleine Projekte geeignet
  • man sagt, dass es zu allg. und zu generisch ist

Erläutern Sie Scrum.

Scrum ist eine agile Projektmanagementmethode mit den Hauptansätzen "empirisch", "inkrementell" und "iterativ". Es hat das folgende agile Manifest:

  1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
  4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Bei Scrum gibt es 3 Rollen:

  1. Product Owner
    • verantwortlich für die Eigenschaften und den wirtschaftlichen Erfolg des Projektes
  2. Entwicklungsteam
    • verantwortlich für die Lieferung der Produktfunktionalitäten, die in einer bestimmten Reihenfolge vom Product Owner vorgegeben werden
  3. Scrum Master
    • als Coach verantwortlich, dass das "Scrum" Rahmenwerk gelingt
    • Zusammenarbeit mit dem Entwicklungsteam - gibt aber keine Arbeitsanweisungen
    • kümmert sich um Störungen und Konflikte
  • Sprints
    • Sprints umfassen ein Zeitfenster von ca. 1 - 4 Wochen (Festlegung am Anfang und sollte nicht verändert werden). Er wird nicht verlängert. Sprints sind zu Ende wenn dasZeitfenster für den Sprint zu Ende ist.
    • Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird
      • er beginnt mit dem Sprint Planning und und endet mit dem Sprint Review -und -Retrospektive
  • Sprint Planning
    • Was kann im kommenden Sprint entwickelt werden
      • gemeinsames Verständnis soll geschaffen werden, für die i Sprint zu erledigende Arbeit
    • Wie wird die Arbeit im kommenden Sprint entwickelt
      • Planung des Entwicklungsteams, welche Aufgaben zum Errreichen des Sprintziels notwendig sind
  • Sprint Review
    • Die Sprint-Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen.
    • Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können

 

Erläutern Sie Kanban.

"Kanban - jap. Signalkarte"

  • Kanban ist eine agile Projektmanagementmethode, mit der man den Workfllow in Projekten optimaler planen, überwachen und steuern kannn
  • dabei gibt es eine adaptierte To-Do-Liste nämlich das Kanban Board
  • das Kanban Board stellt dabei Aufgaben, Verantwortlichkeiten und Abläufe innerhalb eines Projekts übersichtlich dar
  • Die Aufteilung gliedert sich in Spalten mit Einträgen zu Aufgaben, die man mit seinen Projektkollegen der Reihe nach arbarbeiten kann und bei Abarbeitung in die nächste Spalte verschieben kann
  • mit dem Kanban Board lässt sich schnell ein Überblick verschaffen, welche Aufgabe sich gerade in welchem Stadium befindet - dabei wird das ganze im Kanban Board visualisiert
    • Bsp: To-Do, Doing, Done (natürlich erweiterbar oder modifizierbar nach eigenen Anforderungen)

Beschreiben Sie die Schichten des OSI Modells im Detail.

1 – BÜS / PL

  • (De)aktivierung der physischen Verbindungen
  • Übertragung der Bits z.B. über elektr., opt., Signale
  • Protokolle: RS232, RS422

2 - Sicherung (DDL)

  • Aufgabe ist die zuverlässige, d.h. weitgehend fehlerfreie Übertragung zu gewährleisten und den Zugriff auf das Übertragungsmedium zu regeln
  • Aufteilen des Bitdatenstromes in Blöcke - auch als Frames bezeichnet - mit Prüfsümmen versehen (z.B. CRC)
  • BspHw: CSMA/CD

3 - Vermittlung (Network)

  • Routing bei paketorientierten Diensten für die (optimale) Weiterlerleitung zur Stauvermeidung
  • Kontrolle über dynamische Routingtabellen
  • Fragmentierung von Datenpaketen
  • IP, IPsec

4 - Transport

  • Segmentierung des Datenstromes, Stauvermeidung und die Sicherstellung fehlerfreien Übertragung
  • bietet den anwendungsorientierten Schichten 6-8 einen einheitlichen Zugriff, so dass diese die Eigenschaften des Kommunikationsnetzes nicht zu berücksichtigen brauchen
  • Bsp: TCP, UDP

5 - Session

  • Verbindungsauf- und abbau
  • um Zusammenbrüche der Sitzung und ähnliche Probleme zu beheben stellt die Situngsschicht Dienste für eienen organisierten u. synchronisierten Datenaustausch zur Verfügung

6 - Darstellung (Presentation)

  • Umsetzung der systemabhängingen Darstellungen in eine unabhängige Form die von beiden Seiten verstanden wird (z.B. ASN.1)
  • Aufgaben wie Datenkompression und Verschlüsselung (bsp TLS)
  • stellt sicher, dass Daten, die von der Anwendungsschicht eines Systems gesendet werden von der Aschicht eines anderen Sstems gelesen werden können.

Was sind Qualitätsattribute?

Was für Qualitätsattribute gibt es für Softwarearchitekturen?

Qualitätsattribute sind Maßnahmen, zu erörtern, dass das System frei von Defekten ist. Qualitätsattribute sind unabhängig von der Funktionalität eines Systems.

Man unterscheidet zwischen zwei Qualitätsattributen:

  • Statische Qualitätsattribute
    • Reflexion über das System in Zusammenhang mit der Softwarearchitektur, Design und Source Code. 
    • Diese sind nicht sichtbar für den Endser aber haben Einfluss auf die Entwicklungs- und Wartungskosten, wie z.B. Modularität, Testbarkeit imd Wartbarkeit.
  • Dynamische Qualitätsattribute:
    • Reflexion über das System während der Laufzeit
    • Diese sind sichtbar für den Enduser und beinhalten z.B. Performance, Verfügbarkeit, und Skalierbarkeit.

Lernen