Una proposta di modifiche nel sistema corrente del Suframa insieme per una piattaforma orientata agli oggetti utilizzando i modelli di progetto di DDD e solido.

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. Una proposta di modifiche nel sistema corrente del Suframa insieme per una piattaforma orientata agli oggetti utilizzando i modelli di progetto di DDD e solido. Rivista scientifica multidisciplinare di nucleo di conoscenza. 07 edizione. anno 02, vol. 03. pp. 36-43, ottobre 2017. ISSN: 0959-2448

Riepilogo

La raccolta di un'agenzia federale come Suframa è estremamente complessa, come ci sono parecchi integrazione giuridica e regolamentazione necessaria per un buon funzionamento. Pertanto, è opportuno per utilizzare un sistema robusto che soddisfa le regole di business e gli sviluppi necessari in questo processo dinamico. Per questo motivo, questo articolo cerca di offrire una proposta praticabile dal punto di vista dell'architettura software per lo sviluppo di una soluzione con il codice di qualità utilizzando il DDD progetti e modelli solidi.

1. Introduzione

Il software che gestisce l'insieme tenuto dal Suframa è stato sviluppato a metà anni 1990 con la piattaforma il Cobol programming linguaggio e il database SQL DBB, che è una versione precedente a DB2 di IBM. Secondo il computer autorità di coordinamento, tale sistema opera su piattaforma bassa, cioè su un Mainframe IBM Z22.

Prima che il software in funzione presso l'Istituto, possiamo evidenziare i seguenti problemi:

• Limite di archiviazione database e dati non-relazionali;
• Linguaggio di programmazione strutturato;
• Mancanza di controllo delle versioni dei codici;
• Mancanza di test integrato;
• Difficoltà di lavoro per eseguire la manutenzione del sistema.

Come è noto, un software di questa dimensione è un "live" che hanno bisogno di costante evoluzione. In questa luce, è stato trovato da computer coordinamento di Suframa che tale software non soddisfa le esigenze aziendali più né che le esigenze tecnologiche, tra le esigenze dei principali sviluppi sono come segue:

• Integrazione con piattaforme web attraverso servizi Web;
• Integrazione con piattaforme e cellulari
• Lavorazione, generazione ed esportazione dei report in vari formati.

Secondo il sito elettronico dell'istituzione, la Soprintendenza di zona franca di Manaus (Suframa) – è un ente locale di governo federale sotto il Ministero dell'industria, commercio e servizi che mira a costruire un modello di sviluppo regionale utilizzare le risorse naturali in modo sostenibile, garantire sostenibilità economica e migliorare la qualità della vita della popolazione. Attualmente il Suframa ha come ambito Stati di Amazonas, Acre, Rondônia, Roraima e Amapá.

Sull'importanza del comune per la regione e il grande volume di risorse raccolte, giustifica lo sviluppo di un nuovo sistema per la raccolta di modelli di architettura software moderno usato e tecnologie. Pertanto, il corso di questo articolo sarà proposto una strategia per lo sviluppo del software menzionato in questo articolo.

2. Modelli di architettura software

Prima definiamo quali pattern verrà utilizzato, è importante definire che cosa è un modello di progettazione del software, così, secondo la norma di progettazione di Gamma (2000) sono generici soluzioni ai problemi più comuni e ricorrenti nello sviluppo di software Orientato agli oggetti (OOP) da un team di sviluppo software.

L'intento principale del progetto è quello di ridurre il rischio di errori nel software tramite l'utilizzo di tecniche ampiamente testati e approvati dalla comunità di sviluppo di software.

Secondo Gamma (2001), attualmente ci sono diversi modelli di progettazione e un sacco di informazioni disponibili per la ricerca, tra questi modelli che possiamo evidenziare:

• Dependency Injection o Dependency Injection;
• Metodo di fabbrica;
• Bulder;
• Abstracty fabbrica;
• Singleton;
• Prototipo;
• Comando;
• Iteratore;
• Strategia;
• Dei visitatori tra gli altri;

Tra la moltitudine di norme esistenti, questo articolo cerca di evidenziare i modelli suggeriti come base per lo sviluppo del nuovo sistema di raccolta della Soprintendenza della zona franca di Manaus che sono: Domain-Driven Design (DDD) e solido, perché implica l'uso di entrambi nell'uso delle varie procedure di sviluppo Software.

In questo modo, non significa che il corso del progetto non può essere utilizzato altri standard, solo di insegnamento questioni saranno affrontate questi due modelli in questo articolo. Così, nei capitoli successivi si affronterà profondamente tali norme.

2.1. Il Default Domain-Driven Design (DDD)

Secondo Evans (2016) lo sviluppo basato su dominio (DDD) è un approccio disciplinato alla progettazione di software che risolve una serie di concetti e tecniche sempre messa a fuoco nel campo del software.

