Wondershare EdrawMind
Mindmap-Galerie Analyse von Informationssystemen und Design-Mindmapping
- 1
Analyse von Informationssystemen und Design-Mindmapping
Dies ist eine Mindmap über die Analyse und das Design von Informationssystemen, einschließlich Systemanalyse und Designübersicht, Systemanforderungsübersicht, Anwendungsfällen, Domänenmodell usw.
Bearbeitet um 2023-11-14 10:01:51
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Projektmanagement-Prozess-Vorlage
Projektmanagement ist der Prozess der Anwendung von Fachwissen, Fähigkeiten, Werkzeugen und Methoden auf die Projektaktivitäten, so dass das Projekt die festgelegten Anforderungen und Erwartungen im Rahmen der begrenzten Ressourcen erreichen oder übertreffen kann. Dieses Diagramm bietet einen umfassenden Überblick über die 8 Komponenten des Projektmanagementprozesses und kann als generische Vorlage verwendet werden.
Analyse von Informationssystemen und Design-Mindmapping
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Hundert Jahre Einsamkeit Charakter-Beziehungsdiagramm
Einhundert Jahre Einsamkeit ist das Meisterwerk von Gabriel Garcia Marquez. Die Lektüre dieses Buches beginnt mit der Klärung der Beziehungen zwischen den Figuren. Im Mittelpunkt steht die Familie Buendía, deren Wohlstand und Niedergang, interne Beziehungen und politische Kämpfe, Selbstvermischung und Wiedergeburt im Laufe von hundert Jahren erzählt werden.
- Projektmanagement-Prozess-Vorlage
Projektmanagement ist der Prozess der Anwendung von Fachwissen, Fähigkeiten, Werkzeugen und Methoden auf die Projektaktivitäten, so dass das Projekt die festgelegten Anforderungen und Erwartungen im Rahmen der begrenzten Ressourcen erreichen oder übertreffen kann. Dieses Diagramm bietet einen umfassenden Überblick über die 8 Komponenten des Projektmanagementprozesses und kann als generische Vorlage verwendet werden.
- Für Sie empfohlen
- Gliederung
Informationssystem des Projektmanager-Wissenssystems (Kapitel 12 Projektbeschaffungsmanagement)
- 2
Informationssystem des Projektmanager-Wissenssystems (Kapitel 3 Projektumfangsverwaltung)
- 1
Informationssystem Projektmanager-Wissenssystem (Kapitel 10 Projektkommunikationsmanagement und Stakeholder-Management)
- 1
Informationssystem-Projektmanager-Wissenssystem (Kapitel 9 Projekt-Personalmanagement)
- 2
Analyse und Design von Informationssystemen
Kap01 Systemanalyse und Designübersicht
Einführung
Hierbei handelt es sich um eine Reihe von Spezifikationen und Leitlinien zur Unterstützung bei der Entwicklung von Informationssystemen
1.1 Softwareentwicklung sowie Systemanalyse und -design
Computeranwendung
Ein Computersoftwareprogramm, das eine bestimmte Reihe von Funktionen auf einem Computergerät ausführt
Mittlerer Anwendungsbereich
Auch „Anwendung“ (App) genannt
Informationssystem
Eine Reihe miteinander verbundener Komponenten, die Informationen sammeln, verarbeiten, speichern und bereitstellen, die für die Erledigung von Geschäftsaufgaben erforderlich sind
Umfangreicher als „Anwendung“
Umfasst Software, Datenbanken und zugehörige manuelle Prozesse
Systemanalyse
Diese Aktivitäten, die es den Menschen ermöglichen, zu verstehen und festzulegen, was ein Informationssystem leisten soll
System-Design
Jene Aktivitäten, die es einem ermöglichen, das System, das die Anforderungen löst, im Detail zu definieren und zu beschreiben
Die Systemanalyse entspricht dem Zeichnen eines Bauplans, während das Systemdesign einem detaillierten Plan entspricht
1.2 Lebenszyklus der Systementwicklung
Projekt
Eine geplante Aufgabe, die einen Anfang und ein Ende hat und ein bestimmtes Ergebnis hervorbringt
für die Entwicklung von Informationssystemen
Erfordert Kenntnisse über Systemanalyse- und Systemdesign-Tools und -Techniken
SDLC (System Development Life Cycle), also der Systementwicklungslebenszyklus
Der Systementwicklungslebenszyklus identifiziert den gesamten Prozess, der alle Aktivitäten umfasst, die zum Aufbau, zur Einführung und zur Wartung von Informationssystemen erforderlich sind
Alle Aktivitäten umfassen: Systemanalyse, Systemdesign, Programmierung, Tests, Systemwartung
sechs Kernprozesse
Identifizieren Sie Probleme oder Bedürfnisse und holen Sie eine Genehmigung ein
Projekte planen und überwachen
Entdecken und verstehen Sie die Details eines Problems oder Bedarfs
Entwerfen Sie Systemkomponenten, die ein Problem lösen oder einen Bedarf erfüllen
Erstellen, testen und integrieren Sie Systemkomponenten
Führen Sie Systemtests durch und stellen Sie dann die Lösung bereit
Entwicklungsprozess von Informationssystemen
Ein praktischer Ansatz zur Entwicklung eines bestimmten Informationssystems (auch bekannt als Methodik), indem Systemtests durchgeführt und die Lösung dann bereitgestellt werden
Zum Beispiel
Einheitlicher Prozess (UP)
Extreme Programmierung (XP)
Iterativer inkrementeller Softwareentwicklungsprozess Scrum
Die meisten Prozesse/Methoden nutzen mittlerweile eine agile und iterative Entwicklung
Agile EntwicklungAgile Entwicklung
Ein Entwicklungsprozess für Informationssysteme, bei dem die Flexibilität bei der Antizipation neuer Anforderungen während der Entwicklung im Vordergrund steht
Schnell auf den Beinen; reagierbar auf Veränderungen
Weder Benutzer noch Teammitglieder verstehen die Probleme und Komplexitäten des neuen Systems vollständig, sodass bei der Projektplanung und -ausführung unerwartete Probleme berücksichtigt werden müssen.
Iterative EntwicklungIterative Entwicklung
Ein Ansatz zur Systementwicklung, bei dem das System durch mehrere Iterationen schrittweise „wächst“.
Vervollständigen Sie einen kleinen Teil des Systems (Miniprojekt), wiederholen Sie dann den Vorgang, um ihn zu verfeinern und weitere hinzuzufügen. Wiederholen Sie dann die Verfeinerung und fügen Sie weitere hinzu, bis er abgeschlossen ist
Vorteil
1. Teile des Systems können schnell bereitgestellt werden
2. Nehmen Sie zuerst einen kleinen Teil zur Entwicklung heraus, damit Sie schwierige Probleme im Projekt so früh wie möglich finden können
Sechs Kernprozesse für die Iteration eines Projekts
Die Fläche des Kreises stellt die Arbeitslast der entsprechenden Iteration in diesem Prozess dar.
Bei jeder Iteration werden mehrere Prozesse mit unterschiedlichen Schwerpunkten ausgeführt.
1.5 Am Beispiel des RMO-Handelssystems wird der Entwicklungsprozess vorgestellt
1.5.1 Vorbereitung
Identifizieren Sie das Problem und dokumentieren Sie die Ziele des Systems (Kernprozess 1)
Voruntersuchung
Ergebnisse in ein System Vision Document (SVD) übersetzen
Holen Sie die Genehmigung zum Starten des Projekts ein (Kernprozess 1)
Treffen Sie sich mit wichtigen Stakeholdern, einschließlich der Geschäftsleitung
Treffen Sie sich mit wichtigen Stakeholdern, einschließlich der Geschäftsleitung, um Entscheidungen zu treffen und Pläne und Budgets zu genehmigen
SVD (System Vision Dokument)
Ein Systemvisionsdokument wird verwendet, um Funktionen zu identifizieren, die dem Unternehmen zugute kommen, und diejenigen, die in das System aufgenommen werden
Machen Sie es in zwei Schritten
Erstellen Sie eine erste Leistungsabrechnung
Fügen Sie detaillierte Umsatz- und Kostenschätzungen hinzu
Besteht im Allgemeinen aus drei Teilen
Problembeschreibung
Systemfunktionen
Geschäftsvorteile
1.5.2 Aktivitäten am ersten Tag
Kernprozess 2: Planung des Projekts
Identifizieren Sie die erforderlichen Hauptkomponenten (Funktionsbereiche).
Teilen Sie das System in Subsysteme oder Komponenten auf
Ein Subsystem ist ein Teil des Gesamtsystems
Definieren Sie Iterationen und weisen Sie jedem Funktionsbereich Iterationen zu
Planen Sie eine einzelne Iteration
Bestimmen Sie die für die Iteration erforderlichen Aufgaben
Die identifizierten Aufgaben werden zusammengestellt und in einer Liste organisiert, die als Projektstrukturplan (WBS) bezeichnet wird.
Beispiel
Inhalte des WBS (Arbeitspausenstruktur)
Zerlegungsbasis (Name)
Die Grundlage für die Zersetzung hängt von den folgenden vier Kernprozessen ab
benötigte Zeit
Ausführungsauftrag
Die Messung der erforderlichen Zeit und Ausführungsreihenfolge kann beim Aufbau des anschließenden Arbeitsnetzwerks und der Berechnung des kritischen Pfads (PERT) hilfreich sein.
Der kritische Pfad ist der längste Pfad im gesamten Netzwerk. Die Prozesse, die er durchläuft, müssen strikt ausgeführt werden. Die Prozesse auf anderen Pfaden weisen ein gewisses Maß an Flexibilität auf.
Organisieren und ordnen Sie diese Aufgaben nach Datum
Konvertieren Sie WBS in einen Zeitplan
Der Vorteil der Planung einzelner Iterationen besteht darin, dass der Zeitplan informell ist und an unerwartete Umstände angepasst werden kann.
Entwickeln Sie einen Entwurf für die Arbeitssequenz
Vorteile des Arbeitsauftragsentwurfs
1. Helfen Sie bei der Organisation der Teamarbeit
2. Es liefert ein Maß dafür, ob die Iteration wie geplant verläuft
3. Wenn das Projekt nach diesem Zeitplan einige Zeit in Anspruch nimmt, kann der Projektleiter erkennen, dass die Programmierung möglicherweise mehr Zeit und Ressourcen erfordert, und kann Ressourcen frühzeitig organisieren, um bei diesem Teil des Projekts zu helfen
Identifizieren Sie benötigte Ressourcen (Personen) und stellen Sie Personal für die Ausführung der entsprechenden Aufgaben bereit
Identifizieren Sie Teammitglieder und Verantwortlichkeiten
1.5.3 Aktivitäten am zweiten Tag
Führen Sie vorläufige Ermittlungsaufgaben durch, um die Anforderungen zu verstehen. (Kernprozess 3)
Kapitel 2 wird es im Detail erklären
Entwickeln Sie eine vorläufige Liste von Anwendungsfällen und ein Anwendungsfalldiagramm. (Kernprozess 3)
Anwendungsfall
Ein Anwendungsfall zeichnet ein von einem einzelnen Benutzer ausgelöstes Geschäftsereignis und die Reaktion des Systems auf dieses Ereignis auf.
Ein Anwendungsfall bezieht sich auf ein Beispiel oder eine Situation der Systemnutzung
Beispiel: Einkäufer „nutzen“ dieses System, um „Lieferanten abzufragen“.
Anwendungsfälle sind im Allgemeinen Verben, die Anforderungen/Funktionen entsprechen
Beispiel für eine Anwendungsfallliste
Beispiel für ein Anwendungsfalldiagramm
Entwickeln Sie eine vorläufige Klassenliste und ein Klassendiagramm. (Kernprozess 3)
Objektklasse
Systeme zur Identifizierung von Objektklassen müssen diese Dinge in der realen Welt verstehen und verfolgen.
Objektklassen müssen Informationen im System speichern
Beispiel für eine Klassenliste
Beispiel für ein Klassendiagramm
Dies ist ein vorläufiges Klassendiagramm, daher gibt es nur Eigenschaften (statische Merkmale).
Das Entwurfsklassendiagramm verfügt über Attributdatentypen und Klassenmethoden usw.
Das obige Diagramm wurde mit der Unified Modeling Language UML entwickelt
1.5.4 Aktivitäten am dritten Tag
Führen Sie eine eingehende Faktenerhebung durch, um die Details zu erfahren. (Kernprozess 3)
Verstehen und dokumentieren Sie den detaillierten Arbeitsablauf für jeden Anwendungsfall. (Kernprozess 3)
Entwickeln Sie Anwendungsfallbeschreibungen und Workflow-Diagramme
Es gibt zwei Möglichkeiten, Anwendungsfalldetails zu dokumentieren
Die Entwicklung von Workflow-Diagrammen erfordert die Verwendung von Aktivitätsdiagrammen, bei denen es sich um Diagramme in UML handelt
Beispiel für ein Workflow-Diagramm
Die Ovale in der Abbildung stellen Aufgaben dar, die Rauten stellen Entscheidungspunkte dar, die Pfeile stellen den Sequenzfluss dar und die Pfeile, die die Mittellinie kreuzen, stellen die Interaktion zwischen dem Benutzer und dem System dar.
Definieren Sie die Benutzererfahrung mit Bildschirmen und Berichten. (Kernprozess 3 und 4)
Definieren Sie das Bildschirmlayout
1.5.5 Aktivitäten am vierten Tag
Entwerfen Sie die Datenbankstruktur (Schema). (Kernprozess 4)
Tischgestaltung
Schlüsselwörter und Index-IDs
Art der Immobilie
referenzielle Integrität
Beispiel für ein Datenbankschema
Entwerfen Sie die übergeordnete Struktur des Systems. (Kernprozess 4)
Gesamtarchitektonisches Design
Definieren Sie ein vorläufiges Designklassendiagramm
Beispiel für ein vorläufiges Designklassendiagramm
Designklassen umfassen die von der Klasse benötigten Variablen auf Klassenebene, die auch die Methodennamen wichtiger Methoden in jeder Klasse anzeigen. Die letzten Elemente in einem Design-Klassendiagramm sind Pfeile, die zeigen, welche Klassen Zugriff auf Methoden welcher anderen Klassen haben.
Design der Subsystemarchitektur
1.5.6 Aktivitäten am fünften Tag
Weiter mit detailliertem Design (CP4)
Durchführung von Programmierungen und individuellen Tests (CP5)
Bei Design und Programmierung geht es nicht darum, das Ganze zu entwerfen und dann zu programmieren, sondern darum, einen Teil zu entwerfen, zu programmieren, dann einen Teil zu entwerfen und dann noch einmal zu programmieren.
1.5.7 Aktivitäten am sechsten Tag
Vollständige Systemprüfung (CP6)
Gesamtsystemfunktionstest
User Acceptance Testing
Möglicher Einsatz von Teilsystemen (CP6)
1.5.8 Überprüfung der ersten Iteration
1.6 Einführung in den nachfolgenden Inhalt
1.6.1 Teil Eins Einführung in die Systementwicklung
Kapitel eins
1.6.2 Teil 2 Systemanalyseaktivitäten
Kapitel 2, 3, 4 und 5
1.6.3 Teil 3 Systemdesignaktivitäten
Kapitel sechs und sieben
1.6.4 Teil 4 Projekte und Projektmanagement
Kapitel 8 und 9
1.6.5 Teil 5 Erweiterte Konzepte und Bereitstellungskonzepte
Kapitel 10, 11, 12
Kapitel 02: Umfrage zu den Systemanforderungen
2.1 Einführung
In diesem Kapitel beginnen wir damit, den Umfang und die Details des SDLC-Prozesses zu erweitern, um ein breiteres Spektrum an Konzepten, Tools und Techniken abzudecken. Dieses Kapitel konzentriert sich auf Systemanalyseaktivitäten (der dritte aufgeführte Kernprozess), und in den folgenden Kapiteln werden die Modelle, die während dieser Systemanalyseaktivitäten entwickelt wurden, ausführlich erörtert. Nachfolgende Kapitel erweitern die Diskussion anderer zentraler SDLC-Prozesse.
2.2CSMS (Comprehensive Sales and Marketing System) für RMO
2.2.1Das bestehende Informationssystem und die Architektur von RMO
Die Architektur ist in zwei Typen unterteilt
Technologiearchitektur Technologiearchitektur
Technologiearchitektur beschreibt den Satz von Computerhardware, Netzwerkhardware und -topologie sowie Systemsoftware, die von einer Organisation verwendet werden (z. B. Betriebssysteme und Datenbankverwaltungssysteme).
Anwendungsarchitektur Anwendungsarchitektur
Die Anwendungsarchitektur beschreibt, wie Softwareressourcen organisiert und strukturiert werden, um die Informationssysteme einer Organisation zu implementieren. Es beschreibt die Organisation von Software in Module und Subsysteme, einschließlich unterstützender Technologien (wie Programmiersprachen und Entwicklungsumgebungen), Architekturansätzen (wie serviceorientierter Architektur) und Benutzeroberflächentechnologien (wie mobile Computerdisplays, Touchscreens). Technologie und Spracherkennung).
2.1.2 Neues CSMS
Das neue integrierte Vertriebs- und Marketingsystem wird vier Subsysteme umfassen
Vertriebssubsystem
Subsystem zur Auftragsimplementierung
Kundenkonto-Subsystem
Marketing-Subsystem
2.3 Systemanalyseaktivitäten
Es gibt fünf Hauptteile
2.3.1 Sammeln Sie detaillierte Informationen
Interviews, Fragebögen, Dokumentation, Beobachtung von Geschäftsprozessen, Recherche von Lieferanten, Meinungen und Vorschlägen
2.3.2 Anforderungen definieren
Funktionale und nichtfunktionale Anforderungsmodellierung
2.3.3 Priorisierung der Anforderungen
2.3.4 Entwickeln Sie Dialogfelder für die Benutzeroberfläche
Der Interaktionsprozess zwischen Benutzern und dem System
2.3.5 Bewerten Sie die Bedürfnisse mit den Benutzern
Benutzereinbindung, Feedback, Anpassung an Änderungen
2.4 Was ist Nachfrage?
Systemanforderungen sind alle Aktivitäten, die das neue System ausführen oder unterstützen muss, sowie die Einschränkungen, die das neue System erfüllen muss.
Systemanforderungen sind unterteilt in
funktionale Anforderungen
Funktionale Anforderungen sind die Aktivitäten, die das System ausführen muss (z. B. das Unternehmen, auf das das System angewendet wird).
Erfordert die Ausführung durch den Benutzer
Nicht-funktionale Anforderungen
Nichtfunktionale Anforderungen sind Merkmale, die über die Aktivitäten hinausgehen, die das System ausführen oder unterstützen muss.
Wie Leistungsindikatoren, Einschränkungen (Entwicklungstools, Datenformate usw.)
Mit FURPS können Sie Anforderungen einfach aufteilen
funktionale Funktionalität
Verfügbarkeit der Benutzerfreundlichkeit
Zuverlässigkeit
Leistung
Sicherheit
Andere, etwa restriktive Bedingungen
Nicht-funktionale Anforderungen
2.5 Modelle und Modellierung
Modell
Ein Modell ist eine Darstellung eines Aspekts des zu erstellenden Systems.
Art des Modells
Textmodell
Berichte, Dokumente
grafisches Modell
Schematische Darstellung
mathematisches Modell
Formel
Modellierungssprache
Die Entwicklung vieler grafischer Modelle wird durch UML (Undefinierte Modellierungssprache) implementiert.
UML ist eine Reihe von Standardmodellkonstrukten und -symbolen, die von der Object Management Group, einer gemeinnützigen Organisation, definiert werden
2.6 Stakeholder
Stakeholder sind alle, die ein Interesse an der erfolgreichen Umsetzung des Systems haben.
Stakeholder-Klassifizierung
interne Stakeholder
Interne Stakeholder sind Personen innerhalb der Organisation, die mit dem System interagieren oder ein erhebliches Interesse an dessen Betrieb oder Erfolg haben.
externe Stakeholder
Externe Stakeholder sind Personen, die außerhalb der Kontrolle und des Einflusses der Organisation liegen.
operative Stakeholder
Operative Stakeholder sind Personen, die im Rahmen ihrer Arbeit oder ihres Privatlebens häufig mit dem System interagieren.
Zum Beispiel: Buchhalter, die mit Buchhaltungs- oder Abrechnungssystemen interagieren, Fabrikarbeiter, die mit Produktionsplanungssystemen interagieren, Kunden, die mit Internet-Shops interagieren, und Patienten, die mit Websites des Gesundheitswesens, Facebook-Seiten oder Twitter-Newsfeeds interagieren.
Verwalten Sie Stakeholder
Management-Stakeholder sind diejenigen, die nicht direkt mit dem System interagieren, sondern die vom System erzeugten Informationen nutzen oder ein erhebliches finanzielles oder sonstiges Interesse an seinem Betrieb und Erfolg haben.
Zum Beispiel: die Geschäftsleitung und der Vorstand einer Organisation, Aufsichtsbehörden und Steuerbehörden.
Zwei Arten wichtiger Stakeholder
Kunde: die Person, die finanzielle Unterstützung leistet
Personal für den technischen Support des Systems
2.7 Informationserfassungstechnologie
Zu den Informationserfassungstechnologien gehören:
2.7.1 Führen Sie Interviews mit Benutzern und anderen Interessengruppen durch
Systemanalytiker werden benötigt
Bereiten Sie detaillierte Fragen vor
Gegenstand der Frage
Wie soll der Geschäftsprozess aussehen?
Wie Geschäftsprozesse funktionieren
Welche Informationen werden benötigt?
Art der Frage
Offene Fragen
geschlossene Fragen
Frageobjekt: altes System oder neues System
Treffen Sie einzelne Benutzer oder Benutzergruppen
Erhalten und diskutieren Sie Antworten auf Fragen
Antwort aufzeichnen
Verfolgen Sie Informationen, die Sie in zukünftigen Interviews verwenden können
2.7.2 Fragebögen verteilen und einsammeln
Drei Arten von Fragen
geschlossene Fragen
Schauen Sie sich die Formatprobleme an
Offene Fragen
2.7.3 Eingabe, Ausgabe und Prozess prüfen
Es gibt zwei Quellen für Input, Output und Prozesse
Geschäftsunterlagen und Prozessbeschreibungen aus der Organisation
Von außerhalb der Organisation – Berufsverbände und andere Unternehmen aus der gesamten Branche
Prüfen Sie die vorhandene Verarbeitungsdokumentation
2.7.4 Geschäftsprozesse beobachten und protokollieren
Dies wird Ihnen helfen, die Funktion des Unternehmens zu verstehen
2.7.5 Anbieterlösungen recherchieren
Drei Vorteile und eine Gefahr
1. Das Studium dieser Lösungen kann Benutzern helfen, besser darüber nachzudenken, wie sie Geschäftsfunktionen besser ausführen können
2. Einige Lösungen sind bereits erstklassig und es ist schwierig, ohne Recherche mit dem Trend Schritt zu halten.
3. Der Kauf einer Lösung ist weniger riskant und kostengünstiger als die Recherche
Gefahr: Überstürzt eine Lösung kaufen, ohne alle Anforderungen des Systems zu untersuchen
2.7.6 Aktive Benutzerkommentare sammeln
2.8 Verwenden Sie das Aktivitätsdiagramm, um den Arbeitsablauf aufzuzeichnen
Arbeitsablauf
Ein Workflow ist eine Reihe von Verarbeitungsschritten, die einen Geschäftsvorgang oder eine Kundenanfrage vollständig abwickeln.
Aktivitätsdiagramm
Ein Aktivitätsdiagramm beschreibt verschiedene Benutzer- (oder System-)Aktivitäten, die Personen, die jede Aktivität ausführen, und den sequenziellen Ablauf dieser Aktivitäten.
Symbole und Erklärungen
Ellipsen stellen verschiedene Aktivitäten im Workflow dar. Verbindungspfeile zeigen die Reihenfolge zwischen den Aktivitäten an. Die schwarzen Kreise zeigen den Beginn und das Ende des Workflows an. Der Diamant ist ein Entscheidungspunkt, an dem der Prozess in die eine oder andere Richtung verläuft. Die dicke durchgezogene Linie ist ein Synchronisationsbalken, der einen Pfad in mehrere gleichzeitige Pfade aufteilen oder gleichzeitige Pfade neu kombinieren kann. Der Titel der Schwimmbahn stellt den Agenten dar, der die Aktivität ausführt. Da es in einem Workflow in der Regel verschiedene Agenten (d. h. Personen) gibt, die unterschiedliche Schritte des Workflow-Prozesses ausführen, unterteilen Swimlane-Symbole Workflow-Aktivitäten in Gruppen und zeigen an, welcher Agent welche Aktivität ausführt.
Kapitel 03 Anwendungsfall
3.1 Einführung
Wie in den Kapiteln 4 und 5 werden in diesem Kapitel Techniken zur Dokumentation funktionaler Anforderungen durch die Erstellung verschiedener Modelle vorgestellt.
Ein Anwendungsfall ist eine Aktivität, die ein System ausführt, normalerweise als Reaktion auf eine Benutzeranfrage.
Anwendungsfälle definieren funktionale Anforderungen
Analysten zerlegen das System in eine Reihe von Anwendungsfällen (funktionale Zerlegung).
Anwendungsfälle werden normalerweise nach Verben oder Gerundien benannt
3.2 Anwendungsfälle und Benutzerziele
Eine Technik zum Definieren von Anwendungsfällen ist die Benutzerzieltechnik, bei der Benutzer aufgefordert werden, ihre Ziele für die Verwendung eines neuen oder aktualisierten Systems zu beschreiben.
In acht Schritte unterteilt
Identifizieren Sie alle potenziellen Benutzer des neuen Systems
Kategorisieren Sie potenzielle Benutzer anhand funktionaler Rollen (z. B. Transport, Marketing, Vertrieb).
Kategorisieren Sie potenzielle Benutzer weiter nach Organisationsebene (z. B. Betrieb, Management, Führungskraft).
Besuchen Sie jeden Benutzertyp und finden Sie eine Liste der spezifischen Ziele, die er bei der Nutzung des neuen Systems verfolgen wird (aktuelle Ziele und innovative Funktionen, die einen Mehrwert schaffen).
Erstellen Sie eine vorläufige Liste von Anwendungsfällen, geordnet nach Benutzertyp
Finden Sie Kopien mit ähnlichen Anwendungsfallnamen und beheben Sie Inkonsistenzen
Stellen Sie fest, wo verschiedene Benutzertypen dieselben Anwendungsfälle benötigen
Überprüfen Sie die ausgefüllte Liste mit jedem Benutzertyp und interessierten Stakeholdern
Grundsätzlich werden nur Veranstaltungen mit funktionalen Anforderungen berücksichtigt
Techniken zur Benutzerausrichtung sind einfach, werden aber häufig verwendet
3.3 Anwendungsfall- und Ereigniszerlegung
Die Ereigniszerlegungstechnologie ist die umfassendste Technologie zur Identifizierung von Anwendungsfällen
Die Ereigniszerlegungstechnologie ermittelt zunächst alle Geschäftsereignisse, die eine Reaktion des Informationssystems auslösen, und jedes Ereignis führt zu einem Anwendungsfall. Wenn Analysten mit Geschäftsereignissen beginnen, können sie jeden Anwendungsfall mit der richtigen Detailebene definieren
Zur Bestimmung des geeigneten Detaillierungsgrades für einen Anwendungsfall wird der Essential Business Process (EBP) verwendet.
EBP ist eine Aufgabe, die von einer Person an einem Ort ausgeführt wird, um auf Geschäftsereignisse zu reagieren, einen messbaren Geschäftswert zu schaffen und das System und seine Daten in einen stabilen und konsistenten Zustand zu bringen.
Jedes EBP reagiert auf ein Geschäftsereignis, wenn es eintritt
3.3.1 Ereigniszerlegungstechnologie
Ereignis
Ereignisse ereignen sich zu einem bestimmten Zeitpunkt und an einem bestimmten Ort, können beschrieben werden und sollten vom System gespeichert werden
3.3.2 Ereignistypen
externe Ereignisse
Externe Ereignisse sind Ereignisse, die außerhalb des Systems auftreten und normalerweise von externen Agenten oder Akteuren initiiert werden.
Externe Agenten (oder Akteure) sind Einzelpersonen oder Organisationseinheiten, die dem System Daten bereitstellen oder empfangen.
Zum Beispiel
Verschiedene Geschäftsprozesse, wie z. B. das Aufgeben von Bestellungen durch den Benutzer usw.
Externe Ereignisse werden im Allgemeinen verwendet, um auf Benutzeranfragen (Akteursanfragen) zu reagieren, und treten in Interaktionsumgebungen zwischen Mensch und Computer auf.
Zeitgesteuertes Ereignis/vorübergehende Zeit
Ein Ereignis, das als Folge des Erreichens eines bestimmten Zeitpunkts eintritt.
Zum Beispiel
Versenden Sie regelmäßig statistische Berichte usw.
Im System treten vorübergehende Ereignisse auf
Statusereignis
Statusereignisse treten auf, wenn innerhalb des Systems ein Ereignis auftritt, das eine Verarbeitungsanforderung auslöst.
Wird verursacht, wenn sich der Status ändert
Im Allgemeinen handelt es sich dabei um nicht funktionale Anforderungen, die nicht oft berücksichtigt werden.
3.3.3 Ereignisse definieren
Ereignis/Vorbedingung/Reaktion
Analysten müssen eine Abfolge von Ereignissen betrachten und dann die Ereignisse identifizieren, die sich tatsächlich auf das System auswirken
Abfolge der Ereignisse
Es ist nützlich, eine Reihe von Ereignissen zu verfolgen, die bei einer bestimmten externen Entität oder einem bestimmten Akteur aufgetreten sind
Technologieabhängigkeitsereignisse und Systemsteuerung
Manchmal befassen sich Analysten mit Ereignissen, die für das System wichtig sind, aber keinen direkten Bezug zu Benutzern oder Transaktionen haben. Bei diesen Ereignissen handelt es sich typischerweise um Entwurfsentscheidungen oder Systemkontrollen. Analysten sollten diese Ereignisse während der Analyse vorübergehend ignorieren.
Systemkontrollen sind Kontrollen oder Sicherheitsverfahren, die dazu dienen, die Integrität eines Systems zu schützen
Datensicherung, Login etc.
Während der Analysephase verwenden wir ideale technische Annahmen
Die Hypothese der perfekten Technologie besagt, dass Ereignisse nur dann auftreten, wenn das System unter perfekten Bedingungen reagieren muss (z. B. das Gerät fällt nie aus, die Verarbeitungs- und Speicherleistung ist unbegrenzt und die Leute, die das System bedienen, sind völlig ehrlich und machen niemals Fehler). in den Analyseprozess einbezogen.
3.3.4 Verwenden Sie die Ereigniszerlegungstechnologie
1. Berücksichtigen Sie externe Ereignisse in der Systemumgebung, die eine Systemreaktion erfordern
2. Identifizieren und benennen Sie für jedes externe Ereignis den vom System benötigten Anwendungsfall.
3. Verwenden Sie eine Checkliste, um Zeitereignisse zu berücksichtigen, die eine Systemreaktion erfordern.
4. Identifizieren und benennen Sie für jedes Zeitereignis die vom System benötigten Anwendungsfälle und legen Sie dann den Zeitpunkt fest, der den Anwendungsfall auslöst.
5. Berücksichtigen Sie die Zustandsereignisse, auf die das System reagieren kann, insbesondere wenn es sich um ein Echtzeitsystem handelt, bei dem Geräte- oder interne Zustandsänderungen Anwendungsfälle auslösen.
6. Identifizieren und benennen Sie für jedes Zustandsereignis den vom System benötigten Anwendungsfall und definieren Sie dann die Zustandsänderung.
7. Überprüfen Sie nach der Definition von Ereignissen und Anwendungsfällen, ob diese perfekte technische Annahmen erfordern. Schließen Sie keine Ereignisse ein, die Systemkontrollen wie Anmeldung, Abmeldung, Passwortänderung und Sicherung oder Wiederherstellung der Datenbank betreffen, da diese als Systemkontrollen platziert werden.
3.4 Anwendungsfälle und CRUD
Eine weitere wichtige Technologie zur Validierung und Verfeinerung von Anwendungsfällen ist die CRUD-Technologie.
CRUD bedeutet
Erstellen
Lesen Lesen
Aktualisieren, aktualisieren
Löschen, löschen
Hierbei handelt es sich um Vorgänge im Zusammenhang mit der Datenbankverwaltung
CRUD-Techniken sind am nützlichsten, wenn sie zusammen mit User-Targeting-Techniken zur Gegenprüfung verwendet werden. Anstatt es direkt als Methode zur Identifizierung von Anwendungsfällen zu verwenden, kann es dazu führen, dass die Anwendungsfälle den Geschäftsprozess nicht sehr gut verfolgen.
Kann überprüfen, ob Anwendungsfalltypen fehlen
CRUD-Technologieschritte
1. Identifizieren Sie alle am neuen System beteiligten Datenentitäten oder Domänenklassen.
2. Überprüfen Sie für jeden Datentyp (Datenentität oder Domänenklasse), ob Sie Anwendungsfälle zum Erstellen neuer Instanzen, zum Aktualisieren vorhandener Instanzen, zum Lesen oder Melden von Instanzwerten und zum Löschen (Archivieren) von Instanzen identifiziert haben.
3. Wenn ein erforderlicher Anwendungsfall ignoriert wird, fügen Sie einen neuen Anwendungsfall hinzu und identifizieren Sie die Stakeholder.
4. Stellen Sie bei integrierten Anwendungen sicher, dass klar ist, welche Anwendung für das Hinzufügen und Verwalten von Daten verantwortlich ist und welches System die Daten nur verwendet.
3.6 Anwendungsfalldiagramm
Anwendungsfalldiagramme sind UML-Modelle zur grafischen Darstellung von Anwendungsfällen und deren Beziehung zu Benutzern.
3.6.1 Anwendungsfälle, Akteure und Symbole
Implizit sind in den meisten Anwendungsfällen die Personen, die das System nutzen, die wir bisher als Benutzer bezeichnet haben. In UML wird diese Person als Akteur bezeichnet. Akteure befinden sich häufig außerhalb der Automatisierungsgrenzen
Im Anwendungsfalldiagramm stellt das menschliche Symbol den Akteur dar, das Oval stellt den Anwendungsfall dar, der rechteckige Rand stellt die Automatisierungsgrenze dar und die Verbindung zwischen dem Anwendungsfall und dem Akteur stellt dar, welcher Akteur an welchem Anwendungsfall teilnimmt.
Beispiel
Es bestehen nicht nur Beziehungen zwischen Anwendungsfällen und Akteuren, sondern es können auch Beziehungen zwischen Anwendungsfällen bestehen.
Dies ist eine Abhängigkeit zwischen Anwendungsfällen und kommt in zwei Formen vor Verwenden Sie zur Kennzeichnung gestrichelte Pfeile und << >>
<<include>>
Es kann als Nutzungsbeziehung verstanden werden, die sich auf die Verwendung eines Anwendungsfalls in einem anderen Anwendungsfall bezieht. Der durch den Pfeil angezeigte Anwendungsfall ist der verwendete Anwendungsfall (abhängig). Diese Beziehung erfordert, dass ein Anwendungsfall in einem anderen Anwendungsfall verwendet werden muss
<<erweitert>>
Diese Beziehung gibt an, dass ein Anwendungsfall einen anderen Anwendungsfall verwenden kann. In dieser Beziehung wird es einen sogenannten Erweiterungspunkt geben. In einem Bibliotheksverwaltungssystem kann der Anwendungsfall der Rückgabe von Büchern beispielsweise mit Bußgeldern (Zeitüberschreitungen usw.) verbunden sein.
Der Zusammenhang zwischen den beiden besteht darin, dass es sich um Beziehungen zwischen Anwendungsfällen handelt und beide die Verwendung eines anderen Anwendungsfalls in einem Anwendungsfall bedeuten. Der Unterschied zwischen den beiden besteht darin, dass „include“ bedeutet, dass definitiv ein anderer UC verwendet wird, während „extended“ die Beurteilung der Erweiterung erfordert Punkt, bevor Sie über die Verwendung entscheiden oder nicht
Kapitel 04 Domänenmodell
4.1 Einführung
Kernkonzepte: Dinge im Problembereich des Systembenutzers
4.2 Dinge im Problembereich
Die Problemdomäne bezieht sich auf den spezifischen Bereich des Benutzergeschäfts, der im neuen System enthalten ist.
Domänenklassen oder -entitäten sind das, mit dem Endbenutzer im Studio arbeiten müssen. Diese werden in der Systemproblemdomäne oft als „Dinge“ bezeichnet.
Zum Beispiel
Produkte, Bestellungen, Kunden
4.2.1 Methode 1 zur Definition von Dingen im Problembereich – Brainstorming-Methode
1. Identifizieren Sie einen Benutzer und eine Reihe von Anwendungsfällen.
2. Brainstorming mit Benutzern, um die Dinge zu identifizieren, die bei der Ausführung des Anwendungsfalls eine Rolle spielen, d. h. die Dinge, über die das System Informationen erfassen sollte.
3. Verwenden Sie Dingtypen (Kategorien), um systematisch Fragen zu potenziellen Dingen zu stellen, zum Beispiel: Speichern Sie Informationen über konkrete Dinge? Sind Standorte beteiligt? An welche Rollen müssen Sie sich erinnern?
4. Arbeiten Sie weiterhin mit einer Vielzahl von Benutzern und Interessengruppen zusammen, um die Brainstorming-Liste zu erweitern.
5. Kombinieren Sie die Ergebnisse, beseitigen Sie alle Duplikate und erstellen Sie eine erste Liste.
4.2.2 Methode 2 zur Definition von Dingen im Problembereich – Substantivtechnologie
Listen Sie alle von Benutzern erwähnten Substantive auf, die zur Beschreibung von Ereignissen, Anwendungsfällen oder Akteuren verwendet werden.
Schritt
1. Identifizieren Sie alle Substantive anhand von Anwendungsfällen, Akteuren und anderen Informationen über das System (einschließlich Eingaben und Ausgaben).
2. Fügen Sie unter Verwendung bestehender Systeme, aktueller Verfahren und anderer Informationen aus aktuellen Berichten oder Formularen Elemente oder Kategorien erforderlicher Informationen hinzu. Bei einigen dieser Elemente kann es sich um zusätzliche Dinge handeln, bei anderen kann es sich um spezifischere Informationen (sogenannte Attribute) zu Dingen handeln, die Sie bereits identifizieren. Verfeinern Sie die Liste und notieren Sie dann die Hypothesen oder Fragen, die Sie untersuchen möchten.
3. Während diese Liste von Substantiven erstellt wird, müssen Sie sie verfeinern.
Stellen Sie für jedes Substantiv die folgenden Fragen, um zu entscheiden, ob es einbezogen werden soll:
Ist es etwas Einzigartiges, das das System wissen muss?
Liegt es im Rahmen des Systems, das ich entwickle?
Muss sich das System mehr als einen der oben genannten Punkte merken?
Stellen Sie zu jedem Substantiv die folgenden Fragen, um zu entscheiden, ob es ausgeschlossen werden soll:
Ist es wirklich ein Synonym für etwas anderes, das ich identifiziert habe?
Handelt es sich wirklich nur um eine Systemausgabe, die auf anderen von mir identifizierten Informationen basiert?
Ist es wirklich nur eine Eingabe, die dazu führt, dass andere von mir identifizierte Informationen aufgezeichnet werden?
Stellen Sie zu jedem Substantiv die folgenden Fragen, um zu entscheiden, ob es studiert werden sollte:
Ist es möglich, dass es sich um konkrete Informationen (Eigentum) über andere Dinge handelt, die ich identifiziert habe?
Wenn sich Annahmen ändern, brauche ich das möglicherweise?
4. Erstellen Sie eine Hauptliste aller identifizierten Substantive und geben Sie dann an, ob jedes Substantiv einbezogen, ausgeschlossen oder weiter untersucht werden soll.
5. Überprüfen Sie die Liste mit Benutzern, Stakeholdern und Teammitgliedern und verfeinern Sie dann die Liste der Dinge in der Problemdomäne.
Beispiel
4.2.3 Eigenschaften von Dingen
Die meisten Systeme speichern bestimmte Informationen zu Transaktionen, die als Attribute bezeichnet werden
Ein Attribut, das etwas eindeutig identifiziert, wird als Bezeichner oder Schlüsselwort (Schlüssel/Code) bezeichnet.
Zusammengesetzte Attribute bestehen aus mehreren verwandten Attributen wie Adresse, vollständiger Name usw.
4.2.4 Beziehungen zwischen Dingen
Assoziation bezieht sich auf die natürlich vorkommende Beziehung zwischen bestimmten Dingen.
In UML gibt es grob vier Arten von Beziehungen zwischen Dingen
Verband
Generationsverallgemeinerung
AbhängigkeitAbhängigkeit
implementieren
zugehörigen Details
hat einen Namen
Es gibt eine Richtung, und das Ding, auf das der Pfeil zeigt, kann das andere nicht sehen (das heißt, das andere hängt von dem Ding ab, auf das der Pfeil zeigt, und das spitze Ding ändert sich in das andere, aber umgekehrt hat es keine Wirkung).
Beispielsweise heißt A->B A in Abhängigkeit von B.
Assoziation ist Vielfalt, also die quantitative Beziehung zwischen einer Sache und einer anderen Sache
Beispiel
Es gibt Kardinalitätsbeschränkungen zwischen Assoziationen
zugehöriges Element
Eine Assoziation besteht aus mehreren verschiedenen Arten von Dingen, und die Anzahl dieser Dinge ist die Art der Assoziation
Kunde und Auftrag, binäre Beziehung
Assoziation zwischen ähnlichen Dingen, einem Element
Drei oder mehr verschiedene Arten von Dingen sind miteinander verbunden, vielfältig
4.3 Entity-Kontakt-Diagramm
Dies ist ein Modell zur Datenbankmodellierung
Rechtecke stellen Entitäten dar, und Linien, die Rechtecke verbinden, stellen Verbindungen zwischen Entitäten dar.
symbolische Darstellung
Nur vertikale Linien werden abgeschnitten, um darzustellen, dass es nur eine gibt
Vertikale Linien werden abgeschnitten und eingekreist, um 0 oder 1 darzustellen
Ein Kreis mit einer Querlinie zeigt 0 oder mehr an
Abgeschnittene vertikale Linien und gegabelte Linien stellen eine oder mehrere dar
Die der Zahl entsprechende Richtung ist von vorzeichenlos nach vorzeichenbehaftet
In den Attributen der Entität wird der Primärcode (Identifikator) in die erste Zeile eingefügt und mit PK markiert, um anzuzeigen, dass es sich um den Primärcode handelt.
Beispiel
Ein Kunde entspricht 0 bis mehreren Bestellungen; eine Bestellung entspricht genau einem Kunden
4.4 Klassendiagramm des Domänenmodells
Die betreffende Klasse von Dingen wird als Domänenklasse bezeichnet
In UML werden Klassendiagramme verwendet, um die Objektklassen des Systems anzuzeigen
Klassendiagramm des Domänenmodells
Wird verwendet, um Dinge in der Problemdomäne des Benutzers anzuzeigen
Design-Klassendiagramm
für Design
symbolische Darstellung
In einem Klassendiagramm stellen Rechtecke Klassen dar, und gerade Linien, die die Rechtecke verbinden, stellen Beziehungen zwischen Klassen dar.
Das Rechteck besteht aus zwei Teilen (Domänenmodellklassendiagramm, Designklassendiagramm besteht aus drei Teilen: Klassenname, Attribute, Methoden), oben ist der Klassenname und unten sind die Attribute der Klasse
Klassennamen und Attributnamen verwenden die Kamel-Schreibweise für die Benennung. Der erste Buchstabe des Klassennamens wird großgeschrieben, und der erste Buchstabe des Attributnamens wird in Kleinbuchstaben geschrieben.
4.4.1 Notation des Domänenmodellklassendiagramms
Multiplizitätssymbol
Stellt die Anzahl der Beziehungen zwischen Klasseninstanzen dar, ähnlich der Vielzahl von Entitätsbeziehungsdiagrammen
Beispiel
Die Multiplizität ähnelt hier der Mapping-Kardinalität des Entity-Relationship-Diagramms.
Spezifische Anwendung für Domänenklassendiagramme
Dies ist ein Domänenmodell-Klassendiagramm für die Kursauswahl von Studenten. Ein Kurs kann 0 bis mehrere Abschnitte haben, aber ein Abschnitt kann nur zu einem Kurs gehören und die Abschnitte haben eine Viele-zu-Viele-Beziehung, und beide können es sein Null; Es gibt eine Assoziationsklasse zwischen Studierenden und Kursen, markiert mit einer gepunkteten Linie, mit dem Attribut Note
4.4.2 Komplexere Probleme bezüglich Objektklassen
Es gibt drei Arten von Beziehungen in Domänenklassen
Verband
Generierung von Generalisierung/Spezialisierung
Die Grundlage der Generalisierungs-/Spezialisierungsbeziehung besteht darin, dass Menschen Dinge anhand von Ähnlichkeiten und Unterschieden klassifizieren.
Die Generalisierungs-/Spezialisierungsbeziehung wird verwendet, um diese Dinge von allgemeiner zu spezifischer zu strukturieren oder zu ordnen.
Über jeder Klasse in der Hierarchie kann eine allgemeinere Klasse liegen, die als Superklasse bezeichnet wird.
Einer Klasse kann eine speziellere Klasse untergeordnet sein, die als Unterklasse bezeichnet wird.
Durch Vererbung können Unterklassen Merkmale ihrer Oberklasse gemeinsam nutzen.
Verwenden Sie einen dreieckigen Pfeil, um auf die Superklasse zu zeigen
Beispiel
Verwenden Sie Kursivschrift, um abstrakte Klassen zu kennzeichnen
Abstrakte Klassen können nicht instanziiert und nur vererbt werden
Es gibt auch eine konkrete Klasse, also eine Klasse, die Instanzobjekte haben kann.
Superklassen sind manchmal konkret oder abstrakt
Ganzer Teil
Die globale/Teil-Beziehung wird verwendet, um die Beziehung zwischen einer Klasse und anderen in dieser Klasse enthaltenen Klassen auszudrücken.
Polymerisation
In einer Aggregationsbeziehung können Komponenten unabhängig voneinander existieren
Verwenden Sie zur Darstellung Hohlrauten
Kombination
In einer kombinierten Beziehung kann nicht jeder Teil unabhängig voneinander existieren, sobald er in Beziehung steht.
Verwenden Sie zur Darstellung einen massiven Diamanten
Kapitel 05 Erweiterung des Anforderungsmodells
5.2 Beschreibung des Anwendungsfalls
Anwendungsfallbeschreibungen beschreiben die Details jedes Anwendungsfalls.
Einfache Anwendungsfallbeschreibung
Geeignet für einzelne Szenarien und weniger Ausnahmen
Beispiel
Vollständig ausgearbeitete Anwendungsfallbeschreibung
Für einige komplexere Anwendungsfälle ist eine vollständig erweiterte Anwendungsfallbeschreibung erforderlich.
Standardvorlage
Name des Anwendungsfalls
Anwendungsszenarien
auslösendes Ereignis
Kurze Beschreibung
Teilnehmer
Andere damit verbundene Anwendungsfälle und wie es damit verbunden ist
Stakeholder
Voraussetzungen
Voraussetzungen bestimmen den Zustand des Systems zu Beginn eines Anwendungsfalls, einschließlich Objekten, die bereits vorhanden sein müssen, Informationen, die verfügbar sein müssen, und sogar Bedingungen für Akteure, bevor der Anwendungsfall beginnt.
Nachfolgende Bedingungen
Nachbedingungen bestimmen, was wahr sein muss, wenn der Anwendungsfall abgeschlossen ist. Am wichtigsten ist, dass sie angeben, welche neuen Objekte der Anwendungsfall erstellt oder aktualisiert und wie die Objekte verknüpft werden müssen.
Aktivitätsfluss
Aktivitätsablauf einschließlich Teilnehmer (Benutzer) und System
ungewöhnliche Situation
Der Aktivitätsfluss für jeden Anwendungsfall kann sehr unterschiedlich sein, abhängig vom Akteur, der den Anwendungsfall aufruft. Die verschiedenen Aktivitätsflüsse werden als Szenarien, auch als Anwendungsfallinstanzen bezeichnet, bezeichnet
5.3 Anwendungsfall-Aktivitätsdiagramm
Eine Möglichkeit, Anwendungsfälle aufzuzeichnen, ist die Verwendung von Aktivitätsdiagrammen. In Kapitel 2 haben wir gelernt, Aktivitätsdiagramme zum Erstellen von Arbeitsabläufen zu verwenden. Wir werden hier Aktivitätsdiagramme verwenden, um den Aktivitätsfluss von Anwendungsfällen aufzuzeichnen.
Beispiel
Dieses Aktivitätsdiagramm zeigt den Aktivitätsfluss der Kundenregistrierungs-Anwendungsfallregistrierung.
5.4 Systemsequenzdiagramm SSD
Das Systemsequenzdiagramm wird verwendet, um den Informationsfluss in und aus einem Automatisierungssystem zu beschreiben
Verwenden Sie menschliche Symbole, um Anwendungsfallakteure darzustellen, und rechteckige Rahmen, um Automatisierungsgrenzen darzustellen
Das Rechteck ist mit „System“ (mit Doppelpunkt) gekennzeichnet und weist auf das automatisierte System hin
Unterhalb der Teilnehmer und des Systems befindet sich eine gepunktete Linie, die sogenannte Lebenslinie, die den Lebenszyklus der Teilnehmer und des Systems darstellt, und die Zeit fließt von oben nach unten.
Es erfolgt das Senden und Empfangen von Nachrichten zwischen Teilnehmern und der Lebensader des Systems
Das Versenden von Nachrichten wird durch eine durchgezogene Linie dargestellt, mit der Richtung vom Teilnehmer zum System
Empfangene Nachrichten werden durch gestrichelte Linien mit der Richtung vom System zum Teilnehmer dargestellt
Vollständige symbolische Darstellung der Nachricht
(*)[True/False-Bedingung]Rückgabewert:=Nachrichtenname (Parameterliste)
* zeigt eine Schleife an
[] stellt die wahren und falschen Bedingungen dar. Wenn das Innere wahr ist, wird die Nachricht gesendet, andernfalls wird sie nicht gesendet.
Der Nachrichtenname ist eine Beschreibung der gesendeten Nachricht
Die Parameterliste ist die zu übergebende Information
Darüber hinaus gibt es einige alternative Frameworks
Schleife ändern
Wenn mehrere Nachrichten in einer Schleife gesendet und empfangen werden, ist es möglicherweise besser, ein alternatives Framework zu verwenden.
Der alternative Rahmen besteht darin, einen rechteckigen Rahmen zu verwenden, um den Teil auszuwählen, der geloopt werden soll, und in der oberen linken Ecke eine Schleife für alle Elemente auszudrücken
Wählen Sie „Ändern“.
Der alternative Rahmen von „select“ wird zusammen mit „else“ verwendet. Verwenden Sie einen rechteckigen Rahmen, um den Auswahlbereich auszuwählen, der unter verschiedenen Umständen gesendet wird, und markieren Sie sie entsprechend im letzten Teil der gesendeten Nachricht.
5.4.2 SSD entwickeln
1. Bestätigen Sie die Eingabemeldung
2. Verwenden Sie Nachrichtensymbole, um Informationen zu beschreiben, die von außen an das System weitergeleitet werden
3. Fügen Sie der Eingabenachricht bestimmte Bedingungen hinzu, einschließlich Schleifen und Wahr/Falsch-Bedingungen
4. Bestätigen Sie und fügen Sie eine Antwortnachricht hinzu
5.5 Zustandsmaschinendiagramm Zustandsmaschinendiagramm
Der Zustand eines Objekts ist ein Zustand, der während seiner Lebensdauer auftritt, wenn bestimmte Bedingungen erfüllt sind, bestimmte Aktionen ausgeführt werden oder auf ein Ereignis gewartet wird.
Beim Zustandsübergang handelt es sich um die Aktivität eines Objekts, das sich von einem Zustand in einen anderen bewegt.
Zustandsübergangsfunktion
Konvertierungsname (Parameter,...) [Beurteilungsbedingung]/Verhaltensbeschreibung
Ein Aktionsausdruck stellt einen Prozess dar, der stattfinden muss, bevor der Übergang abgeschlossen ist und das Objekt den Zielzustand erreicht.
Eine Bedingung ist ein Qualifikationsmerkmal oder Test für einen Übergang. Es handelt sich lediglich um eine Wahr/Falsch-Bedingung, die erfüllt sein muss, bevor der Übergang ausgelöst werden kann.
5.5.1 Zusammengesetzter Zustand und gleichzeitiger Zustand
Der gleichzeitige Zustand in mehreren Zuständen wird als Parallelität oder gleichzeitige Zustände bezeichnet.
Ein Pfad wird durch gleichzeitige Pfade ähnlich wie Aktivitätsdiagramme dargestellt und ist eine geordnete Menge miteinander verbundener Zustandsübergänge.
Verschachteln Sie Staaten innerhalb anderer übergeordneter Staaten. Diese übergeordneten Zustände werden zusammengesetzte Zustände genannt.
Der zusammengesetzte Zustand wird durch einen Zustand auf hoher Ebene dargestellt, der in einem Zustand auf niedrigerer Ebene verschachtelt ist
Beispiel
Wenn der Drucker eingeschaltet ist (zusammengesetzter Zustand), verfügt er über zwei gleichzeitige Pfade, nämlich den Papierfachteil und den Druckteil. Die beiden Teile sind unabhängig, wenn die Ein-Taste gedrückt wird, und wenn die Aus-Taste gedrückt wird gedrückt wird, schaltet es sich aus. Es gibt keine Einschränkungen.
5.5.2 Regeln für die Entwicklung von Zustandsmaschinendiagrammen
Sehen Sie sich das Klassendiagramm an und wählen Sie die Klassen aus, die möglicherweise einen Status erfordern
Listen Sie für jede ausgewählte Klasse in der Gruppe alle Statusbedingungen auf, die Sie bestimmen können
Beginnt mit der Erstellung eines Zustandsautomatendiagrammfragments, indem die Übergänge identifiziert werden, die dazu führen, dass ein Objekt den identifizierten Zustand verlässt
Ordnen Sie diese Zustandsübergangskombinationen in der richtigen Reihenfolge an
Überprüfen Sie diese Pfade und suchen Sie nach unabhängigen gleichzeitigen Pfaden
Finden Sie andere Konvertierungen
Erweitern Sie jeden Übergang mit entsprechenden Nachrichtenereignissen, Schutzbedingungen und Aktionsausdrücken
Überprüfen und testen Sie jedes Zustandsmaschinendiagramm
5.6 Integration von Nachfragemodellen
Die Beziehung zwischen verschiedenen Nachfragemodellen
Anwendungsfalldiagramm
Beschreibung des Anwendungsfalls
Aktivitätsdiagramm
SSD
Klassendiagramm des Domänenmodells
Zustandsmaschinendiagramm
Die Beziehung wird durch die folgende Abbildung beschrieben
Der Pfeil zeigt in die Richtung vom abhängigen Element zum abhängigen Element
Durchgezogene Linien stellen primäre Abhängigkeiten dar, gepunktete Linien stellen sekundäre Abhängigkeiten dar und einige Pfeile sind bidirektional und weisen auf gegenseitige Beeinflussung hin.
Kap06 Grundpunkte von Design und Designaktivitäten
6.1 Einführung
In der Analysephase werden wir hauptsächlich diskutieren, was das System tut (z. B. Anforderungen); während wir in der Entwurfsphase hauptsächlich diskutieren, wie das System diese Anforderungen erfüllt.
Der Input und Output des Systemdesigns ist nicht der Input und Output des Systems: Der Input des Systemdesigns ist das Ergebnis der Systemanalyse, also der Anforderungen und zugehörigen Modelle, während der Output des Systemdesigns eine detailliertere Lösung ist
6.2 Designelemente
6.2.1 Was ist Systemdesign?
Systemdesign ist ein Brückenprozess zwischen Systemanalyse und -implementierung mit dem Ziel, die Komponenten der endgültigen Lösung als Blaupause für die Konstruktion zu definieren, zu organisieren und zu erstellen
6.2.2 Hauptkomponenten und Designebenen
Hauptbestandteile
Umweltgestaltung
Beschreibt die Netzwerke, Hardware usw., die das System miteinander verbinden
Anwendungsdesign
Computer Programm
UI-Design
Definierte Bildschirme, Berichte und Steuerungen für Ein- und Ausgabe
Datenbank Design
Datenbankstruktur
Systemschnittstellendesign
Beschreibt die Kommunikation mit anderen Systemen
Sicherheits- und Kontrolldesign
zwei Ebenen
Architektur-Design
Klären Sie den gesamten Rahmen und die Form der Lösung, d. h. die umfassende Gestaltung der Gesamtstruktur des Systems
Wird auch Gesamtentwurf oder Konzeptentwurf genannt
Detailliertes Design
Enthält spezifische Programmierdetails
Beispiel
Design pro Anwendungsfall
Datenbank Design
Design von Benutzeroberfläche und Systemschnittstelle
Sicherheits- und Kontrolldesign
6.3 Input und Output des Systemdesigns
Konvertieren Sie Informationen wie Analysemodelle und Dokumente aus der Systemanalyse in ein Modell, das das Lösungssystem darstellt
Analytisches Modell
Klassen Diagramm
Anwendungsfalldiagramm UCD
Systemsequenzdiagramm SSD
Beschreibung des Anwendungsfalls
Zustandsmaschinendiagramm
Aktivitätsdiagramm
Designmodell
Paketkarte
Knoten- und Standortdiagramm
Design-Klassendiagramm
Flussdiagramm
Datenbankschema
Benutzer- und Systemschnittstelle
Systemsicherheitskontrolle
Kollaborationsdiagramm
6.4 Designaktivitäten
Designaktivitäten sind das Design der oben genannten sechs Komponenten. Jede Designaktivität hat entsprechende Schlüsselthemen.
Umweltgestaltung
Haben wir die Umgebung, in der die Software ausgeführt wird, und alle verschiedenen Optionen detailliert beschrieben?
Anwendungsarchitektur und Softwaredesign
Haben wir alle Elemente der Software detailliert beschrieben und wie jeder Anwendungsfall durchgeführt wird?
UI-Design
Haben wir detailliert beschrieben, wie dieses System mit allen anderen Systemen innerhalb und außerhalb der Organisation kommuniziert?
Design der Systemschnittstelle
Haben wir detailliert beschrieben, wie Benutzer mit dem System interagieren, um alle ihre Aufgaben auszuführen [Anwendungsfälle]?
Datenbank Design
Haben wir alle Anforderungen an die Informationsspeicherung, einschließlich aller Schemaelemente, spezifiziert?
Sicherheits- und Kontrolldesign
Haben wir alle erforderlichen Elemente detailliert beschrieben, um sicherzustellen, dass Systeme und Daten sicher und geschützt sind?
6.4.1 Designumgebung
Die Umgebung umfasst die gesamte Technologie, die zur Unterstützung einer Softwareanwendung erforderlich ist
Server, Desktop-Computer
mobile Geräte, Betriebssysteme
Kommunikationsfähigkeit, Input- und Outputfähigkeit
Wir haben es in Kapitel 2 technische Architektur genannt
6.4.2 Anwendungsarchitektur und Software entwerfen
Teilen Sie das System in Subsysteme auf
Softwarearchitektur definieren (Architekturdesign)
Dreistufige MVC-Architektur usw.
Detailliertes Design jedes Anwendungsfalls
Design-Klassendiagramm
Flussdiagramm
Zustandsmaschinendiagramm
6.4.3 Benutzeroberfläche gestalten
Dialogdesign beginnt bei den Anforderungen
Das Design fügt Bildschirmlayout, Erscheinungsbild, Navigation und Benutzererfahrung hinzu
Entwerfen Sie unterschiedliche Schnittstellen für unterschiedliche Geräte
6.4.4 Systemschnittstelle entwerfen
Informationssysteme interagieren mit vielen anderen internen und externen Systemen
Systemschnittstellen stellen auf vielfältige Weise Verbindungen zu anderen Systemen her
6.4.5 Designdatenbank
Beginnen Sie mit einem Domain Model Class Diagram (oder ERD)
Datenbankstruktur auswählen
Designarchitektur (verteilt usw.)
Entwerfen Sie ein Datenbankschema
Tabelle, Attributspalte
Integritätsbeschränkungen für Entwurfsreferenzen
6.4.6 Designsicherheit und Systemkontrollen
Der Zweck besteht darin, die Vermögenswerte einer Organisation zu schützen, die in der Welt des Internets und der drahtlosen Kommunikation von entscheidender Bedeutung sind
Steuerelemente der Benutzeroberfläche
Anwendungssteuerung
Datenbanksteuerung
Netzwerksteuerung
6.5 So gestalten Sie die Umgebung
Entwerfen Sie vor Ort
Es gibt zwei Arten von On-Premise-Softwaresystemen
Eigenständiges Softwaresystem
Von einem Gerät ohne Netzwerk ausführen
Webbasiertes internes System
Hardware-Bereitstellung: LAN
Client-Server-Architektur
Desktop-Anwendungssystem (Client-Server)
Browserbasiertes Anwendungssystem (Browser-Server)
Verwenden Sie Hypertext Markup Language als Seite
Verwenden Sie das TCP/IP-Protokoll als Transportprotokoll
Dreistufige Client/Server-Architektur
Eine effektive Möglichkeit, Software zu entwerfen, besteht darin, die Benutzeroberfläche und die Geschäftslogikschicht sowie die Geschäftslogikschicht und die Datenzugriffsschicht zu trennen. Diese Methode zum Entwerfen von Programmen wird als dreistufige Architektur bezeichnet. Die Grundidee besteht darin, die Software in drei Schichten zu unterteilen
Ansichtsebene: Verantwortlich für den Empfang von Benutzereingaben und deren Verarbeitung in eine formatierte Ausgabe
Logische Schicht/Domänenschicht Domänenschicht: Verantwortlich für die Regeln und Verfahren, die Geschäfts- oder Verarbeitungsprozesse implementieren
Datenschicht: Verantwortlich für die Verwaltung gespeicherter Daten, die normalerweise in einer oder mehreren Datenbanken vorhanden sind
Mehrere Schichten können auf einem einzelnen Computer ausgeführt werden, oder jede Schicht kann von einem separaten Computer betrieben werden. Komplexe Schichten können auf zwei oder drei Schichten verteilt werden, indem die Funktionalität der Schicht auf mehrere redundante Computer implementiert wird
Eine weitere Designidee ist MVC, also Model-View-Controller
Entwerfen Sie die externe Bereitstellung
Wichtige Fragen sind u.a
Konfiguration für die Internetbereitstellung
Der Datenschutz wird mithilfe von Hypertext Transfer Protocol Security (HTTPS) implementiert. Die vom HTTPS-Protokoll bereitgestellten Webseiten werden in verschlüsselter Form übertragen, was sicherer als HTTP ist.
Nutzen Sie mehrstufige Serverstrukturen sowie Lastausgleichs- und Content-Delivery-Netzwerke (CDNs), um die Leistung zu steigern
Die mehrschichtige Serverstruktur umfasst Anwendungsserver und Datenbankserver
Anfragen werden über Lastausgleichscomputer an verschiedene Rechenzentrumsserver gesendet
Wenn Sie auf einige statische Bilder oder Videos zugreifen, können Sie diese über ein unabhängiges CDN senden
Hosting-Optionen für Internetbereitstellungen
Veranstaltungsortvermietung
Bereitstellung eines sicheren Rechenzentrums für Kunden zur Platzierung von Servercomputern. Der Vorteil besteht darin, dass keine physischen, sicheren und komplexen Rechenzentrumskosten anfallen.
Verwaltete Dienste
Bietet zusätzliche Dienstleistungen, einschließlich der Verwaltung von Betriebssystemen, Netzwerkservern, Datenbankservern usw. Der Vorteil besteht darin, dass keine Mitarbeiter für die Verwaltung von Serversystemen und Systemsoftware eingestellt werden müssen.
virtueller Server
Kunden können virtuelle Server mieten, die eine feste Größe haben
Cloud Computing
Kunden müssen nur die Rechenkapazität kaufen, die sie benötigen und nutzen. Wenn die Rechenkapazität wächst, stellt die Cloud automatisch mehr Kapazität bereit. Durch diese Vereinbarung können Kosten gespart werden, da keine unnötige Kapazität gekauft werden muss
Für alle Alternativen gibt es ein Service Level Agreement (Service Level Agreement), das Bestandteil des Vertrags zwischen dem Unternehmen und dem Hosting-Unternehmen ist, um eine bestimmte Systemverfügbarkeit zu gewährleisten.
Vielfalt der für das Internet eingesetzten Kundengeräte
Computer
Mittelgroßes Tablet-Gerät
kleines mobiles Gerät
Design für entfernte und verteilte Umgebungen
Remote-Bereitstellung über ein virtuelles privates Netzwerk (VPN)
Ein VPN ist ein Netzwerk, das auf einem öffentlichen Netzwerk wie dem Internet aufbaut. Es bietet ein sicheres und verbindbares Netzwerk für private Gruppen
Kap07 Benutzeroberfläche und Systemschnittstelle entwerfen
7.2 Benutzeroberfläche und Systemschnittstelle
Die Benutzeroberfläche enthält Eingaben und Ausgaben, die einen direkten Benutzereingriff erfordern.
Die Systemschnittstelle erfordert nur minimale manuelle Eingabe und Ausgabe
7.3 Die Benutzeroberfläche verstehen
Die Benutzeroberfläche besteht aus drei Komponenten
Physikalische Bedeutung: Bürotische und -stühle, Lampen, Tastaturen, Mäuse, Touchscreens
Wahrgenommene Bedeutung: Farben, Formen, Texturen, Schriftarten, Fenster, Menüs, Schaltflächen
Konzeptionelle Bedeutung: Kunde, Teilnehmer, Auftrag, Transport, Feedback
Die Designperspektive der Benutzeroberfläche ist benutzerzentriert und betont die Interaktion zwischen Mensch und Computer (Mensch-Computer-Interaktion).
Die Mensch-Computer-Interaktion ist ein Bereich, der die Effizienz und Effektivität der Benutzerinteraktion mit Computersystemen, menschenorientierte Ein- und Ausgabetechniken sowie die psychologischen Aspekte von Benutzeroberflächen untersucht
Drei Grundprinzipien des benutzerzentrierten Designs
Konzentrieren Sie sich frühzeitig auf die Benutzer und ihre Arbeit
Bewerten Sie das System, um seine Benutzerfreundlichkeit sicherzustellen
Nutzen Sie iterative Entwicklung
Metaphern für die Mensch-Computer-Interaktion
Metaphern sind Analogien zwischen Funktionen der Benutzeroberfläche und physischen Einheiten, die den Benutzern vertraut sind
Metaphern werden beim Design von Benutzeroberflächen häufig in den folgenden Situationen verwendet:
direkte Manipulation
Manipulieren Sie physische Objekte direkt auf dem Display oder Objekte, die sie darstellen
Beispiel: Der Benutzer zieht einen Ordner in den Papierkorb
Desktop-Metapher
Organisieren Sie die visuelle Anzeige in verschiedene Bereiche, mit einem großen leeren Arbeitsbereich in der Mitte, der von einer Reihe von Werkzeugsymbolen umgeben ist
Beispiel: Windows-Desktop
Dokumentmetapher
Zeigen Sie Daten wie eine Seite oder eine Tabelle an
Beispiel: Benutzeranweisungsdokument usw.
Konversationsmetapher
Benutzer und Computer erledigen Aufgaben, indem sie mithilfe von Text, Sprache oder anderen Tools kommunizieren oder einen Dialog führen
Beispiel: cmd-Fenster
Die ersten drei betonen die Objekte, die mit dem Benutzer interagieren, und die Konversationsmetapher betont die Kommunikation, die zwischen dem Benutzer und dem Computer stattfindet
7.4 Designkonzepte für Benutzeroberflächen
7.4.1 Schnelligkeit und Sichtbarkeit
Indikativ bezieht sich auf das Erscheinungsbild eines Steuerelements, das seine Leistung widerspiegelt
Sichtbarkeit bedeutet, dass das Steuerelement sichtbar ist
7.4.2 Konsistenz
7.4.3 Verknüpfungen
7.4.4 Feedback
7.4.5 Vollständiger Dialog
7.4.6 Fehlerbehandlung
7.4.7 Aktion rückgängig machen
7.4.8 Reduzieren Sie die Belastung des Kurzzeitgedächtnisses
7.5 Von der Analyse bis zum User Interface Design
7.5.1 Anwendungsfälle und Menühierarchie
Menüs sind eine Möglichkeit, eine große Anzahl verwandter Anwendungsfälle oder Konversationen in einer Benutzeroberfläche zu organisieren
Der Designer sollte die Menühierarchie basierend auf der Anzahl der Anwendungsfälle abschätzen
Eine Menüebene enthält normalerweise 5-10 Optionen
7.5.2 Dialoge und Storyboards
Sie müssen die Gespräche aufzeichnen, die Benutzer benötigen
Storyboard: Zeigen Sie diese Reihe von Bildschirmskizzen im Gespräch an
7.6 Design der Benutzeroberfläche
7.6.1 Richtlinien für die Gestaltung von Formularen und Tabellen
Schnittstellenlayout und Formatierung
Konsistenz, Beschriftungen und Titel, Verteilung und Reihenfolge, Schriftarten und Farben
Dateneingabe
Textfeld, Listenfeld, Kombinationsfeld, Optionsfeld, Kontrollkästchen
Anleitung und Unterstützungskontrolle
Minimieren, maximieren, schließen, Bildlaufleisten, Größe ändern
7.6.2 Zusätzliche Richtlinien für Browseroberflächen
Konsistenz
Cascading Style Sheets (CSS) – Ein Webseiten-Codierungsstandard, der es Website-Designern ermöglicht, Teile einer Seite anzugeben, die immer gleich aussehen, und Teile, die je nach Aufgabe oder Zielgruppe variieren.
Leistungsüberlegungen
Empfindlich gegenüber Netzwerkverbindungen, übertragener Informationsmenge und Art der übertragenen Informationen
Bilder, Videos und Töne
Es wird Kompatibilitätsprobleme geben
Besondere Benutzer (Behinderung)
Assistive Technologie – Software, die Benutzeroberflächen an die besonderen Bedürfnisse von Menschen mit Behinderungen anpasst (z. B. Text-to-Speech- und Spracherkennungstools)
7.6.3 Zusätzliche Richtlinien für mobile Geräteschnittstellen
Herausforderungen beim Design der Benutzeroberfläche für mobile Geräte
Kleine Bildschirme, Tastaturen und Touchscreens, begrenzte Netzwerkkapazität, Richtlinien und Toolkits für das Anwendungsdesign
7.7 Systemschnittstelle festlegen
Systemschnittstellen werden im weitesten Sinne als Ein- und Ausgänge definiert, die keinen oder nur einen geringen Benutzereingriff erfordern.
Unterteilt in die folgenden Kategorien
Eingabe und Ausgabe von anderen Systemen
XML (Extensible Markup Language) kann für den elektronischen Datenaustausch und die Kommunikation zwischen Systemen verwendet werden.
XML implementiert im Vergleich zu HTML die Einbettung benutzerdefinierter Datenstrukturen
Hochautomatisierte Ein- und Ausgabe
Ein- und Ausgabe aus externen Datenbanken
7.8 Design-Systemeingabe
7.8.1 Automatisierte Eingabegeräte
Der Hauptzweck jeder Dateneingabe besteht darin, dem System fehlerfreie Daten bereitzustellen oder zu aktualisieren. Das Wichtigste ist, Fehler so weit wie möglich zu vermeiden. Es gibt mehrere Möglichkeiten, Fehler effektiv zu vermeiden.
Verwenden Sie automatisierte Eingabegeräte
Vermeiden Sie menschliches Eingreifen so weit wie möglich
Wenn die Eingabeinformationen aus einer Tabellenkalkulation abgerufen werden können, verwenden Sie die Tabellenkalkulation, ohne die Daten erneut einzugeben
Daten überprüfen und korrigieren
7.8.2 Systemeingabedetails definieren
7.9 Systemausgabe entwerfen
Entwerfen Sie Berichte, Abrechnungen und Rücksendedokumente
Art des Berichts
Detaillierter Bericht: Enthält detaillierte Informationen zum Geschäftsprozess
Zusammenfassender Bericht: Diese Art von Bericht wird verwendet, um phasenweise Aktivitäten zusammenzufassen.
Abnormaler Bericht: Wird generiert, wenn die Transaktions- oder Vorgangsergebnisse abnormal sind.
Executive Reporting: Bewerten Sie den allgemeinen Gesundheitszustand und den Betrieb
Die interne Ausgabe wird für den internen Gebrauch der Organisation oder Einheit erstellt. Die zuvor besprochenen Berichte gehören zur internen Ausgabe, die für die Verwendung durch externe Mitglieder der Organisation erstellt wird, z. B. Auftragsbestätigungsinformationen, monatliche Abrechnungen usw. Denn es handelt sich um ein offizielles Geschäftsdokument, das für Außenstehende erstellt wurde und eine höhere Qualität erfordert
Es gibt eine Art externer Ausgabe, die als Rücksendedokument bezeichnet wird. Die Ausgabe, die dem Benutzer bereitgestellt wird, besteht aus einem Teil, der abgerissen und später als Eingabe für das System verwendet werden kann, z. B. einer Rechnung mit einem Zahlungsbeleg, der zusammen mit dem zurückgegeben wird überprüfen.
elektronische Kontoauszüge
Grafik- und Multimedia-Präsentation
Kapitel 08 Systementwicklungsmethode
8.2 Lebenszyklus der Systementwicklung
8.2.1 Traditionelle Vorhersagemethoden für den Lebenszyklus der Systementwicklung
Die Prognosemethode ist eine Methode, mit der Organisationsentwicklungsprojekte im Voraus geplant und neue Informationssysteme gemäß dem Plan entwickelt werden können.
Anforderungen: Es wird davon ausgegangen, dass das Projekt im Voraus geplant werden kann, das Informationssystem gemäß dem Plan entwickelt werden kann, die Anforderungen gut verstanden sind und das technische Risiko gering ist
Wasserfall-Modell
In einem Projekt verlaufen die sechs Phasen des Lebenszyklus von einer Phase zur nächsten, und die Phasen sind sequentiell.
Im traditionellen Wasserfallmodell gibt es keine Überschneidungen und Iterationen zwischen den verschiedenen SDLC-Stufen
Das Modell auf der relativ rechten Seite der Skala ist das verbesserte Wasserfallmodell
Das verbesserte Wasserfallmodell behält immer noch die vorhergesagte Abfolge der Entwicklungsphasen bei, diese Phasen überschneiden sich jedoch, beeinflussen sich gegenseitig und hängen voneinander ab.
Größere Flexibilität, setzt jedoch weiterhin vorausschauende Planung und sequentielle Phasen voraus
8.2.2 Adaptiver Ansatz für den Lebenszyklus der Systementwicklung
Anpassungsmodelle können für die Entwicklung verwendet werden, wenn Anforderungen (Anforderungen) unklar sind und oft mehrere Iterationen umfassen.
Projekte müssen flexibler sein und sich während des Entwicklungsprozesses an sich ändernde Bedürfnisse anpassen; die Nachfrage ist ungewiss und die technischen Risiken sind hoch
Spiralmodell
Relativ weit vom rechten Ende der Skala entfernt
Verwenden Sie zur Beschreibung von SDLC eine Spirale, die in der Mitte beginnt und sich immer wieder nach außen ausdehnt, bis das Projekt abgeschlossen ist.
Mehr als einmal pro Etappe
iteratives Modell
Ähnlich wie bei der Entwicklungsmethode in Kapitel 1 sind die Zeilen der Tabelle Entwicklungsaktivitäten und die Spalten Iterationen.
Jede Iteration enthält mehrere Phasen, und jede Phase wird nicht auf einmal abgeschlossen, sondern in nachfolgenden Iterationen kontinuierlich verbessert.
Zusätzliche Konzepte zu adaptiven Ansätzen
schrittweise Entwicklung
Das Grundkonzept besteht darin, dass Systeme in kleinen Schritten aufgebaut werden und organisch wachsen
Während des Projekts wird das System schrittweise implementiert und teilweise bereitgestellt
Der Vorteil besteht darin, dass Benutzer schnell einen Teil des Systems erhalten können, sodass das Geschäft schnellstmöglich gestartet werden kann.
wandelndes Skelett
Ein früher Ansatz zum Aufbau einer vollständigen Systemstruktur, der jedoch nur grundlegende Funktionen bereitstellt
Stellen Sie zunächst ein „Skelett“ des gesamten Implementierungsprozesses des neuen Systems von vorne bis hinten bereit und füllen Sie dann das Skelett mit nachfolgenden Iterationen aus.
In Projekten ist es oft keine extreme Wahl
8.3 Supportphase
Der prädiktive Ansatz SDLC beinhaltet eine solche Supportphase
Der adaptive Ansatz behandelt die Supportphase als vollständiges, in sich geschlossenes Projekt
Während der Supportphase finden drei Hauptaktivitäten statt
Wartungssystem
Stärken Sie das System
Unterstützen Sie Benutzer
8.4 Methoden, Modelle, Werkzeuge und Techniken
Systementwicklungsmethoden
Der Umfang der Methode ist der größte
Eine Methodik umfasst eine Reihe von Techniken zur Durchführung von Aktivitäten und Aufgaben, einschließlich der Modellierung aller Aspekte eines Projekts
Modell
Ein Modell ist eine abstrakte Darstellung eines bestimmten Aspekts der realen Welt, die es ermöglicht, ein komplexes Konzept zu verstehen, indem man sich nur auf die relevanten Teile konzentriert
Jedes Modell betont unterschiedliche Informationen
Mit einigen dieser Modelle sind wir bereits in Berührung gekommen: ER-Diagramm, Use-Case-Diagramm, Klassendiagramm, Sequenzdiagramm
Werkzeug
Software-Unterstützung
Technologie
durch Lernen erworben
8.5 Zwei Methoden der Softwarekonstruktion und -modellierung
8.5.1 Strukturiertes Vorgehen
Die strukturierte Methode konzentriert sich auf den Prozess und konzentriert sich auf den Datenfluss. Sie geht davon aus, dass das System eine Sammlung von Prozessen ist, die mit dem Datenfluss interagieren.
Die strukturierte Methode ist dieselbe traditionelle Methode wie die SDLC-Vorhersagemethode.
Strukturierte Analyse
Modellierung mithilfe eines Datenflussdiagramms
Es werden auch ER-Diagramme verwendet
strukturiertes Design
Entwerfen Sie Programme mithilfe von Strukturdiagrammen
Erfordert geringe Kopplung und hohe Kohäsion
Geringe Kopplung bedeutet, dass verschiedene Module so unabhängig wie möglich von anderen Modulen sind, sodass die Änderung eines Moduls den Betrieb anderer Module nicht beeinträchtigt.
Hoher Zusammenhalt bedeutet, dass jedes Modul eine klare Aufgabe umsetzt
Strukturierte Programmierung
Enthält einen Anfang, ein Ende und drei Strukturen: Sequenz, Auswahl, Zyklus
Top-Down-Programmierung/modulares Design
8.5.2 Objektorientierter Ansatz
Der objektorientierte Ansatz betrachtet ein System als eine Sammlung von Objekten, die zusammenarbeiten, um eine bestimmte Interaktion zu erreichen.
Objekte sind Dinge im System, die auf Nachrichten reagieren
objektorientierte Analyse
Der Prozess der Identifizierung und Definition von Anwendungsfällen und Objektsätzen (Klassen) in einem neuen System
Objektorientiertes Design
Definieren Sie alle Arten von Objekten, die für die Kommunikation mit Personen und Geräten erforderlich sind, und zeigen Sie, wie sie zur Erledigung von Aufgaben interagieren
Verwenden Sie Modelle wie Klassendiagramme und Anwendungsfalldiagramme
Objekt orientierte Programmierung
Schreiben Sie Anweisungen, um die tatsächliche Klasse und die Rolle jedes Objekts der Klasse zu definieren
Verwenden Sie Modelle wie Sequenzdiagramme und Designklassendiagramme
8.6 Agile Entwicklung
Entwicklungsaktivitäten werden in einer unbekannten und sich schnell verändernden Umgebung durchgeführt
8.6.1 Theorie und Wert der agilen Entwicklung
Kerntheorie
Konzentrieren Sie sich darauf, auf Veränderungen zu reagieren, anstatt einem Plan zu folgen
Schätzen Sie Einzelpersonen und Interaktionen statt Prozesse und Werkzeuge
Wert auf funktionierende Software legen gegenüber umfassender Dokumentation
Konzentrieren Sie sich auf die Zusammenarbeit mit dem Kunden statt auf Vertragsverhandlungen
Beschreiben Sie das Konzept agiler Projekte: Chaos
Das ist Chaos und Ordnung: Die ersten beiden Kerntheorien – die Dominanz individueller Werte über Gruppenwerte – sind die Ursache für Chaos, und dieses Chaos kann mit zunehmender Flexibilität bewältigt werden. Während des unvorhersehbaren Entwicklungsprozesses ist Chaos unvermeidlich. Entwickler müssen das Chaos akzeptieren, aber manchmal ist es notwendig, andere Methoden und Techniken zu verwenden, die dem Projekt Ordnung und Struktur verleihen.
Einfach ausgedrückt bedeutet es, ein gewisses Maß an Chaos zuzulassen und gleichzeitig für Ordnung zu sorgen.
Kap09 Projektplanung und Projektmanagement
Dies sind die ersten beiden der sechs Kernabschnitte: Identifizieren des Problems und Einholen der Genehmigung, Planen und Überwachen des Projekts
9.2 Grundsätze des Projektmanagements
9.2.1 Anforderungen an das Projektmanagement
Laut Statistik sind weniger als ein Drittel der Projekte erfolgreich
Gründe, warum manche Projekte scheitern
Hauptgrund: Mangelnde Einbindung des oberen Managements und mangelnde Managementfähigkeiten
Mangelnde Beteiligung der Benutzergruppe
9.2.2 Die Rolle des Projektmanagers
Projektmanagement ist der Prozess der Organisation und Anleitung anderer, um geplante Ergebnisse gemäß einem zuvor festgelegten Zeitplan und Budget zu erreichen. Es kann auch als der Prozess der Planung und anschließenden Überwachung und Steuerung eines Projekts definiert werden.
Interne Verantwortlichkeiten des Projektmanagers
Projektplan entwickeln
Rekrutieren und schulen Sie Teammitglieder
Koordinieren Sie die Arbeit zwischen den Teammitgliedern
Bewerten Sie Projektrisiken
Überwachen und steuern Sie Projektmeilensteine
Verwalten Sie Menschen und Ressourcen
Externe Verantwortlichkeiten des Projektmanagers
Projektstatus und -fortschritt melden
Arbeiten Sie direkt mit Kunden und anderen Stakeholdern zusammen
Ermitteln Sie den Ressourcenbedarf und beschaffen Sie Ressourcen
Koordinieren Sie die Öffentlichkeitsarbeit
Projektmanager arbeiten mit unterschiedlichen Personengruppen
Kunde: Die Person, die das System finanziert
Aufsichtsausschuss: Besteht aus dem Kunden und anderen leitenden Managern, die das Projekt überwachen
Benutzer: Eine Person, die das System direkt nutzt, um Aufgaben zu erledigen
Projektmanager haben eine doppelte interne und externe Funktion
9.2.3 Projektmanagement und Zeremonie (Zeremonie)
Der Grad der Formalität eines Projekts oder Rituals hat auch Auswirkungen auf das Projektmanagement
Kleinere Projekte führen oft Rituale der unteren Preisklasse durch
Bei größeren und komplexeren Projekten werden oft hochkarätige Zeremonien durchgeführt
Projektrituale unterscheiden sich bei der Verwendung traditioneller prädiktiver Methoden gegenüber adaptiven Methoden
Adaptive Projekte können in ihren Managementmethoden oft formeller oder informeller sein: UP (Unified Process) ist recht formell und hat strenge Rituale, während iterative Methoden eher informell sind
9.2.4 Projektmanagement-Wissenssystem
PMBOK besteht aus neun Modulen
Management im Projektmaßstab
Projektzeitmanagement
Projektkostenmanagement
Projektqualitätsmanagement
Projekt Personalmanagement
Projektkommunikationsmanagement
Projektrisikomanagement
Projektbeschaffungsmanagement
Projekt Integrationsmanagement
9.2.5 Agiles Projektmanagement
Agiles Projektmanagement
Der Umfang ist nicht genau bekannt, muss aber kontrolliert werden
Verwenden Sie mehrere Richtlinien, um Geschäftsprioritäten festzulegen
Agiles Zeitmanagement
Der Zeitplan muss flexibel sein, um Änderungen berücksichtigen zu können
Agiles Kostenmanagement
Da die Kosten schwieriger abzuschätzen sind, ist die Kostenkontrolle nicht so wichtig wie bei einem prädiktiven Ansatz
Agiles Risikomanagement
Hochriskante Aspekte des Projekts werden zuerst abgeschlossen
Agiles Qualitätsmanagement
Führen Sie nach jeder Iteration eine Qualitätsbewertung durch
9.3 Kernprozess 1: Identifizieren Sie das Problem und holen Sie die Genehmigung ein
9.3.1 Identifizieren Sie das Problem
Drei Hauptziele für die Entwicklung neuer Systeme
Reagieren Sie auf neue Entwicklungsmöglichkeiten
Marktanteile besetzen
Bestehende Geschäftsprobleme lösen
Reagieren Sie auf externe Befehle
Recht, Steuern usw.
Eine effektive Möglichkeit, das Problem zu definieren, ist die Erstellung eines System Vision Documents (SVD).
Enthält drei Teile
Problembeschreibung
Was sind die Probleme und Lösungen?
Systemfunktionen
Welche Funktionen wird das neue System haben?
Geschäftsvorteile
Vorteile für die Organisation (materiell oder immateriell)
9.3.2 Projektgenehmigungsfaktoren quantifizieren
Muss klar sein
Geschätzte Fertigstellungszeit
Geschätzte Entwicklungskosten
Geschätzte laufende Kosten
Vorläufiges Ergebnis
Kosten-Nutzen-Analyse
einige Konzepte
NPV (Net Present Value) Nettobarwert
Der Barwert der Vorteile und Kosten einer bestimmten Investition
Berechnet durch Subtrahieren der Kosten unter Verwendung des „Jetzt-Ertrags“ (unter Verwendung eines Abzinsungsfaktors)
Kostendeckungspunkt
In diesem Zeitraum gleichen Dollargewinne die Dollarkosten aus
greifbare Vorteile
Der Teil des Nutzens, der in Geld gemessen werden kann
immaterielle Vorteile
Vorteile für die Organisation, die jedoch nicht quantitativ gemessen oder genau geschätzt werden können
Verbesserungen des Serviceniveaus (auf eine Weise, die nicht in Dollar gemessen werden kann)
Verbesserte Kundenzufriedenheit (nicht in Dollar messbar)
Überleben – man muss so konkurrieren
Notwendigkeit, internes Fachwissen aufzubauen (z. B. Pilotprojekte für neue Technologien)
Methode der Kosten-Nutzen-Analyse
Verwenden Sie den Barwert als Schätzwert
Berechnen Sie die Systemlebensdauer
Berechnen Sie die Amortisationszeit und den endgültigen Umsatz, indem Sie jedes Jahr den Nettobarwert akkumulieren
Beispiel
Die Amortisationszeit verwendet die positiven und negativen Wendepunkte des akkumulierten Nettobarwerts als ganzzahligen Teil, und der dezimale Teil wird anhand von (letzter negativer Wert/Gesamtdifferenz) berechnet.
9.3.3 Risikobewertung und Machbarkeitsanalyse
Bestimmen Sie das Risiko und die Rentabilität der Organisation
Bewerten Sie technische Risiken und Machbarkeit
Bewerten Sie das Risiko und die Lebensfähigkeit von Ressourcen
Bestimmen Sie die Risiken und Machbarkeit des Zeitplans
9.3.4 Zusammenarbeit mit Kunden bei der Genehmigung
Überprüfung und Genehmigung durch den Exekutivausschuss
Vorstände müssen sehr große Projekte prüfen und genehmigen
Die beteiligten Stakeholder müssen verstehen, was von ihnen erwartet wird
IS-Abteilungen müssen wissen, was sie in Bezug auf Personal und Support tun müssen
Die gesamte Organisation sollte sich dieses Projekts und seiner Bedeutung bewusst sein
9.4 Kernprozess 2: Projekte planen und überwachen
9.4.1 Projektumgebung einrichten
Anders als beim zuvor erwähnten Umgebungsdesign bezieht sich die Projektumgebung hier auf die Arbeitsumgebung und Kommunikation innerhalb und außerhalb des Teams und nicht auf die vom System benötigte Technologie usw.
Aufzeichnungen und Kommunikation – intern/extern
Arbeitsumgebung – Unterstützung/Ausrüstung/Werkzeuge
PC oder Workstation
Software und Tools zur persönlichen Entwicklung
Server mit Ressourcenbibliothek, Kommunikationstools
Büros, Konferenzräume, Drucker und andere Geräte
Supportmitarbeiter (außerhalb des Teams)
Prozesse und Verfahren
Berichte und Dokumentation
Programmierung
prüfen
Leistungen
Code- und Versionskontrolle
9.4.2 Arrangieren Sie den Arbeitsfortschritt
Verwenden Sie den Projektiterationszeitplan, um Iterationen Anwendungsfälle zuzuweisen
Planen Sie einen detaillierten Zeitplan für Aufgaben und Arbeiten, die in jeder Iteration erledigt werden müssen – verwenden Sie einen detaillierten Arbeitsplan
Drei Schritte zur Erstellung eines iterativen detaillierten Arbeitsplans
Erstellen Sie einen Projektstrukturplan (PSP).
Aufwand abschätzen und Abhängigkeiten erkennen
Erstellen Sie einen Zeitplan mithilfe eines Gatt-Diagramms
Der Projektstrukturplan enthält
Zerlegungsbasis
benötigte Zeit
Ausführungsauftrag
Bewerten Sie die Zeit anhand relevanter Informationen aus dem PSP und ermitteln Sie Abhängigkeiten, ggf. mithilfe des kritischen Pfads
Ein Gantt-Diagramm ist ein Balkendiagramm mit Aktivitäten in Balkenform, die auf einer horizontalen Zeitachse angezeigt werden
Bis auf die erste Aufgabe hat jede Aufgabe eine Vorgängeraufgabe.
Der helle Teil ist der kritische Pfad, der den gesamten Fortschritt beeinflusst und genau überwacht werden muss.
9.4.3 Personal- und Ressourcenzuweisung
fünf Aufgaben
Erstellen Sie im Projekt einen Ressourcenplan
Identifizieren und fordern Sie bestimmte technische Mitarbeiter an
Identifizieren und fordern Sie bestimmte Benutzermitarbeiter an
Organisieren Sie Teams in Arbeitsgruppen
Richten Sie erste Schulungs- und Teambuilding-Übungen ein
9.4.4 Bewertungsarbeitsprozess
Retrospektive Ausstellung
9.4.5 Überwachungsprozess und Korrektur
Weisen Sie Einzelpersonen oder Teams Arbeit zu
Sammlungsstatus
Wurde die Aufgabe erledigt und das Ziel erreicht?
Anomalien analysieren
Sind Ausnahmen wichtig?
ergreifen Sie die richtigen Maßnahmen
Kapitel 10 Objektorientiertes Design: Designprinzipien
10.2 Objektorientiertes Design: die Brücke zwischen Analyse und Implementierung
10.3 Objektorientierter Architekturentwurf (High-Level-Design)
Softwaresysteme werden im Allgemeinen in zwei Typen unterteilt
Einzelbenutzersystem: Wird auf dem Desktop des Benutzers oder einem Server ohne gemeinsame Nutzung von Ressourcen ausgeführt
Systeme auf Unternehmensebene: Komponenten können von mehreren Personen oder Organisationen gemeinsam genutzt werden
Server/Client-System
Internetsystem (Browser/Server)
Drei grundlegende Unterschiede, die sich auf das Design der Systemarchitektur auswirken
Zustand
Client/Server ist ein zustandsbasiertes System und Client/Server-Verbindungen sind langlebig
Internetsysteme sind zustandslose Systeme und Verbindungen sind nicht langfristig
Client-Bereitstellung
Direkte Anzeige von Bildschirmen und Tabellen
Bildschirme und Tabellen werden über den Browser angezeigt
Serverbereitstellung
Die Anwendung oder der Client stellt eine direkte Verbindung zum Server her
Der Client stellt über den Browser indirekt eine Verbindung zum Anwendungsserver her
Komponentendiagramm und Architekturdesign
Eine Art Entwurfsdiagramm, das die gesamte Systemarchitektur und die darin enthaltenen logischen Komponenten zeigt und veranschaulicht, wie das System implementiert wird
Das Komponentendiagramm identifiziert Systemkomponenten hinsichtlich Logik, Wiederverwendbarkeit und Portabilität
Die Grundelemente eines Komponentendiagramms sind Komponentenelemente mit APIs.
APIs sind öffentliche Methoden, auf die die Außenwelt zugreifen kann
In Komponentendiagrammen gibt es zwei Arten von APIs
Eingangsbuchse (Buchse)
Ausgangsport (Port)
Beispiel
Fall: Zweischichtiges Architekturdesign des Internets (eigentlich kann es auch dreischichtig sein)
Benutzeroberflächenebene (Ansichtsebene)
Domänenschicht (logische Schicht)
Datenbankzugriffsschicht (Datenschicht)
Stellen Sie mithilfe von Komponentendiagrammen dar
10.4 Grundprinzipien der objektorientierten Detailplanung
Objektorientierte detaillierte Entwurfsschritte
Entwickeln Sie vorläufige Designklassendiagramme
Verwenden Sie CRC-Karten, um die Klassenverantwortung und die Zusammenarbeit für Anwendungsfälle zu bestimmen
Entwickeln Sie detaillierte Sequenzdiagramme für jeden Anwendungsfall: Entwickeln Sie zuerst vorläufige Sequenzdiagramme und dann mehrschichtige Sequenzdiagramme
Fügen Sie Methodenmerkmale und Navigationsinformationen hinzu
Teilen Sie die Lösung in Pakete auf (Paketdiagramm)
10.5 Designklasse und Designklassendiagramm
10.5.1 Designsymbole
Ein Prototyp ist eine Möglichkeit, Elemente anhand ihrer Eigenschaften zu klassifizieren, dargestellt durch <<>>
Es gibt vier Arten von Design-Prototypen
Entitätsklasse
Der Entwurfsbezeichner der Problemdomänenklasse, normalerweise persistent, dargestellt durch <<entity>>
Persistente Klassen beziehen sich auf Klassen, die nach dem Herunterfahren des Systems noch über Daten verfügen. Bei der Implementierung von Methoden werden deren Daten in die Datenbank oder Datei geschrieben.
Beispiel
Schüler und Lehrer im Bildungsmanagementsystem
Kontrollklasse
Es handelt sich um eine Klasse, die eine koordinierende Rolle zwischen Ansichtsklassen und Entitätsklassen spielt, ähnlich wie Router oder Switches, dargestellt durch <<Controller>>
Klasse ansehen
Ansichtsklassen oder Grenzklassen befinden sich an der Automatisierungsgrenze des Systems, ähnlich wie Eingabefelder oder Webseiten, gegenüber Benutzern und werden durch <<boundary>> dargestellt
Datenbankzugriffsklasse
Es handelt sich um eine Klasse, die Daten aus der Datenbank abruft und zurückgibt, dargestellt durch <<dataAccess>>
Jede Prototypklasse hat ein anderes Symbol
10.5.2 Darstellung der Designklasse
Definieren Sie das Format von Attributen in einer Designklasse
Sichtweite
Gibt an (oder -), ob ein anderes Objekt direkt auf die Eigenschaft zugreifen kann. Normalerweise private(-) statt public()
Name des Anwesens
Kleinbuchstaben in Kamelform
Typausdruck
Klasse, String, Ganzzahl, Double, Datum
Ursprünglicher Wert
Eigentum
In geschweiften Klammern, wie {key}
Definieren Sie das Format der Methode (Methodenmerkmale)
Sichtbarkeit der Methode
Methodenname
Rückgabewerttyp der Methode
Parameterliste
Beispiel
Zwischen dem Namen und dem Typ der Eigenschaft steht ein Doppelpunkt, und zwischen der Parameterliste und dem Rückgabewerttyp der Methode steht ein Gleichheitszeichen vor dem Anfangswert
Verwenden Sie kursiv geschriebene Klassennamen, um abstrakte Klassen anzuzeigen
Klassen, die nur Vererbung, aber keine Instanziierung zulassen, repräsentieren im Allgemeinen abstrakte Konzepte höherer Ebene
10.5.3 Entwickeln Sie vorläufige Entwurfsklassendiagramme
Attributverfeinerung
Designer bestimmen Attributtypen basierend auf Erfahrung. In den meisten Fällen sind Attribute unsichtbar (privat).
Sichtbarkeit der Navigation
Die Navigationssichtbarkeit bezieht sich darauf, ob eine Klasse für eine andere Klasse sichtbar oder unsichtbar ist, was die Fähigkeit eines Objekts angibt, ein anderes Objekt zu sehen und mit ihm zu interagieren
Verwenden Sie einen Pfeil, um anzuzeigen, dass die Richtung, auf die gezeigt wird, die sichtbare Seite ist
In diesem Beispiel bezieht sich „Kunde“ auf die Klasse „Verkauf“, sodass „Verkauf“ für den Kunden sichtbar ist, „Kunde“ für den Verkauf jedoch nicht.
Art der Navigationssichtbarkeit
Stellt eine Eins-zu-viele-Beziehung zwischen Vorgesetzten und Untergebenen dar, die normalerweise vom Vorgesetzten zum Untergebenen zeigt
Erzwungene Assoziation, bei der ein Objekt in einer Klasse nicht ohne ein Objekt in einer anderen Klasse existieren kann, typischerweise durch Navigieren von einer unabhängigeren Klasse zu einer abhängigen Klasse
Beispielsweise ist in der obigen Beschreibung „Kunde und Verkauf“ der Verkauf bedeutungslos, wenn es keine Kunden gibt.
Wenn ein Objekt Informationen von einem anderen Objekt benötigt, ist möglicherweise ein Navigationspfeil erforderlich
Die Sichtbarkeit der Navigation kann bidirektional sein
Schritte zur Entwicklung vorläufiger Anwendungsfalldiagramme
Anwendungsfall nach Anwendungsfall, dem Diagramm hinzugefügt
Wählen Sie die am Anwendungsfall beteiligten Domänenklassen aus (siehe Idee der Voraussetzungen und Nachbedingungen).
Vor- und Nachbedingungen sollten in der Anwendungsfallbeschreibung in Kapitel 5 enthalten sein
Fügen Sie eine Controller-Klasse hinzu, um den Anwendungsfall zu verwalten
Verwenden Sie Richtlinien, um den anfänglichen Bedarf an Navigationssichtbarkeit zu ermitteln und diese dem Diagramm hinzuzufügen
Beschreiben Sie die Eigenschaften jeder Klasse detailliert mit Sichtbarkeit und Typ
Beachten Sie, dass Assoziationen und Multiplizität häufig aus Designklassendiagrammen entfernt werden, ebenso wie die Navigation im Text hervorgehoben wird, sie jedoch häufig beibehalten werden
Vom Domänenklassendiagramm zum vorläufigen Entwurfsklassendiagramm
10.6 Verwendung von CRC-Karten für detailliertes Design
CRC-Karte bedeutet Klasse, Verantwortung, Zusammenarbeit
Beim objektorientierten Design geht es darum, Klassen Verantwortlichkeiten zuzuweisen und wie sie zusammenarbeiten, um einen Anwendungsfall abzuschließen
Die CRC-Karte ist in drei Bereiche unterteilt: Klassenname, Verantwortungsname und Kooperationsklasse
Schritte zur Verwendung der CRC-Karte
Beginnen Sie mit einem Satz ungenutzter CRC-Karten und arbeiten Sie sich einen Anwendungsfall nach dem anderen durch
Wählen Sie einen Anwendungsfall und eine Karte als Controller aus
Bestimmen Sie die Domänenklasse, die hauptsächlich für diesen Anwendungsfall verantwortlich ist. Die Objekte dieser Klasse erhalten Nachrichten vom Controller, bestimmen die Verantwortlichkeiten und schreiben sie auf die linke Seite der Karte.
Identifizieren Sie andere Klassen, die mit der Hauptobjektklasse zusammenarbeiten, um den Anwendungsfall abzuschließen, und schreiben Sie sie auf die rechte Seite der CRC-Karte
Nachdem Sie die Kooperationskategorien bestimmt haben, führen Sie die oben genannten Vorgänge für jede Kooperationskategorie durch (Verantwortlichkeiten bestimmen/Kooperationskategorien finden).
Benutzeroberflächenklassen und Datenbankzugriffsklassen können entsprechend hinzugefügt werden
Verwenden Sie die Ergebnisse der CRC-Karte, um das vorläufige Designklassendiagramm zu aktualisieren
Aktualisieren Sie die Methode: Die Verantwortung in der CRC-Karte wird zu einer Methode (es gibt jedoch keine Sichtbarkeit und keinen Rückgabetypausdruck, dh es werden keine Methodenmerkmale hinzugefügt).
Aktualisieren Sie die Sichtbarkeit der Navigation
Beispiel
Vorläufiges Designklassendiagramm
Aktualisiertes Designklassendiagramm
10.7 Einige Prinzipien des detaillierten Designs
geringe Kopplung
Hoher Zusammenhalt
Variabler Schutz
indirekt
Objektverantwortlichkeiten
Kapitel 11 Objektorientiertes Design: Designimplementierung
11.2 Detaillierter Entwurf von Mehrschichtsystemen
Designmuster
Designmuster – Standarddesigntechniken und -vorlagen, die weithin als bewährte Verfahren anerkannt sind
Bei häufig auftretenden Design-/Codierungsproblemen schlagen Designmuster die beste Lösung für das Problem vor.
Elemente von Designmustern
Schemaname
Probleme, die Lösungen erfordern
Problemlösungsmodell
Musterkoffer
Vorteile und Folgen von Mustern
Das erste Beispiel für ein Programmierentwurfsmuster ist das Controller-Muster.
Anwendungsfall-Controller werden künstlich erstellt, um Nachrichten von der Ansichtsschicht an die Domänenschicht weiterzuleiten und so die Kopplung zu reduzieren.
Vorteile und Konsequenzen
Reduziert die Kopplung zwischen Domänenschicht und Ansichtsschicht
bietet eine Indirektionsebene
Controller und Domänenklassen sind eng miteinander verbunden
Wenn Sie nicht aufpassen, enthält der Controller eine Menge irrelevanter Logik, insbesondere Geschäftslogik.
11.3 Anwendungsfallimplementierung und Sequenzdiagramm SSD
Anwendungsfallimplementierung – der Prozess der detaillierten Gestaltung von Anwendungsfällen mithilfe von Interaktionsdiagrammen
Es gibt zwei Arten von Interaktionsdiagrammen
Flussdiagramm
Sequenzdiagramme werden durch Erweiterung des Systemsequenzdiagramms dargestellt
Ebenenobjekt anzeigen
Domänenschichtobjekte (normalerweise zuerst erledigt)
Datenzugriffsschichtobjekt
Kollaborationsdiagramm
11.3.1 Sequenzdiagramme verstehen
Der Unterschied zwischen Systemsequenzdiagramm und Sequenzdiagramm
Das Systemsequenzdiagramm hat nur ein Objekt, das das System darstellt: System, während das Sequenzdiagramm das Objekt in das Innere des Systems erweitert.
Das Systemsequenzdiagramm verfügt nur über zwei Lebenslinien, die die Akteure und das System darstellen. Die Akteure und jedes Objekt im Sequenzdiagramm verfügen über eine Lebenslinie, obwohl die Länge unterschiedlich sein kann (die Zeitvorgabe beginnt, wenn das Objekt erstellt wird).
Im gleichen Anwendungsfall sind der Automatisierungsgrenzteil des Systemsequenzdiagramms und das Sequenzdiagramm gleich (das Ganze bleibt unverändert), dh die Eingabe in das System und die Ausgabe des Systems nach außen sind die gleichen Dasselbe.
Sequenzdiagramme verfügen über einen speziellen Lebenslinienabschnitt, der als Aktivitätslebenslinie bezeichnet wird
Die Aktivitätslebenslinie stellt die Zeit dar, die sich ein Objekt im aktiven Ausführungszustand befindet. Der aktive Zustand bleibt bestehen, bis alle Daten gespeichert sind oder andere Methoden aufgerufen werden.
In diesem Sequenzdiagramm zum Erstellen eines Benutzeranwendungsfalls wurden Customform und CustomHandler erstellt, und das Custom-Objekt wird nach der Methode createCustom erstellt, sodass die Startzeit der Lebenslinie unterschiedlich ist und der rechteckige Balken die aktive Lebenslinie ist.
11.3.2 Designprozess der Anwendungsfallimplementierung
Gestaltungsschritte
Entwickeln Sie ein vorläufiges Designklassendiagramm, das die Sichtbarkeit der Navigation zeigt
Verwenden Sie CRC-Karten, um Klassen in Anwendungsfällen Funktionen zuzuweisen
Entwickeln Sie detaillierte Sequenzdiagramme für jeden Anwendungsfall
Vorläufiges Sequenzdiagramm
Mehrstufiges Sequenzdiagramm
Verwenden Sie CRC-Karten und detaillierte Sequenzdiagramme, um Designklassendiagramme zu aktualisieren und Methodenfunktionen hinzuzufügen
Klassendiagramme für das Paketdesign
11.3.3 Fall: Vorläufiges Design-Klassendiagramm zum Erstellen eines Benutzerkontos
Entwickeln Sie ein vorläufiges Sequenzdiagramm basierend auf dem zuvor entwickelten vorläufigen Designklassendiagramm
Erweitern Sie das Systemsequenzdiagramm und markieren Sie die Klassenobjekte, die im ursprünglichen System verwendet werden müssen. Davor befindet sich noch ein Doppelpunkt.
Bestimmen Sie interne Nachrichten zwischen Objekten, fügen Sie Nachrichten und Aktivierungen hinzu, um die Zusammenarbeit zu vervollständigen
Das Format der Nachricht stimmt mit dem Systemsequenzdiagramm überein: *[codition] return_value:=function_name(parameter_list) Sie können als Rückgabewert auch einen gestrichelten Rückwärtspfeil verwenden
Unterthema
11.3.5 Richtlinien und Annahmen für die Entwicklung vorläufiger Sequenzdiagramme
Führung
Akzeptieren Sie jede Nachricht und identifizieren Sie andere interne Nachrichten, die sich aus dieser Eingabenachricht ergeben
Geben Sie bei der Verarbeitung jeder Nachricht die Gruppe der betroffenen Klassen an
Bereichern Sie die Nachrichtenstruktur, fügen Sie wahre und falsche Bedingungen, Schleifen, Rückgabewerte, Parameterübertragung usw. hinzu.
Hypothese
Hypothese der technischen Perfektion
Hypothese der Gedächtnisperfektion
keine Anomalieannahme
11.3.6 Entwicklung mehrschichtiger Sequenzdiagramme
Das Obige ist nur ein vorläufiges Sequenzdiagramm für die Domänenschicht (logische Schicht). Um die Anwendungsfälle detaillierter zu beschreiben, müssen Sie Sequenzdiagramme für die Datenzugriffsschicht und die Ansichtsschicht entwickeln.
11.4 Verwenden Sie ein Kommunikationsdiagramm für ein Kollaborationsdiagramm
11.5 Klassendiagramm für Aktualisierung und Paketdesign
Designklassendiagramm aktualisieren
Fügen Sie basierend auf den Informationen aus dem Sequenzdiagramm Methodenfunktionen hinzu, um die DCD zu aktualisieren
Drei Methodentypen
Konstruktormethode: Erstellen Sie eine neue Objektinstanz
Methoden zum Lesen und Schreiben von Daten: Attributwerte abrufen oder aktualisieren
Anwendungsfallspezifische Methoden: im Design-Klassendiagramm enthalten
Paketkarte
Ein Paketdiagramm ist ein Diagramm auf hoher Ebene, das verwandte Klassengruppen verknüpft
Verwenden Sie ordnerähnliche Symbole, um Pakete darzustellen, und Klassen werden entsprechend den Ebenen, zu denen sie gehören, in entsprechenden Paketen platziert.
Verwenden Sie gepunktete Pfeile, um Abhängigkeiten anzuzeigen, einschließlich Abhängigkeiten zwischen Klassen und Abhängigkeiten zwischen Paketen.
Beispiel
Teilpaketdiagramm mit nur einem Anwendungsfall
Diagramm des Subsystempakets
11.6 Andere gängige Designmuster
Adapter
Wenn zwei Systeme verbunden werden müssen, die Schnittstellen zwischen ihnen jedoch nicht übereinstimmen, ist ein Adapter erforderlich.
Verbinden Sie nicht übereinstimmende Schnittstellen, indem Sie Daten neu schreiben
Wenn Sie beispielsweise mit unterschiedlichen Lieferanten (Steuern, Versandkosten) konfrontiert werden, müssen Sie nur den Adapter neu schreiben
Fabrik
Factory-Klassen werden zum Erstellen vieler verschiedener Arten von Utility-Klasseninstanzen verwendet
Im Allgemeinen benötigt eine Werkzeugklasse nur eine Instanz, und die Factory stellt sicher, dass es nur eine Instanz gibt.
Singleton
Ein Singleton verfügt über eine statische Variable, die auf eine Instanz von sich selbst zeigt. Überprüfen Sie diese Variable mit einer Methode. Wenn es leer ist, können Sie eine Instanz erstellen und diese der Variablen zuweisen. Wenn es nicht leer ist, können Sie die Variableninstanz direkt zurückgeben.
Klassenverbindung{ private statische Verbindung=null; öffentlich synchronisiertes statisches getConnection(){ if conn==null{ conn=neue Verbindung(); } Rücklaufverbindung; } }
Fabrik und Singleton
Die Grundlogik von Fabriken und Singletons ist dieselbe: Beide sollen sicherstellen, dass es nur eine Instanz des Objekts gibt, und Speicheraufwand sparen.
Die Factory muss jedoch für mehrere Klassen verantwortlich sein; der Singleton prüft nur die statischen Instanzvariablen innerhalb der Klasse.