9

Softwarekonstruktion (Fach) / Softwarekonstruktion 2 (Lektion)

Diese Lektion wurde von blumenkohl erstellt.

Lektion lernen

Diese Lektion ist leider nicht zum lernen freigegeben.

zurück  |  weiter 1 / 1

• Woraus besteht ein Maß? • eine Menge von Gegenständen mit einem zu messenden Merkmal• einer Skala• einem Messverfahren• Strukturähnlichkeit zwischen Merkmalsmenge und Skala
• Welche Skalentypen gibt es? Geben Sie jeweils ein Beispiel bezogen auf die Bewertung von Klausuren an. Nominalskala: Reine Kategorisierung von Werten: z.B. ’bestanden’, ’nicht bestanden’, ’nicht teilgenommen’, ’entschuldigt’ Ordinalskala: Skalenwerte geordnet und vergleichbar, Medianwert: z.B. Schulnoten als Text Intervallskala: Werte geordnet, Distanzen bestimmbar, Mittelwert, Standardabweichung: z.B. Schulnoten als Zahl Verhältnisskala: Werte geordnet und in der Regel additiv, Skala hat absoluten Nullpunkt: z.B. Klausurergebnis in % Absolutskala: Skalenwerte sind absolute Größen d.h. nicht skalierbar, sonst wie Verhältnisskala: z.B. Klausurergebnis in Punkten (T1.2 F26)
• Wie kann man zwei unterschiedliche Maße vereinheitlichen? Das heißt was kann man tun um zwei Mengen von gleichartigen Objekten, die aber mit unterschiedlichen Maßen bewertet wurden, vergleichbar zu machen? Wo liegen die Probleme bei den jeweiligen An 1. Man kann ein Maß als Grundlage nehmen und die Menge an Objekten die damit nicht bewertet wurden erneut nach diesem Maß bewerten. Das kann je nach Maß sehr aufwendig sein. Manchmal ist das nicht möglich da eine erneute Messung nicht durchführbar ist.2. Man kann die Abbildung mittels Abbildungsfunktion von einer Skala auf die andere übertragen. Das ist allerdings nur möglich wenn die beiden Skalen und Abbildungsfunktionen sehr ähnlich sind. Das Verfahren ist sehr leicht durchführbar, aber es besteht die Gefahr von Informationsverlust bzw. hinzufügen von Information, die so gar nicht in der uberführten Skala vorhanden war. 3. Man kann eine neue Skala durch zwei Abbildungsfunktionen bilden, die die jeweilige original Skala umwandeln. Wenn die Skala gebildet ist und die Abbildungen bekannt sind, ist dies sehr leicht durchführbar. Das Hauptproblem liegt hier in der sinnvollen Bildung der neuen Skala, so daß keine Informationen verloren gehen oder hinzugefügt werden. Es besteht die Gefahr, daß lediglich eine Ordnung zwischen den Elementen der zwei original Skalen definiert wird, dabei aber Apfel mit Birnen verglichen werden. (T1.2 F29)
• “Qualitätsmaße verbessern ein Produkt nicht. Das tun Qualitätssicherungsmaßnahmen. Und die tun das auch ohne gemessen zu werden.“ Wie stehen Sie zu dieser Aussage? Man kann sich dieser Aussage anschließen. Tatsächlich ist es im Software Engineering ein viel größeres Problem für bestimmte Qualitätseigenschaften geeignete Maßnahmen und Vorgehensweisen zu ergreifen. Sicherheit ist ein Beispiel bei dem es an vielen Stellen noch an dedizierten Tools und erprobtem Vorgehen fehlt. Allerdings darf man nicht vergessen, dass Maßnahmen auch immer mit Arbeitsaufwand, Komplexität und Kosten verbunden sind. Das heißt Maßnahmen zu ergreifen, ohne zu wissen ob diese auch wirklich notwendig sind, kann sich als kontraproduktiv erweisen. Qualitätskennzahlen ermöglichen an dieser Stelle ein gezielteres Vorgehen.
• Geben Sie an, wie sich Sequenzen, Verzweigungen und Sprünge auf die zyklomatische Komplexität auswirken. Sequenzen können beliebig lang sein ohne die zyklomatische Komplexität zu erhöhen.(Kann man beim zeichnen von Kontrollflussgraphen ausnutzen und Sequenzen zu einem Knotenzusammenfassen.) Jede Verzweigung in einer Auswahl erhöht die zyklomatische Komplexität um 1. Goto Anweisungen erhöhen die zyklomatische Komplexität nicht.
• Nennen Sie statische Metriken und erläutern Sie diese kurz. Anzahl Betriebssystem-Aufrufe / Anzahl Prozeduraufrufe-Aufrufe: gibt den Anteil der Betriebssystem-Aufrufe an, je höher, desto enger die Kopplung an das verwendete Betriebssystem (T1.2 F32) Anteil Hardware- oder Betriebssystem-abhängiger Module: je höher, desto enger die Bindung an bestimmte Hardware (T1.2 F32) Anteil Nicht-Standardcodezeilen: z.B. im Vergleich zum ISO-Standard (T1.2 F32) Anzahl Codezeilen: (NCSS) Zahl der Codezeilen ohne Leer- und Kommentarzeilen(T1.2 F38) Anzahl Zeichen: Zahl der Zeichen des Programmes (T1.2 F38) zyklomatische Komplexität: soll über die Zahl der Verzweigungen Rückschlüsse uber die Komplexität des Codes liefern (T1.2 F39)Fan-in/Fan-out: einer Funktion/Methode X ist die Zahl der Funktionen/Methoden, die X aufrufen (Fan-In) oder von X aufgerufen werden (Fan-Out). Hoher Fan-In: X ist eng mit dem System verbunden, Hoher Fan-Out: Steuerungslogik von X muss andere Methoden/Funktionen koordinieren. (T1.2 F51-53) Länge der Bezeichner: Maß der durchschnittlichen Länge der Bezeichner. Die Hoffnung ist, je länger sie sind, desto aussagekräftiger sind sie. (T1.2 F51-53) Tiefe der Verschachtelung: Maß der Tiefe der Verschachtelung von if-Bedingungen. Je tiefer, desto schwerer sind sie wahrscheinlich zu verstehen. (T1.2 F51-53) Fog-Index: Maß der durchschnittlichen Länge von Wörtern und Sätzen. Je höher, desto schwerer ist es wahrscheinlich zu verstehen. (T1.2 F51-53) Gewichtete Methoden pro Klasse: (WMC) Anzahl der Methoden in jeder Klasse gewichtet mit der Komplexität der jeweiligen Methode. (T1.2 F51-53)Tiefe des Vererbungsbaumes: (DIT) Maximale Tiefe der Generalisierungshierarchie. Je tiefer der Baum, desto komplexer das Design. (T1.2 F51-53) Zahl der Kinder: (NOC) Anzahl der direkten Unterklassen (die jeweilige Breite der Klassenhierarchie). Es lohnt sich klassen mit hohem NOC zu validieren, da sie oft wiederverwendet werden und viele Klassen von ihnen abhängen. (T1.2 F51-53)Kopplung von Klassen: (CBO) Die Klassen C und D sind gekoppelt, wenn Methoden von C Variablen oder Methoden von D benutzen. CBO misst wieviele Kopplungen es gibt. Ein hoher CBO zeigt, dass lokale Änderungen systemweite Auswirkungen haben können. (T1.2 F51-53)Reaktion einer Klasse: (RFC) Maß der Anzahl der Methoden, die potentiell als Antwort einer Klasse auf eine Nachricht an die umgebene Klasse ausgeführt werden können. (T1.2 F51-53)Mangel an Zusammenhalt in Methoden: (LCOM) z.B. Anzahl der durch Methoden einer Klasse gemeinsam benutzten Instanzvariablen. Es gibt viele Ausprägungen, die Aussagekraft des LCOM ist unklar. (T1.2 F51-53) Zahl der Variablen, Methoden, Redefinierten Methoden: (NOV, NOM, NORM)(T1.2 54) Software Science: konstruierte Metrik, mit Vorbehalt zu benutzen (T1.2 F50) Anzahl Fehlermeldungen kann Hinweise auf vom Programmier bedachte Sonderfälle geben (T1.2 F62) Länge des Benutzerhandbuches kann Aufchluss uber den Umfang der Dokumentation geben (T1.2 F62)
• Setzen sie statischen Metriken in Bezug zu den Qualitätsmerkmalen Wartbarkeit, Verlässlichkeit, Wiederverwendbarkeit, Benutzbarkeit, Portabilität und Komplexität. Falls Sie einem der Qualitätsmerkmale keine Metrik zuordnen können, schlagen Sie eine w Wartbarkeit: Tiefe des Vererbungsbaumes, Zyklomatische Komplexität, Programmgröße in Codezeilen, Länge des Benutzerhandbuches Verlässlichkeit: Zyklomatische Komplexität, Programmgröße in Codezeilen, Anzahl Fehlermeldungen Wiederverwendbarkeit: Tiefe des Vererbungsbaumes, Programmgröße in CodezeilenBenutzbarkeit: Anzahl Fehlermeldungen, Länge des BenutzerhandbuchesPortabilität: Anzahl Betriebssystem-Aufrufe / Anzahl Prozeduraufrufe-Aufrufe, Anteil Nicht-Standardcodezeilen, Anteil Hardware- oder Betriebssystem-abhängiger Module Komplexität : zyklomatische Komplexität, Software Science (besser nicht verwenden)(T1.2 F32, F39, F62)
• Was ist ein grundlegendes Problem bei der Verwendung von Metriken? Metriken reduzieren teilweise komplexe Zusammenhänge auf simple Zahlenwerte. Wenn man sich bei einer Entscheidung anhand von Metriken nicht genau bewusst ist, wie diese Metrik zu Stande kommt und wovon sie im Detail abhängt, besteht die Gefahr von Fehlentscheidungen.
• Erklären Sie warum es schwierig sein kann den Zusammenhang von internen Produkteigenschaften und externen Produkteigenschaften zu validieren. Nehmen Sie als Beispiel dafür Zyklomatische Komplexität und Wartbarkeit. Die Hauptschwierigkeit, die sich ergibt ist, dass die externen Qualitätsattribute (wie Wartbarkeit) nicht nur von einer kleinen Anzahl an internen Attributen abhängen. Sicherlich beeinflußt die Komplexität der Software die Wartbarkeit. Allerdings hängt die Wartbarkeit auch von anderen Attributen wie ’sprechende’ Variablennamen, Güte der Systemdokumentation und insbesondere der Fähigkeit des Wartungspersonals (insbesondere, wenn es um seltene oder alte Programmiersprachen geht) ab. Deswegen kann die Auswirkung derKomplexität, über die man mit der zyklomatischen Komplexität eine Aussage treffen will, durch andere Attribute überlagert werden. Das spricht nicht generell gegen den Versuch aus der Komplexität auf die Wartbarkeit zu schliessen, allerdings kann man dies bisweilen nur unter Vorbehalt oder wenn man weiss, wie stark sich andere interne Attributeauswirken.

zurück  |  weiter 1 / 1