In questo modello, l'obiettivo dello sviluppo è nella zona del sistema, cioè le regole di business del software.

Un grande vantaggio del DDD è che il tuo approccio è completamente object-oriented, vale a dire gli sviluppatori devono compilare il software utilizzando la programmazione ad oggetti, in questo modo, secondo Cukier (2010) i benefici raggiunti sono i seguenti:

• Codice di allineamento con il business: il coinvolgimento degli sviluppatori con esperti intenditori/dominio è di primaria importanza quando DDD, questa è una caratteristica dello sviluppo agile;
• Favorire il riutilizzo: i codici sviluppati, possono essere riutilizzati in modo trasparente.
• Accoppiamento minimo: dopo la modellazione del modello di dati ben sviluppato, organizzato, i "livelli" del software possono comunicare senza dipendenza attraverso l'uso di interfacce;
• Indipendenza tecnologica: DDD non si concentra sulla tecnologia utilizzata nello sviluppo del software, ma nelle regole di business.

Tuttavia, il vostro obiettivo è raggiungere il codice di area necessario per il software essere sviluppato utilizzando un'architettura che consente l'applicazione dei concetti di DDD, così secondo Cukier (2010) il modello suggerisce l'uso di quattro strati principali sono:

Nella figura precedente, i seguenti sono chiarimenti secondo Cukier (2010):

• Interfaccia utente – è lo strato responsabile per l'interazione diretta con l'utente, come le schermate del software, Web Services SOA o resto, applicazioni cellulari o desktop, tra gli altri;
• Applicazione-funziona direttamente con il livello di dominio al fine di isolare l'area del livello "User Interface", è importante per i documenti di soggiorno distinti, ad esempio: non c'è nessun bisogno di sapere che interfaccia la classe di dominio deve eseguire determinate azione . In questo modo, il livello di applicazione è una sorta di mediatore tra il dominio e l'interfaccia;
• Dominio – è lo strato che contiene tutte le regole di business dell'applicazione, vale a dire tutto ciò che riflette le esigenze funzionali, i calcoli vengono gestiti in questo strato;
• Infrastrutture – responsabile per l'interazione con l'infrastruttura tecnica, ad esempio, accesso ai dati, accedere a file System, invio di e-mail, tra gli altri.

Questi strati non sono obbligatori, a seconda delle necessità del progetto possono essere rimossi o aggiunti nuovi livelli. Che cosa dovrebbe essere tenuto presente è la necessità per la programmazione imperativa orientata al dominio.

Ma c'è qualcosa da notare, Pires (2016) DDD programmazione non è un'architettura a più livelli, né una ricetta pronta per l'uso in qualsiasi software per essere sviluppato. La DDD si concentra sullo sviluppo orientato al dominio, questo è lo stato attivo e non gli strati.

Prima di tali concetti, raggiungiamo i principali benefici acquisiti utilizzando il DDD che secondo Cukier (2010) è che l'induzione per lo sviluppo di software all'interno dello scenario del miglioramento continuo, che lo rende uno strumento estremamente utile per sviluppare software per qualità e che soddisfa le esigenze del cliente.

Quindi, applicare lo standard dei progetti di mezzi di salvataggio DDD veramente programmazione orientata a oggetti, perché l'implementazione del team di sviluppo è necessario per applicare altre norme come: Repository, decoratore, strategia, stato tra gli altri.

2.2. SOLIDO

Secondo Martin (2008), Robert c. Martin identificato cinque principi della programmazione orientata agli oggetti che cercano il miglioramento dei codici, tali principi sono SRP, OCP, LSP, ISP e DIP. Prima di questi principi, Michael Feathers notato che potrebbe essere creato l'acronimo chiamato solido contenente i cinque principi. L'immagine seguente illustra il significato dell'acronimo:

Segue la definizione di ogni parte dell'acronimo secondo la pubblicazione di Martin (2008):

• Responsabilità singolo principio o principio di responsabilità di singolo: una classe dovrebbe avere uno e un solo motivo per cambiare. Questo principio che una classe deve avere solo un unico scopo, per esempio: quando la creazione di una calcolatrice non dovrebbe rendere una matematica classe operazioni e mettere tutte le sue operazioni, ma piuttosto, rendono una classe per ogni operazione;
• Aprire Closed Principle o principio di aperto-chiuso: uno dovrebbe essere sempre aperto alla estensione e chiuso per l'attuazione, che è il motivo, quando si apportano modifiche a un codice esistente corre il rischio di un impatto di errore su parecchi altri frammenti di codice;
• Principio di sostituzione di Liskov o di sostituzione di Liskov: classi basi dovrebbero sempre essere sostituibile da sue fondamenta, vale a dire una classe classe B eredita un 1 gennaio sempre può essere sostituita dalla classe in un'implementazione di codice;
• Principio di isolamento di interfaccia o principio di separazione delle interfacce: molte interfacce specifiche sono meglio di una singola interfaccia, come questa pratica mira a ridurre l'accoppiamento dei codici;
• Principio di inversione di dipendenza o principio di inversione di dipendenza: uno dovrebbe sempre fare affidamento su un'astrazione e mai di un'implementazione.

