Ein Vorschlag für Änderungen im aktuellen System Suframa Collection für ein Objekt-orientierte Plattform mit DDD Projekt Muster und SOLID.

PERES, Paulo Júnior de Jesus [1]

PINTO, Aurílio Guimarães [2]

FREITAS, Caio Guimarães [3]

LEITE, Francisco Canindé da Silva [4]

SILVA, Francisco Eronildo da [5]

OLIVEIRA, Geveson de Souza [6]

RIBEIRO, Dallas dos Santos [7]

ALMEIDA, Cristiany Caliri de [8]

MORAIS, Gilvanete Melo de [9]

PERES, Paulo Júnior de Jesus; et.al. Ein Vorschlag für Änderungen im aktuellen System Suframa Collection für ein Objekt-orientierte Plattform mit DDD Projekt Muster und SOLID. Multidisziplinäre Kern Fachzeitschrift des Wissens. 07-Edition. 02 Jahr, Vol. 03. s. 36-43, Oktober 2017. ISSN: 0959-2448

Zusammenfassung

Die Sammlung von einer Bundesanstalt als Suframa ist äußerst komplex, da gibt es mehrere rechtliche und regulatorische Integration für einen reibungslosen Betrieb notwendig. Daher ist es gerechtfertigt, um ein robustes System zu verwenden, das den Business Rules und notwendige Entwicklungen in diesem dynamischen Prozess entspricht. Aus diesem Grund soll dieser Artikel eine tragfähige Aussage aus der Sicht der Software-Architektur für die Entwicklung einer Lösung mit Qualität Code mithilfe der DDD-Projekte und feste Muster zu bieten.

1. Einführung

Die aktuelle Software, die Sammlung der Suframa verwaltet, wurde Mitte 1990 mit der Plattform der Cobol Programmiersprache und der SQL-Datenbank DBB, das ist eine frühere Version als DB2 von IBM entwickelt. Nach der Koordination Behörde Computer betreibt ein solches System auf niedrige Plattform, d. h. auf einem Großrechner IBM Z22.

Bevor Sie die Software im Betrieb an der Institution können wir folgende Probleme hervorheben:

• Nicht-relationale Datenbank und Daten Speicherbegrenzung;
• Strukturierte Programmiersprache;
• Fehlende Versionierung der Codes;
• Fehlende integrierte Tests;
• Schwierigkeiten bei der Arbeit, Wartungsarbeiten am System durchzuführen.

Wie allgemein bekannt ist, ist eine Software von dieser Dimension eine "live" brauchen ständige Weiterentwicklungen. Vor diesem Hintergrund wurde durch Computer Koordination Suframa festgestellt, die solche Software nicht mehr weder die Geschäftsanforderungen erfüllt sind die technologischen Anforderungen zwischen den Bedürfnissen der wichtigsten Entwicklungen wie folgt:

• Integration mit Web-Plattformen über Webdienste;
• Integration mit Plattformen und Handys
• Verarbeitung, erzeugen und Exportieren von Berichten in verschiedenen Formaten.

Nach dem elektronischen Ort der Institution, die Oberaufsicht der Freihandelszone Manaus (Suframa) – ist eine Gebietskörperschaft der Bundesregierung unter dem Ministerium für Industrie, Handel und Dienstleistungen, die darauf abzielt, ein Modell der Regionalentwicklung zu bauen Verwenden Sie natürliche Ressourcen nachhaltig wirtschaftliche Lebensfähigkeit und Verbesserung der Lebensqualität der Bevölkerung. Derzeit hat die Suframa wie Umfang der Staaten Amazonas, Acre, Rondônia, Roraima und Amapá.

Über die Bedeutung der Gemeinde für die Region und die große Menge an Ressourcen gesammelt rechtfertigt die Entwicklung eines neuen Systems für die Sammlung verwendete moderne Software-Architekturmuster und Technologien. Daher wird der Kurs dieses Artikels eine Strategie für die Entwicklung der Software, die in diesem Artikel erwähnten vorgeschlagen.

2. Software-Architekturmuster

Bevor wir definieren, welche Muster verwendet werden, es ist wichtig zu definieren, was ein Software-Design-Pattern, also, je nach Gestaltungsanspruch Gamma (2000) sind allgemeine Lösungen für die am weitesten verbreitete und immer wiederkehrende Probleme in der Softwareentwicklung Objekt-orientierte (OOP) durch ein Team von Software-Entwicklung.

Das Hauptanliegen des Projekts ist es, das Risiko von Fehlern in der Software durch den Einsatz von Techniken weithin getestet und genehmigt durch Software-Entwickler-Community.

