46676 (Автоматизированная система проведения маркетинговых исследований в Белгородском филиале МЭСИ), страница 5

Итак, получаем следующие отношения сущностей:

«Анкета» : «Вопрос» = «многие ко многим»

«Вопрос» : «Ответ» = «один ко многим»

«Анкета» : «Опрос» = «один ко многим»

«Пользователь» : «Опрос» = «один ко многим»

«Пользователь» : «Роли» = «многие ко многим»

«Опрос» : «Результаты» = «один ко многим»

Логическая модель данных представлена на рисунке

Рис. 3.9 Диаграмма сущность-связь

3.4 Физическое проектирование

3.4.1 Построение диаграммы классов

Физический дизайн — последний шаг этапа планирования в модели процессов MSF. Проектная команда переходит к нему после того, как все ее члены подтвердят, что на этапе логического дизайна получено достаточно информации, На этапе физического дизайна на концептуальный и логический дизайн налагаются технологические ограничения. Поскольку физический дизайн «вырастает» из этих двух типов дизайна, его успех сильно зависит от тщательности их проработки, кроме того, этот факт гарантирует, что физический дизайн удовлетворяет требования бизнеса и пользователей.

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

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

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

Центральное место в ООАП занимает разработка модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация применяется и для объектов - экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается.

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

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

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

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

На следующем рисунке показана диаграмма клас сов

Рис. 3.10. Диаграмма классов

3.4.2. Модель пользовательского интерфейса

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

• стандартный пользовательский интерфейс Windows;

• Web-интерфейс;

Стандартный интерфейс Windows

Стандартный интерфейс Windows применяется, когда необходимо обеспечить работу пользователей в автономном режиме и когда необходима богатая функциональность системы. Он также позволяет эффективно управлять состоянием и обеспечивает постоянство (persistence) данных, а также все преимущества локальной обработки данных.

Web-интерфейс

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

• унифицированная среда разработки;

• привязка данных к пользовательскому интерфейсу;

• интерфейс на основе компонентов с элементами управления;

• встроенная модель безопасности каркаса .NET;

• широкие возможности по поддержке кэширования и управления состоянием;

• доступность, производительность и масштабируемость Web-обработки данных)

Предполагается что система будет использовать Web-интерфейс

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

3.4.3 Создание физической модели данных

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

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

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

Типы физических моделей данных

Помимо определения логического дизайна базы данных необходимо выбрать технологию физического хранении данных. Физическая модель данных системы управления базами данных (СУБД) определяет внутреннюю структуру, которая применяется в СУБД для управления данными. В этой структуре отражены типы таблиц базы данных, которые разрешается создавать, а также скорость доступа и универсальность базы данных. Далее перечислены наиболее распространенные типы физических моделей данных.

• БД на плоских файлах, или неструктурированные БД. В такой базе данных все данные располагаются в одном файле в виде набора строк и столбцов. В этой архитектуре отсутствует связь между различными плоскими файлами, поскольку ни одна из этих БД ничего не знает об остальных. Она поддерживает быстрое обновление и чтение данных за счет метода индексирования ISAM (indexed sequential access method — индексно- последовательны и метод доступа). Технология ISAM применяется в унаследованных мэйнфреймовых БД и небольших базах данных, располагающихся на ПК.

• Иерархические БД способны хранить самую разнообразную информацию в самом различном формате. Их отличает расширяемость и гибкость, поэтому подобные БД используются, когда требования по хранению информации могут сильно отличатся или изменяться. Пример иерархической базы данных — сервер Microsoft Exchange, способный хранить самые различные типы информации в формате, который удовлетворяет требованиям приложений обмена сообщениями и поддержки совместной работы. Эти требования заключаются в возможности инкапсуляции в сообщениях самой разнородной информации.

• Реляционные БД. Здесь данные хранятся в наборе таблиц и столбцов. Реляционные базы данных сочетают преимущества плоских файлов и иерархических баз данных, обеспечивая хорошую производительность и гибкость в хранении данных. Благодаря возможности определять связи между таблицами на основании уникальных значений, реляционные базы данных — одни из самых популярных. Однако важно понимать, что другие модели также применяются и что разработчикам систем масштаба предприятия иногда приходится работать с несколькими типами баз данных одновременно. В реляционной модели основное внимание уделяется хранению, выборке и обеспечению целостности данных. Структурированный язык запросов SQL (Structured Query Language) позволяет эффективно извлекать связанные элементы данных вне зависимости от того, в одной или нескольких таблицах они хранятся. Целостность данных обеспечивается механизмом правил (rules) и ограничений (constraints).

В Белгородском филиале МЭСИ в настоящее время для хранения дынных применяется Microsoft SQL Server 2000. Поэтому для системы было выбрано предпочтение реляционной базе данных. Физическая модель отражает целевую среду реализации.

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

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

Определение таблиц

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