La proposition de changements dans le système actuel de collecte Suframa pour une plateforme orientée objet en utilisant les modèles de projet de DDD et solides.

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. La proposition de changements dans le système actuel de collecte Suframa pour une plateforme orientée objet en utilisant les modèles de projet de DDD et solides. Revue scientifique pluridisciplinaire de la base de connaissances. 07 edition. année 02, vol. 03. p. 36-43, octobre 2017. ISSN : 0959-2448

Résumé

La collecte d’une Agence fédérale Suframa est extrêmement complexe, qu’il y a plusieurs intégration juridique et réglementaire nécessaire pour un bon fonctionnement. Par conséquent, il est justifié d’utiliser un système robuste qui répond aux règles d’entreprise et les évolutions nécessaires dans ce processus dynamique. Pour cette raison, cet article cherche à offrir une solution viable du point de vue de l’architecture de logiciels pour développer une solution avec code de qualité à l’aide de projets DDD et des motifs solides.

1. Introduction

Le logiciel actuel qui gère la collection conservée par la Suframa a été développé au milieu des années 1990 avec la plate-forme le Cobol programmation language et la base de données SQL DBB, qui est une version antérieure à DB2 d’IBM. Selon l’ordinateur de l’autorité de Coordination, un tel système fonctionne sur la plate-forme basse, c'est-à-dire sur un Mainframe IBM Z22.

Avant le logiciel dans le fonctionnement de l’établissement, nous pouvons mettre en évidence les problèmes suivants :

• Limitation de stockage de base de données et les données non relationnelles ;
• Langage de programmation structurée ;
• Manque de contrôle de version des codes ;
• Absence de tests intégrés ;
• Difficulté du travail à effectuer la maintenance du système.

Comme chacun le sait, un logiciel de cette dimension est un « live » ayant besoin d’une évolution constante. Dans cette optique, il a été constaté par ordinateur Coordination de Suframa qui ces logiciels ne satisfait pas les besoins d’affaires plus ni Qu'aux besoins technologiques, entre les besoins des principaux développements sont les suivants :

• Intégration avec les plateformes web via les services Web ;
• Intégration avec les plateformes fixes et mobiles
• Transformation, production et exportation des rapports dans différents formats.

Selon le site électronique de l’institution, l’organe de surveillance de la Zone franche de Manaus (Suframa) – est une collectivité locale du gouvernement fédéral relevant du ministère de l’industrie, de commerce et de services qui vise à construire un modèle de développement régional utiliser les ressources naturelles de manière durable assurant la viabilité économique et l’amélioration de la qualité de vie de la population. Actuellement la Suframa a comme champ d’application les États d’Amazonas, Acre, Rondônia, Roraima et Amapá.

Sur l’importance de la municipalité pour la région et le volume important de ressources collectées, justifie le développement d’un nouveau système de collecte des technologies et des modèles d’architecture de logiciels modernes utilisés. Par conséquent, au cours de cet article sera proposé une stratégie pour le développement des logiciels mentionnés dans cet article.

2. Modèles d’architecture logicielle

Avant de nous définir quels modèles utiliseront, il est important de définir ce qu’est un modèle de conception de logiciel, donc, selon les normes de conception de Gamma (2000) sont des solutions génériques pour les problèmes plus courants et récurrents en développement logiciel Orienté objet (POO) par une équipe de développement de logiciels.

L’objectif principal du projet est de réduire le risque d’erreurs dans le logiciel grâce à l’utilisation de techniques largement testé et approuvé par la communauté de développement de logiciel.

Deuxième Gamma (2001), actuellement il y a plusieurs modèles de conception et beaucoup d’informations disponibles pour la recherche, parmi ces modèles, que nous pouvons mettre en évidence :

• Injection de dépendance ou d’Injection de dépendance ;
• Méthode de fabrique ;
• Bulder ;
• Usine abstracty ;
• Singleton ;
• Prototype ;
• Commande ;
• Itérateur ;
• Stratégie ;
• Visiteur entre autres ;

Au milieu de la multitude des normes existantes, cet article cherche à mettre en évidence les modèles suggérés comme base pour le développement du nouveau système de collection de l’inspection générale de la zone franche de Manaus qui sont : Domain-Driven Design (DDD) et solide, parce que l’utilisation des deux impliquent dans l’utilisation des différentes pratiques de développement logiciel.

De cette façon, ne signifie pas que la durée du projet ne peut-être pas être utilisée autres normes, juste par l’enseignement des questions seront également adressées ces deux patrons dans cet article. Ainsi, dans les chapitres suivants nous aborderons profondément ces normes.

2.1. La conception par défaut pilotée par le domaine (DDD)

Selon Evans (2016) développement piloté par domaine (DDD) est une approche structurée à la conception logicielle qui répond à une série de concepts et de techniques mettant toujours l’accent dans le domaine du logiciel.

Dans ce modèle, l’objectif du développement est dans le domaine du système, c'est-à-dire les règles de l’entreprise de logiciels.

Un grand avantage de la DDD est que votre approche est totalement orienté objet, c'est-à-dire les développeurs doivent créer le logiciel en utilisant l’objet programmation orientée, de cette façon, deuxième Cukier (2010) les avantages obtenus sont les suivants :

• Alignement du code avec l’entreprise : l’implication des développeurs avec des experts connaisseurs/domaine est primordiale lorsque DDD, il s’agit d’une caractéristique du développement agile ;
• Encourager la réutilisation : les codes élaborés, peuvent être réutilisés de manière transparente.
• Couplage minimal : après le modèle de données bien développé de modélisation, organisé, les « couches » du logiciel peuvent communiquer sans dépendance grâce à l’utilisation des interfaces ;
• L’indépendance technologique : DDD n’est pas axé sur la technologie utilisée dans le développement du logiciel, mais dans des règles d’entreprise.

Cependant, votre objectif est d’atteindre l’indicatif nécessaire pour les logiciels à être développé en utilisant une architecture qui permet à l’application des concepts de DDD, alors deuxième Cukier (2010) le motif suggère l’utilisation de quatre couches principales sont :

Dans la figure ci-dessus, Voici des précisions deuxième Cukier (2010) :

• Interface utilisateur – est la couche responsable par une interaction directe avec l’utilisateur, comme écrans logiciels, Web Services SOA ou repos, des applications mobiles ou d’ordinateurs de bureau, entre autres ;
• Application-fonctionne directement avec la couche de domaine afin d’isoler la zone du calque « Interface utilisateur », il est important pour les documents de séjour distincts, par exemple : il n’y a aucun besoin de connaître la classe d’interface qui ne doit exécuter certaines actions . De cette façon, la couche application est une sorte de médiateur entre le domaine et l’interface ;
• Domaine – est la couche qui contient toutes les règles de l’entreprise de l’application, c'est-à-dire tout ce qui reflète les exigences fonctionnelles, les calculs sont traités dans cette couche ;
• Infrastructure – responsable de l’interaction avec l’infrastructure technique, par exemple, l’accès aux données, l’accès aux systèmes de fichiers, présentations de courriel, entre autres.

Ces couches ne sont pas obligatoires, selon le besoin du projet peuvent être enlevés ou ajouté de nouveaux calques. Ce qui devrait garder à l’esprit est la nécessité pour la programmation impérative, orientée vers le domaine.

Mais il y a quelque chose à noter, selon Pires DDD (2016), programmation n’est pas une architecture en couches, ni une prescription prêt à être utilisé dans n’importe quel logiciel à développer. Le DDD met l’accent sur le développement axés sur le domaine, il s’agit de la mise au point et pas les couches.

Avant ces concepts, nous atteignons les principaux avantages gagnés en utilisant la DDD cette deuxième Cukier (2010) qui est l’induction pour le développement de logiciels dans le scénario d’amélioration continue, ce qui en fait un outil extrêmement utile pour développer des logiciels pour qualité et qui répond aux besoins du client.

Alors, appliquer la norme de projets moyens de sauvetage DDD vraiment programmation orientée objet, parce que votre implémentation de l’équipe de développement est tenu d’appliquer les autres normes telles que : référentiel, décorateur, stratégie, état entre autres.

2.2. SOLIDE

Selon Martin (2008), Robert c. Martin identifié cinq principes de programmation orientée objet qui visent l’amélioration des codes, ces principes sont SRP, OCP, LSP, ISP et DIP. Avant ces principes, Michael Feathers a noté que pourrait créer l’acronyme appelé solide contenant les cinq principes. L’image suivante montre la signification de l’acronyme :

Conforme à la définition de chaque partie de l’acronyme selon la publication de Martin (2008) :

• Responsabilité unique principe ou principe de responsabilité unique : une classe doit avoir un et une seule raison de changer. Ce principe, une classe doit avoir qu’un seul but, par exemple : quand créer un calculateur de ne devrait pas faire un math classe opérations et mettre toutes ses opérations, faire mais plutôt une classe pour chaque opération ;
• Ouvert fermé ou ouvert-fermé principe : il faut toujours ouverte à l’extension et fermé pour la mise en œuvre, c’est pourquoi, lorsque vous apportez des modifications à un code existant court le risque d’un impact de l’erreur sur plusieurs autres fragments de code ;
• Principe de Substitution de Liskov ou de substitution de Liskov : les classes de bases doivent toujours être remplaçables par ses fondations, c'est-à-dire une classe classe B hérite un 1 janvier toujours peut être substituée par la classe dans une implémentation de code ;
• Interface ségrégation ou principe de la séparation des Interfaces : nombre d’interfaces spécifique valent mieux qu’une interface unique, que cette pratique a pour but de réduire le couplage de codes ;
• Inversion de dépendance ou principe d’inversion de dépendance : on doit toujours compter sur une abstraction et jamais d’une implémentation.

Lorsque vous appliquez le solide, vous bénéficiez des avantages suivants à votre projet : installation d’effectuer des développements de projet et de l’entretien, facilité de test automatisé, moins d’effort pour coder le développement et le maximum de réutilisation du code.

3. Nouvelle collection System a proposé