Zweite Gamma (2001), derzeit gibt es mehrere Design-Patterns und eine Vielzahl von Informationen zur Forschung, unter diese Muster, die wir hervorheben können:

• Dependency Injection oder Dependency Injection;
• Factory-Methode;
• Bulder;
• Abstracty Fabrik;
• Singleton;
• Prototyp;
• Befehl;
• Iterator;
• Strategie;
• Besucher unter anderem;

Inmitten der Vielzahl von bestehenden Standards, soll dieser Artikel markieren die vorgeschlagenen Muster als Grundlage für die Entwicklung des neuen Systems der Sammlung von der Oberaufsicht der Manaus Free Trade Zone, die sind: Domain-Driven Design (DDD) und solide, weil die Nutzung beider impliziert bei der Verwendung von verschiedenen Software-Entwicklungsmethoden.

Auf diese Weise bedeutet nicht, dass der Verlauf des Projekts nicht verwendet werden dürfen andere Standards nur durch Lehre Probleme werden behandelt diese beiden Muster in diesem Artikel. In den folgenden Kapiteln werden wir so tief solche Standards ansprechen.

2.1. Die Default Domain-Driven Design (DDD)

Domain-driven Development (DDD) ist laut Evans (2016) einen disziplinierten Ansatz für Softwaredesign, das eine Reihe von Konzepten und Techniken immer mit Schwerpunkt auf dem Gebiet der Software befasst sich mit.

In diesem Muster steht im Mittelpunkt der Entwicklung im Bereich des Systems, d.h. die Regeln des Software-Unternehmens.

Ein großer Vorteil von DDD ist, dass Ihr Ansatz ist voll objektorientiert, d.h. müssen Entwickler die Software mit Objekt-orientierte Programmierung, auf diese Weise zweite Cukier aufbauen (2010) die erzielten Vorteile sind folgende:

• Code-Ausrichtung mit dem Geschäft: die Einbindung der Entwickler mit Kenner/Domain-Experten ist entscheidend, wenn DDD, dies ein Feature der agilen Entwicklung ist;
• Wiederverwendung zu fördern: die Codes entwickelt, in transparenter Weise wiederverwendet werden können.
• Minimale Kopplung: nach der Modellierung des Datenmodells, gut entwickelt, organisiert, die "Schichten" der Software können kommunizieren, ohne Abhängigkeit durch den Einsatz von Schnittstellen;
• Technologie-Unabhängigkeit: DDD nimmt keinen Bezug auf die Technologie in der Entwicklung der Software, sondern in Geschäftsregeln.

Aber Ihr Ziel ist es, die Vorwahl für die Software entwickelt werden, mit einer Architektur die Anwendung der Konzepte von DDD, also zweite Cukier ermöglicht zu erreichen (2010) das Muster schlägt die Verwendung von vier Hauptschichten sind:

In der obigen Abbildung sind die folgenden Klarstellungen zweite Cukier (2010):

• Benutzeroberfläche – ist die Schicht verantwortlich für direkte Interaktion mit dem Benutzer als Software-Bildschirme, Web Services SOA REST, mobile Anwendungen oder Desktop-PCs, u.a.;
• Anwendung-arbeitet direkt mit der Domäne Schicht um den Bereich der Ebene "User Interface" zu isolieren, es ist wichtig, für die Papiere deutlich, zum Beispiel zu bleiben: Es gibt keine Notwendigkeit zu wissen, welche die Domänenklasse Schnittstelle muss bestimmte Aktion ausführen . Auf diese Weise ist die Anwendungsschicht eine Art Vermittler zwischen der Domäne und die Schnittstelle;
• Domäne – ist die Schicht, die die Geschäftsregeln der Anwendung, d. h. alles enthält, die funktionale Anforderungen widerspiegelt, die Berechnungen werden in dieser Schicht behandelt;
• Infrastruktur – verantwortlich für die Interaktion mit der technischen Infrastruktur, z. B. Daten Access Zugriff auf Dateisysteme, Email-Einsendungen, unter anderem.

Diese Schichten sind nicht obligatorisch, je nach Bedarf des Projekts entfernt werden oder neue Ebenen hinzugefügt. Was im Auge behalten werden sollte, ist die Notwendigkeit der imperativen Programmierung ausgerichtet an der Domäne.

