Java Agile Development: управление данными с помощью моделей предметной области Java

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

Сегодня вы узнаете, как реализовать различные реляционные модели с помощью фреймворка Spring. Мы покажем вам, как использовать гибкую разработку, основанную на тестировании. Эти популярные методологии помогают нам проектировать и разрабатывать надежные и управляемые приложения.

Что такое гибкая разработка?

Гибкая разработка — это новая методология, которая покорила отрасль. Эта методология разработки программного обеспечения позволяет нам создавать программу постепенно с короткими итерациями в течение 1–4 недель. Пошаговая процедура помогает согласовать процесс разработки с потребностями бизнеса.

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

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

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

Что такое разработка через тестирование?

Разработка через тестирование (TDD) — это ключевой метод разработки, который делает возможной гибкую разработку. TDD ориентирован на постепенную разработку путем создания и тестирования небольших фрагментов кода во время разработки. Если все небольшие фрагменты кода проходят испытания, проект готов к отправке.

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

Процесс TDD состоит из 4 этапов:

1. Напишите тестовый код, который проверяет наличие небольшой желаемой функции.
2. Запустите тест. Это не должно произойти, потому что код еще не добавлен. Если это прошло, вернитесь к шагу 1.
3. Добавьте код, достаточный только для реализации желаемой функции.
4. Снова запустите тест. Если он прошел, переходите к другой функции. Если тест не прошел, вернитесь к шагу 3.

С помощью TDD мы можем делать небольшие измеримые шаги к завершению более крупного проекта. Вместо того, чтобы чувствовать себя перегруженным большой задачей «создать веб-приложение», вы можете разбить ее на небольшие шаги, такие как «создать кнопку входа», «отобразить новейший контент» и т. Д.

TDD также полезен для отладки. Каждый цикл процесса TDD включает меньше кода, чем традиционный процесс кодирования. Намного проще проверить 10-строчный объект на наличие ошибок, чем полный проект на 1000 строк.

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

Модели предметной области для управления данными Java

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

Думайте о моделировании предметной области как о способе описания реальных сущностей вашей программы и отношений между ними.

Гибкие разработчики отдают предпочтение моделированию предметной области для своих реальных приложений и командного планирования. Моделирование предметной области — это концептуальная модель, которая отслеживает как поведение, так и данные сегмента проекта. Каждый из этих сегментов называется «доменами» и представляет собой сферы реальных знаний или поведения в коде.

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

Пример чертежа модели предметной области

Домены обычно представлены в виде прямоугольников, соединенных с другими связанными доменами сетью стрелок. В Java домены представлены через классы.

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

Обзор: процесс разработки модели предметной области

Есть много типов моделей предметной области:

• Автономная организация
• Один к одному однонаправленный
• Один-к-одному двунаправленный
• Самостоятельная ссылка на себя
• Один-ко-многим однонаправленный
• Двунаправленный «один ко многим»
• Самостоятельная ссылка «один ко многим»
• Однонаправленный «многие ко многим»
• Двунаправленный «многие-ко-многим»
• Двунаправленные «многие-ко-многим» с атрибутом соединения
• Самостоятельная ссылка «многие-ко-многим»
• Самостоятельная ссылка «многие ко многим» с атрибутом соединения
  Наследование одной таблицы
• Наследование конкретной таблицы
• Таблицы наследование  классов

Каждый домен имеет свои сильные и слабые стороны и подходит для конкретных типов проектов. Пять наиболее распространенных моделей предметной области — это автономные сущности, однонаправленные одно-к-одному, одно-к-одному с саморегулированием, одно-ко-многим двунаправленное и много-ко-многим.

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

Для создания каждой модели требуется 7 общих шагов. Давайте погрузимся в них.

