Gliederung 1. 2. Erweiterung der Strukturierten Analyse zu SA/RT SW Engineering und der menschliche Faktor Teil 1. Erweiterung der Strukturierten Analyse zu SA/RT Strukturierte Analyse (SA) (Wiederholung – Überblick) Kombination von drei (nicht neuen!) Konzepten: • Hierarchisch angeordnete DFDs, • Data Dictionary-Einträge (DDs), • Mini-Spezifikationen (MiniSpecs). Hierarchisierung zur Steigerung der Übersichtlichkeit • Kontextdiagramm steht als abstraktes DFD in der obersten Hierarchieebene. • Jeder Prozess eines DFD kann in untergeordneten Diagrammen verfeinert werden. • Ist keine Verfeinerung mehr möglich, wird eine textuelle Mini-Spezifikation erstellt. • Balanciertes Datenmodell durch Data Dictionary. SA/RT SWT P. Forbrig und A. Dittmar 3 KontextDiagramm HierarchieKonzept SA Diagramm 0 Diagramm 3 MiniSpec 3.1 SA/RT SWT P. Forbrig und A. Dittmar 4 aus (Balzert, 2000) Datenflussdiagramme (DFD) • Zeigen die funktionalen Beziehungen der von einem System transformierten Daten, einschl. Eingabe-, Ausgabedaten und interne Datenbestände. • Beschreiben Daten-, aber keine Steuerflüsse! • Innerhalb der Strukturierten Analyse (SA) entwickelt (Tom deMarco, 1979). Preis Kunde Preis bestimmen Artikelname SA/RT SWT P. Forbrig und A. Dittmar 5 DFD: Beschreibungsprimitive Prozesse (Funktionen): • beschreiben Funktionalität des Systems • haben Ein- und/oder Ausgabedatenflüsse Datenflüsse: • Transport von Daten zwischen Teilen des Systems • sind getypt • besitzen Quelle und/oder Ziel Speicher (Lager): • ruhende Daten im System, • lesender und/oder schreibender Zugriff • sind getypt • weisen i.allg. auf Dateien oder Datenbanken im späteren System hin Schnittstellen (Begrenzer): • Schnittstelle des Systems zur Außenwelt • nicht Gegenstand der Anforderungsermittlung SA/RT SWT P. Forbrig und A. Dittmar Prozessname Datenname Speichername Schnittstellenname 6 Das Kontextdiagramm • Beschreibt die Schnittstellen des Systems zur Umwelt, • Repräsentiert das Gesamtsystem, • Syntaktische Regeln - Enthält nur einen Prozess (Nr. 0), - Enthält mindestens eine Schnittstelle, - Zwischen Schnittstellen keine Datenflüsse, - Enthält keinen Speicher. D1E S1 D1A Schnittstelle zur Umwelt SA/RT Datenflußname SWT P 0. D2E Eingabedatenfluß S2 D2A Ausgabedatenfluß Prozeß, repräsentiert das Gesamtsystem, gekennzeichet durch 0. P. Forbrig und A. Dittmar 7 Kontextdiagramm (Forts.) • Beschreibt Anwendungsbereich des Systems. • Zeigt Datenflüsse über die Systemgrenzen. • Kann es von derselben Schnittstelle mehrere Instanzen geben, wird sie einmal dargestellt. • Gibt es wenige gleichartige Schnittstellen mit unterschiedlichen Datenflüssen, dann getrennte Darstellung. • Schnittstelle muss ursprüngliche Quelle oder Senke einer Information angeben. • Datenflüsse müssen auf angemessenem Abstraktionsniveau beschrieben werden - nicht zu detailliert, nicht zu abstrakt (also nichtssagend), - die wesentlichen Informationen über die Umwelt müssen erkennbar sein, - problembezogene Namensgebung. SA/RT SWT P. Forbrig und A. Dittmar 8 Funktionsbäume und SA DFD D1 Funktionsbaum D4 A1 D2 A2 S A A3 A1 ... A2 A 21 A3 A 22 D3 ... Wenn eine Funktion F aus dem Funktionsbaum auf einen Prozess P in einem DFD eines entsprechenden SA-Modells abgebildet werden kann, entsprechen die Teilfunktionen von F den Prozessen in dem DFD, das P verfeinert. SA/RT SWT P. Forbrig und A. Dittmar 9 Tom DeMarco • nicht nur bedeutende Beiträge zur SA, sondern auch zum Software-Management. • In “Peopleware” (1987, mit T. Lister) Behandlung von menschlichen Aspekten bei der Software-Entwicklung (z.B. Auswahl der Mitarbeiter, Projektplanung und –management, Motivation, Gruppenarbeit, Einfluss der Arbeitsumgebung) - Die Produktivität bei der Programmierung ist nicht nur von den verwendeten Methoden, Sprachen, Tools... abhängig, sondern in großem Maße von politischen und sozialen Aspekten der Projekte. - Wie erreicht man eine gute Moral im Projektteam? - Vielfalt ist z.B. wichtig! Auch bei der Zusammenstellung von Teams: “A little bit of heterogeneity can be an enormous aid to create a jelled team... It is a clear signal that it’s okay not to be a clone, okay not to fit into the corporate mold of Uniform Plastic Person.” SA/RT SWT P. Forbrig und A. Dittmar 10 Structured Analysis/Real Time Analysis (SA/RT) • SA verzichtet bewusst auf die Beschreibung der Initialisierung und Terminierung eines Systems. • Zeitanforderungen und Reihenfolgen können nicht festgelegt werden. RT erweitert SA, so dass ereignisgesteuerte Systeme mit Zeitanforderungen und komplexen Prozessaktivierungen (-steuerungen) modelliert werden können. • Ward/Mellor 1985: »Structured Development for Real-Time Systems« • Hatley/Pirbhai 1987: »Strategies for Real-Time System Specification« SA/RT SWT P. Forbrig und A. Dittmar 11 SA/RT: neue bzw. modifzierte Konzepte • Flussdiagramm (FD) - um Kontrollflüsse erweitertes DFD, • Kontrollflussspezifikation (CSpec) - optional zu einem FD zugeordnet, - beschreibt die Prozessaktivierung im FD, • Prozess-Spezifikation (PSpec) - beschreibt einen elementaren (nicht verfeinerten) Prozess, - entspricht MiniSpec in SA, • Requirements Dictionary (RD) - beschreibt alle Speicher, Daten- und Kontrollflüsse, - entspricht DD in SA, • Zeitspezifikation - beschreibt absolute Zeitanforderungen zwischen externen Ein- und Ausgabeereignissen in einer Tabelle. SA/RT SWT P. Forbrig und A. Dittmar 12 Modellierungsaufgabe (Balzert, 2000) - Ein einfaches Softwaresystem steuert das Füllen und Leeren eines Tanks, indem es den Flüssigkeitsstand im Tank überwacht und die Ventile entsprechend öffnet und schließt. - Es gibt ein Einlass- und ein Auslassventil. - Jedes Ventil kann zwei Zustände einnehmen: geöffnet und geschlossen. - Das Einlassventil besitzt beim Öffnen eine Zeitverzögerung von 2 sec. - Der Bediener kann das gewünschte Flüssigkeitsniveau ins System eingeben, wenn der Tank leer ist. - Das System akzeptiert folgende Kommandos: - Tank auf das gewünschte Niveau füllen (bei leerem Tank): Beim Füllen des Tanks wird das Einlassventil geöffnet und die Flüssigkeit strömt in den Tank ein, bis die vorgegebene Füllhöhe erreicht ist. - Tank leeren (bei vollem Tank): Das Entleeren des Tanks wird mit entsprechenden Auslassventilkommandos (Auf, Zu) gesteuert. SWT P. Forbrig und A. Dittmar 13 - Ein SA/RT Geber meldet den aktuellen Flüssigkeitsstand des Tanks. Kontextdiagramm im Beispiel Bediener Soll-Füllstand .0 Kommando überwache Tankfüllstand Geber Einlassventil EV_Status Datenfluss AV_Status Auslassventil Ist-Füllstand Kontrollfluss Einträge im Requirements Dictionary (RD): Kommando EV_Status AV_Status Ist_Füllstand Soll_Füllstand SA/RT SWT ::= [Eingabe_Soll | Füllen | Leeren] ::= [Zu | Auf] ::= [Zu | Auf] ::= Integer ::= Integer P. Forbrig und A. Dittmar 14 Datenflüsse vs. Kontrollflüsse Datenflüsse: • Werden in den Prozessen verarbeitet bzw. transformiert. • Elementare Datenflüsse sind meistens kontinuierliche Signale (Beispiel: 0..250 km/h). • Ein Datenfluss kann auch ein diskretes Signal sein, wenn es selbst verarbeitet wird. Kontrollflüsse: • Steuern die Verarbeitung. • Sind immer diskrete Signale. (Beispiel: Startknopf = [ gedrückt | nicht gedrückt ]). Unterscheidung zwischen Kontroll- und Datenflüssen oft schwierig! SA/RT SWT P. Forbrig und A. Dittmar 15 FD 0: Verfeinerung von „überwache Tankfüllstand“ Soll-Füllstand .1 setze Soll-Niveau .2 prüfe Tank Ist-Füllstand Soll-Niveau .3 öffne Auslassventil .4 schließe Auslassventil .6 schließe Einlassventil Balkendiagramm: AV_Status .5 öffne Einlassventil Kommando EV_Status Tank_Status SA/RT SWT P. Forbrig und A. Dittmar 16 FD 0 und aktualisiertes Requirements Dictionary Soll-Füllstand .1 setze Soll-Niveau .2 prüfe Tank Soll-Niveau .3 öffne Auslassventil Ist-Füllstand AV_Status EV_Status Kommando Tank_Status .6 aktualisiertes RD: schließe Kommando ::= [Eingabe_Soll | Füllen | Leeren] Einlassventil EV_Status ::= [Zu | Auf] .5 AV_Status ::= [Zu | Auf] öffne ::= Integer Einlassventil Ist_Füllstand Soll_Füllstand ::= Integer Tank_Status ::= [Voll | Leer] // internes Ereignis Soll-Niveau ::= Integer .4 schließe Auslassventil SA/RT SWT P. Forbrig und A. Dittmar 17 Kontrollspezifikationen (CSpecs) • SA: Verarbeitungsinformationen stehen nur in den MiniSpecs. • RT: ermöglicht die Beschreibung der Prozesssteuerung in Abhängigkeit von externen Ereignissen auf höhereren Hierarchieebenen (m.H. von CSpecs). • Jedem FD kann eine CSpec zugeordnet werden: - enthält Entscheidungstabelle(n) und/oder - Zustandsautomat. AV_Status Kommando EV_Status • Zusammenhang zwischen CSpec und FD: Tank_Status - wird durch Balkendiagramm im FD beschrieben, - Kontrollflüsse, die Eingangsgrößen für eine CSpec sind, werden mit der Pfeilspitze zum Balken gezeichnet, - Kontrollflüsse, die eine CSpec verlassen, führen vom Balken weg. SA/RT SWT P. Forbrig und A. Dittmar 18 Im Beispiel: Zustandsautomat als CSpec von FD 0 [Kommando=Eingabe_Soll ]/ .1 [Tank_Status=Leer ]/ .4 Tank ist leer Tank wird geleert do: .2 Tank wird gefüllt do: .2 [Kommando=Leeren] / .3 Prozesse aus FD 0: .1 setze Soll-Niveau .2 prüfe Tank .3 öffne Auslassventil .4 schließe Auslassventil .5 öffne Einlassventil .6 schließe Einlassventil SA/RT [Kommando=Füllen] / .5 SWT Tank ist voll [Tank_Status=Voll ]/ .6 Einträge aus dem RD: Kommando ::= [Eingabe_Soll | Füllen | Leeren] EV_Status ::= [Zu | Auf] AV_Status ::= [Zu | Auf] Tank_Status ::= [Voll | Leer] P. Forbrig und A. Dittmar 19 Zusammenhang FD und CSpec Fall A: CSpec ist ein Zustandsautomat • Eingabepfeile des Balkens im FD verweisen auf die Kontroll- flüsse, deren Werte die Ereignisse im Zustandsautomaten bilden. • Alle Prozessnamen werden als Aktionsnamen im Zustandsautomaten benutzt. • Ausgabepfeile des Balkens im FD verweisen auf die Kontrollflüsse, deren Werte als Ausgabeereignisse nach außen gesendet werden (im Zustandsautomaten bzw. in den PSpecs von elementaren Prozessen des FDs). Fall B: CSpec ist eine Entscheidungstabelle Fall C: CSpec ist Kombination aus Zustandsautomat und Entscheidungstabelle(n) ... siehe (Balzert, 2000) SA/RT SWT P. Forbrig und A. Dittmar 20 Prozessspezifikation (PSpec) für elementare Prozesse 3 Möglichkeiten zur Prozesssteuerung • Prozess läuft während der gesamten Systemlaufzeit: - darf in keiner CSpec erscheinen. • Prozess wird aktiviert und terminiert sich selbst: - Aktivierung durch Zustandsübergang oder durch Eintreten einer Bedingung in einer Entscheidungstabelle (in CSpec), - In PSpec muss das Schlüsselwort Issue vor den Prozessnamen geschrieben werden. • Prozess wird aktiviert und beim nächsten Zustandsübergang automatisch deaktiviert: - Aktivierung durch Zustandsübergang oder Bedingung in der Entscheidungstabelle (in CSpec). SA/RT SWT P. Forbrig und A. Dittmar 21 Im Beispiel: PSpec für Prozess .2 („prüfe Tank“) // Erzeugung von internen Ereignissen while true if Ist_Füllstand = 0 then erzeuge_Ereignis:“Tank_Status=Leer“ else if Ist_Füllstand >=Soll_Füllstand then erzeuge_Ereignis:“Tank_Status=Voll“ end_while Ausschnitt aus FD 0: Soll-Füllstand .1 setze Soll-Niveau .2 prüfe Tank Ist-Füllstand AV_Status Soll-Niveau EV_Status Kommando Tank_Status SA/RT SWT P. Forbrig und A. Dittmar 22 PSpec für Prozess .3 („öffne Auslassventil“) // Erzeugung eines externen Ereignisses Issue erzeuge_Ereignis:“AV_Status=Auf“ Ausschnitt aus FD 0: .3 öffne Auslassventil AV_Status EV_Status Kommando Tank_Status SA/RT SWT P. Forbrig und A. Dittmar 23 Zeitspezifikationen RT ermöglicht die Spezifikation von externen Zeitanforderungen. 2 Arten von Zeitspezifikationen: • Wiederholungszyklen für externe, elementare Ausgabesignale: - werden im RD durch das Attribut “Rate” festgelegt (z.B.: Stunden = 0..23, Rate: alle 100 msec) • Eingabe-Ausgabe-Antwortzeiten: - Legen den erlaubten Antwortzeitbereich für jedes Eingabeereignis und das resultierende Ausgabeereignis durch Zeitspezifikationstabelle fest. Zeitspezifikationstabelle im Beispiel: Eingabesignal Ereignis Ausgabesignal Ereignis Antwortzeit Kommando EV_Status 2 sec. SA/RT “Füllen” SWT P. Forbrig und A. Dittmar “Auf” 24 Beispiel Uhr • Flussdiagramm (FD): – Enthält sowohl Daten- als auch Kontrollflüsse • Beispiel: Druck– RT-Kontextdiagramm »Digitaluhr« knopf_1 Kno pf 2 o pf 1 n K .0 stelle Uhr Batterie blink ende Anze ige t Star SA/RT Anzeige SWT P. Forbrig und A. Dittmar Druckknopf_2 Uhrendisplay 25 f2 • FD0 a St »Digitaluhr« Anzeige aktualisiere Zeit Zeit auf 0 stellen rt .4 Stunden blinken .2 Normalzeit anzeigen Zeit blinkende Sekunden SA/RT .8 Sekunden blinken SWT erhöhte Minuten ak Se t u e l ku le nd en Null de Sekun e ell n u t ak nde u St erhö hte Stun den .5 Stunde um 1 erhöhen lle tue n ak ute n Mi .9 Sekunde auf 0 stellen blinkende Stunden Kn op f1 8.2 Flussdiagramme .3 .1 op n K .7 Minuten um 1 erhöhen P. Forbrig und A. Dittmar .6 Minuten blinken blinkend e Minuten 26 Automat für Uhr • Zustandsautomat von CSpec 0 SWT P. Forbrig und A. Dittmar SA/RT 27 Beziehung Aktionen aus Automat zu Prozessen • ET von CSpec 0 SA/RT SWT P. Forbrig und A. Dittmar 28 Überblick SA/RT Konzepte: • hierarchisch angeordnete FDs • Requirements Dictionary (RD) • Prozess-Spezifikationen (PSpecs) • Kontrollflussspezifikationen (CSpecs) • Zeitspezifikationen Kontextdiagramm beschreibt die Umgebung des Systems: SA/RT SWT P. Forbrig und A. Dittmar 29 Überblick SA/RT (Forts.) Verfeinerung von Prozessen (hier: P) durch weitere DFs: SA/RT SWT P. Forbrig und A. Dittmar 30 Überblick SA/RT (Forts.) CSpec0 (hier als Zustandsautomat) zur Aktivierung von Prozessen aus FD0: FD0: SA/RT SWT P. Forbrig und A. Dittmar 31 Kontext8.6 Das Diagramm Hierarchiekonzept Zeitspezifikationstabelle 0 FD 0 1 CSpec 0 2 3 Spec 1 Spec 3 FD 2 2.1 RD 2.2 X 2.3 CSpec 2 Spec 2.2 SWT P. Forbrig und A. Dittmar SA/RT Spec 2.1 Spec 2.3 32 Zusammenfassung SA/RT Vorteile: + Gut geeignet zur Modellierung ereignisgesteuerter Systeme. + Komplexe Steuerungszusammenhänge können beschrieben werden. + Gute Werkzeugunterstützung. Nachteile: – Schwieriger als SA zu erlernen und zu verstehen. – Wird leicht unübersichtlich. Zur Methodik und Qualitätssicherung bei der Strukturierten Analyse siehe (Balzert, 2000) SA/RT SWT P. Forbrig und A. Dittmar 33 Teil 2: SW Engineering und der menschliche Aspekt Die Rolle der Menschen im SW Engineering Human-Centered Software Engineering Software wird von Menschen gemacht! - Können - Motivation - Arbeitsumfeld Rollen und Verantwortlichkeiten: • Entwickler und seine Spezialisierungen • Projektleiter und Gruppenleiter • Kunde, Anwender und andere Betroffene (Stakeholder) Rolle Mensch SWT P. Forbrig & A. Dittmar 35 Produktivitätsfaktoren in Projekten (Ludewig, Lichter, 2007) • Schwankungsbreiten bis zu 20:1 • in Gruppen noch 4:1 Rolle Mensch SWT P. Forbrig & A. Dittmar 36 Arbeitstreffen effektiv gestalten “Common complaints about meetings include • The purpose of the meeting is unclear. • The attendees are unprepared. • Essential people are absent or late. • The conversation veers away from its purpose. • Some meeting participants do not discuss substantive issues. Instead, they argue, dominate the conversation, or do not participate. • Decisions made at the meeting are never enacted (Pfleeger, 2001) afterward.” Rolle Mensch SWT P. Forbrig & A. Dittmar 37 Rationale Erkenntnis vs. emotionale Befindlichkeit In der Praxis werden viele Maßnahmen nicht ergriffen, deren Nutzen und Wirksamkeit längst erwiesen ist, z.B. • Größe und Komplexität - Denken im Kleinen vs. Arbeiten im Großen • Ego der Entwickler - Individuum vs. Kollektiv - Kreativität vs. Systematik - Bedrohung durch Überprüfung vs. Qualität durch Prüfung • Lust und Frust - Programmieren ist selbstmotiviert, dokumentieren nicht - Debuggen ist selbstmotiviert, testen nicht • Zeiteffekte - Trägheit vs. Fortschritt - kurzfristiges Denken vs. langfristige Wirkung von SE-Maßnahmen (Glinz, 2006) Rolle Mensch SWT P. Forbrig & A. Dittmar 38 Motivation • Selbstmotivation ausnutzen • Explizite Anreize für nicht selbstmotivierte Arbeiten • “Egoless programming” ohne Ego-Verlust der Entwickler ermöglichen • Gute Arbeitsbedingungen schaffen • Leute ernst nehmen und fördern • Selbstwertgefühl steigern • Software Ingenieure sollen stolz sein können auf ihre Produkte! • Auch Software-Ingenieure brauchen ein Berufsethos (Glinz, 2006) Rolle Mensch SWT P. Forbrig & A. Dittmar 39 4.3 Values and Ideals I must act with professional responsibility and integrity in xxx my dealings with the community and clients, employers, employees and students. I acknowledge: 4.3.1 Priorities I must place the interests of the community above those of personal or sectional interests. 4.3.2 Competence I must work competently and diligently for my clients and employers. 4.3.3 Honesty I must be honest in my representation of skills, knowledge, services and products. 4.3.4 Social Implications I must strive to enhance the quality of life of those affected by my work. 4.3.5 Professional Development I must enhance my own professional development, and that of my colleagues, employees and students. 4.3.6 Information Technology Profession I must enhance the integrity of the information technology profession and the respect of its members for each other. Rolle Mensch SWT P. Forbrig & A. Dittmar 40 Zusammenfassung als Gegenüberstellung von Entwicklungsansätzen technikzentriert menschenzentriert • Systeme werden vollständig geplant • Systeme evolvieren, fortlaufende Planung • Systeme werden aus Komponenten konstruiert • Systeme wachsen • Fokus auf Konstruktion • Fokus auf Verstehen • Systeme realisieren/erzwingen Prozesse und Organisationsformen • Systeme helfen Menschen, ihre Arbeit besser/einfacher zu tun • Prozesse sind detailliert beschrieben und exakt zu befolgen (Workflow) • Prozesse sind Leitplanken / Checklisten • Spezifikationen sind vollständig, exakt, möglichst formal • Spezifikationen sind partiell und evolutionär (aber wohlorganisiert, Konfigurationsmanagement) (Glinz, 2006) Rolle Mensch SWT P. Forbrig & A. Dittmar 41
© Copyright 2024 ExpyDoc
