Предложение о внесении изменений в нынешней системе Suframa коллекции для объектно ориентированных платформы с использованием шаблонов проекта ДДД и твердых.

0
808
DOI: ESTE ARTIGO AINDA NÃO POSSUI DOI SOLICITAR AGORA!
PDF

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. Предложение о внесении изменений в нынешней системе Suframa коллекции для объектно ориентированных платформы с использованием шаблонов проекта ДДД и твердых. Междисциплинарный основной научный журнал знаний. 07 издание. том 03 02 года. PP 36-43, октябрь 2017. ISSN: 0959-2448

Резюме

Коллекция Федерального агентства как Suframa является чрезвычайно сложной, как есть несколько правовых и нормативных интеграции необходимых для бесперебойной работы. Таким образом это оправдано использовать надежные системы, которая удовлетворяет бизнес-правила и необходимые изменения в этот динамичный процесс. По этой причине эта статья стремится предложить жизнеспособные предложения с точки зрения архитектуры программного обеспечения для разработки решения с качества кода с помощью DDD проектов и твердых моделей.

1. Введение

Текущее Программное обеспечение, которое управляет коллекцией, проведенных Suframa был разработан в середине 1990-х с платформой Cobol языка программирования и базы данных SQL DBB, который является более ранней версии, чем DB2 от IBM. Согласно координационный орган компьютер такая система работает на низкой платформы, то есть на Mainframe IBM Z22.

До программного обеспечения в эксплуатацию в учреждении мы можем выделить следующие проблемы:

  • Non реляционной базы данных и данных ограничения хранения;
  • Язык структурного программирования;
  • Отсутствие управления версиями кодов;
  • Отсутствие комплексных испытаний;
  • Сложности труда выполнять обслуживание системы.

Как хорошо известно, программное обеспечение этого измерения является «живой» нуждается в постоянной разработки. В этом свете он нашел компьютер координации Suframa, что такое программное обеспечение не нужд бизнес более ни технологические потребности, между потребностями основных событий являются следующие:

  • Интеграция с веб-платформ через веб-службы;
  • Интеграция с платформ и мобильные
  • Обработка, создание и экспорт отчетов в различных форматах.

По данным электронного сайта учреждения, Управление свободной зоне Манауса (Suframa) – это местный орган власти федерального правительства под эгидой министерства промышленности, торговли и услуг, который стремится построить модель регионального развития использование природных ресурсов на устойчивой основе, обеспечение экономической жизнеспособности и улучшение качества жизни населения. В настоящее время Suframa имеет как область штатов Амазонас, Акко, Рондония, Рорайма и Амапа.

О важности муниципалитета для региона и большой объем ресурсов, собранных оправдывает развитие новой системы для сбора шаблоны архитектура используется современное программное обеспечение и технологии. Таким образом курс этой статьи будет предложил стратегию для разработки программного обеспечения, упомянутые в этой статье.

2. Шаблоны архитектуры программного обеспечения

Перед тем, как мы определяем, какие шаблоны будут использовать, важно определить, что такое шаблон проектирования программного обеспечения, таким образом, стандарту дизайн гамма (2000), универсальные решения для наиболее распространенных и повторяющихся проблем в разработке программного обеспечения Объектно ориентированное (ООП) группой разработки программного обеспечения.

Основной целью проекта является уменьшить риск ошибок в программном обеспечении за счет использования методов широко проверен и одобрен разработчиков программного обеспечения.

Второй гамма (2001), в настоящее время существует несколько шаблонов проектирования и много информации для исследований, среди этих моделей, которые мы можем выделить:

  • Зависимостей или инъекции зависимостей;
  • Фабричный метод;
  • Bulder;
  • Abstracty завод;
  • Синглтон;
  • Прототип;
  • Команда;
  • Итератор;
  • Стратегия;
  • Посетитель, среди прочих;

Среди множества существующих стандартов, эта статья стремится подчеркнуть предлагаемых моделей в качестве основы для разработки новой системы сбора главное Манаус зоны свободной торговли, которые являются: Domain-Driven проектирования (DDD) и твердых, потому что подразумевает использование обоих в использовании различных методов разработки программного обеспечения.

Таким образом, не означает, что курс проекта не могут быть использованы другие, просто путем преподавания, вопросы будут рассмотрены стандарты этих двух шаблонов в этой статье. Таким образом в следующих главах мы будем решать глубоко таких стандартов.

2.1. По умолчанию проблемно ориентированное проектирование (DDD)

По словам Эванс (2016) разработка домена driven (DDD) — дисциплинированный подход к разработке программного обеспечения, которое устраняет ряд концепций и методов, всегда упором в области программного обеспечения.

В этой модели в центре развития находится в области системы, т.е. правила программного обеспечения бизнеса.

Большим преимуществом DDD, что ваш подход полностью объектно ориентированный, т.е. разработчики должны создавать программное обеспечение с использованием объектно ориентированного программирования, таким образом, второй Кукиер (2010) достигнутые преимущества являются следующие:

  • Код выравнивание с бизнесом: участие разработчиков с экспертами ценителей/домен имеет первостепенное значение при DDD, это особенность гибкой разработки;
  • Поощрять повторное использование: коды, разработанные, может быть повторно использован транспарентным образом.
  • Минимальная муфта: после моделирования модель данных, который хорошо развиты, организованной, «слои» программного обеспечения можно общаться без зависимостей с помощью интерфейсов;
  • Технология независимости: DDD не сосредоточиться на технологии, используемые в разработке программного обеспечения, но в бизнес-правила.

Однако, ваша цель заключается в достижении области код, необходимый для программного обеспечения разработаны с использованием архитектуры, которая позволяет применение концепции DDD, так что второй Кукиер (2010) шаблон предполагает использование четырех основных слоев:

Рисунок 1-Предлагаемая архитектура для DDD. Источник: Cukier (2010)
Рисунок 1-Предлагаемая архитектура для DDD. Источник: Cukier (2010)

На рисунке выше, ниже приведены разъяснения второй Кукиер (2010):

  • Пользовательский интерфейс – это слой отвечает за прямое взаимодействие с пользователем, как экраны программного обеспечения, Web Services SOA или отдых, мобильных приложений или настольных компьютеров, среди прочих;
  • Приложение работает непосредственно с уровня домена с целью изолировать области слоя «Пользовательский интерфейс», это важно для документов различны, например: существует не нужно знать который интерфейс класса домена необходимо выполнить некоторые действия . Таким образом уровень приложения является своего рода посредником между доменом и интерфейса;
  • Домен – это слой, который содержит все бизнес-правила применения, то есть все, что отражает функциональные требования, расчеты, обрабатываются в этом слое;
  • Инфраструктура – отвечает за взаимодействие с технической инфраструктуры, например, доступ к данным, доступ к электронной почте представлений, среди других файловых систем.

Эти слои не являются обязательными, в зависимости от потребностей проекта могут быть удалены или добавлены новые слои. Что следует иметь в виду, является необходимость императивного программирования, направленных в домене.

Но есть кое-что отметить, согласно Пиреш (2016) DDD программирование не является многоуровневой архитектуры, ни рецепт готов к использованию в любое программное обеспечение, чтобы быть разработаны. DDD фокусируется на домен ориентированной разработки, это фокус и не слои.

Перед такой концепции, мы достигнем основные преимущества, полученные с помощью DDD, второй Кукиер (2010), что для разработки программного обеспечения в рамках сценария индукции непрерывного совершенствования, что делает его чрезвычайно полезным инструментом для разработки программного обеспечения для качество и что отвечает потребностям клиента.

Таким образом, применять стандарт проектов средства спасения действительно программирования DDD объектно ориентированный, потому что ваша реализация команда разработчиков не требуется применять другие стандарты, такие как: репозитория, декоратор, стратегия, государство, среди других.

2.2. ТВЕРДЫЕ

По словам Мартина (2008) Роберт c. Мартин определены пять принципов объектно ориентированного программирования, которые стремятся улучшению кодов, такие принципы ПСП, OCP, LSP, ISP и DIP. Прежде чем эти принципы Майкл перья отметил, что, может быть создан акроним, называется твердых содержащий пять принципов. Следующее изображение демонстрирует смысл акроним:

Рисунок 2 – твердое представление. Источник: Мартин (2008)
Рисунок 2 – твердое представление. Источник: Мартин (2008)

Ниже приводится определение каждой частью акроним согласно публикации Мартин (2008):

  • Персональной ответственности принципа или принцип персональной ответственности: класс должен иметь один и только один причин для изменения. Этот принцип, класс должен иметь только одну цель, например: при создании калькулятор не следует сделать класс математических операций и поставить всех ее операций, а, скорее, сделать отдельный класс для каждой операции;
  • Откройте принцип закрытия или открытый-закрытый принцип: один всегда должен быть открыт для расширения и закрыт для осуществления, вот почему, когда вы делаете изменения в существующий код рискует влияния ошибки на нескольких других фрагментов кода;
  • Принцип подстановки Лискоу или подстановки Лискоу: классы базы всегда должно быть сменным его фондов, то есть, класс B наследует класс 1 января всегда может быть переопределен в классе в реализации кода;
  • Принцип разделения интерфейса или принципом разделения интерфейсов: много конкретных интерфейсов лучше, чем один единый интерфейс, поскольку эта практика направлена на уменьшение сцепления кодов;
  • Принцип инверсии зависимостей или принцип инверсии зависимостей: один всегда должен зависеть от абстракции и никогда не реализации.

При применении твердого тела, вы получаете следующие преимущества для вашего проекта: объект для выполнения технического обслуживания и проекта события, простота автоматизированного тестирования, меньше усилий для развития и максимальное повторное использование кода кода.

