Интернет-комплекса «Знание»

      Другое  преимущество в использовании каркаса  состоит в том, что он позволяет  коду быть в большой степени независимым  от платформы (как это и есть в  случае Struts). И это может быть достигнуто во многих случаях даже без рекомпиляции кода – то же самое Веб-приложение (или ".war" файл) может просто быть скопирован с одного сервера на другой.

      Другое  особенно важное преимущество – это  то, что каркас дает для начинающих разработчиков "место для старта". Очевидно, что проще иметь основу для приложения и расширять её чем писать все с нуля. Это качество Struts сохраняет программистам дни или даже недели планирования и разработки.

      Struts опирается на шаблон проектирования Model-View-Controller (MVC, Модель-представление-поведение»). Шаблон MVC широко признан как один из самых хорошо разработанных и зрелых шаблонов проектирования которые используются в данное время.

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

      Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контролера), изменяя свое состояние.

      Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

      Поведение (Controller). Интерпретирует данные, введённые  пользователем, и информирует модель и представление о необходимости  соответствующей реакции.

     

     Рисунок 1.2. Схема паттерна проектирования MVC

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

      Каким же образом шаблон проектирования MVC реализуется в Struts?

      Компоненты  моделей предоставляют "модель" для бизнес-логики или данные для Struts программы. Например, в Struts приложении, которое управляет данными клиентов, возможно было бы выгодно создать  компонент модели "Customer", который  бы предоставлял программе доступ к информации о клиентах. Компоненты моделей, как правило, являются стандартными Java классами. Для моделей не требуется специального формата, поэтому можно использовать код, написанный для других проектов.

      Компоненты  представления это те части приложения, которые отвечают за презентацию информации и её прием от пользователя. В Struts компоненты представления соответствуют Веб-страницам.

      Компоненты  представления используются для  представления информации хранящейся в моделях. Обычно для каждой Веб-страницы в Struts приложении имеется один или  более компонент представления.

      Компоненты  представления создаются при  помощи JavaServer Pages (JSP). Struts предлагает разработчику большое количество «JSP Custom Tags» (иногда называемых Struts Tags) которые расширяют обычные возможности JSP и упрощают разработку компонентов представления.

      Компоненты  контроля координируют деятельность в  приложении. Имеется ввиду, например, прием данных от пользователя и обновление базы данных с помощью компонента модели или обнаружение ошибки back-end системой и ее обработка. Контроллер принимает данные от пользователей, принимает решение о том какие компоненты моделей должны быть обновлены и выбирает компоненты представления, которым посылается сообщение сигнализирующее о необходимости демонстрации обновленных результатов.

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

      Компоненты  контроля в Struts являются Java классами и  должны быть созданы по определенным правилам. В контексте Struts их обычно называют «Action classes».

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

 

Глава 2. Анализ предметной области  и создание концептуальной модели

2.1. Сбор информации  о предметной области

      Анализируя  предметную область, рассмотрим более  подробно, в чём заключается деятельность Гродненской областной организации общественного объединения «Белорусское общество «Знание».

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

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

      Таким образом, можно сделать вывод, что  основная информация, которая интересует заказчиков в деятельности организации – это её сотрудники, направления, по которым они работают, и проводимые мероприятия. Для самих специалистов также  интересна информация в помощь.

      Логично разделить всех посетителей Интернет-комплекса  «Знание» на две группы: пользователи и администраторы. Предполагается, что в группу администраторов будут входить сами деятели общества (как специалисты-лекторы, так и управление организации).

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

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

      Кроме того, администратор непосредственно  занимается наполнением Интернет-комплекса  информацией.

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

2.2. Выделение сущностей

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

      1) Деятели

• Фамилия
• Имя
• Отчество
• Статус (занимаемая должность)
• Контактные данные
• Краткая биография
• Резюме
• Фотография

2) Лектории

• Название
• Описание
• Ссылка (ссылка на документ с подробным описанием лектория)
• Авторы

3. Направления деятельности

• Название
• Описание

4) Мероприятия

• Дата
• Тип мероприятия (лекция, встреча, организационное собрание и т. д.)
• Тема
• Место проведения
• Направления деятельности, по которым проводится мероприятие
• Участники мероприятия (деятели)
• Фотографии

5) Фотографии

• Дата
• Описание
• Ссылка на фотографию

6) Информация  в помощь

• Тема
• Авторы
• Ссылка на информацию

2.3. Определение отношений между сущностями

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

      Рассмотрим, например, сущность Мероприятие. Она  характеризуется такими атрибутами, как Участники и Направления  деятельности.

      Понятно, что участвовать в мероприятии  могут несколько человек. С другой стороны, деятели принимают участие в множестве мероприятий.

      Мероприятие может проводиться по нескольким направлениям одновременно. В то же время по каждому направлению  читается множество лекций, следовательно  и в этом случае между Мероприятиями  и Направлениями деятельности существует отношение «многие-ко-многим».

      Такая же ситуация наблюдаются и в отношении  между сущностями Мероприятие и  Фотография.

     Рисунок 2.1. Фрагмент концептуальной модели данных

      Рассмотрим  связь между сущностями Деятель  и Лекторий. Очевидно, что лектор может быть автором многих лекториев. В то же время возможна ситуация соавторства, т.е. у лектория может быть два и более авторов. Получаем, что и для этих двух сущностей характерно отношение «многие-ко-многим».

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

2.4. Создание концептуальной  модели

      Таким образом, построена концептуальная модель для данной предметной области.

      

     Рис 2.2. Концептуальная модель данных

Глава 3. Программная реализация Интернет-комплекса

3.1. Логическая структура  программы

      Давно известно, что любое серьёзное  приложение должно быть грамотно спроектировано и разделено на отдельные модули, которые должны быть относительно независимыми друг от друга. Подобное разделение значительно  облегчает не только реализацию приложения, но и возможную его модификацию. В этом заключается принцип модульности объектно-ориентированного программирования.

      Интернет-комплекс «Знание» представляет собой большое  web-приложение с поддержкой базы данных, и целесообразно было разделить его на слои.

      Были  выделены следующие слои приложения:

1. База данных.
2. Классы работающие с базой данных.
3. Классы-сущности.
4. Action-классы, работающие с сущностями.
5. Пользовательский интерфейс.

      Приложение  реализовано с использованием технологии Struts, а значит его логическая структура сроится в соответствии с паттерном проектирования MVC. В данном случае к Модели (Model) относится вся бизнес-логика классов-сущностей и классов, работающих с базой данных. Пользовательский интерфейс является Представлением (View) в MVC. А все Action-классы, которые получают запросы пользователя и соответствующим образом их обрабатывают, представляют собой Контроллер (Controller).

      Рассмотрим  названные слои более подробно.

3.2. База данных

      Таблицы базы данных – самый низкий логический уровень приложения. В соответствии с концептуальной схемой предметной области создана база данных Knowledge со следующими основными таблицами: