¡GoConqr estrena diseño! Cuéntanos qué te parece.

Regístrate gratis

Fichas

SWT

Tzoko Alemán 87 fichas

SWT

Fichas del conjunto (87)

  1. 1Definition Software SystemSystem, dessen Systemkomponenten/Systemelemente aus Software bestehen
    Systemkomponente/-elemente stehen in Beziehung zueinander, Systemelemente nicht zerlegbar
  2. 2Definition BasissoftwareNutzung anwendungsabhängiger, gerätebezogener Prozesse (Systemsoftware), Orientierung an Hardware, ergänzt funktionale Fähigkeiten der Hardware -> für spezifische Hardware entwickelt, um Betrieb/ Wartung zu ermöglichen
  3. 3Definition Anwendungssoftwareauch Applikationssoftware
    Nutzung technischer Mittel zur Bearbeitung spezifischen Anwendungsprogramms (nutzt Systemsoftware)
  4. 4Definition Software Produkterfolgreich durchgeführtes Projekt, besteht aus Softwaresystem (Dokumentation + Konfigurationsdaten) und Webseiten
  5. 5angestrebte Eigenschaften von SoftwareVerlässlichkeit: beim Versagen der Software keine physischen/ökon. Schäden
    Benutzbarkeit: nach Bedürfnissen des Nutzers richten, ergonomisch/ selbsterklärend
    Wartbarkeit: anpassbar an neue Anforderungen, plattformenunabhängig
    Effizienz: muss ökon. Gebrauch von Ressourcen unterliegenden Programms machen
  6. 6Definition Softwaretechniksystematische Entwicklung (Korrekturen, Anpassungen, Erweiterungen)/ Pflege von Softwaresystemen, die spezifizierte funktionale/ nicht funktionale Attribute erfüllen
  7. 7Organisatorische Aspekte der SoftwaretechnikPlanung, Personalfindung, Stellenbesetzung, Arbeitsorganisation,
    Leitung, Kontrolle
  8. 8Systematische Aspekte SoftwaretechnikMethoden/ Werkzeuge zielgerichtet eingesetzt
  9. 9Funktionale Attribute Nicht-Funktionale Attribute (Qualitätsattribute)- > spezifizieren die Funktion der Software
    -> spezifizieren, wie gut die Software ihre Funktion erfüllt
  10. 10Ziel SoftwaretechnikSoftware mit festgelegtem Funktionsumfang,
    in hoher Qualität ,
    kostengünstig innerhalb des Budgets
    zum geplanten Zeitpunkt
  11. 11Werkzeuge der Softwaretechnikautomatisieren Tätigkeiten, die...
    -> hohe Präzision erfordern
    -> oft wiederholt werden müssen
    -> eine Überprüfung erfordern
    erhöhen Produktivität
  12. 12Prozess und Produkt der Software ErstellungProzess und Produkt der Software Erstellung
  13. 13Anforderungsanalyse Definition Anforderungeinzelne logische Aussage
    beinhaltet ein Schlüsselwort (SHALL, SHOULD, WILL / MUSS,
    SOLLTE, WIRD)
    Ursache - Wirkung
    klar formuliert/ verständlich
    durch eindeutige ID nachverfolgbar
    testbar
  14. 14Requirements EngineeringRequirements Engineering
  15. 151. Schritt Anforderungsanalyse: StakeholderanalyseStakeholder = Informationslieferanten
    für Ziele, Anforderungen, Randbedingungen
    -> alle Personen, die vom Produkt betroffen
  16. 161. Schritt Stakeholder identifizieren1. Schritt Stakeholder identifizieren
  17. 172. Schritt Ziele identifzierenvollständig, korrekt, konsistent,
    testbar, verstehbar für alle Stakeholder,
    umsetzbar, notwendig, eindeutig
    Lösungsneutralität
    einschränkende
    Rahmenbedingungen
  18. 183. Anforderungen aufnehmenInterview, Fragebogen, Inventurmethode, Beobachtungsmethode, Anforderungsworkshop
  19. 19Use CaseAnforderungen des Anwenders,
    aus mehreren Szenarien (Abfolge Schritte zwischen Akteur/System)
    System = Blackbox
    gutes Use Case: fasst mehrere Arbeitsschritte zusammen, klar definierte Ziele/ Startpunkt
  20. 20DokumentationsschabloneDokumentationsschablone
  21. 21Use Case BegriffeUse Case Begriffe
  22. 22Business Use Case System Use CaseInteraktion zwischen Firma/ Geschäftssystem
    Interaktion mit zu entwickelnden Softwaresystem
  23. 23Aktivitätsdiagrammevisualisieren Prozesse/ Abläufe (Flow Chart), Detaillierung von Use Case
  24. 24BegrifflichkeitenBegrifflichkeiten
  25. 25Objekt/-flüsse im AktivitätsdiagrammObjekt/-flüsse im Aktivitätsdiagramm
  26. 26Textuelle Anforderungen - Funktionale Anforderungenbeschreibt, was ein System tun sollTextuelle Anforderungen - Funktionale Anforderungen
  27. 27Nicht-Funktionale Anforderungenwelche Eigenschaften soll das Produkt habenNicht-Funktionale Anforderungen
  28. 28Metriken nicht-funktionaler AnforderungenMetriken nicht-funktionaler Anforderungen
  29. 29Sprachliche PathologienTilgungen: Sachverhalte verkürzt
    Generalisierung: verallgemeinert (nie, kein, alle, jeder, alle-> Universalquantoren=
    Verzerrung: Einzelaktivitäten im Substantiv zusammengefasst
  30. 30Sprachschablone und GlossarSprachschablone und Glossar
  31. 31VorgehensmodelleRahmenwerke, die festlegen
    • welche Aktivitäten
    • in welcher Reihenfolge
    • durch wen (Rollen),
    • mit welchen Ergebnissen (Produkte)
    für individuelles Projekt relevant
    -> definierte, standardisierte Vorgehensweise, machen Projekte plan-/steuerbar, fördern interne/externe Kommunikation, erzwingen struktuiertes, zielorientiertes Handeln
  32. 32Das WasserfallmodellDas Wasserfallmodell
  33. 33Das Wasserfallmodell - Vor- und NachteileVorteile: intuitiv, leicht erlernbar, wenig Managementaufwand, suggeriert planbaren Entwicklungsverlauf, strukturiert und leicht steuerbar
    Nachteile: Realität t Modell, wenig Reaktion auf verändernde Anforderungen, Anwender sieht System Ende, Test Ende, lange Laufzeiten, hohe Aufwände späterer Projektphase
    Optimierung: möglich in vorige Phase zu springen
  34. 34Prototypische EntwicklungPrototypische Entwicklung
  35. 35Iterative EntwicklungIterative Entwicklung
  36. 36Iterativ inkrementelle EntwicklungIterativ inkrementelle Entwicklung
  37. 37Komplexe Vorgehensmodelled
  38. 38Das V-Modell des BundesDas V-Modell des Bundes
  39. 39Tailoring V-Modell XTTailoring V-Modell XT
  40. 40Rational Unified ProcessRational Unified Process
  41. 41Struktur des RUPStruktur des RUP
  42. 42Charakteristik klassischer Software EntwicklungsmethodenDokumentenzentriert: Lastenheft, Pflichtenheft, Designmodelle, Code
    Prozessorientiert: Sequentielle Abarbeitung Schritte
    Arbeitsteilig
    Planorientiert: Vorabplanung Budget, Zeit, Umfang
  43. 43Kritik klassischer Modelleviele Dokumente
    •schwer zu verstehen
    •aufwendiges Tailering
    •wenig Kreativität
    •Anpassungen sind aufwendig
  44. 44Überblick agiler MethodenÜberblick agiler Methoden
  45. 45Zusammenfassung agile MethodenFlexibilität: Änderbarkeit/ Anpassung Anforderungen
    Einfachheit: einfache Lösungen anstreben
    Zufriedenheit: Rückkopplung Kunden, Transparenz
    kürzere Laufzeiten: schneller zum lauffähigen Produkt
  46. 46Vergleich klassische/ agiler MethodenVergleich klassische/ agiler Methoden
  47. 47Grobdesign - Klassendiagrammstatische Sicht auf System,
    zur Abbildung
    Struktur, statischen Eigenschaften/ Beziehungen, Daten/ Operationen
    Beziehungen zwischen Objekten
    - Vererbung (Generalisierung, Spezialisierung)
    - Benutzung (Assoziation)
    - Enthaltensein (Komposition, Aggregation)
    - Abhängigkeit
  48. 48Grobdesign - GUI PrototypingDarstellung / Entwurf einzelner Oberflächen
    Konzeption des Benutzerverhaltens (Screenfolge, UI-Flow)
    Dimensionen:
    • Funktionsumfang
    • Funktionstiefe
    • Darstellungstreue
    • Interaktivität
    • Datengehalt
    • Technische Reife
  49. 49GUI Charakteristik1. Material: aus welchen Mitteln, Materialien, Medien
    2. Scope: welche, wie viele Produkteigenschaften
    modelliert
    3. Fidelity: wie detailliert/ realitätsnah
    Produkteigenschaften jeweiligen Dimensionen
    realisiert
  50. 50Feindesign -SequenzdiagrammeInteraktion der Klassen auszugsweise nachspielen
    • mit Sequenzdiagrammen so beschreiben, dass sie mit
    Nutzereingaben beginnen und resultierende Ausgaben
    beschreiben
  51. 51Softwarearchitekturlegt übergeordnete Organisation Softwaresystems mit globalen Kontrollstrukturen fest
    • definiert die SW-Komponenten des Systems mit Schnittstellen
    • beschreibt dynamisches Verhalten Systems, indem
    Beziehungen/ Interaktionen zwischen den SWKomponenten
    festlegt
  52. 52PaketdiagrammeStrukturierung Software Pakete:
    Klassen, die eng zusammenhängen
    Klassen die schwach zusammenhängen    Paketdiagramme
  53. 53Komponentendiagrammstellt logische Komponente und Schnittstellen darKomponentendiagramm
  54. 54Systemarchitektur - Deployment DIagrammbeschreibt verwendete Hardware & Deployment (Verteilung Software Komponente auf Hardware)Systemarchitektur - Deployment DIagramm
  55. 55Systemzerlegung/ Architekturprinzipien - allgemeine HeuristikenKISS - Lösung Problems so einfach wie möglich und nachvollziehbar
    YAGNI - keine theoretischen Funktionen, die man später eventuel brauch könnte
  56. 56Softwarespezifische Architekturprinzipien Lose KopplungKopplung der Subsysteme untereinander, Abhängigkeit von Subsystemen
    Möglichst lose Kopplung
    - Änderungen beteiligten Subsystem geringe
    Auswirkungen (Stabilität)
    - Erleichtert Wartbarkeit/ Erweiterbarkeit
    • Mittel zur Verringerung der Kopplung
    - zusätzliche Unterteilung in Subsysteme
    aber: dann größere Komplexität
  57. 57Architekturprinzip - Hohe KohäsionBeziehung zwischen Elemnen Elementen Subsystems
    Möglichst hohe Kohäsion !
    • enge Beziehung oder ähnliche Aufgaben der Elemente
    • erleichtert Verständnis, Wartung/ Anpassung
    Mittel zum Erreichen hoher Kohäsion
    • Datenkapselung, Objektorientierung
    • Benutzung geeigneter Patterns
  58. 58Seperation of COncernverschiedene Aspekte trennen, jeden für sich behandeln, verschiedene Subsysteme
    reduziert Komplexität, ermöglicht arbeitsteilige Bearbeitung
    Mittel zum Erreichen
    • Modularisierung
    • Orientierung an Anwendungsfällen
    • Trennung von technisch und fachlichen Anteilen
  59. 59VerantwortlichkeitsprinzipObjekte/ Klassen erfüllen in Zusammenarbeit mit anderen Klassen/ Objekte Aufgaben eigenverantwortlichVerantwortlichkeitsprinzip
  60. 60Information Hidingnur Schnittstelle mit Umwelt kommunizieren lassen (interfaces)
  61. 61Abstraktionwichtige Aspekte identifizieren, unwichtige Details vernachlässigen
    explizite Schnittstellen
    • Trennung von Schnittstelle und Implementierung
    • Liskow-Substitutions-Prinzip
    • Schnittstellen Segrationsprinzip
  62. 62Taktiken - Stile -MusterTaktiken - Stile -Muster
  63. 63Architekturmuster - SchichtenarchitekturZerlegungshierarchie
    Innerhalb der Schicht, können Bausteine frei agieren
    • zwischen zwei Schichten kann nur über die
    vorgesehene Schnittstelle kommuniziert werden
    bietet darüberlegenden Schicht Dienste an
    Abhängigkeit nur von darunterliegenden
  64. 643-Schichten Architektur1. Präsentationsschicht (Benutzeroberfläche, Reaktion auf Dateneingabe)
    • der Anwendungsschicht und (fachliche Logik/ Objekte um Geschäftspozesse abzubilden)
    • der Persistenzschicht (Dienste, die für dauerhafte Verwaltung sorgen)
  65. 65Model-View-ControllerModel-View-Controller
  66. 66Pipes und Filters Ketteflexible Architektur zur Bearbeitung Datenströme
    Anwendungen mit kompatiblen Ein- und Ausgangsdatenströmen
    • Leicht rekonfigurierbar, hoher Grad an Nebenläufigkeit    Pipes und Filters Kette
  67. 67RepositoryRepository
  68. 68Peer-toPeerPeer-toPeer
  69. 69EntwurfsmusterEntwurfsmuster primär nach Zweck klassifiziert
    Daraus sind drei Gruppen entstanden:
    • Erzeugungsmuster (Creational Patterns)
    • Strukturmuster (Structural Patterns)
    • Verhaltensmuster (Behavioral Patterns)
    Sekundär in Klassen- und Objektmuster unterteilt:
    • Klassenmuster legen Beziehungen bereits zum Kompilierzeitpunkt
    fest, während
    • die Beziehungen in Objektmustern zur Laufzeit dynamisch
    veränderbar sind
  70. 70Erzeugungsmuster (Creational Patterns)AbstrahierenErzeugung von Objekten–
    Entscheidung welcher Typ,
    – zu welchem Zeitpunkt;
    – auf welche Art (Kontext, Konfiguration etc.)
    Delegation der Erzeugung an andere Objekte
    ( 'Fabrik'-Konzept: Man fordert ein Objekt an)
  71. 71Strukturmuster (Structual Patterns)Fassen Objekte (oder Klassen) zu größeren/
    veränderten Strukturen zusammen,
    Erlauben unterschiedlichen Strukturen sich einander
    anzupassen/miteinander zu verbinden
  72. 72VerhaltensmusterBeschreiben Interaktion zwischen Objekten
    – Legen Kontrollflüsse zwischen Objekten fest
    Zuständigkeit und/oder Kontrolle werden delegiert
  73. 73Übersicht MusterÜbersicht Muster
  74. 74Entwurfsmuster Singleton (Erzeugungsmuster, objektbasiert)von Klasse nur genau eine Instanz erzeugt, auf diese Zugriffspunkt
    Implementierungseigenschaften:
    - statisches Attribut für Objektinstanz
    - statische Methode für Zugriff auf Objekt
    - privater Konstruktor (verhindert externe Instanzierung)
  75. 75Beispiel SingletonBeispiel Singleton
  76. 76Beispiel Singletonpublic class Singleton {
    private int x=0;
    private int y=0;
    private static Singleton pkt=null; //für einziges
    //Exemplar
    private Singleton(int x, int y){
    this.x=x;
    this.y=y;
    }
    public static Singleton getPunkt(){
    if (pkt==null) // ein einziges Mal erzeugen
    pkt= new Singleton(6,42);
    return pkt;
    }
  77. 77Observer (Verhaltensmuster, Publisher Subscriber, objektbasiert)Verwendung Daten, die von anderer Komponente bereitgestellt
  78. 78Observer ProblemÄnderung internen Zustands Komponente ->
    Inkonsistenzen zwischen kooperierenden Komponenten
    für Herstellung Konsistenz Mechanismus benötigt ->
    Daten/ Informationen über Zustand
    Komponenten ausgetauscht, dabei Komponenten nur lose gekoppelt
    vorher nicht bekannt, welche Komponenten internen
    Zustand kennen müssen
  79. 79Lösung ObeserverSubjekte für deren Zustand sich viele interessieren
    (z. B. Nachrichtenkanäle)
    • Die Subjekte bieten die Möglichkeit, dass sich Interessenten
    (Beobachter) dynamisch anmelden (z. B. Kanal abonnieren)
    • Bei jeder Subjektzustandsänderung werden Interessenten
    informiert (neue Nachrichten)
    Interessent muss sich bei Subjekt anmelden
    Damit Subjekt weiß, wie Interessent angesprochen werden soll,
    muss Interessent bestimmte Schnittstelle realisieren
  80. 80Beispiel Grafik ObeseverBeispiel Grafik Obesever
  81. 81Beispiel Grafik ObserverBeispiel Grafik Observer
  82. 82Obeser BeispielObeser Beispiel
  83. 83Fassade (Strukturmuster, objektorientiert)stellt einheitliche, zusammengefasste Schnittstelle zu Menge von Schnittstellen Subsystems zur Verfügung
    Motivation für Einsatz
    – Minimierung Abhängigkeiten zwischen Subsystemen
    – vereinfachte Anwendung Subsystems
    – Austauschbarkeit Subsystems gewährleisten
  84. 84FassadeFassade
  85. 85Vor-/ Nachteile PatternVor-/ Nachteile Pattern
  86. 86Test und Qualitätssicherung Ziele von TestenAusführung Programms mit Ziel, Fehlerwirkungen nachzuweisen, Qualität zu bestimmen, Vertrauen in Programm erhöhen, Systemanalyse, um Fehler vorzubeugen
  87. 87—

Información

Descripción
Fichas sobre SWT, creado por Tzoko el 06/07/2015.
Creado por
Tzoko · jul 2015
Actualizado
7 mar 2018
Visitas
10
Valoración

Escríbenos

¿Sobre qué es tu mensaje?

¿Qué te parece el nuevo diseño?

¿Te gusta?