3. Предлагаемая новая коллекция системы

Целью этой статьи является предоставить базу знаний для разработки нового программного обеспечения для управления коллекции, проведенного Управлением Манаус свободной торговли зоны Suframa с использованием парадигмы объектно ориентированного программирования путем применения стандартов DDD и твердых проекты в развитии проекта.

В этом предложении следующий план действий, основанный на модели администрирования 5W1H, мы бы следующие планирования для дальнейшего развития:

Таблица 01-план развития новой системы.

Что делать? Почему? Каким образом? Где? Кто? Когда?
Определить язык программирования и технологии для проекта Стандартизация разработки программного обеспечения. Технические совещания О координации в области информатики Менеджеры ИКТ, программисты и разработчики программного обеспечения Первая неделя
Подготовка среды разработки и утверждения Создать механизмы для команды для работы над проектом Установка серверов, программного обеспечения и рамки На рабочей станции, членов группы разработки и на серверах. Команды настройки и поддержки ИКТ Вторая неделя
Требования к программному обеспечению сбора Документ информация быть запрограммированы в поле Встречи и интервью Suframa Требования к аналитики 10 недели 3 недели.
Кодирование Создание программного обеспечения Кодирование и тестирование На Suframa Фабрика программного обеспечения 22 недели 11 недели.
Утверждение и исправления Узнайте, если то, что был разработан действительно что Suframa потребностей и выполнения исправления Выполнение тестов Одобрение окружающая среда Доменные экспертов (бизнес) Неделя 23-25.
Развертывание Сделать систему в производство Построение в производственной среде Хостинг системы Аналитик конфигурации Неделя 26.

Источник: Нарисована автором.

В таблице выше, представляется, что проект займет около шести с половиной месяцев для завершения, однако следует отметить, что этот план действий содержит макросы, действия будут необходимы другие планы к деталям каждого действия в вашем выполнения макроса.

С учетом действия «кодирование» указал на 01 таблицы, использование DDD, рекомендует это предложение быть созданы следующие слои:

  • Презентационный слой и слой это будет пользователя видение и для угловых рамки web 2.0 будет использоваться и для мобильных устройств (Android/IOS) с помощью платформы ионных;
  • Слой служб – будет отвечать за предоставление слой представления всех веб-служб в формате REST и будет иметь роль управления с помощью ninject рамки инъекции зависимостей;
  • Применение слой – ответственность за применение реализаций, как журнал запись и домен инкапсуляции;
  • Домен содержит слой реализации бизнес-правил, он будет сущности, интерфейсы и доменных службах;
  • Уровень инфраструктуры – ответственность за данные доступа к слоя с помощью инструмента ORM в репозитории, путем отправки сообщения электронной почты и проверки подлинности.

В все слои должны быть применены принципы твердых.

Заключение

Эта Техническая статья, стремился просто разработать конкретное предложение о миграции от устаревшей системы в низкой платформы развития для современной платформы, используя в качестве базы стандартов проектов разработки программного обеспечения ориентированной на развитие Домен (DDD) и твердых.

Понятно, что это предложение служит основой не только для коллекции управление свободной зоне Манауса, но и как основа для других проектов миграции и эволюции программного обеспечения, работающего в открытом для дальнейшей корректировки и будущих повторно вопросов другие авторы.

Ссылки

Бек, Кент. «Динамика реализации». Книжник. 2013. 168 p. ISBN 8565837971.

Гамма, Эрих. «Шаблоны проектирования». Книжник. 2000. 528p. ISBN 8573076100.

Эванс, Эрик. «Домена инициативе дизайн 3-е издание». Высокая книги. 2016. 528p. ISBN 8550800651.

Мартин, Роберт. Чистый код: Справочник мастерства гибкой разработки программного обеспечения». Прентис Холл PTR. 431p. ISBN 0132350882.

Доступно в: <http: cieam.com.br/?u="suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf">на 21 апреля 2017.</http:>

Доступно в: <http: www.eduardopires.net.br/2012/06/ddd-tdd-bdd/="">на 21 апреля 2017.</http:>

Доступно в: <http: www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/="">на 21 апреля 2017.</http:>

Доступно в: <http: www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/="">на 21 апреля 2017.</http:>

[1] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы. Специалист по базам данных для УЛБРА.

[2] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.

[3] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.

[4] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.

[5] Окончил в области компьютерных наук, он действует как общественных сервер на SUFRAMA, что административные аналитик-вы.

[6] Окончил в области компьютерных наук, действует как сервер SUFRAMA, как административные аналитик-вы.

[7] Окончил в области компьютерных наук, действует как сервер SUFRAMA, как административные аналитик-вы.

[8] Окончил в области делового администрирования, выступает в качестве государственного служащего на SUFRAMA, как администратор.

[9] Окончил в экономике, выступает в качестве государственного служащего на SUFRAMA, как экономист.

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here