ZIEL: Ein Miniprojekt nach den 12 unten aufgeführten Übungen zu entwickeln. 1. Eine Problem-Anweisung zu entwickeln. 2. Entwickeln Sie ein IEEE-Standard-SRS-Dokument. Entwickeln Sie auch das Risikomanagement und den Projektplan (Gantt-Diagramm). 3. Identifizieren Sie Use Cases und entwickeln Sie das Use Case-Modell. 4. Identifizieren Sie die Geschäftsaktivitäten und erstellen Sie ein UML-Aktivitätsdiagramm. 5. Identifizieren Sie die begrifflichen Klassen und entwickeln Sie ein Domänenmodell mit UML-Klassendiagramm. 6. Mit den identifizierten Szenarien finden Sie die Interaktion zwischen Objekten und stellen sie mit UML Interaktionsdiagrammen dar. 7. Zeichnen Sie das Zustandsdiagramm. 8. Identifizieren Sie die Benutzeroberfläche, die Domänenobjekte und die technischen Dienste. Zeichnen Sie das partiell geschichtete, logische Architekturdiagramm mit der UML-Paketdiagramm-Notation. 9. Implementieren Sie den Technischen Service-Layer. 10. Implementieren Sie die Domänenobjektschicht. 11. Implementieren Sie die Oberfläche der Benutzeroberfläche. 12. Zeichnen Sie Komponenten - und Bereitstellungsdiagramme. 18 Vorgeschlagene Domains für Mini-Projekt. 1. Passport-Automatisierungssystem. 2. Buchbank 3. Prüfungsregistrierung 4. Lagerverwaltungssystem. 5. Online-Kursreservierungssystem 6. E-Ticketing 7. Software-Personal-Management-System 8. Kreditkarten-Verarbeitung 9. E-Book-Management-System 10. Recruitment-System 11. Foreign Trading System 12. Konferenz-Management-System 13. BPO Management System Klicken Sie auf Unten Links zum Download des Handbuchs Related Posts: CS2357 2 Kommentare: kann u geben die Codierung in Java oder Visual Basic für Lagerhaltung System. Können Sie das Dokument oder die Codierung in embedded c für ATM-Sicherheitssystem geben Sie einen Kommentar LAB MANUAL Suche in diesem Blog LABOR MANUAL Blog ArchiveUse Falldiagramme Use Case Diagrammen Neben der Einführung von Use Cases als primäre Elemente in der Software-Entwicklung, Jacobson (1994) auch eingeführt Ein Diagramm zur Visualisierung von Anwendungsfällen. Das Anwendungsfalldiagramm ist auch Teil der UML. Viele Leute finden diese Art von Diagramm nützlich. Allerdings muss ich betonen, dass Sie nicht brauchen, um ein Diagramm zu verwenden Use Cases. Eines der effektivsten Projekte, die ich kenne, dass benutzte Use Cases involviert jedes halten auf einer Karteikarte und Sortierung der Karten in Haufen zu zeigen, was brauchte Gebäude in jeder Iteration. Abbildung 3-2 zeigt einige Anwendungsfälle für ein Finanzhandelssystem. Abbildung 3-2. Anwendungsfalldiagramm Ein Akteur ist eine Rolle, die ein Benutzer in Bezug auf das System spielt. Es gibt vier Akteure in Abbildung 3-2: Trading Manager, Trader, Salesperson und Accounting System. (Ja, ich weiß, es wäre besser, die Wortrolle zu gebrauchen, aber anscheinend gab es eine Fehlübersetzung von den Schwedischen.) Es wird wahrscheinlich viele Händler in der gegebenen Organisation geben, aber was das System angeht, spielen sie alle Die gleiche Rolle. Ein Benutzer kann auch mehr als eine Rolle spielen. Zum Beispiel kann ein Senior Trader die Rolle des Trading Manager spielen und auch ein normaler Trader sein, ein Trader kann auch ein Verkäufer sein. Im Umgang mit Akteuren, ist es wichtig, über Rollen zu denken, anstatt Menschen oder Jobtitel. Schauspieler führen Anwendungsfälle durch. Ein einzelner Akteur kann viele Anwendungsfälle umgekehrt durchführen, ein Anwendungsfall kann mehrere Akteure haben, die ihn ausführen. In der Praxis finde ich, dass Schauspieler am nützlichsten sind, wenn sie versuchen, mit den Anwendungsfällen zu kommen. Angesichts eines großen Systems, kann es oft schwierig sein, kommen mit einer Liste von Anwendungsfällen. In diesen Situationen ist es leichter, zuerst in die Liste der Akteure zu kommen und dann die Anwendungsfälle für jeden Akteur zu erarbeiten. Schauspieler müssen nicht menschlich sein, obwohl Schauspieler in einem Anwendungsfalldiagramm als Strichmännchen dargestellt werden. Ein Akteur kann auch ein externes System sein, das einige Informationen aus dem aktuellen System benötigt. In Abbildung 3-2 sehen wir die Notwendigkeit, die Konten des Rechnungswesens zu aktualisieren. Es gibt verschiedene Varianten, was die Leute als Schauspieler zeigen. Einige Leute zeigen jedes externe System oder menschlichen Akteur auf dem Anwendungsfall Diagramm andere bevorzugen den Initiator des Anwendungsfalles zu zeigen. Ich ziehe es vor, den Schauspieler zu zeigen, der Wert aus dem Use Case erhält, den manche Leute als primären Schauspieler bezeichnen. Allerdings nehme ich das nicht zu weit. Im glücklich, das Buchhaltungssystem zu sehen, erhalten Wert, ohne zu versuchen, herauszufinden, der menschliche Akteur, der Wert aus dem Buchhaltungssystem, die mit der Modellierung des Rechnungsführungssystems selbst. Das heißt, sollten Sie immer Frage Anwendungsfälle mit System-Akteure, um herauszufinden, was die tatsächlichen Nutzer Ziele sind, und betrachten alternative Wege zur Erfüllung dieser Ziele. Wenn Im, das mit Schauspielern und Gebrauchfällen arbeitet, sorge ich nicht zu viel über, was die exakten Verhältnisse unter ihnen sind. Die meisten der Zeit, was Im wirklich nach ist die Use Cases die Schauspieler sind nur ein Weg, um dorthin zu gelangen. Solange ich alle Use Cases, Im nicht besorgt über die Details der Schauspieler. Es gibt Situationen, in denen es sich lohnt, die Schauspieler später zu verfolgen. Das System muss möglicherweise für verschiedene Arten von Benutzern konfiguriert werden. In diesem Fall ist jede Art von Benutzer ein Schauspieler, und die Use Cases zeigen Ihnen, was jeder Schauspieler tun muss. Tracking, die Use Cases kann Ihnen helfen, verhandeln Prioritäten zwischen verschiedenen Akteuren. Einige Anwendungsfälle haben keine klare Links zu bestimmten Akteuren. Betrachten Sie ein Versorgungsunternehmen. Eindeutig ist einer der Anwendungsfälle Send Out Bill. Es ist nicht so einfach, einen assoziierten Schauspieler zu identifizieren. Keine bestimmte Benutzerrolle fordert eine Rechnung an. Die Rechnung wird an den Kunden gesendet, aber der Kunde würde nicht widersprechen, wenn er nicht geschehen würde. Die beste Vermutung bei einem Schauspieler ist hier die Abrechnungsabteilung, indem sie Wert aus dem Anwendungsfall erhält. Aber die Abrechnung ist in der Regel nicht bei der Wiedergabe der Anwendungsfall beteiligt. Seien Sie sich bewusst, dass einige Anwendungsfälle nicht Pop-out als Ergebnis der Prozess des Denkens über die Anwendungsfälle für jeden Schauspieler. Wenn das passiert, nicht zu viel Sorgen. Das Wichtigste ist das Verständnis der Anwendungsfälle und der Nutzerziele, die sie erfüllen. Eine gute Quelle für die Identifizierung von Use Cases sind externe Ereignisse. Denken Sie über alle Ereignisse von der Außenwelt, auf die Sie reagieren möchten. Ein gegebenes Ereignis kann eine Systemreaktion hervorrufen, die keine Benutzer involviert, oder es kann eine Reaktion in erster Linie von den Benutzern verursachen. Die Identifizierung der Ereignisse, die Sie benötigen, um zu reagieren hilft Ihnen, die Anwendungsfälle zu identifizieren. Anwendungsfallbeziehungen Zusätzlich zu den Verknüpfungen zwischen Akteuren und Anwendungsfällen können Sie verschiedene Arten von Beziehungen zwischen Anwendungsfällen zeigen. Die Include-Beziehung tritt auf, wenn Sie ein Stück des Verhaltens haben, das in mehr als einem Anwendungsfall ähnlich ist, und Sie möchten nicht die Kopie der Beschreibung dieses Verhaltens beibehalten. Zum Beispiel, beide Analyze Risk und Preis Deal verlangen, dass Sie den Deal Wert. Beschreiben Deal Bewertung ist ein faires Stück des Schreibens, und ich hasse copy-and-paste. Also habe ich einen separaten Value Deal-Use-Fall für diese Situation ausgelöst und von den ursprünglichen Use Cases darauf verwiesen. Sie verwenden Anwendungsfallverallgemeinerung, wenn Sie einen Anwendungsfall haben, der einem anderen Anwendungsfall ähnelt, aber ein bisschen mehr macht. In der Tat, dies gibt uns eine andere Möglichkeit, alternative Szenarien zu erfassen. In unserem Beispiel ist der grundlegende Anwendungsfall Capture Deal. Dies ist der Fall, in dem alles reibungslos läuft. Dinge können die reibungslose Erfassung eines Deals jedoch aufregen. Einer ist, wenn eine Grenze überschritten wird, zum Beispiel die maximale Höhe der Handelsorganisation für einen bestimmten Kunden etabliert hat. Hier führen wir nicht das übliche Verhalten, das mit dem gegebenen Anwendungsfall verbunden ist, durch, den wir eine Alternative durchführen. Wir könnten diese Variante innerhalb des Capture Deal-Use-Case als Alternative, wie mit dem Buy a Product Use-Fall, den ich zuvor beschrieben habe. Allerdings können wir fühlen, dass diese Alternative genügend verschieden ist, um einen gesonderten Anwendungsfall zu verdienen. Wir setzen den alternativen Pfad in einen spezialisierten Anwendungsfall, der sich auf den Basiskonsum bezieht. Der spezialisierte Anwendungsfall kann einen beliebigen Teil des Basiskonsums überschreiben, obwohl es immer noch darum geht, dasselbe wesentliche Nutzerziel zu erfüllen. Eine dritte Beziehung, die ich nicht in Abbildung 3-2 gezeigt habe, wird als verlängert bezeichnet. Im Wesentlichen ist dies ähnlich wie die Generalisierung, aber mit mehr Regeln für sie. Mit diesem Konstrukt kann der erweiterte Anwendungsfall dem Basisebenen-Fall ein Verhalten hinzufügen, aber dieses Mal muss der Basis-Use-Case bestimmte Erweiterungspunkte deklarieren und der erweiterte Use Case kann nur an den Erweiterungspunkten ein zusätzliches Verhalten hinzufügen. (Siehe Abbildung 3-3) Abbildung 3-3. Extend-Beziehung Ein Anwendungsfall kann viele Erweiterungspunkte aufweisen, und ein erweiterter Anwendungsfall kann einen oder mehrere dieser Erweiterungspunkte verlängern. Sie geben an, welche auf der Linie zwischen den Anwendungsfällen auf dem Diagramm liegen. Beide Verallgemeinerungen und Erweiterungen ermöglichen es Ihnen, einen Anwendungsfall aufzuteilen. Während der Ausarbeitung, habe ich oft Split alle Anwendungsfälle, die immer zu kompliziert. Ich spaltete während der Bauphase des Projekts, wenn ich finde, dass ich nicht den ganzen Anwendungsfall in einer Iteration bauen kann. Wenn ich split, mag ich den normalen Fall zuerst und die Variationen später zu tun. Wenden Sie die folgenden Regeln an. Verwenden Sie, wenn Sie sich wiederholen, sich in zwei oder mehr separate Anwendungsfälle und Sie Wiederholungen vermeiden möchten. Verwenden Sie Verallgemeinerung, wenn Sie eine Veränderung des normalen Verhaltens beschreiben, und Sie möchten es beiläufig beschreiben. Verwenden Sie erweitern, wenn Sie eine Variation des normalen Verhaltens beschreiben und möchten Sie die mehr kontrollierte Form, Deklaration Ihrer Erweiterungspunkte in Ihrem base use case. Prepare die folgenden Dokumente für jedes Experiment und entwickeln die Software mit Software-Engineering-Methodik. 1. Problemanalyse und Projektplanung Sorgfältiges Studium des Problems 8211 Projektumfang, Ziele, Infrastrukturen identifizieren 2. Software-Bedarfsanalyse Beschreiben Sie die einzelnen Phasenmodule des Projekts, Identifizieren Sie die Ergebnisse. 3. Datenmodellierung Verwenden Sie das Arbeitsverzeichnis 8211, verwenden Sie Falldiagramme und Aktivitätsdiagramme, erstellen und testen Sie Klassendiagramme, Sequenzdiagramme und fügen Sie Schnittstellen zu Klassendiagrammen hinzu. 4. Software-Entwicklung und Debugging. 5. Software-Tests Vorbereiten des Testplans, Durchführung von Validierungstests, Abdeckungsanalyse, Speicherlecks, Entwicklung der Testfallhierarchie, Site-Check und Site-Monitor. Liste der Experimente: Kursregistrierung System Quiz System Online-Ticketreservierungssystem Remotecomputermonitoring Studentmarks-Analysesystem Expertensystem zur Verschreibung der Medikamente für die gegebenen Symptome ATM-System Plattformzuweisungssystem für die Züge in einem Bahnhof Lagerhaltung E-Mail Client-System. Fall Tools: Rational Suite, Win Runner, Empirix Sprachen: CCJDK 1.3, JSDK, INTERNET EXPLORER, UML Frontend: VB, VC, Entwickler 2000
No comments:
Post a Comment