Le but de cet article est de fournir la base de connaissances pour le développement de nouveaux logiciels pour la gestion de la collection conservée par l’inspection générale de la zone de libre-échange Manaus-Suframa utilisant le paradigme de programmation orientée objet en appliquant les normes de Projets DDD et solide au développement du projet.

Dans cette proposition, suite à un plan d’action basé sur le modèle d’administration de 5W1H, nous aurions la planification suivante pour poursuivre son développement :

Tableau 01-plan d’action pour le développement du nouveau système.

Que faut-il faire ?	Pourquoi ?	Comment ?	Où ?	Qui ?	Quand ?
Définir le langage de programmation et technologies pour le projet	Standardiser le développement de logiciels.	Réunions techniques	Sur la coordination de l’informatique	Gestionnaires de TIC, les programmeurs et les architectes logiciels	Première semaine
Préparer l’environnement de développement et d’approbation	Créer des mécanismes pour l’équipe de travailler sur le projet	Installation des serveurs, des logiciels et des cadres	Sur le poste de travail des membres de l’équipe de développement et sur les serveurs.	Équipe de configuration et prise en charge des TIC	Deuxième semaine
Configuration logicielle requise collecte	Documenter l’information d’être programmé sur le terrain	Rencontres et entrevues	Suframa	Analystes d’exigences	La semaine 10 semaine 3.
Encodage	Créer le logiciel	Codage et tests	Sur Suframa	Software Factory	De la semaine 22 semaine 11.
Approbation et corrections	Vérifier si ce qui a été mis au point est vraiment ce que les besoins de la Suframa et effectuer les corrections	Les tests	Environnement d’approbation	Experts du domaine (affaires)	De la semaine 23 à 25.
Déploiement	Rendre le système dans la production	Faire la construction dans l’environnement de production	Systèmes d’hébergement	Analyste de configuration	Semaine 26.

Source : Dessiné par l’auteur.

Comme le tableau ci-dessus, il semble que le projet prendra environ six mois pour terminer, il convient toutefois de noter que ce plan d’action contienne des macros, des actions serait nécessaire des autres régimes de détailler chaque action dans l’exécution de votre macro.

Compte tenu de l’action de « codage » pointu sur 01 tableau, l’utilisation de DDD, cette proposition recommande créé les couches suivantes :

• Couche-cette couche de présentation sera vision de l’utilisateur et pour le web 2.0 cadre angulaire sera utilisé et aux appareils mobiles (Android/IOS) en utilisant le framework ionique ;
• Couche de services – sera chargé de fournir la couche de présentation tous les webservices sous forme de repos et aurez pour mission de contrôle à l’aide du dependency injection cadre ninject ;
• Couche application – responsable des implémentations d’application, tel que log record et domaine encapsulation ;
• Domaine couche-contient l’implémentation des règles d’entreprise, ce sera les entités, les Interfaces et les services de domaine ;
• Couche à l’aide d’un outil ORM, de référentiels, en envoyant des e-mails et authentification d’accès aux couche infrastructure – responsable des données.

Dans toutes les couches doivent être appliquent les principes du solide.

Conclusion

Cet article technique voulu simplement élaborer une proposition concrète de la migration d’un système hérité dans le développement de la plate-forme basse pour une plate-forme moderne en utilisant comme base des normes de projets de développement logiciel orienté vers le développement Domaine (DDD) et solide.

Il est entendu que cette proposition sert comme base non seulement pour la collecte de la Surintendance de la zone franche de Manaus, mais aussi comme base pour d’autres projets de migration et évolution des logiciels s’exécutant dans propice aux ajustements et rééditions futures de d’autres auteurs.

Références

Beck, Kent. « Patterns of application ». Bookman. 2013. 168P. ISBN 8565837971.

Gamma, Erich. « Design patterns ». Bookman. 2000. 528p. ISBN 8573076100.

Evans, Eric. « Domain Driven Design 3e édition ». Livres hautes. 2016. 528p. ISBN 8550800651.

Martin, Robert. Code propre : Un guide de l’artisanat de logiciel Agile «. Prentice Hall PTR. 431p. ISBN 0132350882.

Disponible à : <http: cieam.com.br/?u="suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf">consulté le 21 avril 2017.</http:>

Disponible à : <http: www.eduardopires.net.br/2012/06/ddd-tdd-bdd/="">consulté le 21 avril 2017.</http:>

Disponible à : <http: www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/="">consulté le 21 avril 2017.</http:>

Disponible à : <http: www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/="">consulté le 21 avril 2017.</http:>

[1] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous. Spécialiste de la base de données pour ULBRA.

[2] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[3] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[4] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[5] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[6] Gradué en informatique, agit en tant que serveur SUFRAMA, en tant qu’analyste administratif-vous.

[7] Gradué en informatique, agit en tant que serveur SUFRAMA, en tant qu’analyste administratif-vous.

[8] Diplômé en administration des affaires, agit en tant que fonctionnaire sur SUFRAMA, en tant qu’administrateur.

[9] Diplômé en économie, agit en tant que fonctionnaire sur SUFRAMA, en tant qu’économiste.