Aber es gibt etwas zu beachten, nach Pires (2016) DDD ist keine Programmierung einer Schichtenarchitektur noch ein Rezept bereit für den Einsatz in jeder Software entwickelt werden. DDD konzentriert sich auf Domain-orientierten Entwicklung, das ist im Vordergrund und nicht die Schichten.

Bevor solche Konzepte, erreichen wir die Hauptvorteile, die mithilfe der DDD verdient dieser zweiten Cukier (2010) ist, dass die Induktion in der Entwicklung von Software im Rahmen des Szenarios der kontinuierlichen Verbesserung, so dass es ein äußerst nützliches Instrument zur Entwicklung von Software für Qualität und erfüllt die Anforderungen des Kunden.

Also, wenden den Standard Projekte retten bedeutet wirklich Programmierung DDD, Objekt-orientierte, denn Ihre Umsetzung das Entwicklungsteam anzuwenden, andere Standards wie z. B.: Repository, Dekorateur, Strategie, stand unter anderem.

2.2. SOLIDE

Laut Martin (2008) Robert c. Martin identifiziert fünf Prinzipien der objektorientierten Programmierung, die die Verbesserung der Codes suchen, solche Prinzipien sind SRP, OCP, LSP, ISP und DIP. Bevor diese Grundsätze merkten Michael Feathers, dass die Abkürzung genannt, solide mit den fünf Grundsätzen erstellt werden konnte. Die folgende Abbildung veranschaulicht die Bedeutung der Abkürzung:

Folgt die Definition der einzelnen Teile der Abkürzung nach der Veröffentlichung von Martin (2008):

• Einzigen Verantwortung Grundsatz oder Prinzip der einzigen Verantwortung: eine Klasse sollte einen und nur einen Grund für eine Änderung haben. Dieses Prinzip eine Klasse muss nur einen einzigen Zweck, zum Beispiel: beim Erstellen eines Rechners sollte kein Klasse Mathematik Operationen machen und setzen alle ihre Vorgänge machen sondern eher eine Klasse für jeden Vorgang;
• Offen-geschlossen-Prinzip oder offen-geschlossen-Prinzip: man sollte immer offen für Erweiterung und geschlossen für die Umsetzung, das ist, warum, wenn Sie einen vorhandenen Code ändern läuft Gefahr, Fehler Auswirkungen auf mehrere andere Code-Fragmente;
• Liskov Substitution-Prinzip oder Grundsatz Liskov Substitution: Basen Klassen sollte immer ersetzbar durch seine Stiftungen, d. h. eine Klasse B erbt ein 1. Januar immer werden von Klasse in einer Code-Implementierung überschrieben kann;
• Interface Segregation Prinzip oder Grundsatz der Trennung von Schnittstellen: viele spezifische Schnittstellen sind besser als eine einzige Schnittstelle, da diese Praxis zielt darauf ab, reduzieren Sie die Kopplung von Codes;
• Dependency Inversion Prinzip oder Dependency Inversion Prinzip: man sollte immer verlassen auf eine Abstraktion und nie eine Umsetzung.

Bei der Anwendung der Feststoff erhalten Sie die folgenden Vorteile für Ihr Projekt: Anlage auszuführenden Wartungs- und Entwicklungen, einfache automatisierte Tests, weniger Aufwand zur Entwicklung und maximale Wiederverwendung von Code zu codieren.

3. Vorgeschlagene neue Kollektion System

Der Zweck dieses Artikels soll die Wissensbasis für die Entwicklung einer neuen Software für die Verwaltung der Sammlung im Besitz der Oberaufsicht der Manaus Free Trade Zone-Suframa mit dem Paradigma der objektorientierten Programmierung durch die Anwendung der Normen des DDD und solide Projekte in der Entwicklung des Projekts.

In diesem Vorschlag hätten nach einen Aktionsplan basierend auf 5W1H Verwaltungsmodell, wir die folgende Planung für die weitere Entwicklung:

Tabelle 01-Aktionsplan für die Entwicklung des neuen Systems.