1. Объект передачи данных: разработайте объект, который действует как карта между пользовательским интерфейсом и уровнем объекта доступа к данным. Внутренний дизайн базы данных не должен раскрываться пользовательскому интерфейсу.
2. Мок-сервис: разработайте фиктивный сервис, который сохраняет данные в базе данных в памяти.
3. Имитация пользовательского интерфейса: разработайте фиктивный пользовательский интерфейс, чтобы продемонстрировать, как мы можем интегрироваться с фиктивным сервисом. Это позволяет команде пользовательского интерфейса сотрудничать с группой разработки службы, показывая, как пользовательский интерфейс взаимодействует со службой.
4. Уровень ресурсов: создайте уровень программного обеспечения ресурсов, чтобы содержать программные объекты. Сущности управляются реализацией Hibernate.
5. Уровень доступак данным : создайте программный уровень доступа к данным, который обеспечивает упрощенный доступ к объектам. Этим занимается Spring.
6. Уровень бизнес-сервисов: создайте уровень программного обеспечения бизнес-сервисов, который управляет подсистемами доступа к данным и позволяет приложениям вызывать уровень доступа к данным. Должен содержать преобразователь для перехода объектов доступа к данным в сущности.
7. Уровень презентации: создайте уровень программного обеспечения для презентации, который использует контроллеры Spring на основе JSON REST для предоставления услуг пользователям.

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

Как настроить рабочее пространство

Для успешного запуска моделей предметной области Java вам понадобится 5 инструментов. Если вы не хотите что-либо скачивать прямо сейчас, смело переходите к разделу с примерами, в котором представлен встроенный код.

Вам понадобятся следующие инструменты:

• Eclipse IDE для разработчиков Java EE
• JDK 1.7
• Apache Maven
• Сервер БД MySql
• Apache Tomcat

Вам также понадобится zip с исходным кодом из нашей книги Spring-Hibernate на Github.

Затем вам нужно будет распаковать эти файлы и импортировать их в Eclipse как проект Maven.

После выбора опции «Существующие проекты Maven» выберите папку, в которую вы распаковали загруженный файл, и выберите каталог, содержащий POM, как показано ниже.

Отсюда используйте MySQL для создания новой схемы с именем spring в MySQL Workbench.

Затем откройте Tomcat и установите сервер v7.0. Затем щелкните Добавить библиотеку -> Система JRE -> Библиотека -> Альтернативная JRE -> Установленные JRE. Установите это значение по умолчанию и нажмите «Готово».

Наконец, добавьте проект Spring OODD в конфигурацию Tomcat. После запуска Tomcat загрузит страницу индекса из web.xml.

Поздравляем, теперь у вас есть рабочее пространство для реализации моделей предметной области Java!

Далее мы обсудим пять общих моделей предметной области и научим вас создавать объект передачи данных для каждой из них.

Автономная организация

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

Например, мы можем взглянуть на сущность Productс полем строкового name.

Разработка объекта передачи данных: автономная сущность

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

public class ProductDto implements Serializable {
  private static final long serialVersionUID = 1L; private Integer id;
  private String name;

  // getters and setters 
}

Здесь implementsключевое слово сопоставляет этот объект с пользовательским интерфейсом. Каждая переменная является частной, чтобы не раскрывать структуру базы данных пользовательскому интерфейсу.

Однонаправленная связь один-к-одному

Однонаправленные модели «один к одному» включают в себя два отдельных объекта, в которых данные и сервис могут двигаться только в одном направлении. После того, как данные отправлены в дочерний объект, они не могут ссылаться на родительский объект, поскольку в дочернем элементе нет ссылки на родительский объект.

Например, представьте, что у нас есть программа доставки книжного магазина, представленная однозначной однонаправленной моделью с двумя объектами, Bookи Shipping. У Bookобъекта есть идентификатор и nameполе String. Аналогично, у Shippingобъекта есть идентификатор и cityполе String. Экземпляр Shippingдолжен присутствовать в экземпляре Book. Собственная Bookсторона отношений. Он может проходить Shipping, но Shippingне может Book.

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

Разработка объекта передачи данных: однонаправленная связь один-к-одному

Чтобы создать объект передачи данных в однонаправленной связи один-к-одному, вы будете использовать следующий BookDtoкласс:

public class BookDto { 
  private Integer id; 
  private String name; 
  private String city;
 
  // getters and setters 
}

