Ausländisches Handelssystemprojekt In Ooad

Objektorientiertes Design Nach der Analysephase wird das Konzeptmodell mit objektorientiertem Design (OOD) zu einem objektorientierten Modell weiterentwickelt. In OOD werden die technologieunabhängigen Konzepte im Analysemodell auf implementierende Klassen abgebildet, Einschränkungen identifiziert und Schnittstellen entworfen, die zu einem Modell für die Lösungsdomäne führen. In Kürze wird eine detaillierte Beschreibung erstellt, wie das System auf konkreten Technologien aufgebaut werden soll. Die Stufen für objektorientiertes Design können identifiziert werden: Definition des Kontextes des Systems Entwurf der Systemarchitektur Identifizierung der Objekte im System Konstruktion des Designs Modelle Spezifikation von Objektschnittstellen Objektorientiertes Systemdesign Systemdesign Objektorientiertes Systemdesign beinhaltet die Definition des Kontextes eines Systems, gefolgt von der Gestaltung der Architektur des Systems. Kontext. Der Kontext eines Systems hat einen statischen und einen dynamischen Teil. Der statische Kontext des Systems wird mit einem einfachen Blockdiagramm des Gesamtsystems entworfen, das in eine Hierarchie von Subsystemen erweitert wird. Das Subsystemmodell wird durch UML-Pakete dargestellt. Der dynamische Kontext beschreibt, wie das System mit seiner Umgebung interagiert. Sie wird anhand von Anwendungsfalldiagrammen modelliert. Systemarchitektur . Die Systemarchitektur ist auf der Grundlage des Kontextes des Systems nach den Prinzipien der architektonischen Gestaltung sowie Domain-Wissen entwickelt. Typischerweise wird ein System in Schichten unterteilt, und jede Schicht wird zersetzt, um die Subsysteme zu bilden. Objektorientierte Zersetzung Zerlegung bedeutet, dass ein komplexes System in eine Hierarchie kleinerer Komponenten mit geringerer Komplexität, nach den Prinzipien von divideandconquer, geteilt wird. Jede Hauptkomponente des Systems wird als Subsystem bezeichnet. Objektorientierte Zerlegung identifiziert einzelne autonome Objekte in einem System und die Kommunikation zwischen diesen Objekten. Die Vorteile der Zersetzung sind: Die einzelnen Komponenten sind von geringerer Komplexität und damit verständlicher und überschaubarer. Es ermöglicht die Teilung der Belegschaft mit speziellen Fähigkeiten. Sie ermöglicht es, Subsysteme zu ersetzen oder zu modifizieren, ohne andere Subsysteme zu beeinträchtigen. Gleichzeitigkeit identifizieren Gleichzeitigkeit ermöglicht, dass mehr als ein Objekt gleichzeitig Ereignisse empfängt und mehrere Aktivitäten gleichzeitig ausgeführt werden. Gleichzeitigkeit wird im dynamischen Modell identifiziert und dargestellt. Um Gleichzeitigkeit zu ermöglichen, wird jedem gleichzeitigen Element ein separater Thread des Steuerelements zugewiesen. Wenn die Parallelität auf Objektebene ist, werden zwei gleichzeitigen Objekten zwei verschiedene Threads der Steuerung zugewiesen. Wenn zwei Operationen eines einzelnen Objekts gleichzeitig in der Natur sind, dann wird dieses Objekt unter verschiedenen Threads aufgeteilt. Gleichzeitigkeit ist mit den Problemen der Datenintegrität, Deadlock und Hunger verbunden. Daher muss eine klare Strategie gemacht werden, wann immer Parallelität erforderlich ist. Außerdem muss Parallelität in der Entwurfsphase selbst identifiziert werden und kann nicht für die Implementierungsphase überlassen werden. Identifizieren von Patterns Beim Entwerfen von Anwendungen werden für einige Kategorien von Problemen einige allgemein akzeptierte Lösungen verwendet. Dies sind die Muster des Designs. Ein Muster kann als ein dokumentierter Satz von Bausteinen definiert werden, der bei bestimmten Arten von Anwendungsentwicklungsproblemen verwendet werden kann. Einige häufig verwendete Entwurfsmuster sind: Fadenmuster Modellansicht Trennmuster Beobachtermuster Modellansicht Steuerungsmuster Veröffentlichen Abonnementmuster Proxymuster Steuern von Ereignissen Während des Entwurfs des Systems müssen die Ereignisse, die in den Objekten des Systems auftreten können, identifiziert und entsprechend behandelt werden. Ein Ereignis ist eine Spezifikation eines bedeutenden Ereignisses, das einen Ort in Zeit und Raum hat. Es gibt vier Arten von Ereignissen, die modelliert werden können, nämlich: Signal Event. Ein benanntes Objekt, das von einem Objekt geworfen und von einem anderen Objekt gefangen wird. Ereignis anrufen. Synchrones Ereignis, das den Versand einer Operation darstellt. Zeit-Ereignis. Ein Ereignis, das den Ablauf der Zeit darstellt. Ereignis ändern. Ein Ereignis, das eine Zustandsänderung darstellt. Handhabung von Randbedingungen Die Systemdesignphase muss die Initialisierung und die Beendigung des Systems als Ganzes sowie jedes Subsystem adressieren. Die verschiedenen Aspekte, die dokumentiert werden, sind wie folgt: Die Inbetriebnahme des Systems, d. h. der Übergang des Systems vom nicht initialisierten Zustand in den stationären Zustand. Die Beendigung des Systems, d. h. das Schließen aller laufenden Threads, das Aufräumen der Ressourcen und die zu sendenden Nachrichten. Die Erstkonfiguration des Systems und die Rekonfiguration des Systems bei Bedarf. Vorhersehen von Fehlern oder unerwünschter Beendigung des Systems. Randbedingungen werden unter Verwendung von Grenznutzungsfällen modelliert. Objektdesign Nachdem die Hierarchie der Subsysteme entwickelt wurde, werden die Objekte im System identifiziert und deren Details entworfen. Hier beschreibt der Designer die Strategie, die während des Systemdesigns gewählt wurde. Der Schwerpunkt wechselt von Anwendungsdomänenkonzepten hin zu Computerkonzepten. Die während der Analyse identifizierten Objekte werden zur Implementierung herausgeätzt, um die Ausführungszeit, den Speicherverbrauch und die Gesamtkosten zu minimieren. Das Objektdesign umfasst die folgenden Phasen: Objektidentifizierung Objektdarstellung, d. h. Konstruktion von Entwurfsmodellen Klassifizierung von Operationen Algorithmendesign Entwurf von Beziehungen Implementierung der Steuerung für externe Interaktionen Paketklassen und Assoziationen in Module Objektidentifizierung Der erste Schritt des Objektdesigns ist die Objektidentifizierung. Die in den objektorientierten Analysephasen identifizierten Objekte werden in Klassen gruppiert und verfeinert, so dass sie für die eigentliche Umsetzung geeignet sind. Die Funktionen dieser Stufe sind: Identifizieren und Verfeinern der Klassen in jedem Subsystem oder Paket Definieren der Links und Assoziationen zwischen den Klassen Entwerfen der hierarchischen Assoziationen zwischen den Klassen, dh die Generalisierungen und Vererbung Object Representation Sobald die Klassen identifiziert sind, müssen sie sein Dargestellt unter Verwendung von Objektmodellierungstechniken. Diese Stufe beinhaltet im Wesentlichen die Konstruktion von UML-Diagrammen. Es gibt zwei Arten von Designmodellen, die hergestellt werden müssen: Statische Modelle. Um die statische Struktur eines Systems anhand von Klassendiagrammen und Objektdiagrammen zu beschreiben. Dynamische Modelle. Um die dynamische Struktur eines Systems zu beschreiben und die Interaktion zwischen Klassen anhand von Interaktionsdiagrammen und Zustandsdiagrammen darzustellen. Klassifizierung von Operationen In diesem Schritt werden die Operationen, die an Objekten durchgeführt werden sollen, durch Kombination der drei in der OOA-Phase entwickelten Modelle, nämlich Objektmodell, dynamisches Modell und Funktionsmodell, definiert. Ein Vorgang legt fest, was zu tun ist und nicht wie es durchgeführt werden soll. Für Operationen werden folgende Aufgaben ausgeführt: Das Zustandsübergangsdiagramm jedes Objekts im System wird entwickelt. Operationen werden für die Ereignisse definiert, die von den Objekten empfangen werden. Fälle, in denen ein Ereignis andere Ereignisse in gleichen oder verschiedenen Objekten auslöst, werden identifiziert. Die Teiloperationen innerhalb der Maßnahmen werden identifiziert. Die Hauptaktionen werden auf Datenflussdiagramme erweitert. Algorithm Design Die Operationen in den Objekten werden mittels Algorithmen definiert. Ein Algorithmus ist eine schrittweise Prozedur, die das in einer Operation festgelegte Problem löst. Algorithmen konzentrieren sich darauf, wie es zu tun ist. Es kann mehr als einen Algorithmus geben, der einer gegebenen Operation entspricht. Sobald die alternativen Algorithmen identifiziert sind, wird der optimale Algorithmus für die gegebene Problemdomäne ausgewählt. Die Metriken für die Auswahl des optimalen Algorithmus sind: Computational Complexity. Komplexität bestimmt die Effizienz eines Algorithmus hinsichtlich Rechenzeit und Speicherbedarf. Flexibilität. Flexibilität bestimmt, ob der gewählte Algorithmus in geeigneter Weise ohne Verlust der Angemessenheit in verschiedenen Umgebungen implementiert werden kann. Verständlichkeit. Dies bestimmt, ob der gewählte Algorithmus einfach zu verstehen und zu implementieren ist. Design von Beziehungen Die Strategie zur Umsetzung der Beziehungen muss während der Objektentwurfsphase ausgeklammert werden. Die Hauptbeziehungen, die angesprochen werden, umfassen Assoziationen, Aggregationen und Erbschaften. Der Designer sollte in Bezug auf Assoziationen Folgendes tun: Ermitteln Sie, ob eine Assoziation unidirektional oder bidirektional ist. Analysieren Sie den Pfad der Zuordnungen und aktualisieren Sie sie, wenn nötig. Implementieren Sie die Assoziationen als ein eigenständiges Objekt, im Falle von vielen zu vielen Beziehungen oder als Verknüpfung zu anderen Objekten im Falle von oneto-one oder oneto-many Beziehungen. Bei Erbschaften sollte der Designer folgende Schritte durchführen: Passen Sie die Klassen und ihre Zuordnungen an. Identifizieren Sie abstrakte Klassen. Machen Sie Vorkehrungen, so dass Verhaltensweisen gemeinsam genutzt werden, wenn nötig. Implementierung der Steuerung Der Objektdesigner kann Verfeinerungen in die Strategie des Statechart-Modells einfließen lassen. Im Systementwurf wird eine Basisstrategie zur Realisierung des dynamischen Modells erstellt. Während des Objektentwurfs ist diese Strategie für eine angemessene Implementierung treffend verschönert. Die Ansätze für die Umsetzung des dynamischen Modells sind: Represent State als Standort innerhalb eines Programms. Dies ist der traditionelle, prozessorientierte Ansatz, bei dem der Standort der Steuerung den Programmzustand definiert. Eine Finite-State-Maschine kann als Programm implementiert werden. Ein Übergang bildet eine Eingangsbehauptung, der Hauptsteuerpfad bildet die Folge von Anweisungen, die Zweige bilden die Bedingungen und die Rückwärtspfade bilden die Schleifen oder Iterationen. Maschine. Dieser Ansatz stellt direkt eine Zustandsmaschine durch eine Zustandsmaschinenmotorklasse dar. Diese Klasse führt die Zustandsmaschine durch einen Satz von Übergängen und Aktionen durch, die von der Anwendung bereitgestellt werden. Steuerung als gleichzeitige Aufgaben. Bei diesem Ansatz wird ein Objekt als Aufgabe in der Programmiersprache oder dem Betriebssystem implementiert. Dabei wird ein Ereignis als Inter-Task-Aufruf implementiert. Es bewahrt inhärente Gleichzeitigkeit von realen Objekten. Verpackungsklassen In jedem größeren Projekt ist eine sorgfältige Partitionierung einer Implementierung in Module oder Pakete wichtig. Beim Objektentwurf werden Klassen und Objekte in Pakete zusammengefasst, so dass mehrere Gruppen kooperativ an einem Projekt arbeiten können. Die verschiedenen Aspekte der Verpackung sind: Ausblenden von internen Informationen aus der Außenansicht. Sie ermöglicht es, dass eine Klasse als Blackbox betrachtet wird und die Klassenimplementierung geändert werden kann, ohne dass Clients der Klasse Code modifizieren müssen. Kohärenz der Elemente. Ein Element, wie eine Klasse, eine Operation oder ein Modul, ist kohärent, wenn es auf einem konsistenten Plan organisiert ist und alle seine Teile intrinsisch verwandt sind, so dass sie ein gemeinsames Ziel erfüllen. Aufbau von Physical Modules. Die folgenden Richtlinien helfen beim Erstellen physikalischer Module: Klassen in einem Modul sollten ähnliche Dinge oder Komponenten in demselben zusammengesetzten Objekt darstellen. Eng verbundene Klassen sollten sich im selben Modul befinden. Unverbundene oder schwach verbundene Klassen sollten in separaten Modulen platziert werden. Module sollten eine gute Kohäsion aufweisen, d. h. eine hohe Kooperation unter ihren Komponenten. Ein Modul sollte eine niedrige Kopplung mit anderen Modulen aufweisen, d. h. Interaktion oder Interdependenz zwischen Modulen sollte minimal sein. Design-Optimierung Das Analysemodell erfasst die logischen Informationen über das System, während das Designmodell Details zur Unterstützung eines effizienten Informationszugriffs hinzufügt. Bevor ein Entwurf implementiert wird, sollte es optimiert werden, um die Implementierung effizienter zu gestalten. Das Ziel der Optimierung ist es, die Kosten in Bezug auf Zeit, Raum und andere Metriken zu minimieren. Designoptimierung sollte jedoch nicht übertrieben sein, da einfache Implementierung, Wartbarkeit und Erweiterbarkeit ebenfalls wichtige Belange sind. Es wird oft gesehen, dass ein perfekt optimiertes Design effizienter, aber weniger lesbar und wiederverwendbar ist. So muss der Designer ein Gleichgewicht zwischen den beiden schlagen. Die verschiedenen Dinge, die für die Design-Optimierung getan werden können, sind: Hinzufügen redundanter Assoziationen Weglassen nicht verwendbarer Assoziationen Optimierung von Algorithmen Speichern von abgeleiteten Attributen zur Vermeidung von Re-Berechnungen komplexer Ausdrücke Hinzufügen redundanter Assoziationen Bei der Designoptimierung wird überprüft, ob neue Assoziationen abgeleitet werden können Reduzieren. Obwohl diese redundanten Assoziationen keine Informationen hinzufügen können, können sie die Effizienz des Gesamtmodells erhöhen. Unterlassung von nicht verwendbaren Verbänden Das Vorhandensein zu vieler Assoziationen kann ein System unentzifferbar machen und damit die Gesamteffizienz des Systems reduzieren. Während der Optimierung werden also alle nicht verwendbaren Zuordnungen entfernt. Optimierung von Algorithmen In objektorientierten Systemen erfolgt die Optimierung von Datenstrukturen und Algorithmen kollaborativ. Sobald das Klassen-Design vorhanden ist, müssen die Operationen und die Algorithmen optimiert werden. Die Optimierung der Algorithmen erhält man durch: Umordnen der Reihenfolge der Rechenaufgaben Umkehrung der Ausführungsreihenfolge der Schleifen von der im Funktionsmodell festgelegten Entfernung von Totpfaden im Algorithmus Speichern und Speichern abgeleiteter Attribute Abgeleitete Attribute sind diejenigen Attribute, deren Werte berechnet werden Als Funktion von anderen Attributen (Basisattributen). Eine Neuberechnung der Werte von abgeleiteten Attributen wird jedes Mal, wenn sie benötigt werden, ein Zeitkonsumierungsverfahren. Um dies zu vermeiden, können die Werte berechnet und in ihren berechneten Formen gespeichert werden. Dies kann jedoch Aktualisierungsanomalien darstellen, d. H. Eine Änderung der Werte von Basisattributen ohne entsprechende Änderung der Werte der abgeleiteten Attribute. Um dies zu vermeiden, werden folgende Schritte unternommen: Bei jeder Aktualisierung des Basisattributwerts wird das abgeleitete Attribut ebenfalls neu berechnet. Alle abgeleiteten Attribute werden in einer Gruppe und nicht nach jeder Aktualisierung neu berechnet und aktualisiert. Entwurfsdokumentation Dokumentation ist ein wesentlicher Bestandteil eines jeden Softwareentwicklungsprozesses, der das Verfahren zur Herstellung der Software aufzeichnet. Die Designentscheidungen müssen für jedes nicht-triviale Software-System dokumentiert werden, um das Design an andere weiterzugeben. Anwendungsgebiete Obwohl es sich um ein sekundäres Produkt handelt, ist eine gute Dokumentation unabdingbar, insbesondere in den folgenden Bereichen: Bei der Entwicklung von Software, die von einer Anzahl von Entwicklern entwickelt wird In iterativen Softwareentwicklungsstrategien Bei der Entwicklung nachfolgender Versionen eines Softwareprojekts Zur Auswertung einer Software Für die Suche Bedingungen und Prüfbereiche Für die Wartung der Software. Eine nützliche Dokumentation sollte im Wesentlichen die folgenden Inhalte enthalten: Highlevel-Systemarchitektur. Prozessdiagramme und Moduldiagramme Schlüsselentwürfe und - mechanismen. Klassendiagramme und Objektdiagramme. Szenarien, die das Verhalten der Hauptaspekte illustrieren. Verhaltensdiagramme Die Merkmale einer guten Dokumentation sind: Prägnant und zugleich eindeutig, konsistent und vollständig Nachvollziehbar auf die Anforderungen der Systemanforderungen Gut strukturiert Diagrammatisch statt beschreibendOOAD - Kurzübersicht Objektorientiertes Paradigma Eine kurze Geschichte Das objektorientierte Paradigma Nahm seine Form von der ursprünglichen Konzept eines neuen Programmierungsansatzes, während das Interesse an Design-und Analyse-Methoden kam viel später. Die erste objektorientierte Sprache war Simula (Simulation realer Systeme), die 1960 von Forschern am Norwegian Computing Center entwickelt wurde. Im Jahr 1970 gründete Alan Kay und seine Arbeitsgruppe bei Xerox PARK einen Personal Computer namens Dynabook und die erste reine objektorientierte Programmiersprache (OOPL) - Smalltalk, für die Programmierung des Dynabook. In den 1980er Jahren veröffentlichte Grady Booch ein Papier mit dem Titel Object Oriented Design, das hauptsächlich ein Design für die Programmiersprache Ada vorstellte. In den darauffolgenden Ausgaben erweiterte er seine Ideen auf eine komplette objektorientierte Designmethode. In den neunziger Jahren verkörperte Coad Verhaltensideen zu objektorientierten Methoden. Die anderen bedeutenden Neuerungen waren Object Modeling Techniques (OMT) von James Rumbaugh und Object-Oriented Software Engineering (OOSE) von Ivar Jacobson. Objektorientierte Analyse ObjectOriented Analysis (OOA) ist die Prozedur der Identifizierung von Software-Engineering-Anforderungen und die Entwicklung von Software-Spezifikationen in Bezug auf ein Software-System-Objektmodell, das aus interagierenden Objekten besteht. Der Hauptunterschied zwischen objektorientierter Analyse und anderen Analyseformen besteht darin, dass im objektorientierten Ansatz die Anforderungen an Objekte gegliedert sind, die sowohl Daten als auch Funktionen integrieren. Sie sind nach realen Objekten modelliert, mit denen das System interagiert. In den traditionellen Analyseverfahren werden die beiden Aspekte - Funktionen und Daten - getrennt betrachtet. Grady Booch hat definiert OOA as, Objekt-orientierte Analyse ist eine Methode der Analyse, die Anforderungen aus der Perspektive der Klassen und Objekte im Vokabular der Problemdomäne gefunden untersucht. Die primären Aufgaben in der objektorientierten Analyse (OOA) sind: Identifizieren von Objekten Organisieren der Objekte durch Erstellen eines Objektmodelldiagramms Definieren der Interne der Objekte oder Objektattribute Definieren des Verhaltens der Objekte, dh Objektaktionen Beschreiben, wie die Objekte interagieren Modelle, die in OOA verwendet werden, sind Anwendungsfälle und Objektmodelle. Objektorientiertes Design Objektorientiertes Design (OOD) beinhaltet die Implementierung des konzeptionellen Modells, das während der objektorientierten Analyse erzeugt wird. Im OOD werden Konzepte im Analysemodell, die technologieunabhängig sind, auf implementierende Klassen abgebildet, Beschränkungen identifiziert und Schnittstellen entworfen, die zu einem Modell für die Lösungsdomäne führen, dh eine detaillierte Beschreibung, wie das System auf Beton aufgebaut werden soll Technologien. Die Implementierungsdetails umfassen im Allgemeinen: Umstrukturierung der Klassendaten (falls erforderlich), Implementierung von Methoden, d. h. interne Datenstrukturen und Algorithmen, Implementierung der Steuerung und Implementierung von Assoziationen. Grady Booch hat das objektorientierte Design als eine Methode des Entwurfs definiert, die den Prozess der objektorientierten Zerlegung und eine Notation umfasst, um sowohl logische als auch physikalische sowie statische und dynamische Modelle des Systems im Entwurf darzustellen. Objektorientierte Programmierung Objektorientierte Programmierung (OOP) ist ein Programmierparadigma auf der Basis von Objekten (mit Daten und Methoden), die die Vorteile der Modularität und Wiederverwendbarkeit integrieren sollen. Objekte, die in der Regel Instanzen von Klassen sind, werden verwendet, um miteinander zu interagieren, um Anwendungen und Computerprogramme zu entwerfen. Die wichtigsten Merkmale der objektorientierten Programmierung sind: Bottomup-Ansatz im Programm-Design Programme organisiert um Objekte, gruppiert in Klassen Fokus auf Daten mit Methoden für den Betrieb von Objekten Daten Interaktion zwischen Objekten durch Funktionen Wiederverwendbarkeit des Designs durch die Schaffung neuer Klassen durch Hinzufügen von Features zu bestehenden Klassen Einige Beispiele für objektorientierte Programmiersprachen sind C, Java, Smalltalk, Delphi, C, Perl, Python, Ruby und PHP. Grady Booch hat die objektorientierte Programmierung als eine Methode der Implementierung definiert, in der Programme als kooperative Sammlungen von Objekten organisiert werden, von denen jede eine Instanz einer Klasse repräsentiert und deren Klassen alle Mitglieder einer Hierarchie von Klassen sind, die über Vererbungsbeziehungen vereint sind. OOAD - Objektmodell Das Objektmodell visualisiert die Elemente in einer Softwareanwendung nach Objekten. In diesem Kapitel werden wir die grundlegenden Konzepte und Terminologien von objektorientierten Systemen untersuchen. Objekte und Klassen Die Begriffe von Objekten und Klassen sind intrinsisch miteinander verknüpft und bilden das Fundament eines objektorientierten Paradigmas. Ein Objekt ist ein Element der realen Welt in einer objektorientierten Umgebung, die eine physische oder eine begriffliche Existenz haben kann. Jedes Objekt hat: Identität, die es von anderen Objekten im System unterscheidet. Zustand, der die charakteristischen Eigenschaften eines Objekts sowie die Werte der Eigenschaften festlegt, die das Objekt enthält. Verhalten, das von außen sichtbare Aktivitäten darstellt, die von einem Objekt in Form von Änderungen in seinem Zustand ausgeführt werden. Objekte können nach den Bedürfnissen der Anwendung modelliert werden. Ein Objekt kann eine physische Existenz, wie ein Kunde, ein Auto, etc. oder eine immaterielle konzeptionelle Existenz, wie ein Projekt, ein Prozess, etc. haben. Eine Klasse repräsentiert eine Sammlung von Objekten mit gleichen charakteristischen Eigenschaften, die ein gemeinsames Verhalten aufweisen. Es gibt die Blaupause oder Beschreibung der Objekte, die daraus erstellt werden können. Die Erzeugung eines Objekts als Mitglied einer Klasse wird als Instanziierung bezeichnet. Somit ist object eine Instanz einer Klasse. Die Bestandteile einer Klasse sind: Eine Menge von Attributen für die Objekte, die aus der Klasse instanziiert werden sollen. Im Allgemeinen haben verschiedene Objekte einer Klasse einen gewissen Unterschied in den Werten der Attribute. Attribute werden oft als Klassendaten bezeichnet. Ein Satz von Operationen, die das Verhalten der Objekte der Klasse darstellen. Operationen werden auch als Funktionen oder Methoden bezeichnet. Betrachten wir eine einfache Klasse, Circle, die den geometrischen Figurenkreis in einem zweidimensionalen Raum darstellt. Die Attribute dieser Klasse können wie folgt identifiziert werden: xcoord, um xcoordinate des Zentrums ycoord zu bezeichnen, um ycoordinate des Zentrums a zu bezeichnen, um den Radius des Kreises zu bezeichnen. Einige seiner Operationen können wie folgt definiert werden: findArea () Methode zum Berechnen des Bereichs findCircumference (), Methode zur Berechnung der Umfangsskala (), Methode zum Erhöhen oder Verringern des Radius Während der Instanziierung werden Werte für mindestens einige der Attribute zugeordnet. Wenn wir ein Objekt mycircle erstellen, können wir Werte wie x-coord zuordnen. 2, y-Koord. 3 und a. Um ihren Zustand darzustellen. Wenn nun die Operationsskala () auf mycircle mit einem Skalierungsfaktor von 2 durchgeführt wird, wird der Wert der Variablen a zu 8 werden. Dieser Vorgang bewirkt eine Änderung im Zustand von mycircle, d. h. das Objekt hat ein bestimmtes Verhalten gezeigt. Encapsulation und Data Hiding Encapsulation Encapsulation ist der Prozess der Bindung sowohl Attribute und Methoden zusammen innerhalb einer Klasse. Durch Kapselung können die inneren Details einer Klasse von außen verborgen werden. Es erlaubt, dass die Elemente der Klasse von außen nur über die von der Klasse bereitgestellte Schnittstelle aufgerufen werden. Data Hiding Typischerweise ist eine Klasse so konzipiert, dass ihre Daten (Attribute) nur durch ihre Klassenmethoden zugänglich sind und von direktem externen Zugriff isoliert sind. Dieser Prozess der Isolierung von Objekten Daten heißt Daten versteckt oder Informationen zu verstecken. Im Class Circle können Daten versteckt werden, indem Attribute von außerhalb der Klasse unsichtbar gemacht werden und der Klasse für den Zugriff auf Klassendaten zwei weitere Methoden hinzugefügt werden: setValues ​​(), die Methode, x-coord, y-coord, Und ein getValues ​​() - Methode zum Abrufen von Werten von x-coord, y-coord und a Hier können die privaten Daten des Objekts mycircle nicht direkt von einer Methode abgerufen werden, die nicht im Class Circle eingekapselt ist. Sie sollte stattdessen über die Methoden setValues ​​() und getValues ​​() aufgerufen werden. Message Passing Jede Anwendung erfordert eine Reihe von Objekten, die in einer harmonischen Weise interagieren. Objekte in einem System können miteinander kommunizieren, indem sie Nachrichten weitergeben. Angenommen ein System hat zwei Objekte: obj1 und obj2. Das Objekt obj1 sendet eine Nachricht an das Objekt obj2, wenn obj1 obj2 eine seiner Methoden ausführen möchte. Die Eigenschaften der Nachrichtenübertragung sind: Nachricht, die zwischen zwei Objekten geht, ist im Allgemeinen unidirektional. Nachrichtenübergabe ermöglicht alle Interaktionen zwischen Objekten. Bei der Nachrichtenübergabe werden im Wesentlichen Klassenmethoden aufgerufen. Objekte in verschiedenen Prozessen können bei der Nachrichtenübertragung beteiligt sein. Vererbungsvererbung ist der Mechanismus, der es ermöglicht, neue Klassen aus bestehenden Klassen zu erstellen, indem sie ihre Fähigkeiten erweitern und verfeinern. Die bestehenden Klassen werden die BasisklassenPaar-Klasse-Super-Klassen, und die neuen Klassen werden die abgeleiteten classeschild classessubclasses genannt. Die Unterklasse kann die Attribute und Methoden der Super-Klasse (en) erben oder ableiten, sofern die Superklasse dies zulässt. Außerdem kann die Unterklasse ihre eigenen Attribute und Methoden hinzufügen und jede der übergeordneten Methoden modifizieren. Vererbung definiert eine Beziehung ist. Von einer Klasse Mammal können eine Reihe von Klassen abgeleitet werden, wie Mensch, Katze, Hund, Kuh, etc. Menschen, Katzen, Hunde und Kühe haben alle die verschiedenen Merkmale von Säugetieren. Darüber hinaus hat jeder seine eigenen Besonderheiten. Es kann gesagt werden, dass eine Kuh ein Säugetier ist. Vererbungstypen: Einzelvererbung. Eine Unterklasse leitet sich von einer einzigen Superklasse ab. Mehrfachvererbung. Eine Unterklasse leitet sich aus mehr als einer Superklasse ab. Mehrstufige Vererbung. Eine Unterklasse leitet sich von einer Superklasse ab, die wiederum von einer anderen Klasse abgeleitet ist und so weiter. Hierarchische Vererbung. Eine Klasse hat eine Anzahl von Unterklassen, von denen jede nachfolgende Unterklassen aufweisen kann, die für eine Anzahl von Ebenen fortgesetzt werden, um so eine Baumstruktur zu bilden. Hybride Vererbung. Eine Kombination von mehrfacher und mehrstufiger Vererbung, um eine Gitterstruktur zu bilden. Die folgende Abbildung zeigt die Beispiele für verschiedene Vererbungstypen. Polymorphismus Polymorphismus ist ursprünglich ein griechisches Wort, das die Fähigkeit, mehrere Formen zu nehmen bedeutet. Im objektorientierten Paradigma, Polymorphismus impliziert die Verwendung von Operationen auf unterschiedliche Weise, je nach dem, auf dem sie arbeiten. Polymorphismus ermöglicht, dass Objekte mit unterschiedlichen internen Strukturen eine gemeinsame externe Schnittstelle haben. Polymorphismus ist besonders effektiv bei der Umsetzung von Vererbung. Wir betrachten zwei Klassen, Circle und Square, jeweils mit einer Methode findArea (). Obwohl der Name und der Zweck der Methoden in den Klassen dieselben sind, ist die interne Implementierung, d. h. die Prozedur der Berechnung des Bereichs, für jede Klasse unterschiedlich. Wenn ein Objekt der Klasse Circle seine findArea () - Methode aufruft, findet die Operation den Bereich des Kreises ohne Konflikt mit der findArea () - Methode der Square-Klasse. Verallgemeinerung und Spezialisierung Verallgemeinerung und Spezialisierung stellen eine Hierarchie der Beziehungen zwischen Klassen dar, in denen Unterklassen von Superklassen erben. Verallgemeinerung In dem Verallgemeinerungsprozess werden die gemeinsamen Merkmale von Klassen zu einer Klasse in einer höheren Hierarchieebene kombiniert, d. h. Unterklassen werden kombiniert, um eine verallgemeinerte Superklasse zu bilden. Es stellt eine ist eine Art von Beziehung. Zum Beispiel ist Auto eine Art Landfahrzeug oder Schiff ist eine Art von Wasserfahrzeug. Spezialisierung Spezialisierung ist der umgekehrte Prozess der Generalisierung. Hier werden die Unterscheidungsmerkmale von Gruppen von Objekten verwendet, um spezialisierte Klassen aus existierenden Klassen zu bilden. Man kann sagen, dass die Unterklassen die spezialisierten Versionen der Superklasse sind. Die folgende Abbildung zeigt ein Beispiel für Verallgemeinerung und Spezialisierung. Links und Association Ein Link stellt eine Verbindung dar, durch die ein Objekt mit anderen Objekten zusammenarbeitet. Rumbaugh definiert sie als eine physische oder begriffliche Verbindung zwischen Objekten. Durch einen Link kann ein Objekt die Methoden aufrufen oder durch ein anderes Objekt navigieren. Ein Link stellt die Beziehung zwischen zwei oder mehreren Objekten dar. Vereinigung ist eine Gruppe von Verbindungen mit gemeinsamen Struktur und gemeinsames Verhalten. Vereinigung stellt die Beziehung zwischen Objekten einer oder mehrerer Klassen dar. Eine Verknüpfung kann als Instanz einer Assoziation definiert werden. Assoziationsgrad Ein Assoziationsgrad bezeichnet die Anzahl der an einer Verbindung beteiligten Klassen. Der Grad kann unär, binär oder ternär sein. Eine unäre Beziehung verbindet Objekte derselben Klasse. Eine binäre Beziehung verbindet Objekte von zwei Klassen. Eine ternäre Beziehung verbindet Objekte von drei oder mehr Klassen. Kardinalitätsverhältnisse von Assoziationen Die Kardinalität einer binären Assoziation bezeichnet die Anzahl der an einer Assoziation teilnehmenden Instanzen. Es gibt drei Arten von Kardinalitätsverhältnissen, nämlich: OnetoOne. Ein einzelnes Objekt der Klasse A ist einem einzelnen Objekt der Klasse B zugeordnet. OnetoMany. Ein einziges Objekt der Klasse A ist mit vielen Objekten der Klasse B verknüpft. ManytoMany. Ein Objekt der Klasse A kann mit vielen Objekten der Klasse B assoziiert sein, und umgekehrt kann ein Objekt der Klasse B mit vielen Objekten der Klasse A assoziiert werden. Aggregation oder Zusammensetzung Aggregation oder Komposition ist eine Beziehung zwischen Klassen, durch die eine Klasse gebildet werden kann Einer beliebigen Kombination von Objekten anderer Klassen. Sie ermöglicht es, Objekte direkt in den Körper anderer Klassen zu legen. Aggregation wird als eine partof oder hasa Beziehung bezeichnet, mit der Fähigkeit, aus dem Ganzen zu seinen Teilen zu navigieren. Ein Aggregatobjekt ist ein Objekt, das aus einem oder mehreren anderen Objekten besteht. In der Beziehung, ein Auto hat einen Motor, Auto ist das ganze Objekt oder das Aggregat, und der Motor ist ein Teil des Autos. Aggregation kann bedeuten: Physische Eindämmung. Beispielsweise besteht ein Computer aus Monitor, CPU, Maus, Tastatur und so weiter. Begriffsbegrenzung. Beispiel, shareholder hasa Anteil. Vorteile des Objektmodells Nachdem wir die Kernkonzepte der Objektorientierung durchlaufen haben, wäre es sinnvoll, die Vorteile dieses Modells zu beachten. Die Vorteile der Verwendung des Objekt-Modells sind: Es hilft bei der schnelleren Entwicklung von Software. Es ist einfach zu pflegen. Angenommen, ein Modul entwickelt einen Fehler, dann kann ein Programmierer das jeweilige Modul reparieren, während die anderen Teile der Software noch aktiv sind. Es unterstützt relativ problemlose Upgrades. Es ermöglicht die Wiederverwendung von Objekten, Designs und Funktionen. Es reduziert Entwicklungsrisiken, insbesondere bei der Integration komplexer Systeme. Objektorientiertes System Wir wissen, dass die OOM-Technik (Object-Oriented Modeling) die Dinge in einer Anwendung visualisiert, indem sie Modelle verwendet, die um Objekte herum organisiert sind. Jede Software-Entwicklung Ansatz geht durch die folgenden Phasen: In der objektorientierten Software-Engineering identifiziert und organisiert der Software-Entwickler die Anwendung in Bezug auf Objekt-orientierte Konzepte, vor ihrer endgültigen Darstellung in einer bestimmten Programmiersprache oder Software-Tools. Phasen der objektorientierten Softwareentwicklung Die wesentlichen Phasen der Softwareentwicklung mit objektorientierter Methodik sind objektorientierte Analyse, objektorientiertes Design und objektorientierte Implementierung. ObjectOriented Analysis In diesem Stadium wird das Problem formuliert, Benutzeranforderungen identifiziert und dann ein Modell auf der Grundlage von Realworld-Objekten erstellt. Die Analyse erzeugt Modelle, wie das gewünschte System funktionieren soll und wie es entwickelt werden muss. Die Modelle enthalten keine Implementierungsdetails, so dass sie von jedem nichttechnischen Anwendungsexperten verstanden und geprüft werden können. Objektorientiertes Design Objektorientiertes Design umfasst zwei Hauptstadien, nämlich Systemdesign und Objektdesign. Systemdesign In dieser Phase wird die komplette Architektur des gewünschten Systems entworfen. Das System ist als ein Satz von interagierenden Subsystemen konzipiert, der wiederum aus einer Hierarchie von interagierenden Objekten besteht, die in Klassen gruppiert sind. Die Systemgestaltung erfolgt sowohl nach dem Systemanalysemodell als auch nach der vorgeschlagenen Systemarchitektur. Dabei liegt der Schwerpunkt auf den Objekten des Systems und nicht auf den Prozessen im System. Objektdesign In dieser Phase wird ein Entwurfsmodell entwickelt, das sowohl auf den Modellen, die in der Systemanalysephase entwickelt wurden, als auch auf der Architektur, die in der Systemdesignphase entworfen wurde, basiert. Alle Klassen werden identifiziert. Der Designer entscheidet, ob neue Klassen von Grund auf neu erstellt werden sollen, alle vorhandenen Klassen können in ihrer ursprünglichen Form verwendet werden oder neue Klassen sollten von den vorhandenen Klassen vererbt werden. Die Assoziationen zwischen den identifizierten Klassen werden eingerichtet und die Hierarchien der Klassen werden identifiziert. Außerdem entwirft der Entwickler die internen Details der Klassen und deren Zuordnungen, d. h. die Datenstruktur für jedes Attribut und die Algorithmen für die Operationen. Objektorientierte Implementierung und Testing In diesem Stadium wird das im Objektdesign entwickelte Designmodell in eine entsprechende Programmiersprache oder ein Software-Tool in Code übersetzt. Die Datenbanken werden erstellt und die spezifischen Hardwareanforderungen ermittelt. Sobald der Code in Form ist, wird er mit speziellen Techniken getestet, um die Fehler im Code zu identifizieren und zu entfernen. Objektorientierte Prinzipien Prinzipien von objektorientierten Systemen Das Konzept der objektorientierten Systeme basiert auf dem Objektmodell. Es gibt zwei Kategorien von Elementen in einem objektorientierten System: Major Elements. Von Dur ist gemeint, dass, wenn ein Modell keines dieser Elemente hat, es aufhört, objektorientiert zu sein. Die vier wichtigsten Elemente sind: Kleine Elemente. Von kleinem, ist es gemeint, dass diese Elemente nützlich sind, aber nicht unentbehrlicher Teil des Objektmodells. Die drei kleinen Elemente sind: Abstraktion Abstraktion bedeutet, sich auf die wesentlichen Merkmale eines Elements oder Objekts im OOP zu konzentrieren und dabei seine äußeren oder zufälligen Eigenschaften zu ignorieren. Die wesentlichen Merkmale beziehen sich auf den Kontext, in dem das Objekt verwendet wird. Grady Booch hat die Abstraktion folgendermaßen definiert: Eine Abstraktion bezeichnet die wesentlichen Merkmale eines Objekts, die es von allen anderen Objekten unterscheiden und somit knackig definierte begriffliche Grenzen gegenüber der Perspektive des Betrachters schaffen. Beispiel. Wenn eine Klasse Student entworfen wird, werden die Attribute Registrierungsnummer, Name, Kurs und Adresse eingeschlossen, während Merkmale wie pulserate und sizeofshoe eliminiert werden, da sie in der Perspektive der Bildungseinrichtung irrelevant sind. Encapsulation Encapsulation ist der Prozess der Bindung sowohl Attribute und Methoden zusammen innerhalb einer Klasse. Durch Kapselung können die inneren Details einer Klasse von außen verborgen werden. Die Klasse verfügt über Methoden, die Benutzeroberflächen zur Verfügung stellen, mit denen die von der Klasse bereitgestellten Dienste verwendet werden können. Modularität Modularität ist der Prozess der Zerlegung eines Problems (Programm) in eine Reihe von Modulen, um die Gesamtkomplexität des Problems zu reduzieren. Booch hat Modularität definiert als: Modularität ist die Eigenschaft eines Systems, das in einen Satz von zusammenhängenden und locker gekoppelten Modulen zerlegt wurde. Modularität ist intrinsisch mit Verkapselung verbunden. Modularität kann als ein Weg abgebildet werden, um gekapselte Abstraktionen in reale physikalische Module mit hoher Kohäsion innerhalb der Module abzubilden und deren Intermodulinteraktion oder Kopplung gering ist. In Grady Boochs Worten, Hierarchie ist die Rangfolge oder Reihenfolge der Abstraktion. Durch Hierarchie kann ein System aus miteinander verbundenen Subsystemen gebildet werden, die ihre eigenen Subsysteme haben können und so weiter, bis die Komponenten der kleinsten Ebene erreicht sind. Es nutzt das Prinzip der Teilung und Eroberung. Hierarchie erlaubt Code-Wiederverwendbarkeit. Die beiden Arten von Hierarchien in OOA sind: ISA Hierarchie. Es definiert die hierarchische Beziehung in der Vererbung, wobei aus einer Superklasse eine Anzahl von Unterklassen abgeleitet werden kann, die wiederum Unterklassen und so weiter haben können. Zum Beispiel, wenn wir eine Klasse Rose aus einer Klasse Blume ableiten, können wir sagen, dass eine Rose isa Blume. PARTOF Hierarchie. Sie definiert die hierarchische Beziehung in der Aggregation, durch die eine Klasse aus anderen Klassen bestehen kann. Zum Beispiel besteht eine Blume aus Kelchblättern, Blütenblättern, Staubblättern und Karpellen. Es kann gesagt werden, dass ein Blütenblatt ein Teil der Blume ist. Nach den Theorien des abstrakten Datentyps ist ein Typ eine Charakterisierung eines Satzes von Elementen. In OOP wird eine Klasse als Typ dargestellt, der Eigenschaften besitzt, die sich von anderen Typen unterscheiden. Typing ist die Durchsetzung der Vorstellung, dass ein Objekt eine Instanz einer einzelnen Klasse oder eines Typs ist. Es erzwingt auch, dass Gegenstände verschiedener Typen nicht generell vertauscht werden können und nur in sehr eingeschränkter Weise vertauscht werden können, wenn dies unbedingt erforderlich ist. Die beiden Typen der Eingabe sind: Strong Typing. Hier wird die Operation an einem Objekt zum Zeitpunkt der Kompilierung überprüft, wie in der Programmiersprache Eiffel. Schwach Typing. Hier können Nachrichten an jede Klasse gesendet werden. Die Operation wird nur zum Zeitpunkt der Ausführung überprüft, wie in der Programmiersprache Smalltalk. Gleichzeitigkeit Gleichzeitigkeit in Betriebssystemen ermöglicht die Ausführung mehrerer Aufgaben oder Prozesse gleichzeitig. Wenn ein einzelner Prozess in einem System existiert, wird gesagt, dass es einen einzelnen Thread der Steuerung gibt. Allerdings haben die meisten Systeme mehrere Threads, einige aktive, einige warten auf CPU, einige suspendiert, und einige beendet. Systeme mit mehreren CPUs erlauben inhärent gleichzeitige Threads der Steuerung, aber Systeme, die auf einer einzigen CPU laufen, verwenden geeignete Algorithmen, um den Threads eine gerechte CPU-Zeit zu geben, um gleichzeitig Parallelität zu ermöglichen. In einer objektorientierten Umgebung gibt es aktive und inaktive Objekte. Die aktiven Objekte verfügen über unabhängige Threads des Steuerelements, die gleichzeitig mit Threads anderer Objekte ausgeführt werden können. Die aktiven Objekte synchronisieren sich untereinander sowie mit rein sequentiellen Objekten. Persistenz Ein Objekt belegt einen Speicherraum und existiert für einen bestimmten Zeitraum. In der traditionellen Programmierung, war die Lebensdauer eines Objekts in der Regel die Lebensdauer der Ausführung des Programms, die es erstellt. In Dateien oder Datenbanken ist die Objektlebensdauer länger als die Dauer des Prozesses, der das Objekt erzeugt. Diese Eigenschaft, durch die ein Objekt weiterhin besteht, auch nachdem sein Schöpfer aufhört zu existieren, wird als Persistenz bezeichnet. Objektorientierte Analyse In der Systemanalyse bzw. objektorientierten Analysephase der Softwareentwicklung werden die Systemanforderungen festgelegt, die Klassen identifiziert und die Beziehungen zwischen Klassen identifiziert. Die drei Analysetechniken, die in Verbindung mit einander für die objektorientierte Analyse verwendet werden, sind Objektmodellierung, dynamische Modellierung und funktionale Modellierung. Objektmodellierung Objektmodellierung entwickelt die statische Struktur des Softwaresystems in Bezug auf Objekte. Es identifiziert die Objekte, die Klassen, in die die Objekte gruppiert werden können, und die Beziehungen zwischen den Objekten. Es kennzeichnet auch die wichtigsten Attribute und Operationen, die jede Klasse kennzeichnen. Der Prozess der Objektmodellierung kann in den folgenden Schritten visualisiert werden: Identifizieren von Objekten und Gruppierung in Klassen Identifizieren der Beziehungen zwischen Klassen Erstellen von Benutzerobjektmodelldiagrammen Definieren von Benutzerobjektattributen Definieren Sie die Operationen, die auf den Klassen ausgeführt werden sollen Überprüfen Sie das Glossar Dynamische Modellierung Nach dem Static Verhalten des Systems analysiert, sein Verhalten in Bezug auf Zeit und externe Veränderungen untersucht werden. Dies ist der Zweck der dynamischen Modellierung. Dynamische Modellierung kann definiert werden, um zu beschreiben, wie ein einzelnes Objekt auf Ereignisse reagiert, entweder interne Ereignisse, die durch andere Objekte ausgelöst werden, oder externe Ereignisse, die von der Außenwelt ausgelöst werden. Der Prozess der dynamischen Modellierung kann in den folgenden Schritten visualisiert werden: Identifizieren von Zuständen jedes Objekts Identifizieren von Ereignissen und Analysieren der Anwendbarkeit von Aktionen Konstruieren Sie ein dynamisches Modelldiagramm mit Zustandsübergangsdiagrammen Expressieren Sie jeden Status in Form von Objektattributen Überprüfen Sie die übergebenen Statetransitiondiagramme Functional Modellierung Funktionsmodellierung ist die letzte Komponente der objektorientierten Analyse. Das Funktionsmodell zeigt die Prozesse an, die in einem Objekt ausgeführt werden und wie sich die Daten zwischen den Methoden ändern. Es legt die Bedeutung der Operationen der Objektmodellierung und der Aktionen der dynamischen Modellierung fest. Das funktionale Modell entspricht dem Datenflussdiagramm der traditionellen strukturierten Analyse. Der Prozess der funktionalen Modellierung kann in den folgenden Schritten visualisiert werden: Identifizieren Sie alle Inputs und Outputs Konstruieren Sie Datenflussdiagramme, die funktionale Abhängigkeiten anzeigen State der Zweck jeder Funktion Identifizieren von Constraints Geben Sie Optimierungskriterien Structured Analysis vs Objektorientierte Analyse Das Strukturierte AnalysisStructured Design (SASD ) Ansatz ist der traditionelle Ansatz der Software-Entwicklung basierend auf dem Wasserfall-Modell. Die Phasen der Entwicklung eines Systems, das SASD verwendet, sind: Machbarkeitsstudie Anforderungsanalyse und Spezifikation Systemdesign-Implementierung Nach der Implementierung Im Folgenden werden die relativen Vorteile und Nachteile eines strukturierten Analyseansatzes und eines objektorientierten Analyseansatzes betrachtet. VorteileDieVorteile der objektorientierten Analyse konzentriert sich auf Daten und nicht auf die Verfahren wie in der Strukturierten Analyse. Funktionalität ist innerhalb von Objekten eingeschränkt. Dies kann ein Problem für Systeme darstellen, die inhärent prozeduraler oder rechnerischer Natur sind. Die Prinzipien der Kapselung und der versteckten Daten helfen dem Entwickler, Systeme zu entwickeln, die nicht durch andere Teile des Systems manipuliert werden können. Es kann nicht identifiziert werden, welche Objekte ein optimales Systemdesign erzeugen würden. Die Prinzipien der Kapselung und der versteckten Daten helfen dem Entwickler, Systeme zu entwickeln, die nicht durch andere Teile des Systems manipuliert werden können. Die objektorientierten Modelle zeigen nicht leicht die Kommunikation zwischen den Objekten im System. Es ermöglicht eine effektive Verwaltung der Software-Komplexität durch die Tugend der Modularität. Alle Schnittstellen zwischen den Objekten können nicht in einem einzigen Diagramm dargestellt werden. Es kann von kleinen zu großen Systemen mit größerer Leichtigkeit aufgerüstet werden als in Systemen nach strukturierter Analyse. VorteileDieVorteile der strukturierten Analyse Da es im Gegensatz zum Bottom-up-Ansatz der objektorientierten Analyse zu einem Top-down-Ansatz kommt, kann er leichter verstanden werden als OOA. In traditionellen strukturierten Analysemodellen sollte eine Phase vor der nächsten Phase abgeschlossen werden. Dies stellt ein Problem im Design, insbesondere wenn Fehler auftauchen oder Anforderungen ändern. Es basiert auf Funktionalität. Der allgemeine Zweck wird identifiziert und dann wird die funktionelle Zersetzung für die Entwicklung der Software durchgeführt. Die Betonung gibt nicht nur ein besseres Verständnis des Systems, sondern erzeugt auch vollständigere Systeme. Die anfänglichen Kosten des Konstruierens des Systems sind hoch, da das gesamte System sofort entworfen werden muß, so daß eine sehr geringe Option zum späteren Hinzufügen von Funktionalität verbleibt. Die darin enthaltenen Spezifikationen sind in einfacher englischer Sprache verfasst und können daher von nichttechnischem Personal leichter analysiert werden. Es unterstützt keine Wiederverwendbarkeit von Code. So sind die Zeit und die Kosten der Entwicklung von Natur aus hoch. Dynamische Modellierung Das dynamische Modell repräsentiert die zeitabhängigen Aspekte eines Systems. Es geht um die zeitlichen Änderungen der Zustände der Objekte in einem System. Die Hauptkonzepte sind: Zustand, der die Situation zu einer bestimmten Bedingung während der Lebenszeit eines Gegenstandes ist. Übergang, eine Änderung des Zustandsereignisses, ein Ereignis, das Übergänge Aktion auslöst, eine ununterbrochene und atomare Berechnung, die aufgrund eines Ereignisses auftritt, und Gleichzeitigkeit von Übergängen. Eine Zustandsmaschine modelliert das Verhalten eines Objekts, während es durch eine Anzahl von Zuständen in seiner Lebenszeit aufgrund einiger Ereignisse sowie der Aktionen, die aufgrund der Ereignisse auftreten, durchläuft. Eine Zustandsmaschine wird durch ein Zustandsübergangsdiagramm graphisch dargestellt. Zustände und Zustandsübergänge Der Zustand ist eine Abstraktion, die durch die Werte der Attribute gegeben wird, die das Objekt zu einem bestimmten Zeitpunkt hat. Es ist eine Situation, die für einen endlichen Zeitraum in der Lebenszeit eines Objekts auftritt, in dem es bestimmte Bedingungen erfüllt, bestimmte Tätigkeiten ausführt oder auf bestimmte Ereignisse wartet. In Zustandsübergangsdiagrammen wird ein Zustand durch abgerundete Rechtecke dargestellt. Teile eines Staates. Ein String unterscheidet einen Zustand von einem anderen. Ein Staat darf keinen Namen haben. EntryExit-Aktionen. Es bezeichnet die Tätigkeiten, die beim Eintritt und beim Verlassen des Staates durchgeführt werden. Interne Übergänge. Die Änderungen innerhalb eines Zustandes, die keine Änderung im Zustand verursachen. Stoffe. Staaten innerhalb der Staaten. Anfangs - und Endzustände Der Standardausgangszustand eines Objekts wird als Anfangszustand bezeichnet. Der endgültige Zustand zeigt den Abschluss der Ausführung der Zustandsmaschine an. Der Anfangs - und der Endzustand sind Pseudostatus und dürfen nicht die Teile eines regulären Zustandes außer Namen haben. In Zustandsübergangsdiagrammen wird der Anfangszustand durch einen gefüllten schwarzen Kreis dargestellt. Der endgültige Zustand wird durch einen gefüllten schwarzen Kreis dargestellt, der in einem anderen ungefüllten schwarzen Kreis umkreist ist. Übergang Ein Übergang bezeichnet eine Änderung des Zustands eines Objekts. Wenn sich ein Objekt in einem bestimmten Zustand befindet, wenn ein Ereignis auftritt, kann das Objekt bestimmte Aktivitäten unter bestimmten Bedingungen ausführen und den Status ändern. In diesem Fall wird angenommen, dass ein Statetransition aufgetreten ist. Der Übergang gibt die Beziehung zwischen dem ersten Zustand und dem neuen Zustand. Ein Übergang wird grafisch durch einen festen gerichteten Bogen vom Quellzustand zum Zielzustand dargestellt. Die fünf Teile eines Übergangs sind: Quellzustand. Der Staat durch den Übergang betroffen. Ereignisauslöser. Das Auftreten, durch das ein Objekt im Quellzustand einen Übergang erfährt, wenn die Schutzbedingung erfüllt ist. Guard Zustand. Ein boolescher Ausdruck, der, wenn True, einen Übergang beim Empfang des Ereignisauslösers bewirkt. Handlung. Eine ununterbrochene und atomare Berechnung, die aufgrund eines Ereignisses auf dem Quellobjekt auftritt. Zielzustand. Der Zielzustand nach Beendigung des Übergangs. Nehmen wir an, dass eine Person ein Taxi vom Platz X zum Platz Y nimmt. Die Zustände der Person können sein: Warten (warten auf Taxi), Reiten (er hat ein Taxi und reist in ihm) und erreicht (er hat das erreicht Reiseziel). Die folgende Abbildung zeigt den Zustandsübergang. Ereignisse sind einige Vorkommen, die einen Zustandsübergang eines Objekts oder einer Gruppe von Objekten auslösen können. Ereignisse haben einen Ort in Zeit und Raum, aber nicht über einen Zeitraum mit ihm verbunden. Ereignisse sind in der Regel mit einigen Aktionen assoziiert. Beispiele für Ereignisse sind Mausklick, Tastendruck, Interrupt, Stacküberlauf usw. Ereignisse, die Übergänge auslösen, werden neben dem Übergangsbogen in Zustandsdiagrammen geschrieben. Wenn man das in der obigen Figur gezeigte Beispiel betrachtet, findet der Übergang vom Wartezustand zum Reitzustand statt, wenn die Person ein Taxi bekommt. Ebenso wird der Endzustand erreicht, wenn er das Ziel erreicht. Diese beiden Ereignisse können als Ereignisse GetTaxi und ReachDestination bezeichnet werden. Die folgende Abbildung zeigt die Ereignisse in einer Zustandsmaschine. Externe und interne Ereignisse Externe Ereignisse sind Ereignisse, die von einem Benutzer des Systems zu den Objekten im System übergeben werden. Zum Beispiel, Mausklick oder Tastendruck durch den Benutzer sind externe Ereignisse. Interne Ereignisse sind diejenigen, die von einem Objekt zu einem anderen Objekt innerhalb eines Systems übergeben werden. Beispielsweise Stapelüberlauf, ein Divisionsfehler usw. Verzögerte Ereignisse Verzögerte Ereignisse sind diejenigen, die nicht sofort vom Objekt in dem aktuellen Zustand behandelt werden, sondern in einer Warteschlange aufgereiht sind, so dass sie von dem Objekt in einem anderen Zustand behandelt werden können zu einem späteren Zeitpunkt. Ereignisklassen Ereignisklasse gibt eine Gruppe von Ereignissen mit gemeinsamer Struktur und Verhalten an. Wie bei Objektklassen können auch Ereignisklassen in einer hierarchischen Struktur organisiert sein. Event-Klassen können Attribute zugeordnet werden, wobei es sich um ein implizites Attribut handelt. Zum Beispiel können wir die Ereignisse der Abfahrt eines Fluges einer Fluggesellschaft betrachten, die wir in die folgende Klasse einteilen können: FlightDeparts (FlightNo, FromCity, ToCity, Route) Aktivität ist eine Operation auf die Zustände eines Objekts, das etwas Zeit benötigt Periode. Sie sind die laufenden Ausführungen innerhalb eines Systems, das unterbrochen werden kann. Aktivitäten werden in Aktivitätsdiagrammen dargestellt, die den Fluss von einer Aktivität zur anderen darstellen. Eine Aktion ist eine atomare Operation, die als Ergebnis bestimmter Ereignisse ausgeführt wird. Atom bedeutet, dass Aktionen nicht unterbrechbar sind, d. H. Wenn eine Aktion mit der Ausführung beginnt, läuft sie in Abschluß, ohne durch irgendein Ereignis unterbrochen zu werden. Eine Aktion kann auf einem Objekt ausgeführt werden, auf dem ein Ereignis ausgelöst wurde, oder auf anderen Objekten, die für dieses Objekt sichtbar sind. Eine Reihe von Aktionen umfasst eine Aktivität. Ein - und Ausfahraktionen Eintragsaktion ist die Aktion, die bei der Eingabe eines Zustands ausgeführt wird, unabhängig vom Übergang, der in ihn hineinführt. Ebenso wird die Aktion, die ausgeführt wird, während ein Zustand verlassen wird, unabhängig von dem Übergang, der aus ihm herausgeführt wird, eine Exit-Aktion genannt. Szenario ist eine Beschreibung einer bestimmten Abfolge von Aktionen. Es zeigt das Verhalten von Objekten, die sich einer bestimmten Aktionsreihe unterziehen. The primary scenarios depict the essential sequences and the secondary scenarios depict the alternative sequences. Diagrams for Dynamic Modelling There are two primary diagrams that are used for dynamic modelling: Interaction Diagrams Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of objects, their relationships, and the message that the objects send and receive. Thus, an interaction models the behavior of a group of interrelated objects. The two types of interaction diagrams are: Sequence Diagram . It represents the temporal ordering of messages in a tabular manner. Collaboration Diagram . It represents the structural organization of objects that send and receive messages through vertices and arcs. State Transition Diagram State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates the sequences of states that an object goes through in its lifetime, the transitions of the states, the events and conditions causing the transition and the responses due to the events. Concurrency of Events In a system, two types of concurrency may exist. They are: System Concurrency Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of state machines, where each state machine executes concurrently with others. Concurrency within an Object Here, an object can issue concurrent events. An object may have states that are composed of sub-states, and concurrent events may occur in each of the sub-states. Concepts related to concurrency within an object are as follows: (a) Simple and Composite States A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity of a state machine. Sub-states can be nested to any number of levels. Composite states may have either sequential sub-states or concurrent sub-states. (b) Sequential Sub-states In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after another in a sequential manner. There is at most one initial state and one final state in these state machines. The following figure illustrates the concept of sequential sub-states. (c) Concurrent Sub-states In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently executing state machines within it. Each of the state machines has its own initial and final states. If one concurrent sub-state reaches its final state before the other, control waits at its final state. When all the nested state machines reach their final states, the sub-states join back to a single flow. The following figure shows the concept of concurrent sub-states. Functional Modelling Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of what the system is supposed to do. It defines the function of the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the functional derivation of the data values without indicating how they are derived when they are computed, or why they need to be computed. Data Flow Diagrams Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation. Rumbaugh et al. have defined DFD as, A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects. The four main parts of a DFD are: The other parts of a DFD are: Features of a DFD Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function. Representation in DFD . A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values. Beispiel. The following figure shows a process ComputeHCFLCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple). Data Flows Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow. Representation in DFD . A data flow is represented by a directed arc or an arrow, labelled with the name of the data item that it carries. In the above figure, Integera and Integerb represent the input data flows to the process, while L. C.M. and H. C.F. are the output data flows. A data flow may be forked in the following cases: The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value. The data flow contains an aggregate value, and each of the components is sent to different places as shown in the following figure. Here, each of the forked components is labelled. Actors are the active objects that interact with the system by either producing data and inputting them to the system, or consuming data produced by the system. In other words, actors serve as the sources and the sinks of data. Representation in DFD: An actor is represented by a rectangle. Actors are connected to the inputs and outputs and lie on the boundary of the DFD. Beispiel. The following figure shows the actors, namely, Customer and SalesClerk in a counter sales system. Data Stores Data stores are the passive objects that act as a repository of data. Unlike actors, they cannot perform any operations. They are used to store data and retrieve the stored data. They represent a data structure, a disk file, or a table in a database. Representation in DFD . A data store is represented by two parallel lines containing the name of the data store. Each data store is connected to at least one process. Input arrows contain information to modify the contents of the data store, while output arrows contain information retrieved from the data store. When a part of the information is to be retrieved, the output arrow is labelled. An unlabelled arrow denotes full data retrieval. A two-way arrow implies both retrieval and update. Beispiel. The following figure shows a data store, SalesRecord, that stores the details of all sales. Input to the data store comprises of details of sales such as item, billing amount, date, etc. To find the average sales, the process retrieves the sales records and computes the average. Constraints Constraints specify the conditions or restrictions that need to be satisfied over time. They allow adding new rules or modifying existing ones. Constraints can appear in all the three models of object-oriented analysis. In Object Modelling, the constraints define the relationship between objects. They may also define the relationship between the different values that an object may take at different times. In Dynamic Modelling, the constraints define the relationship between the states and events of different objects. In Functional Modelling, the constraints define the restrictions on the transformations and computations. Representation . A constraint is rendered as a string within braces. Beispiel. The following figure shows a portion of DFD for computing the salary of employees of a company that has decided to give incentives to all employees of the sales department and increment the salary of all employees of the HR department. It can be seen that the constraint causes incentive to be calculated only if the department is sales and the constraint causes increment to be computed only if the department is HR. Control Flows A process may be associated with a certain Boolean value and is evaluated only if the value is true, though it is not a direct input to the process. These Boolean values are called the control flows. Representation in DFD . Control flows are represented by a dotted arc from the process producing the Boolean value to the process controlled by them. Beispiel. The following figure represents a DFD for arithmetic division. The Divisor is tested for non-zero. If it is not zero, the control flow OK has a value True and subsequently the Divide process computes the Quotient and the Remainder. Developing the DFD Model of a System In order to develop the DFD model of a system, a hierarchy of DFDs are constructed. The top-level DFD comprises of a single process and the actors interacting with it. At each successive lower level, further details are gradually included. A process is decomposed into sub-processes, the data flows among the sub-processes are identified, the control flows are determined, and the data stores are defined. While decomposing a process, the data flow into or out of the process should match the data flow at the next level of DFD. Beispiel. Let us consider a software system, Wholesaler Software, that automates the transactions of a wholesale shop. The shop sells in bulks and has a clientele comprising of merchants and retail shop owners. Each customer is asked to register with hisher particulars and is given a unique customer code, CCode. Once a sale is done, the shop registers its details and sends the goods for dispatch. Each year, the shop distributes Christmas gifts to its customers, which comprise of a silver coin or a gold coin depending upon the total sales and the decision of the proprietor. The functional model for the Wholesale Software is given below. The figure below shows the top-level DFD. It shows the software as a single process and the actors that interact with it. The actors in the system are: In the next level DFD, as shown in the following figure, the major processes of the system are identified, the data stores are defined and the interaction of the processes with the actors, and the data stores are established. In the system, three processes can be identified, which are: Register Customers Process Sales Ascertain Gifts The data stores that will be required are: The following figure shows the details of the process Register Customer. There are three processes in it, Verify Details, Generate CCode, and Update Customer Details. When the details of the customer are entered, they are verified. If the data is correct, CCode is generated and the data store Customer Details is updated. The following figure shows the expansion of the process Ascertain Gifts. It has two processes in it, Find Total Sales and Decide Type of Gift Coin. The Find Total Sales process computes the yearly total sales corresponding to each customer and records the data. Taking this record and the decision of the proprietor as inputs, the gift coins are allotted through Decide Type of Gift Coin process. Advantages and Disadvantages of DFD DFDs depict the boundaries of a system and hence are helpful in portraying the relationship between the external objects and the processes within the system. DFDs take a long time to create, which may not be feasible for practical purposes. They help the users to have a knowledge about the system. DFDs do not provide any information about the time-dependent behavior, i. e. they do not specify when the transformations are done. The graphical representation serves as a blueprint for the programmers to develop a system. They do not throw any light on the frequency of computations or the reasons for computations. DFDs provide detailed information about the system processes. The preparation of DFDs is a complex process that needs considerable expertise. Also, it is difficult for a non-technical person to understand. They are used as a part of the system documentation. The method of preparation is subjective and leaves ample scope to be imprecise. Relationship between Object, Dynamic, and Functional Models The Object Model, the Dynamic Model, and the Functional Model are complementary to each other for a complete Object-Oriented Analysis. Object modelling develops the static structure of the software system in terms of objects. Thus it shows the doers of a system. Dynamic Modelling develops the temporal behavior of the objects in response to external events. It shows the sequences of operations performed on the objects. Functional model gives an overview of what the system should do. Functional Model and Object Model The four main parts of a Functional Model in terms of object model are: Process . Processes imply the methods of the objects that need to be implemented. Actors . Actors are the objects in the object model. Data Stores . These are either objects in the object model or attributes of objects. Data Flows . Data flows to or from actors represent operations on or by objects. Data flows to or from data stores represent queries or updates. Functional Model and Dynamic Model The dynamic model states when the operations are performed, while the functional model states how they are performed and which arguments are needed. As actors are active objects, the dynamic model has to specify when it acts. The data stores are passive objects and they only respond to updates and queries therefore the dynamic model need not specify when they act. Object Model and Dynamic Model The dynamic model shows the status of the objects and the operations performed on the occurrences of events and the subsequent changes in states. The state of the object as a result of the changes is shown in the object model. UML Analysis Model The Unified Modeling Language (UML) is a graphical language for OOAD that gives a standard way to write a software systems blueprint. It helps to visualize, specify, construct, and document the artifacts of an object-oriented system. It is used to depict the structures and the relationships in a complex system. Brief History It was developed in 1990s as an amalgamation of several techniques, prominently OOAD technique by Grady Booch, OMT (Object Modeling Technique) by James Rumbaugh, and OOSE (Object Oriented Software Engineering) by Ivar Jacobson. UML attempted to standardize semantic models, syntactic notations, and diagrams of OOAD. Systems and Models in UML System . A set of elements organized to achieve certain objectives form a system. Systems are often divided into subsystems and described by a set of models. Model . Model is a simplified, complete, and consistent abstraction of a system, created for better understanding of the system. View . A view is a projection of a systems model from a specific perspective. Conceptual Model of UML The Conceptual Model of UML encompasses three major elements: Basic building blocks Rules Common mechanisms Basic Building Blocks The three building blocks of UML are: There are four kinds of things in UML, namely: Structural Things . These are the nouns of the UML models representing the static elements that may be either physical or conceptual. The structural things are class, interface, collaboration, use case, active class, components, and nodes. Behavioral Things . These are the verbs of the UML models representing the dynamic behavior over time and space. The two types of behavioral things are interaction and state machine. Grouping Things . They comprise the organizational parts of the UML models. There is only one kind of grouping thing, i. e. package. Annotational Things . These are the explanations in the UML models representing the comments applied to describe elements. Relationships are the connection between things. The four types of relationships that can be represented in UML are: Dependency . This is a semantic relationship between two things such that a change in one thing brings a change in the other. The former is the independent thing, while the latter is the dependent thing. Association . This is a structural relationship that represents a group of links having common structure and common behavior. Generalization . This represents a generalizationspecialization relationship in which subclasses inherit structure and behavior from super-classes. Realization . This is a semantic relationship between two or more classifiers such that one classifier lays down a contract that the other classifiers ensure to abide by. (c) Diagrams . A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML includes nine diagrams in all, namely: Class Diagram Object Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram UML has a number of rules so that the models are semantically self-consistent and related to other models in the system harmoniously. UML has semantic rules for the following: Common Mechanisms UML has four common mechanisms: Specifications Adornments Common Divisions Extensibility Mechanisms Specifications In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. These are the specifications. The specifications provide a semantic backplane that contains all the parts of a system and the relationship among the different paths. Adornments Each element in UML has a unique graphical notation. Besides, there are notations to represent the important aspects of an element like name, scope, visibility, etc. Common Divisions Object-oriented systems can be divided in many ways. The two common ways of division are: Division of classes and objects . A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system. Division of Interface and Implementation . An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in the interface. Extensibility Mechanisms UML is an open-ended language. It is possible to extend the capabilities of UML in a controlled manner to suit the requirements of a system. The extensibility mechanisms are: Stereotypes . It extends the vocabulary of the UML, through which new building blocks can be created out of existing ones. Tagged Values . It extends the properties of UML building blocks. Constraints . It extends the semantics of UML building blocks. UML Basic Notations UML defines specific notations for each of the building blocks. A class is represented by a rectangle having three sections: the top section containing the name of the class the middle section containing class attributes the bottom section representing operations of the class The visibility of the attributes and operations can be represented in the following ways: Public . A public member is visible from anywhere in the system. In class diagram, it is prefixed by the symbol . Private . A private member is visible only from within the class. It cannot be accessed from outside the class. A private member is prefixed by the symbol . Protected . A protected member is visible from within the class and from the subclasses inherited from this class, but not from outside. It is prefixed by the symbol . An abstract class has the class name written in italics. Beispiel. Let us consider the Circle class introduced earlier. The attributes of Circle are x-coord, y-coord, and radius. The operations are findArea(), findCircumference(), and scale(). Let us assume that x-coord and y-coord are private data members, radius is a protected data member, and the member functions are public. The following figure gives the diagrammatic representation of the class. An object is represented as a rectangle with two sections: The top section contains the name of the object with the name of the class or package of which it is an instance of. The name takes the following forms: object-name . class-name. package-name class-name . in case of anonymous objects The bottom section represents the values of the attributes. It takes the form attribute-name value. Sometimes objects are represented using rounded rectangles. Beispiel. Let us consider an object of the class Circle named c1. We assume that the center of c1 is at (2, 3) and the radius of c1 is 5. The following figure depicts the object. A component is a physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces. It represents the physical packaging of elements like classes and interfaces. Notation . In UML diagrams, a component is represented by a rectangle with tabs as shown in the figure below. Interface is a collection of methods of a class or component. It specifies the set of services that may be provided by the class or component. Notation . Generally, an interface is drawn as a circle together with its name. An interface is almost always attached to the class or component that realizes it. The following figure gives the notation of an interface. A package is an organized group of elements. A package may contain structural things like classes, components, and other packages in it. Notation . Graphically, a package is represented by a tabbed folder. A package is generally drawn with only its name. However it may have additional details about the contents of the package. See the following figures. Relationship The notations for the different types of relationships are as follows: Usually, elements in a relationship play specific roles in the relationship. A role name signifies the behavior of an element participating in a certain context. Beispiel. The following figures show examples of different relationships between classes. The first figure shows an association between two classes, Department and Employee, wherein a department may have a number of employees working in it. Worker is the role name. The 1 alongside Department and alongside Employee depict that the cardinality ratio is onetomany. The second figure portrays the aggregation relationship, a University is the wholeof many Departments. UML Structured Diagrams UML structural diagrams are categorized as follows: class diagram, object diagram, component diagram, and deployment diagram. Class Diagram A class diagram models the static view of a system. It comprises of the classes, interfaces, and collaborations of a system and the relationships between them. Class Diagram of a System Let us consider a simplified Banking System. A bank has many branches. In each zone, one branch is designated as the zonal head office that supervises the other branches in that zone. Each branch can have multiple accounts and loans. An account may be either a savings account or a current account. A customer may open both a savings account and a current account. However, a customer must not have more than one savings account or current account. A customer may also procure loans from the bank. The following figure shows the corresponding class diagram. Classes in the system: Bank, Branch, Account, Savings Account, Current Account, Loan, and Customer. Relationships: A Bank hasa number of Branches . composition, onetomany A Branch with role Zonal Head Office supervises other Branches . unary association, oneto-many A Branch hasa number of accounts . aggregation, onetomany From the class Account, two classes have inherited, namely, Savings Account and Current Account. A Customer can have one Current Account . association, onetoone A Customer can have one Savings Account . association, onetoone A Branch hasa number of Loans . aggregation, onetomany A Customer can take many loans . association, onetomany Object Diagram An object diagram models a group of objects and their links at a point of time. It shows the instances of the things in a class diagram. Object diagram is the static part of an interaction diagram. Beispiel. The following figure shows an object diagram of a portion of the class diagram of the Banking System. Component Diagram Component diagrams show the organization and dependencies among a group of components. Component diagrams comprise of: Components Interfaces Relationships Packages and Subsystems (optional) Component diagrams are used for: constructing systems through forward and reverse engineering. modeling configuration management of source code files while developing a system using an object-oriented programming language. representing schemas in modeling databases. modeling behaviors of dynamic systems. The following figure shows a component diagram to model a systems source code that is developed using C. It shows four source code files, namely, myheader. h, otherheader. h, priority. cpp, and other. cpp. Two versions of myheader. h are shown, tracing from the recent version to its ancestor. The file priority. cpp has compilation dependency on other. cpp. The file other. cpp has compilation dependency on otherheader. h. Deployment Diagram A deployment diagram puts emphasis on the configuration of runtime processing nodes and their components that live on them. They are commonly comprised of nodes and dependencies, or associations between the nodes. Deployment diagrams are used to: model devices in embedded systems that typically comprise of software-intensive collection of hardware. represent the topologies of clientserver systems. model fully distributed systems. The following figure shows the topology of a computer system that follows clientserver architecture. The figure illustrates a node stereotyped as server that comprises of processors. The figure indicates that four or more servers are deployed at the system. Connected to the server are the client nodes, where each node represents a terminal device such as workstation, laptop, scanner, or printer. The nodes are represented using icons that clearly depict the real-world equivalent. UML Behavioural Diagrams UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system. Die Verhaltensdiagramme sind wie folgt gegliedert: Anwendungsfalldiagramme, Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme. Anwendungsfall Modell (a) Anwendungsfall Ein Anwendungsfall beschreibt die Abfolge von Aktionen, die ein System mit sichtbaren Ergebnissen durchführt. Es zeigt das Zusammenspiel von Dingen außerhalb des Systems mit dem System selbst. Anwendungsfälle können sowohl auf das gesamte System als auch auf einen Teil des Systems angewendet werden. Ein Darsteller repräsentiert die Rollen, die die Benutzer der Anwendungsfälle spielen. Ein Akteur kann eine Person (z. B. Student, Kunde), eine Einrichtung (beispielsweise eine Arbeitsstation) oder ein anderes System (z. B. Bank, Institution) sein. Die folgende Abbildung zeigt die Notationen eines Akteurs namens Student und eines Use Case namens Generate Performance Report. (C) Anwendungsfalldiagramme Anwendungsfalldiagramme stellen eine Außenansicht der Art und Weise dar, wie sich die Elemente in einem System verhalten und wie sie im Kontext verwendet werden können. Die Anwendungsfalldiagramme umfassen: Anwendungsfälle Akteure Beziehungen wie Abhängigkeit, Verallgemeinerung und Assoziation Anwendungsfalldiagramme werden verwendet: Um den Kontext eines Systems zu modellieren, indem alle Aktivitäten eines Systems innerhalb eines Rechtecks ​​eingeschlossen werden und sich die Akteure außerhalb des Systems um Interaktion mit ihm. Um die Anforderungen eines Systems von außen zu modellieren. Betrachten wir ein automatisiertes Handelshaus-System. Wir übernehmen die folgenden Merkmale des Systems: Das Handelshaus hat Geschäfte mit zwei Arten von Kunden, Einzelkunden und Firmenkunden. Sobald der Kunde einen Auftrag erteilt, wird er vom Vertrieb verarbeitet und der Kunde erhält die Rechnung. Das System ermöglicht es dem Manager, Kundenkonten zu verwalten und alle vom Kunden gestellten Fragen zu beantworten. Interaktionsdiagramme Interaktionsdiagramme zeigen Interaktionen von Objekten und deren Beziehungen. Sie enthalten auch die Nachrichten zwischen ihnen übergeben. Es gibt zwei Arten von Interaktionsdiagrammen: Sequenzdiagramme Kooperationsdiagramme Für die Modellierung werden Interaktionsdiagramme verwendet: der Kontrollfluss durch Zeitreihenfolge mit Sequenzdiagrammen. Der Kontrollfluss der Organisation mit Hilfe von Kooperationsdiagrammen. Sequenzdiagramme Sequenzdiagramme sind Interaktionsdiagramme, die die Reihenfolge der Meldungen nach Zeit darstellen. Bezeichnungen. Diese Diagramme sind in Form von zweidimensionalen Diagrammen. Die Objekte, die die Interaktion initiieren, werden auf der Xaxis platziert. Die Nachrichten, die diese Objekte senden und empfangen, werden entlang der Yaxis in der Reihenfolge der zunehmenden Zeit von oben nach unten platziert. Beispiel. Ein Sequenzdiagramm für das Automated Trading House System ist in der folgenden Abbildung dargestellt. Kollaborationsdiagramme Kollaborationsdiagramme sind Interaktionsdiagramme, die die Struktur der Objekte veranschaulichen, die Nachrichten senden und empfangen. Bezeichnungen. In diesen Diagrammen werden die Objekte, die an der Interaktion teilnehmen, mit Ecken gezeigt. Die Verbindungen, die die Objekte verbinden, werden verwendet, um Nachrichten zu senden und zu empfangen. Die Nachricht wird als markierter Pfeil angezeigt. Beispiel. Das Kooperationsdiagramm für das Automated Trading House System ist in der folgenden Abbildung dargestellt. StateChart Diagramme Ein Zustandsdiagramm zeigt eine Zustandsmaschine, die den Steuerungsfluss eines Objekts von einem Zustand zum anderen darstellt. Eine Zustandsmaschine stellt die Sequenzen von Zuständen dar, die ein Objekt aufgrund von Ereignissen und deren Antworten auf Ereignisse erfährt. StateChart Diagramme umfassen: Zustände: Einfach oder zusammengesetzt Übergänge zwischen Zuständen Ereignisse, die Übergänge bewirken Aktionen aufgrund der Ereignisse Zustandsdiagramm-Diagramme werden für die Modellierung von Objekten verwendet, die in der Natur reaktiv sind. Im Automated Trading House System können wir Order Order als Objekt modellieren und deren Reihenfolge verfolgen. Die folgende Abbildung zeigt das entsprechende Zustandsdiagramm. Aktivitätsdiagramme Ein Aktivitätsdiagramm zeigt den Fluss von Aktivitäten, die laufende nicht-atomare Operationen in einer Zustandsmaschine sind. Aktivitäten führen zu Aktionen, die atomare Operationen sind. Aktivitätsdiagramme umfassen: Aktivitätszustände und Aktionszustände Übergänge Objekte Aktivitätsdiagramme werden für die Modellierung verwendet: Arbeitsabläufe, wie sie von Akteuren gesehen werden und mit dem System interagieren. Details von Operationen oder Berechnungen anhand von Flussdiagrammen. Die folgende Abbildung zeigt ein Aktivitätsdiagramm eines Teils des Automated Trading House Systems. Object Oriented Design After the analysis phase, the conceptual model is developed further into an object-oriented model using object-oriented design (OOD). In OOD werden die technologieunabhängigen Konzepte im Analysemodell auf implementierende Klassen abgebildet, Einschränkungen identifiziert und Schnittstellen entworfen, die zu einem Modell für die Lösungsdomäne führen. In Kürze wird eine detaillierte Beschreibung erstellt, wie das System auf konkreten Technologien aufgebaut werden soll. Die Stufen für objektorientiertes Design können identifiziert werden: Definition des Kontextes des Systems Entwurf der Systemarchitektur Identifizierung der Objekte im System Konstruktion des Designs Modelle Spezifikation von Objektschnittstellen Objektorientiertes Systemdesign Systemdesign Objektorientiertes Systemdesign beinhaltet die Definition des Kontextes eines Systems, gefolgt von der Gestaltung der Architektur des Systems. Kontext. Der Kontext eines Systems hat einen statischen und einen dynamischen Teil. Der statische Kontext des Systems wird mit einem einfachen Blockdiagramm des Gesamtsystems entworfen, das in eine Hierarchie von Subsystemen erweitert wird. Das Subsystemmodell wird durch UML-Pakete dargestellt. Der dynamische Kontext beschreibt, wie das System mit seiner Umgebung interagiert. Sie wird anhand von Anwendungsfalldiagrammen modelliert. Systemarchitektur . Die Systemarchitektur ist auf der Grundlage des Kontextes des Systems nach den Prinzipien der architektonischen Gestaltung sowie Domain-Wissen entwickelt. Typischerweise wird ein System in Schichten unterteilt, und jede Schicht wird zersetzt, um die Subsysteme zu bilden. Objektorientierte Zersetzung Zerlegung bedeutet, dass ein komplexes System in eine Hierarchie kleinerer Komponenten mit geringerer Komplexität, nach den Prinzipien von divideandconquer, geteilt wird. Jede Hauptkomponente des Systems wird als Subsystem bezeichnet. Objektorientierte Zerlegung identifiziert einzelne autonome Objekte in einem System und die Kommunikation zwischen diesen Objekten. Die Vorteile der Zersetzung sind: Die einzelnen Komponenten sind von geringerer Komplexität und damit verständlicher und überschaubarer. Es ermöglicht die Teilung der Belegschaft mit speziellen Fähigkeiten. Sie ermöglicht es, Subsysteme zu ersetzen oder zu modifizieren, ohne andere Subsysteme zu beeinträchtigen. Gleichzeitigkeit identifizieren Gleichzeitigkeit ermöglicht, dass mehr als ein Objekt gleichzeitig Ereignisse empfängt und mehrere Aktivitäten gleichzeitig ausgeführt werden. Gleichzeitigkeit wird im dynamischen Modell identifiziert und dargestellt. Um Gleichzeitigkeit zu ermöglichen, wird jedem gleichzeitigen Element ein separater Thread des Steuerelements zugewiesen. Wenn die Parallelität auf Objektebene ist, werden zwei gleichzeitigen Objekten zwei verschiedene Threads der Steuerung zugewiesen. Wenn zwei Operationen eines einzelnen Objekts gleichzeitig in der Natur sind, dann wird dieses Objekt unter verschiedenen Threads aufgeteilt. Gleichzeitigkeit ist mit den Problemen der Datenintegrität, Deadlock und Hunger verbunden. Daher muss eine klare Strategie gemacht werden, wann immer Parallelität erforderlich ist. Außerdem muss Parallelität in der Entwurfsphase selbst identifiziert werden und kann nicht für die Implementierungsphase überlassen werden. Identifizieren von Patterns Beim Entwerfen von Anwendungen werden für einige Kategorien von Problemen einige allgemein akzeptierte Lösungen verwendet. Dies sind die Muster des Designs. Ein Muster kann als ein dokumentierter Satz von Bausteinen definiert werden, der bei bestimmten Arten von Anwendungsentwicklungsproblemen verwendet werden kann. Einige häufig verwendete Entwurfsmuster sind: Fadenmuster Modellansicht Trennmuster Beobachtermuster Modellansicht Steuerungsmuster Veröffentlichen Abonnementmuster Proxymuster Steuern von Ereignissen Während des Entwurfs des Systems müssen die Ereignisse, die in den Objekten des Systems auftreten können, identifiziert und entsprechend behandelt werden. Ein Ereignis ist eine Spezifikation eines bedeutenden Ereignisses, das einen Ort in Zeit und Raum hat. Es gibt vier Arten von Ereignissen, die modelliert werden können, nämlich: Signal Event. Ein benanntes Objekt, das von einem Objekt geworfen und von einem anderen Objekt gefangen wird. Ereignis anrufen. Synchrones Ereignis, das den Versand einer Operation darstellt. Zeit-Ereignis. Ein Ereignis, das den Ablauf der Zeit darstellt. Ereignis ändern. Ein Ereignis, das eine Zustandsänderung darstellt. Handhabung von Randbedingungen Die Systemdesignphase muss die Initialisierung und die Beendigung des Systems als Ganzes sowie jedes Subsystem adressieren. Die verschiedenen Aspekte, die dokumentiert werden, sind wie folgt: Die Inbetriebnahme des Systems, d. h. der Übergang des Systems vom nicht initialisierten Zustand in den stationären Zustand. Die Beendigung des Systems, d. h. das Schließen aller laufenden Threads, das Aufräumen der Ressourcen und die zu sendenden Nachrichten. Die Erstkonfiguration des Systems und die Rekonfiguration des Systems bei Bedarf. Vorhersehen von Fehlern oder unerwünschter Beendigung des Systems. Randbedingungen werden unter Verwendung von Grenznutzungsfällen modelliert. Objektdesign Nachdem die Hierarchie der Subsysteme entwickelt wurde, werden die Objekte im System identifiziert und deren Details entworfen. Hier beschreibt der Designer die Strategie, die während des Systemdesigns gewählt wurde. Der Schwerpunkt wechselt von Anwendungsdomänenkonzepten hin zu Computerkonzepten. Die während der Analyse identifizierten Objekte werden zur Implementierung herausgeätzt, um die Ausführungszeit, den Speicherverbrauch und die Gesamtkosten zu minimieren. Das Objektdesign umfasst die folgenden Phasen: Objektidentifizierung Objektdarstellung, d. h. Konstruktion von Entwurfsmodellen Klassifizierung von Operationen Algorithmendesign Entwurf von Beziehungen Implementierung der Steuerung für externe Interaktionen Paketklassen und Assoziationen in Module Objektidentifizierung Der erste Schritt des Objektdesigns ist die Objektidentifizierung. Die in den objektorientierten Analysephasen identifizierten Objekte werden in Klassen gruppiert und verfeinert, so dass sie für die eigentliche Umsetzung geeignet sind. Die Funktionen dieser Stufe sind: Identifizieren und Verfeinern der Klassen in jedem Subsystem oder Paket Definieren der Links und Assoziationen zwischen den Klassen Entwerfen der hierarchischen Assoziationen zwischen den Klassen, dh die Generalisierungen und Vererbung Object Representation Sobald die Klassen identifiziert sind, müssen sie sein Dargestellt unter Verwendung von Objektmodellierungstechniken. Diese Stufe beinhaltet im Wesentlichen die Konstruktion von UML-Diagrammen. Es gibt zwei Arten von Designmodellen, die hergestellt werden müssen: Statische Modelle. Um die statische Struktur eines Systems anhand von Klassendiagrammen und Objektdiagrammen zu beschreiben. Dynamische Modelle. Um die dynamische Struktur eines Systems zu beschreiben und die Interaktion zwischen Klassen anhand von Interaktionsdiagrammen und Zustandsdiagrammen darzustellen. Klassifizierung von Operationen In diesem Schritt werden die Operationen, die an Objekten durchgeführt werden sollen, durch Kombination der drei in der OOA-Phase entwickelten Modelle, nämlich Objektmodell, dynamisches Modell und Funktionsmodell, definiert. Ein Vorgang legt fest, was zu tun ist und nicht wie es durchgeführt werden soll. Für Operationen werden folgende Aufgaben ausgeführt: Das Zustandsübergangsdiagramm jedes Objekts im System wird entwickelt. Operationen werden für die Ereignisse definiert, die von den Objekten empfangen werden. Fälle, in denen ein Ereignis andere Ereignisse in gleichen oder verschiedenen Objekten auslöst, werden identifiziert. Die Teiloperationen innerhalb der Maßnahmen werden identifiziert. Die Hauptaktionen werden auf Datenflussdiagramme erweitert. Algorithm Design Die Operationen in den Objekten werden mittels Algorithmen definiert. Ein Algorithmus ist eine schrittweise Prozedur, die das in einer Operation festgelegte Problem löst. Algorithmen konzentrieren sich darauf, wie es zu tun ist. Es kann mehr als einen Algorithmus geben, der einer gegebenen Operation entspricht. Sobald die alternativen Algorithmen identifiziert sind, wird der optimale Algorithmus für die gegebene Problemdomäne ausgewählt. Die Metriken für die Auswahl des optimalen Algorithmus sind: Computational Complexity. Komplexität bestimmt die Effizienz eines Algorithmus hinsichtlich Rechenzeit und Speicherbedarf. Flexibilität. Flexibilität bestimmt, ob der gewählte Algorithmus in geeigneter Weise ohne Verlust der Angemessenheit in verschiedenen Umgebungen implementiert werden kann. Verständlichkeit. Dies bestimmt, ob der gewählte Algorithmus einfach zu verstehen und zu implementieren ist. Design von Beziehungen Die Strategie zur Umsetzung der Beziehungen muss während der Objektentwurfsphase ausgeklammert werden. Die Hauptbeziehungen, die angesprochen werden, umfassen Assoziationen, Aggregationen und Erbschaften. Der Designer sollte in Bezug auf Assoziationen Folgendes tun: Ermitteln Sie, ob eine Assoziation unidirektional oder bidirektional ist. Analysieren Sie den Pfad der Zuordnungen und aktualisieren Sie sie, wenn nötig. Implementieren Sie die Assoziationen als ein eigenständiges Objekt, im Falle von vielen zu vielen Beziehungen oder als Verknüpfung zu anderen Objekten im Falle von oneto-one oder oneto-many Beziehungen. Bei Erbschaften sollte der Designer folgende Schritte durchführen: Passen Sie die Klassen und ihre Zuordnungen an. Identifizieren Sie abstrakte Klassen. Machen Sie Vorkehrungen, so dass Verhaltensweisen gemeinsam genutzt werden, wenn nötig. Implementierung der Steuerung Der Objektdesigner kann Verfeinerungen in die Strategie des Statechart-Modells einfließen lassen. Im Systementwurf wird eine Basisstrategie zur Realisierung des dynamischen Modells erstellt. Während des Objektentwurfs ist diese Strategie für eine angemessene Implementierung treffend verschönert. Die Ansätze für die Umsetzung des dynamischen Modells sind: Represent State als Standort innerhalb eines Programms. Dies ist der traditionelle, prozessorientierte Ansatz, bei dem der Standort der Steuerung den Programmzustand definiert. Eine Finite-State-Maschine kann als Programm implementiert werden. Ein Übergang bildet eine Eingangsbehauptung, der Hauptsteuerpfad bildet die Folge von Anweisungen, die Zweige bilden die Bedingungen und die Rückwärtspfade bilden die Schleifen oder Iterationen. Maschine. Dieser Ansatz stellt direkt eine Zustandsmaschine durch eine Zustandsmaschinenmotorklasse dar. Diese Klasse führt die Zustandsmaschine durch einen Satz von Übergängen und Aktionen durch, die von der Anwendung bereitgestellt werden. Steuerung als gleichzeitige Aufgaben. Bei diesem Ansatz wird ein Objekt als Aufgabe in der Programmiersprache oder dem Betriebssystem implementiert. Dabei wird ein Ereignis als Inter-Task-Aufruf implementiert. Es bewahrt inhärente Gleichzeitigkeit von realen Objekten. Verpackungsklassen In jedem größeren Projekt ist eine sorgfältige Partitionierung einer Implementierung in Module oder Pakete wichtig. Beim Objektentwurf werden Klassen und Objekte in Pakete zusammengefasst, so dass mehrere Gruppen kooperativ an einem Projekt arbeiten können. Die verschiedenen Aspekte der Verpackung sind: Ausblenden von internen Informationen aus der Außenansicht. Sie ermöglicht es, dass eine Klasse als Blackbox betrachtet wird und die Klassenimplementierung geändert werden kann, ohne dass Clients der Klasse Code modifizieren müssen. Kohärenz der Elemente. Ein Element, wie eine Klasse, eine Operation oder ein Modul, ist kohärent, wenn es auf einem konsistenten Plan organisiert ist und alle seine Teile intrinsisch verwandt sind, so dass sie ein gemeinsames Ziel erfüllen. Aufbau von Physical Modules. Die folgenden Richtlinien helfen beim Erstellen physikalischer Module: Klassen in einem Modul sollten ähnliche Dinge oder Komponenten in demselben zusammengesetzten Objekt darstellen. Eng verbundene Klassen sollten sich im selben Modul befinden. Unverbundene oder schwach verbundene Klassen sollten in separaten Modulen platziert werden. Module sollten eine gute Kohäsion aufweisen, d. h. eine hohe Kooperation unter ihren Komponenten. Ein Modul sollte eine niedrige Kopplung mit anderen Modulen aufweisen, d. h. Interaktion oder Interdependenz zwischen Modulen sollte minimal sein. Design-Optimierung Das Analysemodell erfasst die logischen Informationen über das System, während das Designmodell Details zur Unterstützung eines effizienten Informationszugriffs hinzufügt. Bevor ein Entwurf implementiert wird, sollte es optimiert werden, um die Implementierung effizienter zu gestalten. Das Ziel der Optimierung ist es, die Kosten in Bezug auf Zeit, Raum und andere Metriken zu minimieren. Designoptimierung sollte jedoch nicht übertrieben sein, da einfache Implementierung, Wartbarkeit und Erweiterbarkeit ebenfalls wichtige Belange sind. Es wird oft gesehen, dass ein perfekt optimiertes Design effizienter, aber weniger lesbar und wiederverwendbar ist. So muss der Designer ein Gleichgewicht zwischen den beiden schlagen. Die verschiedenen Dinge, die für die Design-Optimierung getan werden können, sind: Hinzufügen redundanter Assoziationen Weglassen nicht verwendbarer Assoziationen Optimierung von Algorithmen Speichern von abgeleiteten Attributen zur Vermeidung von Re-Berechnungen komplexer Ausdrücke Hinzufügen redundanter Assoziationen Bei der Designoptimierung wird überprüft, ob neue Assoziationen abgeleitet werden können Reduzieren. Obwohl diese redundanten Assoziationen keine Informationen hinzufügen können, können sie die Effizienz des Gesamtmodells erhöhen. Unterlassung von nicht verwendbaren Verbänden Das Vorhandensein zu vieler Assoziationen kann ein System unentzifferbar machen und damit die Gesamteffizienz des Systems reduzieren. Während der Optimierung werden also alle nicht verwendbaren Zuordnungen entfernt. Optimierung von Algorithmen In objektorientierten Systemen erfolgt die Optimierung von Datenstrukturen und Algorithmen kollaborativ. Sobald das Klassen-Design vorhanden ist, müssen die Operationen und die Algorithmen optimiert werden. Die Optimierung der Algorithmen erhält man durch: Umordnen der Reihenfolge der Rechenaufgaben Umkehrung der Ausführungsreihenfolge der Schleifen von der im Funktionsmodell festgelegten Entfernung von Totpfaden im Algorithmus Speichern und Speichern abgeleiteter Attribute Abgeleitete Attribute sind diejenigen Attribute, deren Werte berechnet werden Als Funktion von anderen Attributen (Basisattributen). Eine Neuberechnung der Werte von abgeleiteten Attributen wird jedes Mal, wenn sie benötigt werden, ein Zeitkonsumierungsverfahren. Um dies zu vermeiden, können die Werte berechnet und in ihren berechneten Formen gespeichert werden. Dies kann jedoch Aktualisierungsanomalien darstellen, d. H. Eine Änderung der Werte von Basisattributen ohne entsprechende Änderung der Werte der abgeleiteten Attribute. Um dies zu vermeiden, werden folgende Schritte unternommen: Bei jeder Aktualisierung des Basisattributwerts wird das abgeleitete Attribut ebenfalls neu berechnet. Alle abgeleiteten Attribute werden in einer Gruppe und nicht nach jeder Aktualisierung neu berechnet und aktualisiert. Entwurfsdokumentation Dokumentation ist ein wesentlicher Bestandteil eines jeden Softwareentwicklungsprozesses, der das Verfahren zur Herstellung der Software aufzeichnet. Die Designentscheidungen müssen für jedes nicht-triviale Software-System dokumentiert werden, um das Design an andere weiterzugeben. Anwendungsgebiete Obwohl es sich um ein sekundäres Produkt handelt, ist eine gute Dokumentation unabdingbar, insbesondere in den folgenden Bereichen: Bei der Entwicklung von Software, die von einer Anzahl von Entwicklern entwickelt wird In iterativen Softwareentwicklungsstrategien Bei der Entwicklung nachfolgender Versionen eines Softwareprojekts Zur Auswertung einer Software Für die Suche Bedingungen und Prüfbereiche Für die Wartung der Software. Eine nützliche Dokumentation sollte im Wesentlichen die folgenden Inhalte enthalten: Highlevel-Systemarchitektur. Prozessdiagramme und Moduldiagramme Schlüsselentwürfe und - mechanismen. Klassendiagramme und Objektdiagramme. Szenarien, die das Verhalten der Hauptaspekte illustrieren. Behavioural diagrams The features of a good documentation are: Concise and at the same time, unambiguous, consistent, and complete Traceable to the systems requirement specifications Well-structured Diagrammatic instead of descriptive OOAD Implementation Strategies Implementing an object-oriented design generally involves using a standard object oriented programming language (OOPL) or mapping object designs to databases. In most cases, it involves both. Implementation using Programming Languages Usually, the task of transforming an object design into code is a straightforward process. Any object-oriented programming language like C, Java, Smalltalk, C and Python, includes provision for representing classes. In this chapter, we exemplify the concept using C. The following figure shows the representation of the class Circle using C. Implementing Associations Most programming languages do not provide constructs to implement associations directly. So the task of implementing associations needs considerable thought. Associations may be either unidirectional or bidirectional. Besides, each association may be either onetoone, onetomany, or manytomany. Unidirectional Associations For implementing unidirectional associations, care should be taken so that unidirectionality is maintained. The implementations for different multiplicity are as follows: Optional Associations . Here, a link may or may not exist between the participating objects. For example, in the association between Customer and Current Account in the figure below, a customer may or may not have a current account. For implementation, an object of Current Account is included as an attribute in Customer that may be NULL. Implementation using C: Onetoone Associations . Here, one instance of a class is related to exactly one instance of the associated class. For example, Department and Manager have onetoone association as shown in the figure below. This is implemented by including in Department, an object of Manager that should not be NULL. Implementation using C: Onetomany Associations . Here, one instance of a class is related to more than one instances of the associated class. For example, consider the association between Employee and Dependent in the following figure. This is implemented by including a list of Dependents in class Employee. Implementation using C STL list container: Bi-directional Associations To implement bi-directional association, links in both directions require to be maintained. Optional or onetoone Associations . Consider the relationship between Project and Project Manager having onetoone bidirectional association as shown in the figure below. Implementation using C: Onetomany Associations . Consider the relationship between Department and Employee having onetomany association as shown in the figure below. Implementation using C STL list container: Implementing Associations as Classes If an association has some attributes associated, it should be implemented using a separate class. For example, consider the onetoone association between Employee and Project as shown in the figure below. Implementation of WorksOn using C: Implementing Constraints Constraints in classes restrict the range and type of values that the attributes may take. In order to implement constraints, a valid default value is assigned to the attribute when an object is instantiated from the class. Whenever the value is changed at runtime, it is checked whether the value is valid or not. An invalid value may be handled by an exception handling routine or other methods. Consider an Employee class where age is an attribute that may have values in the range of 18 to 60. The following C code incorporates it: Implementing State Charts There are two alternative implementation strategies to implement states in state chart diagrams. Enumerations within Class In this approach, the states are represented by different values of a data member (or set of data members). The values are explicitly defined by an enumeration within the class. The transitions are represented by member functions that change the value of the concerned data member. Arrangement of Classes in a Generalization Hierarchy In this approach, the states are arranged in a generalization hierarchy in a manner that they can be referred by a common pointer variable. The following figure shows a transformation from state chart diagram to a generalization hierarchy. Object Mapping to Database System Persistency of Objects An important aspect of developing object-oriented systems is persistency of data. Through persistency, objects have longer lifespan than the program that created it. Persistent data is saved on secondary storage medium from where it can be reloaded when required. Overview of RDBMS A database is an ordered collection of related data. A database management system (DBMS) is a collection of software that facilitates the processes of defining, creating, storing, manipulating, retrieving, sharing, and removing data in databases. In relational database management systems (RDBMS), data is stored as relations or tables, where each column or field represents an attribute and each row or tuple represents a record of an instance. Each row is uniquely identified by a chosen set of minimal attributes called primary key . A foreign key is an attribute that is the primary key of a related table. Representing Classes as Tables in RDBMS To map a class to a database table, each attribute is represented as a field in the table. Either an existing attribute(s) is assigned as a primary key or a separate ID field is added as a primary key. The class may be partitioned horizontally or vertically as per requirement. For example, the Circle class can be converted to table as shown in the figure below. Mapping Associations to Database Tables OnetoOne Associations To implement 1:1 associations, the primary key of any one table is assigned as the foreign key of the other table. For example, consider the association between Department and Manager: SQL commands to create the tables: OnetoMany Associations To implement 1:N associations, the primary key of the table in the 1-side of the association is assigned as the foreign key of the table at the N-side of the association. For example, consider the association between Department and Employee: SQL commands to create the tables: ManytoMany Associations To implement M:N associations, a new relation is created that represents the association. For example, consider the following association between Employee and Project: Schema for WorksOn Table . WORKSON (EMPID, PID, HOURS, STARTDATE) SQL command to create WorksOn association :CREATE TABLE WORKSON Mapping Inheritance to Tables To map inheritance, the primary key of the base table(s) is assigned as the primary key as well as the foreign key in the derived table(s). OOAD Testing and Quality Assurance Once a program code is written, it must be tested to detect and subsequently handle all errors in it. A number of schemes are used for testing purposes. Another important aspect is the fitness of purpose of a program that ascertains whether the program serves the purpose which it aims for. The fitness defines the software quality. Testing Object-Oriented Systems Testing is a continuous activity during software development. In object-oriented systems, testing encompasses three levels, namely, unit testing, subsystem testing, and system testing. Unit Testing In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented as per design and whether the methods and the interfaces are error-free. Unit testing is the responsibility of the application engineer who implements the structure. Subsystem Testing This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead. It involves testing the associations within the subsystem as well as the interaction of the subsystem with the outside. Subsystem tests can be used as regression tests for each newly released version of the subsystem. System Testing System testing involves testing the system as a whole and is the responsibility of the quality-assurance team. The team often uses system tests as regression tests when assembling new releases. Object-Oriented Testing Techniques Grey Box Testing The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. Some of the important types of grey box testing are: State model based testing . This encompasses state coverage, state transition coverage, and state transition path coverage. Use case based testing . Each scenario in each use case is tested. Class diagram based testing . Each class, derived class, associations, and aggregations are tested. Sequence diagram based testing . The methods in the messages in the sequence diagrams are tested. Techniques for Subsystem Testing The two main approaches of subsystem testing are: Thread based testing . All classes that are needed to realize a single use case in a subsystem are integrated and tested. Use based testing . The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems. Categories of System Testing Alpha testing . This is carried out by the testing team within the organization that develops software. Beta testing . This is carried out by select group of co-operating customers. Acceptance testing . This is carried out by the customer before accepting the deliverables. Software Quality Assurance Software Quality Schulmeyer and McManus have defined software quality as the fitness for use of the total software product. A good quality software does exactly what it is supposed to do and is interpreted in terms of satisfaction of the requirement specification laid down by the user. Quality Assurance Software quality assurance is a methodology that determines the extent to which a software product is fit for use. The activities that are included for determining software quality are: Auditing Development of standards and guidelines Production of reports Review of quality system Quality Factors Correctness . Correctness determines whether the software requirements are appropriately met. Usability . Usability determines whether the software can be used by different categories of users (beginners, non-technical, and experts). Portability . Portability determines whether the software can operate in different platforms with different hardware devices. Maintainability . Maintainability determines the ease at which errors can be corrected and modules can be updated. Reusability . Reusability determines whether the modules and classes can be reused for developing other software products. Object-Oriented Metrics Metrics can be broadly classified into three categories: project metrics, product metrics, and process metrics. Project Metrics Project Metrics enable a software project manager to assess the status and performance of an ongoing project. The following metrics are appropriate for object-oriented software projects: Number of scenario scripts Number of key classes Number of support classes Number of subsystems Product Metrics Product metrics measure the characteristics of the software product that has been developed. The product metrics suitable for object-oriented systems are: Methods per Class . It determines the complexity of a class. If all the methods of a class are assumed to be equally complex, then a class with more methods is more complex and thus more susceptible to errors. Inheritance Structure . Systems with several small inheritance lattices are more wellstructured than systems with a single large inheritance lattice. As a thumb rule, an inheritance tree should not have more than 7 ( 2) number of levels and the tree should be balanced. Coupling and Cohesion . Modules having low coupling and high cohesion are considered to be better designed, as they permit greater reusability and maintainability. Response for a Class . It measures the efficiency of the methods that are called by the instances of the class. Process Metrics Process metrics help in measuring how a process is performing. They are collected over all projects over long periods of time. They are used as indicators for long-term software process improvements. Some process metrics are: Number of KLOC (Kilo Lines of Code) Defect removal efficiency Average number of failures detected during testing Number of latent defects per KLOCForex Trading Systems A Forex trading system is a method of trading that uses objective entry and exit criteria based on parameters that have been validated by historical testing on quantifiable data. Obwohl es keine harte und schnelle Regel für die Gestaltung der besten Forex-Handelssysteme (verschiedene Experten haben unterschiedliche Meinungen) die Essenz bleibt die gleiche. Im Allgemeinen bietet das Forex-Handelssystem die Disziplin, die Angst und Gier zu überwinden, die in vielen Fällen ein Händler lahmlegen und verhindert, dass er oder sie rechtzeitige Entscheidungen zu treffen. Jede bestellte Bestellung wird durch einen vorgegebenen Satz von Regeln geregelt, die nicht auf der Grundlage einer anderen als der Markthandlung abweichen. Wir wissen, dass Forex-Handel kann überwältigend sein Thats, warum wir eine Forex-Training-Klasse für Anfänger, die Ihnen helfen, lernen können Forex Trading-Strategien, die ARBEITEN Der Kurs heißt Forex 1, 2, 3 und seine kostenlos Klicken Sie hier, um mehr zu erfahren. Wie jedes andere Trading-System und Methode, Forex Trading-Systeme kochen bis hin zu Risiko versus Belohnung. Wie viel Kapital Sie bereit sind, ein Risiko für eine gegebene Rendite zu setzen, sollte Ihre oberste Erwägung sein. Darüber hinaus müssen die Kosten, die Handelsaktivitäten und die Märkte, die vor der Anlage gehandelt werden, berücksichtigt werden. In der Tat sind die besten Forex-Handelssysteme eine gute Mischung aus Kunst und Wissenschaft 8211 Kunst, weil es durch die Praxis und Wissenschaft kommt, weil es bestimmte Regeln, Vorschriften und Grundsätze zu beachten. Wissen und Technologie spielen bei jeder Entscheidung eine sehr wichtige Rolle. Im Bereich der Handelssysteme, sind automatisierte Forex-Handelssysteme Techniken, die Handelsentscheidungen für Sie treffen. Sie geben die Handelsdaten ein und das System erzeugt eine Antwort, die die entsprechende Aktion anzeigt. Sie kaufen, verkaufen oder nichts tun, abhängig von den Formeln dieses System verwendet und betreibt. Die neuesten Computer-Versionen dieser mechanischen Systeme sind komplette 8220black box8221 Operationen (Sie können nicht alle Emotionen beteiligt, wenn Sie ein bestimmtes System folgen). Vielleicht ist das einer der Gründe, warum diese Systeme als mechanische Systeme bezeichnet werden. Aber das bedeutet nicht, dass sie arent intelligent genug. Schalten Sie den Computer ein, starten Sie das System, und es aktualisiert Ihre Datenbank und generiert Trading-Empfehlungen, und legt Ihre Aufträge direkt an die Broker. Sehen Sie unsere Forex Trading Video Swingtrading Forex Dancing mit dem Markt mit Trend Jumper Unbestreitbar, in Forex Trading-Systeme, ist die Geschwindigkeit der Essenz in diesen hektischen Zeiten. Jede Nanosekunde zählt, wenn Sie mit fünf Minuten Charts handeln. Die grundlegendsten Forex Trading-Strategien beruhen auf gleitenden Durchschnitten. Die 8220sophisticated8221 Systeme verwenden Kombinationen von gleitenden Durchschnitten von Preis und Volumen. Die meisten 8220expensive8221 Systeme enthalten Stochastik, die die mathematischen Techniken für eine nicht-lineare Wissenschaft sind. Die meisten dieser Forex-Handelssysteme sind reaktiv (nicht proaktiv) durch Design. Wie, wenn eine Aktie oder eine Ware in einer bestimmten Weise handelt, geht das System davon aus, dass die Aktie oder eine Ware weiterhin so handeln wird. Es erzeugt diese Schlussfolgerung, die auf den in das System programmierten Formeln basiert. Einige Black Boxes8221 berechnen auch eine große Anzahl von Indikatoren, um das Vertrauen einer Handlungsempfehlung zu erhöhen. Die meisten mechanischen Handelssysteme kaufen oder verkaufen Ausbrüche. Der Aktienmarkt nennt diese Trader Momentum Spieler. Ihre Formeln nehmen eine Fortsetzung dieser Bewegung an. Sollte diese Bewegung nicht fortsetzen, wird das Forex-System einen Verlust zuzüglich der Provisionskosten generieren. Die Bedeutung eines guten Forex Trading System kann nicht übertrieben werden Jeder, der verpflichtet ist, so viel Geld wie möglich mit Fremdwährungen muss die Bedeutung der mit dem besten Forex Trading System zu verstehen. Der wirkliche Vorteil, dass ein System auf Handelsentscheidungen angewiesen ist, ergibt sich weitgehend aus der Tatsache, dass wir nicht wirklich die bestmöglichen Entscheidungen treffen können, ohne einen Rahmen zu haben. Während seine sicherlich wahr, dass dies einschüchtern kann, um Menschen, die brandneu zu Forex Devisenhandel sind. Ist dies ein Konzept, das wirklich muss verstanden werden, wenn eine Person ist, sich die beste Chance möglich, erfolgreich zu sein. Es gibt viele Vorteile und Nachteile zu Forex Trading. In vielerlei Hinsicht ist dies viel wie ein Strategiespiel. Während seine sicherlich wahr, dass Sie das Spiel spielen können, ohne tatsächlich eine Strategie im Ort, Ihre Chancen auf Erfolg sind viel niedriger. Es ist die gleiche Weise mit Handelswährungen. Sie müssen eine grundlegende Strategie oder Rahmen an Ort und Stelle, die alle handelnden Entscheidungen, die Sie regeln zu haben. Glücklicherweise müssen Sie nicht Ihre eigenen Forex Trading System erfinden. Es gibt eine Vielzahl von verschiedenen Systemen, die Sie betrachten können, um so in der Lage, eine auswählen, die am besten geeignet für Sie und Ihre Ziele ist. Was youll entdecken, nachdem Sie mit Forex Devisenhandel für einen Zeitraum von Zeit beteiligt waren, ist, dass Sie beginnen, Elemente der verschiedenen Strategien zu leihen, um die besten Forex Trading System für Sie zu schaffen. Sie können entdecken, dass es bestimmte Aspekte eines bestimmten Systems, die Sie finden sehr ansprechend. Nicht nur das, können Sie auch feststellen, dass diese Aspekte unglaublich profitabel sein können, wenn in Verbindung mit Elementen eines anderen Forex Trading System verwendet. Davon abgesehen, ist dies in der Regel nur etwas, das Menschen, die mit Devisenhandel für einen Zeitraum von Zeit gewesen sind, wirklich bestimmen können. Was Sie tun sollten, wenn Sie nagelneu in der Welt des Devisenhandels sind vertraut machen Sie sich mit einigen der verschiedenen Devisenhandel Ansätze, die es gibt. Nicht nur wird dies Ihnen den Standpunkt in der Lage zu sehen, wie andere über den Prozess des Handels mit Währungen gehen, wird es auch dazu beitragen, Ihnen einige der verschiedenen Forex Trading Systemvariablen, die (in einigen Fällen) sind universell unter allen Verschiedenen Währungshandelsrahmen. Vor allem ist es wichtig zu erkennen, dass der einzige Weg, um wirklich eine Entscheidung, welche Forex Trading-System für Sie am besten ist, um tatsächlich mit einer Vielzahl von verschiedenen Systemen zu experimentieren, um zu sehen, welche Art von Ergebnissen erhalten Sie. Sein nicht genug, um einfach die Resultate zu betrachten, die durch jemand anderes erhalten werden. Am Ende des Tages sind die einzigen Ergebnisse, die wirklich wichtig sind diejenigen, die Sie waren in der Lage, für sich selbst durch die Verwendung eines bestimmten Systems zu erhalten. Daher müssen Sie aufgeschlossen sein, um verschiedene Ansätze zu versuchen, um zu sehen, welche Art von Ergebnissen Sie erhalten. Unabhängig von der spezifischen Forex-Handelssystem, das Sie letztlich entscheiden, ist es von entscheidender Bedeutung, dass Sie verstehen, dass Sie müssen einige grundlegende Rahmenbedingungen vor dem Beginn des Handels mit Währungen im Ernst haben.