Was ist zu tun?	Warum, warum?	Wie?	Wo?	Wer?	Wann?
Programmiersprache und Technologien für das Projekt zu definieren	Standardisierung der Software-Entwicklung.	Fachsitzungen	Über die Koordinierung der Informatik	ICT-Manager, Programmierer und Software-Architekten	Erste Woche
Vorbereitung der Entwicklungsumgebung und Genehmigung	Schaffung von Mechanismen für das Team an dem Projekt arbeiten	Installation von Servern, Software und frameworks	Auf der Arbeitsstation der Mitglieder des Entwicklungsteams und auf den Servern.	Konfiguration und Support-Team von IKT	Zweite Woche
Software-Anforderungen sammeln	Dokumentieren Sie die Informationen im Feld programmiert werden	Besprechungen und interviews	SUFRAMA	Anforderungen-Analysten	Woche 10 3.
Codierung	Die Software zu erstellen	Codieren und testen	Auf Suframa	Softwarefactory	Woche 22 11.
Genehmigung und Korrekturen	Herausfinden Sie, ob was entwickelt wurde, wirklich was der Suframa braucht ist und durchführen Korrekturen	Durchführung von tests	Zulassung-Umgebung	Fachexperten (Geschäft)	Der Woche 23 bis 25.
Bereitstellung	Machen Sie das System in der Produktion	Der Buildvorgang in der Produktionsumgebung	Hosting-Systeme	Konfiguration-analyst	Woche 26.

Quelle: Gezeichnet vom Autor.

Wie aus der Tabelle oben, es scheint, dass das Projekt dauert rund sechseinhalb Monaten, jedoch ist anzumerken, dass dieser Aktionsplan enthält Makros, Aktionen wäre benötigt andere Pläne zum detail jede Aktion in Ihrer Ausführung des Makros.

Im Hinblick auf die Wirkung von "Kodierung" spitz auf 01 Tabelle, die Verwendung von DDD, dieser Vorschlag empfiehlt die folgenden Schichten erstellt werden:

• Darstellungsschicht Schicht-das werden des Benutzers Vision und für Web 2.0 eckige Rahmen verwendet werden und auf mobile Geräte (Android/IOS) mit dem Ionischen Framework;
• Schicht von Dienstleistungen – werden verantwortlich für die Bereitstellung der Darstellungsschicht alle Webservices im REST-Format und wird die Rolle der Steuerung mittels Dependency Injection Framework Ninject;
• Anwendungsschicht – verantwortlich für Anwendung Implementierungen, wie Record und Domäne Kapselung anmelden;
• Domäne-Layer enthält die Implementierung von Geschäftsregeln, es werden die Entitäten, Schnittstellen und Domain-Services;
• Infrastruktur-Ebene – verantwortlich für die Daten zugreifen Schicht mit einer ORM-Tool von Repositorien, durch Versenden von E-mails und Authentifizierung.

In alle Schichten sollte angewendet, die Grundsätze der SOLID.

Fazit

Dieser Fachartikel wollte einfach zu erarbeiten, einen konkreten Vorschlag der Migration aus einem Altsystem in niedrigen Plattform-Entwicklung für eine moderne Plattform, die mit den Standards der Software-Entwicklungsprojekte als Basis orientierte Entwicklung Domäne (DDD) und solide.

Es wird davon ausgegangen, dass dieser Vorschlag als Grundlage nicht nur für die Sammlung von der Oberaufsicht der Freihandelszone Manaus, sondern auch als Basis für andere Projekte von Migration dient und Entwicklung von Software im offen für weitere Anpassungen und künftige Neuauflagen von andere Autoren.

Referenzen

Beck, Kent. "Patterns of Umsetzung". Bookman. 2013. 168 p. ISBN 8565837971.

Gamma, Erich. "Design Patterns". Bookman. 2000. 528p. ISBN 8573076100.

Evans, Eric. "Domain Driven Design 3rd Edition". Hohen Bücher. 2016. 528p. ISBN 8550800651.

Martin, Robert. Sauberen Code: Ein Handbuch der agilen Softwareentwicklung Handwerkskunst ". Prentice Hall PTR. 431p. ISBN 0132350882.

Abrufbar: <http: cieam.com.br/?u="suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf">abgerufen am 21. April 2017.</http:>

Abrufbar: <http: www.eduardopires.net.br/2012/06/ddd-tdd-bdd/="">abgerufen am 21. April 2017.</http:>

Abrufbar: <http: www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/="">abgerufen am 21. April 2017.</http:>

Abrufbar: <http: www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/="">abgerufen am 21. April 2017.</http:>

[1] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie. Datenbank-Spezialist für ULBRA.

[2] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.

[3] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.

[4] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.

[5] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.

[6] Abschluss in Informatik, fungiert als Server SUFRAMA, als Administrative Analyst-Sie.

[7] Abschluss in Informatik, fungiert als Server SUFRAMA, als Administrative Analyst-Sie.

[8] Abschluss in Business Administration, fungiert als Beamter auf SUFRAMA, als Administrator.

[9] Studierte Wirtschaftswissenschaften, fungiert als Beamter auf SUFRAMA, als Ökonom.