Quando si applica il solido, si ottengono i seguenti vantaggi per il vostro progetto: possibilità di eseguire gli sviluppi del progetto e di manutenzione, facilità di esecuzione di test automatizzati, meno sforzo per lo sviluppo e il massimo riutilizzo di codice del codice.

3. Proposta nuova collezione sistema

Lo scopo di questo articolo è quello di fornire la conoscenza di base per lo sviluppo di nuovo software per la gestione dell'insieme dalla Soprintendenza della zona di libero scambio Manaus-Suframa utilizzando il paradigma della programmazione orientata a oggetti dall'applicazione delle norme di Progetti DDD e solido nello sviluppo del progetto.

In questa proposta, seguendo un piano d'azione basato sul modello di amministrazione 5W1H, avremmo la seguente pianificazione per un ulteriore sviluppo:

Tabella 01-piano d'azione per lo sviluppo del nuovo sistema.

Fonte: Disegnato dall'autore.

Come nella tabella qui sopra, sembra che il progetto prenderà circa sei e una metà di mesi per completare, tuttavia dovrebbe essere notato che questo piano d'azione contiene macro, azioni sarebbero necessari altri piani al dettaglio ogni azione in esecuzione della macro.

In considerazione l'azione di "codifica" punta su 01 tabella, l'utilizzo di DDD, questa proposta raccomanda essere creato i seguenti strati:

• Layer-questo livello di presentazione sarà visione dell'utente e per angolare framework web 2.0 sarà utilizzato e per dispositivi mobili (Android/IOS) utilizzando il framework ionico;
• Strato di servizi – sarà responsabile di fornire il livello di presentazione tutti i servizi Web in formato di resto e avrà il ruolo di controllo utilizzando la dipendenza iniezione quadro ninject;
• Strato di applicazione – responsabile per le implementazioni di applicazione, come log record e dominio incapsulamento;
• Dominio strato-contiene l'implementazione di regole di business, sarà l'entità, interfacce e servizi di dominio;
• Livello di infrastrutture – responsabile dei dati accedere al secondo livello utilizzando uno strumento ORM, dai repository, inviando messaggi di posta elettronica e l'autenticazione.

In tutti gli strati devono essere applicati i principi di solido.

Conclusione

In questo articolo tecnico voluto semplicemente redigere una proposta concreta di migrazione da un sistema legacy nello sviluppo di piattaforma bassa per una moderna piattaforma utilizzando come base gli standard dei progetti di sviluppo di Software orientato allo sviluppo Dominio (DDD) e solido.

Resta inteso che la presente proposta serve come base non solo per la raccolta della Soprintendenza della zona franca di Manaus, ma anche come base per altri progetti di migrazione ed evoluzione del software in esecuzione in aperto per ulteriori regolazioni e futuri riedizioni di altri autori.

Riferimenti

Vasca di tintura, Kent. "Modelli di implementazione". Bookman. 2013. 168 p. ISBN 8565837971.

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

Evans, Eric. "Domain Driven Design 3 ° edizione". Libri alte. 2016. 528p. ISBN 8550800651.

Martin, Robert. Codice pulito: Un manuale di Software Agile artigianato ". Prentice Hall PTR. 431p. ISBN 0132350882.

Disponibile a: <http: cieam.com.br/?u="suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf">letta il 21 aprile 2017.</http:>

Disponibile a: <http: www.eduardopires.net.br/2012/06/ddd-tdd-bdd/="">letta il 21 aprile 2017.</http:>

Disponibile a: <http: www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/="">letta il 21 aprile 2017.</http:>

Disponibile a: <http: www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/="">letta il 21 aprile 2017.</http:>

[1] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si. Esperto di database per ULBRA.

[2] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.

[3] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.

[4] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.

[5] Laureato in informatica, si comporta come un server pubblico su SUFRAMA, come analista amministrativo-si.

[6] Laureato in informatica, atti come server SUFRAMA, come analista amministrativo-si.

[7] Laureato in informatica, atti come server SUFRAMA, come analista amministrativo-si.

[8] Laureato in economia aziendale, atti come dipendente pubblico il SUFRAMA, come amministratore.

[9] Si è laureato in economia e commercio, atti come dipendente pubblico il SUFRAMA, come economista.