Опять же, мы инкапсулируем дизайн объекта, используя частные переменные, чтобы предотвратить просмотр ненужной информации клиентом или пользовательским интерфейсом. Объект передачи данных содержит идентификатор Bookобъекта, имя и поле города. Однако у него нет идентификатора ShippingEntity. Пока Bookи Shippingсвязаны в сервисе, пользователь видит только Bookобъект через объект передачи данных.

Эта архитектура поможет вашей команде пользовательского интерфейса в дальнейшем, поскольку им не нужно управлять Shippingидентификатором объекта, и они могут просто вызывать службу как один объект.

Отношения один-к-одному, ссылающиеся на себя

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

Например, представьте себе отношения между Studentсущностью и наставником, который также является экземпляром Student. У каждой Studentсущности есть идентификатор и поле имени строки. У Studentорганизации может быть необязательный наставник, который также является Student. Эта ассоциация объявляется в первом случае Student, а не внутри наставника Student.

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

Разработка объекта передачи данных: однозначная связь с саморегулированием

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

public class StudentDto {
    private Integer id;
    private String name;
    private String mentorName;
    
    // getters and setters
}

Обратите внимание, что у нас есть id, nameи, mentorNameно не включают в себя идентификацию объекта наставника.

Объект передачи данных не имеет идентификатора объекта- Studentнаставника, потому что команде пользовательского интерфейса не нужно будет видеть внутренний дизайн нашей системы отношений. Мы включаем только одного mentorName, так как у каждого Studentможет быть только один наставник.

Двунаправленная связь «один ко многим»

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

Например, рассмотрим программу, которая перечисляет функции элемента с двумя объектами Itemи Feature. ItemЛицо имеет идентификатор и тип строки nameполя. FeatureПредприятие также имеет идентификатор и тип строки number поля. Каждый экземпляр Itemдолжен содержать ссылку хотя бы на один. Точно так же каждый экземпляр Featureдолжен ссылаться на один экземпляр Item.

Поскольку отношение является двунаправленным, все экземпляры одного Itemили Featureмогут получить доступ к любому связанному с ним экземпляру.

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

Разработка объекта передачи данных: двунаправленная связь «один-ко-многим»

Для двунаправленного отношения «один ко многим» наш объект передачи данных будет выглядеть так:

public class ItemDto {
    private Integer id;
    private String name;
    private List<String> featureList;
    
   // getters and setters
}

Объект Itemпередачи данных имеет идентификатор, имя Itemи список Featureимен String. Использование списка Featureимен позволяет нам связать несколько Featureобъектов с одним Item.

Мы исключаем идентификатор Featureобъекта в объекте передачи данных, чтобы упростить вызов API для команды пользовательского интерфейса. Это не только обеспечивает безопасность проекта базы данных, но также избавляет команду пользовательского интерфейса от необходимости управлять идентификаторами каждого дочернего объекта.

Однонаправленные отношения «многие ко многим»

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

Однонаправленные отношения «многие ко многим»

Например, представьте, что вы создаете простую программу для социальных сетей, которая позволяет родительской сущности, Userсвязываться с дочерней сущностью Group. UserЛицо имеет идентификатор и имя поля типа Строка. GroupПредприятие также имеет имя поле идентификатора и типа строки.

У всех отношений «многие ко многим» есть родитель. В этом примере пользователь является родителем. Каждый экземпляр Userсвязан по крайней мере с одним экземпляром Group. Многие экземпляры Userмогут быть связаны с одним и тем же экземпляром Group.

Экземпляр Userможет получить доступ к данным во всех связанных Groupэкземплярах, однако Groupэкземпляры не могут получить доступ к данным внутри Userэкземпляра.

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

Разработка объекта передачи данных: однонаправленная связь «многие-ко-многим»

Для однонаправленной связи «многие ко многим» нам нужно создать три объекта передачи данных.

public class UserDto {
    private Integer id;
    private String name;

    // getters and setters
}

public class GroupDto {
    private Integer id;
    private String name;

    // getters and setters
}

public class UserGroupDto {
    private UserDto userDto;
    private GroupDto groupDto;
    
    // getters and setters
}

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