Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network

Share

Anforderungsanalyse und UML Grundlagen

on

  • 4,741 views

 

Statistics

Views

Total Views
4,741
Views on SlideShare
4,261
Embed Views
480

Actions

Likes
0
Downloads
50
Comments
0

11 Embeds 480

http://software-technik.blogspot.com 252
http://software-technik.blogspot.de 179
http://software-technik.blogspot.co.at 19
http://software-technik.blogspot.ru 9
http://software-technik.blogspot.ch 9
http://www.software-technik.blogspot.com 7
http://software-technik.blogspot.hu 1
http://software-technik.blogspot.co.uk 1
http://software-technik.blogspot.com.es 1
http://webcache.googleusercontent.com 1
http://software-technik.blogspot.kr 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Anforderungsanalyse und UML Grundlagen Presentation Transcript

  • 1. Software Technik II HTWG Konstanz Anforderungsanalyse Anwendungsfälle modellieren und UML Christian Baranowski
  • 2. Funktionale Anforderungen erfassen mittels Prototyping
  • 3. JAVASCRIPT Wiederholung
  • 4. Functions sayHello(function(){ alert('Hello World'); }); function sayHello(printer) { printer(); }
  • 5. Objects function Customer(){}; Customer.prototype.setName = function(name){ this.name = name; };! Customer.prototype.getName = function(){ return this.name; }; var customer = new Customer(); customer.setName('Christian');
  • 6. DOM • getElementById(...) • document.createElement('input') • addEventListener('click', function(){}, true); • ...
  • 7. JSON • Syntax Objekte { string : value } oder {string : value, string value} • Syntax Array [value, value] • value = string, number, object, array, true, false, null
  • 8. JavaScript Model persistieren im Klickpilot window.name = JSON.stringify(model); model = JSON.parse(window.name);
  • 9. HTML Seite laden window.location.href = 'customer.html';
  • 10. JQUERY Einführung in JQuery
  • 11. Was ist JQuery • jQuery ist ein von John Resig entwickeltes, open source Javascript-Framework. • Funktionen zum Navigieren / Manipulieren DOM • Funktionen für animierte Effekte, Ajax und Event- Handling
  • 12. Wie verwendet man JQuery <script src="jQuery.js" type="text/ javascript"></script>
  • 13. JQuery Syntax ${<<selektor>>} Beispiele: $("a").click(function(){ alert("Click Link!"); return false; }); $("#saveButton").click(function(){ alert("Click Button with ID saveButton"); return false; });
  • 14. Vorteile von JQuery • DOM Abstraktion • FlexibleFunktionen um Elemente im DOM zu selektieren • jQuery ist ein Tool um viel Zeit und Code zu sparen. • leicht lesbarerer Javascript-Code
  • 15. Übungen I •Verbinden Sie Ihre Formulare via JavaScript •Ziel: Man kann eine Aufgabe anlegen diese wird auf der Übersichtsseite angezeigt. •Speichern Sie Daten für den Klickpilot im Browser z.B. in den window.name via JSON
  • 16. Anforderungsanalyse und Spezifikation
  • 17. Requirement Analysis Wasserfallmodell Wir sind immer noch in der Phase der System Design Anforderungsanalyse Coding Testing Delivery
  • 18. Ausgangssituation • Wir wissen nicht was der Kunde wünscht • Der Kunde weiß es - auch nicht!
  • 19. Anforderungsanalyse How Projects Really Work (version 2.0) Create your own How the How the project How the analyst How the What the beta How the How customer leader designed it programmer testers received business explained it understood it wrote it consultant doc described it Create your own cartoon at www.projectcartoon.com
  • 20. Anforderungsanalyse Verstehen was der Kunde braucht Ziel Ziele Vision Spezifikation Anforderungsanalyse der Anforderungen Ausgangssituation
  • 21. Ziele der Anforderungsanalyse • Wünsche erfassen (Anforderungen) • Abhängigkeiten aufdecken • Sinnhaftigkeit verifizieren • Machbarkeit prüfen
  • 22. Anforderungstypen oder welche Art Wünsche gibt es ?
  • 23. Anforderungstypen Qualitätsmerkmale ISO9126 Architekturziele Verfügbarkeit Änderbarkeit Funktionale Anforderungen nicht Performanz Funktionale Anforderungen Sicherheit Anwendungsfälle Geschäftsprozesse Testbarkeit Bedienbarkeit Quelle: Dr. Peter Hruschka & Dr. Gernot Starke - ARC42.de
  • 24. Prozess zur Anforderungserfassung 1. Oberfläche skizzieren z.B. Methode Wireframes in einem Workshop mit dem Kunden 2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und JavaScript 3. Fachliche Komponenten aus dem Klick-Modell identifizieren 4. Use-Cases und Geschäftsmodell aus dem Klick-Modell ableiten für die einzelnen fachlichen Komponenten 5. Spezifikation erstellen
  • 25. Prozess zur Anforderungserfassung 1. Oberfläche skizzieren z.B. Methode Wireframes in einem Workshop mit dem Kunden 2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und JavaScript 3. Fachliche Komponenten aus dem Klick-Modell identifizieren 4. Use-Cases und Geschäftsmodell aus dem Klick-Modell ableiten für die einzelnen fachlichen Komponenten 5. Spezifikation erstellen
  • 26. Fachliche Komponenten erfassen und modellieren
  • 27. Fachliche Komponenten Eine fachliche Komponente gruppiert Funktionalität die fachlich zusammengehört. Die Anwendung wird in fachliche Einheiten Komponenten aufgeteilt. Beispiele: Kunden Verwaltung, Verkauf, Vertrieb Logging, Suche, ...
  • 28. Fachliche Komponenten Aus welchen Teilen besteht meine Anwendung? Mind-Maps nutzen als Methode zur Ermittlung
  • 29. Fachliche Komponenten Aus welchen Teilen besteht meine Anwendung? Substantive nutzen Mind-Maps nutzen als Methode zur Ermittlung
  • 30. Use-Case / Anwendungsfälle erfassen und modellieren für die fachlichen Komponenten
  • 31. Anwendungsfall „Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen.“ - Wikipedia
  • 32. Anwendungsfall Ein Anwendungsfall sollte nach dem Muster: Substantiv Verb benannt werden. Beispiele: Kunde anlegen, Kunden verwalten ...
  • 33. Aufbau eines Anwendungsfalls • Name und Nummer (z.B. Kunden verwalten / UC-2.01) • Beschreibung • Kurze Beschreibung, was im Anwendungsfall passiert. • Beteiligte Akteure • Akteure sind beteiligte Personen oder Systeme • Verwendete Anwendungsfälle • Aufzählung der verwendeten Anwendungsfälle • Auslöser • Vorbedingungen • Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt werden kann. • Nachbedingung / Ergebnis • Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet wird.
  • 34. Use-Case / Anwendungsfälle erfassen mit der UML
  • 35. UML Use Cases • Was ist die UML? • Unified Modeling Language • Vereinheitlichte Modellierungssprache • UMLwird von der Object Management Group (OMG) entwickelt
  • 36. UML Use Cases • UML kennt 13 verschiedene Diagramme
  • 37. UML Use Cases • UML Use Cases (Anwendungsfälle) • “High Level” Beschreibung des Systems • Beschreiben - Systemgrenze - Funktionalität - Berechtigungskonzept • Einfach erlernbar, wenige Notationselemente
  • 38. Notationselemente • Akteur • Assoziationen - Steht mir Use Case in Verbindung - Können gerichtet sein - Hat immer einen Name - Nur binäre Assoziationen - Darstellung: z.B. als Strichmännchen - Darstellung: Linie • Use Case • System - Beschreibt nach außen sichtbares - Beschreibt die System grenzen Verhalten des Systems - Darstellung: Rechteck - Von Akteur ausgelöst - Hat Ergebnis, kein internes Verhalten - Darstellung: Ellipse
  • 39. Anwendungsfälle erfassen mit UML
  • 40. Anwendungsfälle erfassen mit UML
  • 41. Rollen erfassen mit UML
  • 42. Systemgrenze erfassen mit UML
  • 43. Übungen II •Anwendungsfälle anhand des Klickpilot oder Wireframes erfassen als UML Diagramm.
  • 44. Anwendungsfälle spezifizieren oder kurz gesagt Text schreiben • Tabellen basiere Beschreibung (Template) • Domain spezifische Sprache zur Spezifikation • Textuelle Beschreibung
  • 45. Use-Case Beispiel
  • 46. Use-Case als zentrales Analyseelement Architekturziele UI Anforderungen Verfügbarkeit UI Design Änderbarkeit Business Regeln Performanz Use-Case Sicherheit Daten Format Testbarkeit ... Bedienbarkeit
  • 47. Nicht-funktionale Anforderungen I 1. Technische Anforderungen 2. Anforderungen an die Benutzerschnittstelle 1. 1. Design/Lösungen 2. 1. Gestaltung und Beschriftung 1. 1. 1. Programmiersprache 2. 2. Konformität zu bestehenden Systemen 1. 1. 2. Client / Arbeitsstation 2. 3. Dialogführung 1. 1. 3. Server 2. 4. Personalisierung und Internationalisierung 1. 1. 4. Netzwerk 2. 5. Zugänglichkeit 1. 1. 5. Datenaustausch 2. 6. Verschiedenes 1. 1. 6. Software 1. 1. 7. Hardware 1. 1. 8. Architektur 1. 1. 9. Einzusetzende Materialien 1. 1.10. Physikalische Aspekte 1. 2. Betriebliche Anforderungen 1. 2. 1. Physikalisches Umfeld 1. 2. 2. Technologisches Umfeld 1. 2. 3. Arbeitsplatz-Umgebung 1. 2. 4. Mengengerüst 1. 3. Neue Probleme 1. 3. 1. Auswirkungen bestehendes Umfeld 1. 3. 2. Auswirkungen auf die Benutzer 1. 3. 4. Kulturelle Aspekte Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
  • 48. Nicht-funktionale Anforderungen II 3. Qualitätsanforderungen 3. 5. 2. Konformität 3. 1. Benutzbarkeit 3. 5. 3. Installierbarkeit 3. 1. 1. Verständlichkeit 3. 5. 4. Austauschbarkeit 3. 1. 2. Bedienbarkeit 3. 5. 5. Wiederverwendbarkeit 3. 1. 3. Erlernbarkeit 3. 1. 4. Effektivität 3. 6. Zuverlässigkeit 3. 1. 5. Einheitlichkeit 3. 6. 1. Fehlertoleranz 3. 6. 2. Reife 3. 2. Effizienz 3. 6. 3. Wiederherstellbarkeit 3. 2. 1. Verbrauchsverhalten 3. 2. 2. Zeitverhalten 3. 7. Änderbarkeit 3. 7. 1. Analysierbarkeit 3. 3. Produktnutzungszeitraum 3. 7. 2. Modifizierbarkeit 3. 3. 1. Wartung 3. 7. 3. Stabilität 3. 3. 2. Produzierbarkeit 3. 7. 4. Testbarkeit 3. 3. 3. Produktentsorgung 3. 3. 4. Langlebigkeit 3. 8. Funktionalität 3. 8. 1. Richtigkeit 3. 4. Safety und Security 3. 8. 2. Ordnungsmäßigkeit 3. 4. 1. Schutz der Systemumgebung 3. 8. 3. Funktionsabdeckung 3. 4. 2. Schutz des Systems 3. 8. 4. Funktionale Widerspruchsfreiheit 3. 8. 5. Interoperabilität 3. 5. Übertragbarkeit 3. 8. 6. Angemessenheit 3. 5. 1. Anpassbarkeit 3. 8. 7. Verfolgbarkeit 3. 9. Durchführbarkeit Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
  • 49. Nicht-funktionale Anforderungen III 4. Anforderungen an sonstige Lieferbestandteile 5. Anforderungen an durchzuführende Tätigkeiten 4. 1. Software-Dokumentation 5. 1. Produktlebenszyklus 4. 1. 1. Requirements Spec./ Pflichtenheft 5. 1. 1. Analyse 4. 1. 2. Architektur und Design 5. 1. 2. Architektur und Design 4. 1. 3. Interfaces / Schnittstellen 5. 1. 3. Implementierung 4. 2. Hardware-Dokumentation 5. 1. 4. Tests 4. 3. Testdokumentation 5. 1. 5. Fertigung 4. 4. Prototypen 5. 1. 6. Installation 4. 5. Wartungshandbuch 5. 1. 7. Auslieferung 4. 6. Installationshandbuch 5. 1. 8. Wartung 4. 7. Benutzerdokumentation 5. 1. 9. Support 4. 7. 1. Hilfs- und Lernprogramme 5. 2. Anforderungsmanagement 4. 7. 2. Benutzerhandbuch 5. 3. Projekt Management 4. 7. 3. Administrationshandbuch 5. 3. 1. Projekthandbuch 4. 8. Schulungen 5. 3. 2. Projekt Plan 4. 9. Marketing und Vertrieb 5. 3. 3. Rollen 4.10. Hardware 5. 3. 4. Kommunikationsrichtlinien 4.11. Projekt Management 5. 4. Qualitätsmanagement 4.11. 1. Projektplan und -beschreibung 5. 5. Konfigurationsmanagement 4.11. 2. Richtlinien 5. 6. Änderungsmanagement 4.12. Support 5. 7. Risikomanagement 4.13. Allgemein Fortsetzung Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
  • 50. Nicht-funktionale Anforderungen IV 5. 8. Benutzerdoku. und Schulungen 6. Rechtlich-vertragliche Anforderungen 5. 8. 1. Benutzerhandbuch und Hilfesystem 6. 1. Vertragliche Anforderungen 5. 8. 2. Schulungs- und Lernunterlagen 6. 2. Anforderungen an den Auftragnehmer 5. 8. 3. Schulungen 6. 3. Lieferantenmanagement 5. 8. 4. Administrationsdokumentation 6. 4. Kosten 5. 9. Allgemein 6. 4. 1. Financial Budget for the Project 5. 9. 1. Standards 6. 5. Angebot 5. 9. 2. Dokumentationsmanagement 6.5.1. Formale Aspekte 6.5.2. Inhalt des Angebotes 6. 6. Rechtliche Anforderungen 6. 7. Compliance Requirements 6. 7. 1. Gesetzliche Anforderungen 6. 7. 2. Standards Quelle: Ivena Referenzdatenbank, SOPHIST GmbH
  • 51. Geschäftsmodell erfassen und modellieren mit der UML
  • 52. UML Klassendiagramme Teil 1 Klassendiagramme sind Strukturdiagramm der UML zur grafischen Darstellung von Klassen und deren Beziehungen.
  • 53. Klassen und Assoziationen
  • 54. Kardinalitäten
  • 55. Gerichtet und Bidirektionale Assoziation
  • 56. Aggregation
  • 57. Komposition
  • 58. Vererbung
  • 59. UML Klassendiagramme • Mehr zu den Klassendiagrammen in der nächsten Vorlesung wenn es um Design geht.
  • 60. Spezifikation erstellen Gesamtspezifikation / Pflichtenheft
  • 61. Template Gesamtspezifikation Anforderungsanalyse 1. Einleitung 2. Ausgangssituation und Zielsetzung 3. Funktionale Anforderungen 4. Nicht-funktionale Anforderungen 5. Sicherheitsrelevante Anforderungen, Risikoakzeptanz und Sicherheitsstufen 6. Lebenszyklusanalyse und Gesamtsystemarchitektur 7. Schnittstellenübersicht
  • 62. Template Anforderungsanalyse PROJECT DRIVERS: NON-FUNCTIONAL REQUIREMENTS: 1. The Purpose of the Project 10. Look and Feel 2. Client, Customer, Stakeholders 11. Usability and Humanity 3. Users of the Product 12. Performance 13. Operational PROJECT CONSTRAINTS: 14. Maintainability and Support 4. Mandated Constraints 15. Security 5. Naming Conventions and Definitions 16. Cultural and Political 6. Relevant Facts and Assumptions 17. Legal FUNCTIONAL REQUIREMENTS: PROJECT ISSUES: 7. The Scope of the Work 18. Open Issues 8. The Scope of the Product 19. Off-the-shelf Solutions 9. Functional and Data Requirements 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions Quelle: http://www.volere.co.uk
  • 63. Übungen III •Geschäftsmodell (Klassendiagramm) entwickeln •Erstellen sie eine kleine Gesamtspezifikation