Objektorientierte Modellierung mit UML
|
|
- Götz Hofmeister
- vor 6 Jahren
- Abrufe
Transkript
1 Objektorientierte Modellierung mit UML Anwendungsfalldiagramm Der vorliegende Foliensatz basiert auf: M. Seidl, M. Brandsteidl, C. Huemer, G. Kappel: dpunkt.verlag, C. Larman: UML 2 und Patterns angewendet, mitp-verlag,
2 Anwendungsfallmodellierung Einführung Funktionale Zerlegung des zu entwickelnden Systems in Anwendungsfälle und in Akteure Anwendungsfälle (Use Cases) repräsentieren die Anforderungen der Kunden Akteure interagieren mit dem System im Kontext der Anwendungsfälle Ergebnisse der Anwendungsfallmodellierung Globales Anwendungsfalldiagramm (Use Case Diagram) Weitere Anwendungsfalldiagramme nach Bedarf Für jeden Anwendungsfall detaillierte textuelle Beschreibung Anwendungsfallmodellierung 4
3 Diagrammart Strukturdiagramm Verhaltensdiagramm Anwendungsfalldiagramm Einführung Beispiel ONLINEKALENDER Klassendiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Anwendungsfalldiagramm Zustandsdiagramm Objektdiagramm Kompositionsstrukturdiagramm Interaktionsdiagramm Aktivitätsdiagramm Sequenzdiagramm Kommunikationsdiagramm Zeitdiagramm Interaktionsübersichtsdiagramm Akteur: Wer benutzt das System? Benutzer des Kalenders (Nutzer des Systems, befindet sich außerhalb des Systems, mit dem er interagiert.) abfragen e exportieren ONLINEKALENDER löschen Benutzer Beziehung: Der Akteur benutzt einen Use Case, um ein Ziel zu erreichen (z. B. er führt Use Case durch, muss Eingaben machen o. ä.). erfassen ändern Use Case: Was machen die Akteure? erfassen, ändern, löschen, abfragen, etc. System: Was wird beschrieben? Onlinekalender (= Systemgrenze) Anwendungsfallmodellierung 5
4 Anwendungsfalldiagramm Akteur (Actor) Akteure interagieren mit dem System indem sie das System benutzen, d.h. die Ausführung von Anwendungsfällen initiieren indem sie vom System benutzt werden, d.h. Funktionalität zur Realisierung von Anwendungsfällen zur Verfügung stellen Akteur wird durch Assoziationen mit Anwendungsfällen verbunden, d.h. er»kommuniziert«mit dem System Jeder Akteur muss mit mindestens einem Anwendungsfall kommunizieren Notationsvarianten: Benutzer «actor» -System Anwendungsfallmodellierung 6
5 Anwendungsfalldiagramm Akteur Klassifikation Menschlich: z.b. Benutzer, Administrator, Lehrender Nicht menschlich: z.b. -System, Datenbank Primär: Hauptnutznießer der Anwendung, hat Anwenderziele, die durch Nutzung der Dienste des Systems erfüllt werden Sekundär: Notwendig für das Funktionieren des Systems, stellt einen Dienst (bspw. Informationen) für das System zur Verfügung; oft ein Computersystem (bspw. -Server) Aktiv: stößt selbst Anwendungsfälle an Passiv: stößt selbst keine Anwendungsfälle an menschlich primär aktiv Benutzer ONLINEKALENDER erfassen Teilnehmer verständigen «actor» -System nicht-menschlich sekundär passiv Anwendungsfallmodellierung 8
6 Anwendungsfalldiagramm Akteur - Fragen zur Identifikation Wer startet und stoppt das System? Wer benutzt die wesentlichen Anwendungsfälle? Wer braucht Systemunterstützung für die tägliche Arbeit? Ist die "Zeit" ein Akteur, weil das System auf zeitliche Ereignisse reagiert? (Akteur Zeit einführen!) Wer ist für die Systemadministration zuständig? Mit welchen externen Geräten / (Software-) Systemen muss das System kommunizieren können? Wer oder was interessiert sich für die Ergebnisse des Systems? Wer wird bei Fehlern oder Misserfolgen benachrichtigt?... Akteure sind anfänglich beim Brainstorming wichtig, um Vollständigkeit zu erreichen! Frage sollte lauten: "Was sind Ihre Ziele, deren Ergebnisse einen messbaren Wert haben?" Primärakteur Benutzer Administrator... Akteur-Ziele-Liste Anwendungsfallmodellierung 9 Ziel erfassen abfragen löschen löschen
7 Anwendungsfalldiagramm Anwendungsfall (Use Case) Anwendungsfälle beschreiben das Verhalten, das von dem zu entwickelnden System erwartet wird Identifizierung durch Sammeln von Kundenwünschen und Analyse der textuellen Problemstellung Notationsvarianten: Kurzbeschreibung als Notiz: erfassen erfassen erfassen»ein kann für einen oder mehrere Teilnehmer von berechtigten Benutzern (müssen nicht notwendigerweise auch Teilnehmer sein) erfasst werden. Alle Teilnehmer müssen über diesen neuen verständigt werden. Neue e müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden.«anwendungsfallmodellierung 10
8 Ablauf einer include-beziehung Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - «include» Das Verhalten des benutzten Anwendungsfalls (inkludierter Anwendungsfall) wird in den benutzenden Anwendungsfall (Basis-Anwendungsfall) eingebunden Der inkludierte Anwendungsfall B ist unbedingt notwendig, um die Funktionalität des Basis-Anwendungsfalls A sicherzustellen Der inkludierte Anwendungsfall B kann allerdings separat ausgeführt werden A erfassen Basis-Anwendungsfall - benötigt inkludierten Anwendungsfall um die Funktionalität sicher zu stellen «include» B Kalender aktualisieren Inkludierter Anwendungsfall - kann auch separat ausgeführt werden Anwendungsfallmodellierung 11
9 Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - «extend» Das Verhalten von B kann in A inkludiert werden Somit entscheidet A, ob B ausgeführt wird. Der erweiternde Anwendungsfall B kann von A aktiviert werden, muss aber nicht Angabe des»wo«durch Erweiterungsstellen in A Angabe des»wann«durch Bedingung in A bzw. als Teil der «extend»-beziehung A Programm verwalten «extend» B Zugriffsrechte verwalten Ablauf einer extend-beziehung A extension points EP1 Basis-Anwendungsfall - kann auch separat ausgeführt werden - entscheidet, ob B ausgeführt wird oder nicht Erweiternder Anwendungsfall - kann auch separat ausgeführt werden Anwendungsfallmodellierung 12
10 Anwendungsfalldiagramm Analogien zu Programmiersprachen «include» entspricht Unterprogrammaufruf void B () { } A «include» B void A () { } B(); } «extend» entspricht bedingtemunterprogrammaufruf A condition: { } «extend» B void B () { } void A () { } /* EP */ if Condition then B(); } Anwendungsfallmodellierung 14
11 Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - Generalisierung 1/2 Vergleichbar mit Generalisierungsbeziehung zwischen Klassen B erbt Verhalten von A und kann dieses überschreiben oder ergänzen B erbt alle Beziehungen von A Modellierung abstrakter Anwendungsfälle möglich - {abstract} A B Basis-Anwendungsfall - kann auch separat ausgeführt werden Abgeleiteter Anwendungsfall - benötigt A (übernimmt Grundfunktionalität von A) - entscheidet, was von A ausgeführt bzw. geändert wird Anwendungsfallmodellierung 15
12 Anwendungsfalldiagramm Beziehungen zwischen Anwendungsfällen - Generalisierung 2/2 Benutzer {abstract} Eintrag erfassen erfassen ToDoEintrag erfassen Anwendungsfallmodellierung 16
13 Anwendungsfalldiagramm Generalisierung bei Akteuren 1/2 Akteur A erbt von Akteur B A kann mit den Anwendungsfällen X und Y kommunizieren B kann nur mit Y kommunizieren A X B Y Bsp.: Administrator Benutzer Benutzer anlegen erfassen Anwendungsfallmodellierung 17
14 Anwendungsfalldiagramm Generalisierung bei Akteuren 2/2 Unterscheidung, ob mehrere Akteure gemeinsam mit einem Anwendungsfall kommunizieren können oder müssen. A X A X {abstract} C B A und B kommunizieren mit X B A oder B kommuniziert mit X Anwendungsfallmodellierung 18
15 Anwendungsfalldiagramm Beziehungen Beispiel: ONLINEKALENDER (verfeinert) Benutzer Administrator abfragen erfassen Programm verwalten «extend» Zugriffsrechte verwalten e exportieren ändern Teilnehmer verständigen Einstellungen verwalten typen verwalten ONLINEKALENDER löschen «include» «include» «extend» Benutzer verwalten Kalender aktualisieren «actor» -System Anwendungsfallmodellierung 19
16 Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 1/3 Anwendungsfalldiagramme werden schnell unübersichtlich Allgemeiner UML-Abstraktionsmechanismus: Paket «systemmodel» ONLINEKALENDER Systemverwaltung verwaltung Anwendungsfallmodellierung 20
17 Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 2/3 verwaltung Benutzer abfragen erfassen Einträge exportieren aktualisieren «include» «include» «include» ändern löschen «include» «include» «include» Teilnehmer verständigen «actor» -System Anwendungsfallmodellierung 21
18 Anwendungsfalldiagramm Partitionierung des Anwendungsfalldiagramms 3/3 Systemverwaltung verwaltung ::Benutzer Programm verwalten Benutzer verwalten «extend» «extend» Einstellungen verwalten Zugriffsrechte verwalten typen verwalten Administrator Anwendungsfallmodellierung 22
19 Anwendungsfalldiagramm Zusammenfassung Richtlinien Erstellen Sie eine Akteur-Ziele-Liste Zeichnen Sie einfache Anwendungsfalldiagramme Primärakteure stehen links Unterstützende Akteure stehen rechts Vorteile: Anwendungsfalldiagramme vermitteln ein ausgezeichnetes Bild des Systemkontextes bzw. der Systemgrenzen! Man hat sehr schnell ein Verständnis für das System (top-level). Man findet, wenn nötig, sehr schnell zu den relevanten Details. Anwendungsfalldiagramme sind leicht verständlich! Kunde/Anwender/Sponsor versteht, was er bekommen wird. Entwickler/Projektleiter versteht, was er bauen/liefern muss. Anwendungsfallmodellierung 23
20 Anwendungsfalldiagramm Lasst uns beginnen und folgende Fehlerquellen vermeiden: Zu kleine und damit zu viele Anwendungsfälle Zu frühe Betrachtung von Sonderfällen Zu detaillierte Beschreibung der Anwendungsfälle Verwechseln von Generalisierung und extend-beziehung Anwendungsfälle beschreiben Dialog(GUI)-Abläufe Es wird versucht, im Anwendungsfalldiagramm eine Ablaufreihenfolge zu modellieren Anwendungsfälle für Auftraggeber nicht verständlich Anwendungsfallmodellierung 24
21 Sind Anwendungsfalldiagramme ausreichend? Use-Case-Experten warnen:... NEIN!!! Anwendungsfalldiagramme und Beziehungen spielen bei der Anwendungsfall-Erhebung eine untergeordnete Rolle! Anwendungsfälle sind Textdokumente! Don t spend much time on diagramming. Use case work means to write text, not draw diagrams Anwendungsfall-Erhebung bedeutet, Text zu schreiben! (strukturierte und textuelle) Anwendungsfallbeschreibung Anwendungsfallmodellierung 25
22 Anwendungsfallbeschreibung Szenarien eines Anwendungsfalls Ein Anwendungsfall ist eine Abfolge von erfolgreichen und nicht erfolgreichen Aktivitäten. Alternative endet mit Fehler Alternative mündet wieder in Hauptszenario ein Hauptszenario Erfolg ("glücklicher Weg") Alternative endet mit Fehler Anwendungsfallmodellierung 26
23 Anwendungsfallbeschreibung Beschreibungsvorlage 1/2 Use-Case-Abschnitt Use-Case-Name/Nummer Kurzbeschreibung Primärakteur (mit Ziel) Sekundärakteur (mit Ziel) Vorbedingungen Ergebnis bei Erfolg (~Nachbedingung) Ergebnis bei Fehler Standardablauf (Hauptszenario) Alternativ- und Fehlerabläufe Spezielle Anforderungen Kommentar Nennen Sie das Objekt und dann das Verb. [ erfassen] Kurze, abstrakte Beschreibung des Ablaufs (ca. zwei bis drei Sätzen) Nutzt einen Dienst des Systems, um ein Ziel zu erfüllen. [AdministratorIn] Andere am Use Case beteiligte (unterstützende) Akteure und Systeme, die vom System während der Abarbeitung des Use Cases benötigt werden. [ -System] Bedingungen, die erfüllt sein müssen, damit der Use Case ausgeführt werden kann. Der Zustand des Systems nach erfolgreicher Beendigung des Use Cases. Der Zustand des Systems, wenn der Use Case nicht erfolgreich beendet wurde. Das Szenario für einen typischen, erfolgreichen Durchlauf durch den Use Case. Alternative Abläufe zum Hauptszenario für Erfolg oder Misserfolg. Zum System gehörige, nichtfunktionale Anforderungen Häufigkeit des Auftretens Status Beeinflusst die Untersuchung, das Testen und die zeitliche Gestaltung der Implementierung Status beschreibt, ob der Use Case ein Entwurf, bereit zum Review oder abgenommen ist. Offene Punkte Offene Punkte, die den Use Case betreffen. Anwendungsfallmodellierung 27
24 Anwendungsfallbeschreibung Beschreibungsvorlage 2/2 Standardablauf (Hauptszenario) ein typisches (erfolgreiches) Szenario des Ablaufs des Anwendungsfalls, ohne Verzweigungen (siehe Alternativabläufe) besteht aus einzelnen Schritten wie bspw. Interaktionen zwischen Akteuren Validierungen, normalerweise durch das System Zustandsänderungen durch das System (z.b. speichern, ändern) Aufruf anderer Anwendungsfälle Alternativ- und Fehlerabläufe (Erweiterungen) Konkretisierungen sowie Erweiterungen des Standardablaufs ein derartiger Ablauf kann sich auf mehrere Schritte im Standardablauf beziehen besteht meist aus einer Bedingung und Aktionen nach Ausführung Rückkehr in Standardablauf oftmals umfangreicher als der Standardablauf Anwendungsfallmodellierung 28
25 Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 1/3 erfassen UC 3 V1.1 Kurzbeschreibung: Ein kann für einen oder mehrere Teilnehmer von berechtigten Benutzern (müssen nicht notwendigerweise auch Teilnehmer sein) erfasst werden. Alle Teilnehmer müssen über diesen neuen verständigt werden. Neue e müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden. Primärakteure (auslösende Akteure): Benutzer: Will für sich oder mehrere Teilnehmern erfassen. Will, dass alle Teilnehmer über diesen neuen verständigt werden. Will, dass neue e sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden. Sekundärakteure (unterstützende Akteure): -System: Will Einladung zum im richtigem Format erhalten. Vorbedingungen: Benutzer ist dem System bekannt Ergebnis bei Erfolg: Neuer ist erfasst. Alle Teilnehmer sind verständigt und gegebenenfalls informiert, dass es aus Berechtigungsgründen nicht möglich war, ihren kalender zu verändern. Alle Sichten (Kalender) sind aktualisiert. Anwendungsfallmodellierung 29
26 Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 2/3 Entferne alle Fehlerbedingungen, die durch die Vorbedingungen ausgeschlossen sind. Anderes Use Case-Szenario ausführen Bedingung Handhabung/Reaktion (kann in einem oder mehreren Schritten beschrieben werden) Ergebnis bei Fehler: Fehler Ergebnis Bedingung, die dazu geführt hat a. Benutzer ist nicht berechtigt, zu erfassen. Standardablauf: 1. Benutzer identifiziert sich. Der Versuch den zu erfassen ist protokolliert. 2. Daten des neuen s (Zeit, Ort, Dauer, Teilnehmer, etc.) werden eingegeben. 3. Benutzer ist berechtigt, für alle Teilnehmer den zu erfassen. [a] 4. führt bei keinem Teilnehmer zu Kollisionen und wird erzeugt. 5. Alle Teilnehmer (ausgenommen der Benutzer, wenn dieser auch Teilnehmer ist) werden gemäß ihrer bevorzugten Kommunikationsart verständigt. («include» UC 5 Teilnehmer verständigen) 6. Alle geöffneten Kalender von Teilnehmern werden aktualisiert. («include» UC 9 Kalender aktualisieren) Erweiterungen (alternative Abläufe): Kalender wurde von Teilnehmer nicht an den Benutzer freigegeben. 3a Benutzer ist für mindestens einen Teilnehmer nicht berechtigt, den in seinem Kalender zu erfassen. 1. System signalisiert Benutzer fehlende Berechtigung 4a Analog zu (4) 5a Analog zu (5), wobei jene Teilnehmer, deren Kalender nicht änderbar waren, zusätzlich davon informiert werden, dass es aus Berechtigungsgründen nicht möglich war, ihren kalender zu verändern. 6a Alle geöffneten Kalender von jenen Teilnehmern werden aktualisiert, für die eine Anwendungsfallmodellierung Berechtigung zur Änderung des Kalenders vorliegt. 30 Fehlerbedingung leitet Alternative ein!
27 Anwendungsfallbeschreibung Beschreibung Beispiel: ONLINEKALENDER 3/3 Spezielle Anforderungen: Antwortzeit bei der Kollisionsprüfung der e anderer Teilnehmer innerhalb von 15 Sekunden in 90 % der Fälle bei max. 10 Teilnehmer. Aktualisierung betroffener Kalender innerhalb von 30 Sekunden in 70 % der Fälle. Häufigkeit des Auftretens: Beinahe laufend Status: In Arbeit/bereit zum Review/im Review/abgelehnt/abgenommen Offene Fragen: Wie und in welcher Form werden Teilnehmer informiert, bei denen aus fehlenden Berechtigungsgründen kein belegt werden konnte. Anwendungsfallmodellierung 31
28 Anwendungsfallbeschreibung Vorgehen Achte auf Zeit und Ressourcen gehe zuerst in die Breite zuerst Akteure und deren Ziele dann Hauptszenarien beschreiben gehe erst danach in die Tiefe erst dann Fehlerbedingungen und deren Behandlung in Alternativen beschreiben Benutzerschnittstelle nicht berücksichtigen In 4 Schritten vorgehen: 1. Primäre Akteure und Ziele identifizieren 2. Hauptszenarien schreiben 3. Fehlerbedingungen identifizieren 4. Alternativen schreiben Anwendungsfallmodellierung 32
29 Anwendungsfallbeschreibung Zusammenfassung Wie viel Anwendungsfall-Modellierung braucht man? Anwendungsfälle sind ein Vertrag zwischen Kunde und Entwicklerteam. Beide müssen diesem guten Gewissens zustimmen können, auch wenn sich Details später ändern können. Wie viele Anwendungsfälle sollte man haben? Hängt vom Projekt ab, z.b In der ersten Iteration ca % detaillierter beschreiben Wie lange soll ein Anwendungsfall sein? Hängt vom Anwendungsfall ab, 5-12 Schritte, Seiten Was ist das beste Format? Es gibt nicht das beste Format! Anwendungsfallmodellierung 33
30 Anwendungsfälle sind eine gute Basis... für die Kommunikation zwischen Kunden und Entwicklern um zu verstehen, was das Problem des Kunden ist um das Problem spezifizieren und somit entwickeln zu können zum Identifizieren von Objekten, deren Funktionalität, Interaktion und Schnittstellen für die Aufwandschätzung für die Planung der Entwicklung Aufteilung in mehreren Releases/Interationen für die Definition der funktionalen Testfälle und der Akzeptanztests für die Erstellung von Dokumentation für den Endanwender Anwendungsfallmodellierung 34
31 Aufwandschätzung auf Basis von Anwendungsfällen Erstelle eine Liste der Anwendungsfälle Bewerte jeden Anwendungsfall (bspw. einfach / mittel / schwierig). Gewichte die Anwendungsfälle mit Aufwandsfaktor (z.b. 2 Tage für einfachen Anwendungsfall, 5 für mittleren, 15 für schwierigen, Faktoren müssen für Projekt und Projektmitarbeiter passen!). Teile die Anwendungsfälle Personen zu. Summiere, wer wie viel Arbeit hat. Anwendungsfallmodellierung 35
32 Aufwandschätzung Beispiel Aufwand pro Entwickler Use Cases Komplexität Aufwand Entwickler R1 R2 UC 4 Content und Playlisten zum Server übertragen m 5 R1 5 0 UC 5 Playlist aktivieren m 5 R1 5 0 UC 14 - Content-Verteilung per CD definieren m 5 R2 0 5 UC 15 Content versionieren l 2 R2 0 2 UC 18 Playlist und Content zur lokalen Abspielung vorbereiten m 5 R1 5 0 UC 19 Playlist und Content lokal kopieren e 2 R1 2 0 UC 20 Einstellungen definieren e 2 R1 2 0 UC 21 Content und Playlisten vom Server holen m 5 R1 5 0 UC 6 Benutzer, Hosts und Gruppen definieren e 2 R2 0 2 UC 7 Jobs definieren e 2 R2 0 2 UC 8 - Fehlerbenachrichtigung bearbeiten e 2 R2 0 2 UC 9 CD einspielen e 2 R2 0 2 UC 10 Job ausführen e 2 R1 2 0 UC 11 Job submitten e 2 R1 2 0 UC 12 Fehlerbenachrichtigung verschicken m 5 R2 0 5 UC 13 Content abspielen e 2 R1 2 0 UC 16 Content von CD installieren m 5 R2 0 5 UC 17 Playlist in der Bankstelle aktivieren m 5 R Aufwandsfaktor e 2 m 5 s 15 Anwendungsfallmodellierung 36
33 Zusammenfassung Sie haben Anwendungsfallmodellierung verstanden, wenn Sie wissen dass mit dem Anwendungsfallidagramm das Verhalten eines Systems aus der Sicht der Benutzer beschrieben wird. dass an einem Anwendungsfalldiagramm Akteure und Anwendungsfälle beteiligt sind. dass bei einem Anwendungsfalldiagramm die Grenzen des Systems klar definiert sein müssen und sich die Akteure immer außerhalb des Systems befinden. wie das Zusammenspiel zwischen Akteuren und Anwendungsfällen aussieht. dass es sowohl für Anwendungsfälle als auch für Akteure Generalisierungsbeziehungen gibt. worin der Unterschied zwischen <<include>> und <<extend>> besteht. Anwendungsfallmodellierung 37
34 Literaturhinweise Alistair Cockburn: "Use Cases effektiv erstellen", MITP Verlag (2003, ISBN: ) Kurt Bittner, Ian Spence: Use Case Modeling, Addison-Wesley (2003, ISBN: ) Steve Adolph, Paul Bramble, Alistair Cockburn: Patterns for Effective Use Cases, Addison- Wesley (2003, ISBN: ) Daryl Kulak, Eamonn Guiney: Use Cases, Addision-Wesley (2004, ISBN ) Anwendungsfallmodellierung 38
Objektorientierte Modellierung. Anwendungsfalldiagramm
Objektorientierte Modellierung Anwendungsfalldiagramm Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040
MehrObjektorientierte Modellierung
Objektrientierte Mdellierung ANWENDUNGSFALLDIAGRAMM Anwendungsfälle sind Ausgangspunkt vieler bjektrientierter Entwicklungsmethden, haben aber nicht unbedingt etwas mit bjektrientierter Prgrammierung zu
MehrObjektorientierte Analyse (OOA) Übersicht
Übersicht UML ist die Notation für ein objektorientiertes Vorgehensmodell, sowohl für die Analyse als auch für das Design. Analyse (WAS?) Use Cases Aktivitätsdiagramme (für die Use Cases) Klassendiagramme
MehrDatenbanken. Teil 2: Informationen. Kapitel 7: Objektorientierte Sicht. UML-Diagramme. Vorstellung der unterschiedlichen UML-Diagramme
Datenbanken objektorientierte Sicht Seite 1 von 76 Datenbanken Teil 2: Informationen Kapitel 7: Objektorientierte Sicht UML-Diagramme Vorstellung der unterschiedlichen UML-Diagramme 1. Diagrammtypen 2.
MehrAnwendungsfalldiagramm UseCaseDiagramm
Anwendungsfalldiagramm UseCaseDiagramm Notation und Beispiele Prof. DI Dr. Erich Gams htl wels.e.gams@eduhi.at UML Seminar HTL-Wels 2010 Anwendungsfall und SE Prozess Ein Anwendungsfalldiagramm ist ein
MehrObjektorientierte Modellierung mit UML
Objektorientierte Modellierung mit UML Verteilungsdiagramm Der vorliegende Foliensatz basiert auf: M. Seidl, M. Brandsteidl, C. Huemer, G. Kappel: UML@Classroom, dpunkt.verlag, 2012. C. Larman: UML 2 und
MehrObjektorientierte Analyse (OOA) Inhaltsübersicht
Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der
MehrInhalt. 1 Einführung 17. Strukturdiagramme. 2 Klassendiagramm 37
Vorwort... 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden?... 17 1.2 Die Phasen bei der Softwareentwicklung... 18 1.2.1 Analyse... 18 1.2.2 Entwurf... 19 1.2.3 Implementierung und Dokumentation...
MehrVgl. Oestereich Kap 2.1 Seiten
Vgl. Oestereich Kap 2.1 Seiten 21-49. 1 Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt). Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel Daten
MehrSoftwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML
Softwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML The role of UML Theoretical model model for comparison calibration verification Empirical model model of deduction induction Generating
MehrINSPIRE - Modellierung
INSPIRE - Modellierung Inhalt Motivation Modellierung UML Diagramme INSPIRE-Schulung LKROS 2 Motivation Was ist ein Modell, und warum wollen wir modellieren? Warum brauchen wir eine Modellierungssprache
MehrUML (Unified Modelling Language) von Christian Bartl
UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...
MehrChristoph Kecher, Alexander Salvanos UML 2.5. Das umfassende Handbuch. Rheinwerk. Computing
Christoph Kecher, Alexander Salvanos UML 2.5 Das umfassende Handbuch Rheinwerk Computing Inhalt Vorwort 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden? 17 1.2 Die Phasen bei der Softwareentwicklung
MehrUnified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8
Literatur Martin Fowler and Kendall Scott: UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley 1997. James Rumbaugh, Ivar Jacobson, and Grady Booch: The Unified Language Reference
MehrTEIL I Strukturdiagramme 1 Einführung Klassendiagramm Objektdiagramm Kompositionsstrukturdiagramm...
Auf einen Blick TEIL I Strukturdiagramme 1 Einführung... 13 2 Klassendiagramm... 29 3 Objektdiagramm... 111 4 Kompositionsstrukturdiagramm... 125 5 Komponentendiagramm... 145 6 Verteilungsdiagramm... 161
MehrNACHRICHTENTECHNISCHER SYSTEME
Einführung UML COMPUTERSIMULATION NACHRICHTENTECHNISCHER SYSTEME 11. Unified Modeling Language UML 220 Standardsprache d zur Visualisierung, i Spezifikation, Konstruktion und Dokumentation komplexer (Software-)
MehrÜbungen Softwaretechnik I
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Übungen Softwaretechnik I Übung 5: Objektorientierte Analyse Einführung Objektorientierung in der
MehrCARL HANSER VERLAG. Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML 2 glasklar
CARL HANSER VERLAG Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins UML 2 glasklar 3-446-22575-7 www.hanser.de Einleitung... 1 Liebe Leserin, lieber Leser... 1 Ihre Meinung ist uns
MehrRequirements Engineering I
Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2008 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind
MehrSo#waretechnologie für Fortgeschri4ene Teil Eide. Stunde IV: UML. Köln 26. Januar 2017
So#waretechnologie für Fortgeschri4ene Teil Eide Stunde IV: UML Köln 26. Januar 2017 Model of vs. model for TheoreKcal model model for comparison calibra9on verifica9on Empirical model model of deduc9on
MehrMario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML2 glasklar. UNIFIED MODELING LANGUAGE l HANSER
Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins UML2 glasklar UNIFIED MODELING LANGUAGE l V HANSER Inhalt Vorwort 1 Einleitung 2 Liebe Leserin, lieber Leser 2 Ihre Meinung ist uns
MehrUse Cases effektiv erstellen
mitp Professional Use Cases effektiv erstellen von Alistair Cockburn 1. Auflage Use Cases effektiv erstellen Cockburn schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG Thematische
MehrDie Unified Modeling Language UML
Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 4 Die Unified Modeling Language UML Universität Zürich Institut für Informatik Inhalt 4.1 Hintergrund 4.2 Grundkonzepte der UML 4.3 Die Rolle
MehrUnified Modeling Language 2
Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was
MehrDas umfassende Handbuch
Christoph Kecher UML 2.0 Das umfassende Handbuch. Jfjf- Ali' ' w v^i* >" '-«(."', Galileo Press Inhalt Vorwort 11 1 Einführung 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3
MehrVorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Unified Modeling Language (UML)
MehrSoftwaretechnik 2015/2016
Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon
MehrAnalyse und Design mituml2
Analyse und Design mituml2 Objektorientierte Softwareentwicklung von Bernd Oestereich 7, aktualisierte Auflage Oldenbourg Verlag München Wien Ш1!Н1Н1КД nhjektorientierte Softwareentwicklung - Analyse und
MehrObjektorientiertes Design
Objektorientiertes Design Yi Zhao Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Zhao, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1
MehrAnwendungsfall. Das Anwendungsfall-Diagramm (Use-Cases/Use-Case Diagramm) Die Anwendungsfall-Beschreibung. Dr. Beatrice Amrhein
Anwendungsfall Das Anwendungsfall-Diagramm (Use-Cases/Use-Case Diagramm) Die Anwendungsfall-Beschreibung Dr. Beatrice Amrhein Kundenbedürfnisse Fertigungs-System 2 Erste Schritte: Kundenbedürfnisse erfassen
MehrWirtschaftsinformatik 6a: Modellierung. Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte
Wirtschaftsinformatik 6a: Modellierung Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte Computertechnik Man kann Software auf 2 Arten herstellen: Entweder macht man sie so klar und einfach,
MehrAnalyse und Design mituml2.1
Analyse und Design mituml2.1 Objektorientierte Softwareentwicklung Von Bernd Oestereich 8., aktualisierte Auflage Oldenbourg Verlag München Wien nhaltsverzeichnis Objektorientierte Softwareentwicklung
MehrJason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel
Jason T. Roff UML IT Tutorial Übersetzung aus dem Amerikanischen von Reinhard Engel Inhaltsverzeichnis Inhaltsverzeichnis Einführung 11 Grundlagen der UML 15 Warum wir Software modellieren 16 Analyse,
MehrUML 2.0 Das umfassende Handbuch
Christoph Kecher V.-M \MM UML 2.0 Das umfassende Handbuch Galileo Computing Inhalt Vorwort 11 1 Einführung 13 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3 Die Geschichte
MehrSoftwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 7 Lösungshilfe Aufgabe 1. Analysephase (12 Punkte) Eine Firma hat den Auftrag erhalten eine
MehrAnalyse und Design mit U ML 2.3
Analyse und Design mit U ML 2.3 Objektorientierte Softwareentwicklung von Bernd Oestereich unter Mitarbeit von Stefan Bremer 9., aktualisierte und erweiterte Auflage Ofdenbourg Verlag München Inhaltsverzeichnis
MehrEINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.
EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG
MehrObjektorientierte Systementwicklung
Karl-Heinz Rau Objektorientierte Systementwicklung Vom Geschäftsprozess zum Java-Programm Mit 162 Abbildungen vieweg Überblick und Vorbemerkungen 1 1 Objektorientierte Software-Entwicklung 5 1.1 Überblick
MehrOracle JDeveloper 10 g
Oracle JDeveloper 10 g Modellierung Evgenia Rosa Business Unit Application Server ORACLE Deutschland GmbH Agenda Warum Modellierung? UML Modellierung Anwendungsfall (Use Case)-Modellierung Aktivitätenmodellierung
MehrMartin Fowler, Kendall Scott. UML konzentriert. Eine strukturierte Einführung in die Standard-Objektmodellierungssprache. 2., aktualisierte Auflage
Martin Fowler, Kendall Scott UML konzentriert Eine strukturierte Einführung in die Standard-Objektmodellierungssprache 2., aktualisierte Auflage Deutsche Übersetzung von Arnulf Mester, Michael Sczittnick
Mehr09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
MehrVorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
MehrANWENDUNGSFALLDIAGRAMM:
EINFÜHRUNG Ein UML Modell kann folgende unterschiedliche Sichtweisen auf den Problemlösungsbereich (Aspekte) enthalten: Dynamische Aspekte Softwareorganisatorische Aspekte Statische Aspekte Welche Aussagen
MehrUnified Modeling Language
Unified Modeling Language Thomas Röfer Motivation Entwicklung Spracheinheiten Diagramme (Struktur-/Verhaltensdiagramme) Rückblick Textsuche Naive Suche abrakadabra Boyer-Moore abrakadabra a Knuth-Morris-Pratt
MehrVORDIPLOMSPRÜFUNG FÜR ELEKTROINGENIEURE. Einführung in die Informatik III
Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner VORDIPLOMSPRÜFUNG FÜR ELEKTROINGENIEURE Einführung in die Informatik III Name: Matrikelnummer:
MehrTamagotchi-Spezifikation in UML
Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug
MehrModellbasierter Test mit der UML. Vortragender: Lars Westmeier Seminar: Spezifikationsbasierter Softwaretest
Modellbasierter Test mit der UML Vortragender: Lars Westmeier Seminar: Spezifikationsbasierter Softwaretest Inhalt Einleitung und Motivation UML Testgenerierung Fazit Inhalt Einleitung und Motivation UML
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 Inhalt Vorwort 15 Ziele 15 Publikum 16 Wie Sie dieses Buch verwenden sollten 16 Aufbau und besondere Merkmale 17
MehrChristoph Kecher UML2. Das umfassende Handbuch. Galileo Press
Christoph Kecher UML2 Das umfassende Handbuch Galileo Press Vorwort 11 TEIL I Strukturdiagramme i '...,....,...,.;..,,,...,, 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario
MehrInhalt. Einleitung Liebe Leserin, lieber Leser, Wer dieses Buch aus welchem Grund lesen sollte Ihre Meinung ist uns sehr wichtig.
Inhalt Vorwort Einleitung Liebe Leserin, lieber Leser, Wer dieses Buch aus welchem Grund lesen sollte Ihre Meinung ist uns sehr wichtig Danksagungen Die Autoren XIII XV XV XVII XVIII XVIII XIX Teil I:
MehrVon UML 1.x nach UML 2.0
Zürich Soft Summer 2005 Fortgeschrittene Aspekte der Software Technologie Von UML 1.x nach UML 2.0 Prof. Dr. Martin Glinz www.ifi.unizh.ch/req Ergänzendes Material zur Vorlesung Spezifikation und Entwurf
MehrObjektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl 26.07.21 Themenübersicht Objektorientierte Software-Entwicklung Objektorientierte Analyse und Design OOA OOD Objektorientierte
MehrInhaltsverzeichnis.
Wegweiser durch das Buch 1 1 Problembereich und Lösungsbereich 10 1.1.Unterschiede zwischen Problembereich und Lösungsbereich 10 1.2 Paradigmen der Softwareentwicklung 12 1.3 Methoden für die verschiedenen
MehrUML fürs Pflichtenheft
UML fürs Pflichtenheft Sebastian Fischmeister Department of Computer Science University of Salzburg, Austria Sebastian.Fischmeister@cs.uni-salzburg.at Overview Use-Case Diagramm State-Machine Diagramm
MehrUML Crashkurs v0.1. UML für Fachinformatiker. von Hanjo Müller
UML Crashkurs v0.1 UML für Fachinformatiker von Hanjo Müller 3. Mai 2005 Inhaltsverzeichnis Inhaltsverzeichnis 1 UML - Unified Modeling Language 3 2 UML im Software Entwurf 4 2.1 Ablauf der Softwareentwicklung.............................
MehrUnified Modeling Language (UML )
Unified Modeling Language (UML ) Seminar: Programmiersprachenkonzepte Inhalt Einleitung UML 2.0 Diagrammtypen 2 Einleitung Objektorientierte Modellierungssprache Definiert vollständige Semantik Dient der
MehrEinführung in die objektorientierte Programmierung
Einführung in die objektorientierte Programmierung Seminarunterlage Version: 4.04 Copyright Version 4.04 vom 17. Juni 2016 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten.
Mehr4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 17 Objektorientiertes Design Florin Pinte Marc Spisländer Lehrstuhl für Software
MehrUnified Modelling Language
Unified Modelling Language SEP 72 Software-Entwicklung Software-Entwicklung ist Prozess von Anforderung über Modellierungen zu fertigen Programmen Anforderungen oft informell gegeben fertige Programme
MehrUML 2 glasklar Praxiswissen für die UML-Modellierung
Chris Rupp, Stefan Queins, Barbara Zengler UML 2 glasklar Praxiswissen für die UML-Modellierung ISBN-10: 3-446-41118-6 ISBN-13: 978-3-446-41118-0 Inhaltsverzeichnis Weitere Informationen oder Bestellungen
MehrSOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing.
SOFTWAREPROJEKT (WI) Anforderungsanalyse Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing. Ralph Maschotta Inhalt Das Pflichtenheft Das UML-Modellierungswerkzeug
MehrMedia Engineering. Objektorientierte Modellierung. Verhaltensmodellierung. R. Weller University of Bremen, Germany cgvr.cs.uni-bremen.
Media Engineering Objektorientierte Modellierung Verhaltensmodellierung R. Weller University of Bremen, Germany cgvr.cs.uni-bremen.de Objektorientierte Analyse und Design im Detail Identifiziere Akteure
MehrSoftware-Engineering
SWE43 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML SWE43 Slide 2 UML: Was ist das? UML = Unified Modelling Language ist ein Standard,
MehrUML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language
UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language ADV-Seminar Leiter: Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?
MehrTechniken der Projektentwicklungen
Dynamische Modellierung 8. Termin Rückblick auf statische Modellierung Dynamische Modellierung Basiskonzepte Beispiel Erweiterungen Eigenschaften Syntax Rückblick auf statische Modellierung Dynamische
MehrObjektorientierte Softwareentwicklung
Objektorientierte Softwareentwicklung Analyse- und Designmethoden Analyse- & Designmethoden Strukturierte, traditionelle Methoden Objektorientierte Methoden Funktionsorientierte Methoden Datenorientierte
MehrObjektorientierte Softwareentwicklung
Objektorientierte Softwareentwicklung Grundkonzepte der UML Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus sind viele Teile direkt aus der Vorlesung
MehrSystems Engineering mit SysML/UML
Tim Weilkiens Systems Engineering mit SysML/UML Modellierung, Analyse, Design 2., aktualisierte u. erweiterte Auflage "SJ dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1 Vorweg 1 1.1.1 Passt das Buch
MehrMartin Fowler, Kendali Scott. UML - konzentriert. Die Standardobjektmodellierungssprache anwenden
Martin Fowler, Kendali Scott 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. UML - konzentriert Die Standardobjektmodellierungssprache
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 17 Objektorientiertes Design Florin Pinte Marc Spisländer Lehrstuhl für Software
MehrComelio GmbH - Goethestr Berlin. Course Catalog
Comelio GmbH - Goethestr. 34-13086 Berlin Course Catalog 2 Table Of Contents a. Locations... 3 1. UML... 4 i. Design und Analyse... 4 ii. Notation und Konzepte...6 iii. OCUP Zertifizierung (Advanced)...8
MehrGuido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis
Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses
MehrGliederung des Vortrages
Gliederung des Vortrages Unified Modeling Language Rational Rose Sergej Schwenk Oktober 1999 0. Einführung 1. Historie 2. Der Entwicklungsprozeß 3. UML 3.1 Anwendungsfalldiagramme 3.2 Klassendiagramme
MehrTesten mit Use Cases. Chris Rupp Dr. Stefan Queins
Testen mit Use Cases Chris Rupp Dr. Stefan Queins Das Problem Requirements- Engineering Was kann passieren? Was ist das gewünschte Verhalten? Was soll ich testen? Welche Eingaben benötigt mein Testpfad?
MehrSoftwareentwicklung OOA Videothek
Softwareentwicklung OOA Seite 1 von 8 Softwareentwicklung OOA thek Ein mögliches Vorgehen bei OOA soll im Rahmen einer Softwareentwicklung am Beispiel einer thek exemplarisch vorgestellt werden. 1. Systemidee
MehrModellierungstipps für die Anwendungsfallmodellierung
Modellierungstipps für die Anwendungsfallmodellierung Identifiziere nur relativ grobe Abläufe als Anwendungsfälle! Anwendungsfälle werden nicht in weitere Anwendungsfälle zerlegt, höchstens unter Verwendung
MehrInteraktionsdiagramme in UML
Interaktionsdiagramme in UML Interaktionsdiagramm ist ein Oberbegriff für eine Reihe von Diagrammen, die das Verhalten eines objektorientierten Systems durch Objektinteraktionen beschreiben Ein Sequenzdiagramm
MehrLehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Objektmodellierung. Grundkurs C++
Grundkurs C++ Objektmodellierung Grundkurs C++ Objektmodellierung welche Objekte bzw. Klassen werden benötigt? welche Information wird benötigt, um ein Objekt zu beschreiben? welche Beziehungen bestehen
MehrLösung zur Zusatzaufgabe Bankensoftware
Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich Lösung zur Zusatzaufgabe Bankensoftware Aufgabe 1 Anwendungsfälle a) Externe Akteure Kunde (Kontoinhaber)
MehrFormale Modellierung Vorlesung vom : Beyond JML
Rev. 1702 1 [12] Formale Modellierung Vorlesung vom 07.05.12: Beyond JML Till Mossakowski & Christoph Lüth Universität Bremen Sommersemester 2012 2 [12] Heute im Programm Grenzen der JML Nach JML: UML
MehrUse Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
MehrOOA-Dynamische Konzepte
Proseminar UML im SS 2005 OOA-Dynamische Konzepte Teil 2 von Benjamin Daeumlich 1 Übersicht Szenario Definition Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Sequenz- vs. Kommunikationsdiagramm
MehrMethoden des Software Engineering
Methoden des Software Engineering Funktions-, daten-, objekt- und aspektorientiert entwickeln Bearbeitet von Joachim Goll 1. Auflage 2012. Buch. xxxviii, 794 S. Hardcover ISBN 978 3 8348 2433 2 Format
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für
MehrInformatik IIa: Modellierung
Informatik IIa: Modellierung Frühlingssemester 2014 Übung 6: Petrinetze, Interaktionsmodelle, Systemmetaphern, Abstraktion Kapitel 7, 10, 11, 12 Ausgabe: 02.05.2014 Abgabe: 16.05.2014 Name: Matrikelnummer:
MehrObjektorientierte Programmierung (OOP)
orientierte Programmierung (OOP) 1. Motivation Die objektorientierte Sichtweise der Welt Als Motivation für die OOP sieht man sich am besten die reale Welt an: Die reale Welt besteht aus "en", z. B.: Gegenstände,
MehrSoftware Engineering, SoSe 07, WSI, D. Huson, May 7,
Software Engineering, SoSe 07, WSI, D. Huson, May 7, 2007 17 4 Modellierung in UML Nach einer Vorlesung von Prof. Andreas Zeller, Lehrstuhl Softwaretechnik Universität des Saarlandes, Saarbrücken. 4.1
MehrVgl. Oestereich Kap 2.4 Seiten
Vgl. Oestereich Kap 2.4 Seiten 99-110 1 Vgl. Oestereich Kap 2.41 Seiten 99ff 2 Wie das Klassendiagramm ist auch das Objektdiagramm ebenfalls ein Strukturdiagramm. Da die Anzahl der Attribute sehr groß
MehrDokumente eines IT-Projektes:
Dokumente eines IT-Projektes: - Pflichtenheft & Co - jheger@upb.de Fachbereich Informatik Paderborn, 04.06.2003 Überlappendes Phasenschema Dokumente der einzelnen Phasen 2 1.1 Überlappendes Phasenschema
MehrTrainingsmanagement Gutschein Management. Beschreibung
Trainingsmanagement Beschreibung www.dastm.de info@dastm.de 1. Einführung... 2 2. Gutschein Funktionen... 3 2.1. Gutschein Menü... 3 2.2. Gutscheine anlegen... 4 Gutschein Kassenwirksam erfassen... 6 Gutschein
MehrUML - Unified Modeling Language
Rainer Burkhardt UML - Unified Modeling Language Objektorientierte Modellierung für die Praxis ADDISON-WESLEY An imprint of Addison Wesley Longman, Inc. Bonn Reading, Massachusetts Menlo Park, California
MehrUnified Modeling Language (UML)
Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine
MehrSoftwaretechnik SS 2006
Softwaretechnik (SWT) Vorlesung und Praktikum SS 2006 Inhaltsübersicht SW-Management SW-Entwicklung SW-Qualitätsmgmt. Softwaretechnik SS 2006 7. Vorlesungseinheit Vorgehensmodelle (insbes. RUP) Best-Practices
MehrCheckliste: Konfiguration eines Datenraums nach einem Upgrade von Brainloop Secure Dataroom von Version 8.10 auf 8.20
Checkliste: Konfiguration eines Datenraums nach einem Upgrade von Brainloop Secure Dataroom von Version 8.10 auf 8.20 Diese Checkliste hilft Ihnen bei der Überprüfung Ihrer individuellen Datenraum-Konfiguration
MehrAnalyse und Modellierung von Informationssystemen
Analyse und Modellierung von Informationssystemen Dr. Klaus Höppner Hochschule Darmstadt Sommersemester 2013 1 / 18 UML Einführung Klassendiagramme in der UML Relationen zwischen Klassen 2 / 18 UML: Grundsätzliches
MehrUML konzentriert. Eine kompakte Einführung in die Standard-Objektmodellierungssprache. Martin Fowler. ADDISON-WESLEY An imprint of Pearson Education
Martin Fowler UML konzentriert Eine kompakte Einführung in die Standard-Objektmodellierungssprache ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills,
MehrAnwendungsfälle als Rückgrat des Anforderungsmodells für die Entwicklung eines Stammdatensystems. Wien,
Anwendungsfälle als Rückgrat des Anforderungsmodells für die Entwicklung eines Stammdatensystems Wien, 21.03.2014 Wir stellen uns vor Dr. Franziska Gietl Senior Consultant für modellbasierte Anforderungs-und
Mehr