Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ (стр. 6 из 11)
Рис. 3.7. Диаграмма вариантов использования Опубликовать анкеты
Рис. 3.8. Диаграмма вариантов использования Создать отчеты
Из данных диаграмм становится ясным тот функциональный набор, который потребуется реализовать.
В процессе концептуального дизайна решение описывается с точки зрения бизнеса и пользователей. Далее следует продумать решение с точки зрения проектной команды. Именно это и выполняется на стадии логического дизайна.
На этапе анализа в процессе создания логического дизайна, команда разделяет проблему, и ее решение на более мелкие части, или модули.
3.3.1 Создание модулей и сервисов
Модульная декомпозиция
· Модуль “Создание анкет”
· Модуль “Опубликование анкет”
· Модуль “Анкетирование”
· Модуль “Создание отчетов”
· Модуль “Просмотр отчетов”
В модуле “Создание анкет” реализованы следующие функции:
· Создание анкет— при создании новой анкеты указывается название анкеты и ее заголовок, а также указываются дополнительные параметры, например, вводный текст.
· Редактирование существующих анкет — существует возможность редактирования всех тех параметров, которые указываются при создании анкеты.
· Удаление анкет.
· Добавление вопросов в анкету — при добавлении новых вопросов из списка типов выбирается нужный тип вопроса. Типы вопросов зависят от формы ответа. Например, может быть вопрос, подразумевающий выбор одного варианта из нескольких, вопрос, подразумевающий ввод строки ответа и т. д. В зависимости от выбранного типа вопроса задаются различные параметры вопроса, например, список ответов.
· Редактирование вопросов — при редактировании вопросов существует возможность изменения типа вопроса, а также всех необходимых параметров.
· Просмотр анкеты — на любой этапе создания анкеты можно просмотреть получающуюся анкету.
Модуль “Опубликование анкет” позволяет размещать на странице сайта различные анкеты, задавать интервалы проведения анкетирования.
Модуль “Анкетирование” позволяет пользователям проходить различные виды анкетирования.
Модуль “Создание отчетов” позволяет формировать различные шаблоны для формирования отчетов, а также их дальнейшее редактирования и удаление.
Модуль “Просмотр отчетов” позволяет проанализировать введенные данные и просмотреть отчеты на основании созданных шаблонов
3.3.2 Логическая модель данных
Для представления логического дизайна используют логическую модель объектов или данных. Однако проектная команда иногда создает обе модели, представляя логический проект с разных сторон. Это необходимо, когда одна из моделей представляет какую-либо часть проекта особо четко.
Логический дизайн — это промежуточный этап между концептуальным и физическим дизайном. Создавая модель данных, происходит преобразование концептуальных требований к данным (они определяются при концептуальном дизайне) в реальные объекты-сущности и отношения, отображающие реальное взаимодействие данных. Полученная информация помогает в дальнейшем моделировать физический дизайн.
При переходе к логической стадии дизайна данных одна из первоочередных задач заключается в формулировке сущностей на основании требований к данным и другой связанной информации. Сущностью(entity) обычно считают человека, место, элемент или понятие, которое определяет данные или о котором данные собираются и хранятся. Атрибут — это характеристика, представляющая собой дополнительное определение и описание свойств экземпляра сущности. У сущности обычно несколько атрибутов.
После определения сущностей следует определить необходимые атрибуты — они описывают сущности решения.
При реализации физического дизайна атрибуты обычно превращаются в столбцы таблиц базы данных.
Логическая модель данных представляется в виде диаграмм “сущность-связь” (ERD), предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD, а также диаграммы атрибутов и диаграммы декомпозиции. Эти диаграммные техники используются прежде всего для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования как иерархических, так и сетевых баз данных).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр.
Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (имеет, определяет, может владеть и т.п.).
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
· обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
· использование этой информации различными приложениями.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:
1. 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
2. 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.
3. n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).
В результате исследования usecase были выделены следующие сущности:
1. Анкета
2. Вопрос
3. Ответ
4. Опрос
5. Пользователь
6. Роли
7. Результаты
Анкета содержит список всех вопросов и, в то же время один и тот же вопрос может быть использована в разных анкетах. Поэтому сущности Анкета и Вопрос состоят в отношениях «многие ко многим»
Вопрос – один из пунктов анкеты, формулирует некоторую проблему, отношение к которой должен выразить опрашиваемый человек. За каждым вопросом закрепляется фиксированный список вопросов, поэтому сущности Вопрос и Ответы находятся в отношении «один ко многим».
Одна и та же анкета может быть использована в разных опросах, то есть использоваться огромное количество раз в различные периоды времени, в то время как текущий опрос проходит только по одной анкете. Поэтому сущности Анкета и Опрос состоят в отношении «один ко многим»
Анкетирование может проходить произвольное количество пользователей, однако пользователь может участвовать только в одном опросе. Поэтому сущности Пользователь и Опрос находятся в отношении «один ко многим».
Один пользователь может иметь несколько ролей, с другой стороны одна и та же роль может принадлежать различным пользователям. Поэтому сущности Пользователь и Роли находятся в отношении «один ко многим».
Пользователь может быть автором нескольких анкет, однако анкета может принадлежать только одному автору. Поэтому сущности Пользователь и Анкета находятся в отношении «один ко многим».
В результате анкетирования пользователь выбирает определенный вариант ответа на поставленный вопрос, в результате чего формируются результаты ответов, которые могут принадлежать только данному опросу, с другой стороны опрос содержит некоторое количество результатов ответов. Поэтому сущности Опрос и Результаты находятся в отношении «один ко многим».
Итак, получаем следующие отношения сущностей:
«Анкета» : «Вопрос» = «многие ко многим»
«Вопрос» : «Ответ» = «один ко многим»
«Анкета» : «Опрос» = «один ко многим»
«Пользователь» : «Опрос» = «один ко многим»
«Пользователь» : «Роли» = «многие ко многим»
«Опрос» : «Результаты» = «один ко многим»
Логическая модель данных представлена на рисунке
Рис. 3.9 Диаграмма сущность-связь
3.4 Физическое проектирование
3.4.1 Построение диаграммы классов
Физический дизайн — последний шаг этапа планирования в модели процессов MSF. Проектная команда переходит к нему после того, как все ее члены подтвердят, что на этапе логического дизайна получено достаточно информации, На этапе физического дизайна на концептуальный и логический дизайн налагаются технологические ограничения. Поскольку физический дизайн «вырастает» из этих двух типов дизайна, его успех сильно зависит от тщательности их проработки, кроме того, этот факт гарантирует, что физический дизайн удовлетворяет требования бизнеса и пользователей.