Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Grundlagen und Prinzipien des Architekturentwurfs > Flashcards

Grundlagen und Prinzipien des Architekturentwurfs Flashcards

1
Q

Charakterisierung: Softwarekomponenten

A
  • klar definierte Schnittstellen
  • definierte Abhängigkeiten zu anderen Komponenten
  • können unabhängig von anderen Komponenten entwickelt werden
  • Kapseln Teilsysteme
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Wie wird ein System entworfen?

A
  • Anforderungsspezifikation ist Ausgangspunkt für den Systementwurf
  • Grobentwurf (Festlegung von Systemarchitektur und Komponenten)
  • Feinentwurf (Softwarearchitektur der Komponenten)
  • Entscheidende Rolle für

Entwicklungsprozess (Zerlegung eines Systems, arbeitsteilige Entwicklung,
Integration und Tests)

Qualitätseigenschaften (Komplexitätsbeherrschung, Performanz, Skalierung,
Wartbarkeit)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Gliederungskonzepte für Architekturen

A
  • Klassen (als Typ-Konzept) legen fest, wie die Exemplare (Objekte) den
    Nachrichtenaustausch zwischen Objekten mittels Methodenaufrufen
    realisieren
  • Datenflusskomponenten beschreiben, wie die Komponenten durch das
    Versenden von Nachrichten über Kanäle miteinandere kooperieren
  • Prozeduraufrufkomponenten kooperieren mittels Aufrufen von
    Prozeduren in den an der Kommunikation beteiligten Komponenten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Schichtenarchitektur

A

System besteht aus Schichten, welche über/unter einander liegen und die informationen von unten nach oben verarbeiten.
z.B.
* Präsentationsschicht
* Applikationsschicht
* Datenschicht

Pro:
* Modular
* Vorteilhaft strukturierung

Con;
* Performance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Perspektiven des Architekturentwurfs

A
  • Logische Architektur (beschreibt, welche Komponenten welche
    Funktionalitäten übernehmen und wie sie funktional und logisch
    zusammenwirken)
  • Realisierungsarchitektur (beschreibt, wie die logische Architektur
    konkrete auf dem Software-/Hardwar-System realisiert wird)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Bestandteile der Architekturbeschreibung

A

Typische Bestandteile:
* Architekturanforderungen, Entwurfsziele und -prinzipien
* Systemgliederung in Komponenten
* Verbindung der Komponenten über Schnittstellen
* Schnittstellenbeschreibung der Komponenten
* Benutzungsschnittstelle des Gesamtsystems als Teil der Architektur

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Welche Hardwarearchitekturen gibt es?

A
  • Großrechnersysteme (gesamte Software läuft auf einem Rechner)
  • Client/Serversysteme (Rechnernetz von Kleinrechnern/Clients und
    Servern, Kommunkation durch Middleware)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Verteilte und nebenläufige Systeme

A

Verbunden durch ein Netzwerk und stellen Komponenten der Anwendung durch Middleware zur Verfügung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Interaktive verteilte Systeme

A

Interaktion durch Nachrichtenaustausch:
Unterscheidung zwischen:
* Synchroner Kommunikation (wartet auf Antwort)
* Asynchroner Kommunikation (Kann während des Wartens weitere Aufgaben bearbeiten)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Statik und Dynamik in Architekturen

A
  • Dynamische Bestandteile (Zielen auf das Verhalten der Architektur (Wechselspiel
    zwischen Komponenten, z.B. Protokolle)
  • Statische Bestandteile (Anzahl der Komponenten und
    Kommunikationsbeziehungen, Darstellung durch Diagramme)
  • Statische Architekturen (Zahl der Komponenten und deren Verbindungen ändern
    sich zur Laufzeit nicht)
  • Dynamische Architekturen (Zahl der Komponenten und deren Verbindungen
    können sich zur Laufzeit ändern)
  • Statische Sichten (z.B. Klassendiagramme in objektorientierten Systemen)
  • Dynamische Sichten (z.B. Objektdiagramme als Zustandsabbildung)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Aufgaben des Architekten

A
  • Evaluierung unterschiedlicher Realisierungsalternativen (Entwicklerrolle)
  • Koordination der Schnittstellen zwischen Teilprojekten (Entwicklerrolle)
  • Entwicklung einer Systemvision (Analytikerrolle)
  • Anforderungsbewertung (Analytikerrolle)
  • Entscheidung über Systementwürfe (Projektmanagerrolle)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Prinzipien des Architekturentwurfs
(Strukturierung einer Architektur)

A

Zentrale Prinzipien zur Strukturierung einer Achitektur:
* Das Gebot der Einfachheit: KISS
* Kopplung und Kohäsion
* Kapselung und Information Hiding
* Separation of Concerns

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

KISS

A

Keep it simple and stupid (“Mache es einfach und nicht zu raffiniert”)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Kopplung

A

Kopplung: Abhängigkeiten zwischen Komponenten
* Beeinflusst die Wartbarkeit
* Maß zur Abschätzung der Auswirkungen von Änderungen im System
* Generell: Je niedriger die Kopplung, desto eigenständiger ist die Komponente oder das Modul.

Grundform Beispiel
Aufruf: A ruft B auf (A nutzt einen Service von B)
Erzeugung: A erzeugt B
Daten: A und B nutzen gemeinsame Daten/-strukturen und Zustände
Umgebung: A und B erfordern dieselbe Laufzeitumgebung/Hardware
Zeit: B muss existieren, solange A existiert

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Kohäsion

A

Kopplung und Kohäsion
* Kohäsion: innerer Zusammenhang von Komponenten

Klasse beinhaltet Methode welche nicht zu den anderen gehört -> schwache Kohäsion

  • Generell: Je stärker die Kohäsion, desto wohldefinierter ist die Komponente oder das Modul.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Kapselung und Information Hiding

A
  • Kapselung:
    Zugriff mittels Schnittstelle einschränken, System robuster gegenüber
    Änderungen machen
  • Information Hiding:
    Komponente ist “Black Box”, gibt keine Informationen über konkrete Implementierung
17
Q

Teile und Herrsche

A

Modularisierung als wichtigstes technisches Hilfsmittel zur Reduktion der Komplexität einer Entwicklungsaufgabe.

  • Große Aufgaben in Module einteilen um diese kleineren Einheiten realisieren zu können
  • Am Ende werden Module wieder zu Gesamtaufgabe zusammengesetzt

Arten von Modularisierung:
* Funktionale Dekomposition (Zerlegen einer Aufgabe in Unteraufgaben)
* Strukturelle Dekomposition (Zerlegen von Systemkomponenten in
Teilkomponenten)
* Parametrisierung (Anpassung der modularen Stuktur an bestimmte
Bedürfnisse durch passende Konfiguration über Parameter)

18
Q

Design by Contract

A

Idee: frühe Festlegung von Schnijstellen, die über den
Systemlebenszyklus weitgehend stabil gehalten werden.

Schnittstellenbeschreibung bildet “Vertrag” zwischen Nutzern und
ImplemenSerern einer Schnijstelle
- Nutzer verlässt sich auf das in der Schni_stelle spezifizierte Verhalten
- Implemen\erer garan\ert die Schni_stelle

19
Q

Software-Wiederverwendung

A

Nutzung existierenden Wissens und existierender Softwareartefakte zur Entwicklung neuer Systeme

Optimierungsziele:
* Kostenreduktion und Verkürzung von Entwicklungszyklen (time-to-market)
* Qualitätssteigerung durch bewährte, getestete Komponenten (product quality)
* Senkung der Lebenszykluskosten (total cost of ownership)

20
Q

Kompatibilität

A

Kompatibilität: Austauschbarkeit, Vereinbarkeit, Gleichwertigkeit
* Abwärtskompatibilität: ein (oh neueres) System erfüllt mindestens die
Anforderungen eines anderen (alten) Systems
* Aufwärtskompatibilität: ein altes System kann die Anforderungen eines
neuen Erfüllen
* AustauschkompaUbilität: eine Komponente ist durch eine andere
ersetzbar, ohne dass das Systemverhalten fehlerhah wird
* Interoperabilität: wechselseitige KompaSbilität, Komponenten passen
zusammen und können Seite and Seite eingesetzt werden
* KomposiUonskompatibilität: Schnijstellen von Komponenten passen
syntaktisch und semantisch zusammen

21
Q

Austauschkompabilität

A

Eine Komponente B heißt austauschkompa@bel zu einer Komponente A, wenn man in einem beliebigen korrekten Programm bzw. einer korrekten Sobware A durch B ersetzt werden kann, ohne dass das Programm bzw. die Software inkorrekt wird.

22
Q

Wiederverwendung und Wartung

A
  • Bei Wiederverwendung ist im Allgemeinen die Wartung einfacher
  • Wiederverwendete Komponenten müssen aber einer Qualitätssicherung
    unterzogen und in Wartungsaktivitäten eingebzogen werden
23
Q

Herausforderungen in der Wiederverwendung

A
  • Hunderte von Entwurfsentscheidungen
  • Komplexe Abhängigkeiten im Entwurf
  • Mangelnde Dokumenta\on, insbesondere des Entwurfs
  • Mangelde Transparenz des Entwurfs
  • Fehlende Begründung der Entwicklungsschri_e und –entscheidungen
24
Q

Wie kann man Probleme im Architekturentwurf verhindern?

A

Problemen begegnen durch:
* Entwicklerwissen dokumentieren (Abhängigkeiten und Entscheidungen)
* Standardlösungen beschreiben
* Lösungen bewerten
* Software dokumentieren (Entwurf und Implementierung)
* Wiederverwendung betreiben
* Terminologie konsolidieren (Glossar)
* Unternehmens-Know-How sichern

25
Q

Strategien der Wiederverwendung

A
  • Top-down (Aufbrechen von Aufgaben, bis gleichlautende Teilaufgaben
    entstehen, für die Komponenten wiedervenwendet werden können)
  • Bottom-Up (Zusammensetzen des Systems aus vorhandenen
    Komponenten)
  • Mischform ratsam (Zerlegung, sodass vorhandene Komponenten
    eingebunden werden können)

++++
* Entwicklung mit Wiederverwendung (zunächst nicht geplant)
* Entwicklung für Wiederverwendung (von Beginn an vorgesehen)

26
Q

Strategien der Wiederverwendung

A

Opportunistische (ad-hoc) vs. geplante (strategische) Wiederverwednung

Software Engineering (10 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions