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

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

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

· обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

· использование этой информации различными приложениями.

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

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

1. 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

2. 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.

3. n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений).

В результате исследования use case были выделены следующие сущности:

1. Анкета

2. Вопрос

3. Ответ

4. Опрос

5. Пользователь

6. Роли

7. Результаты

Анкета содержит список всех вопросов и, в то же время один и тот же вопрос может быть использована в разных анкетах. Поэтому сущности Анкета и Вопрос состоят в отношениях «многие ко многим»

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

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

Анкетирование может проходить произвольное количество пользователей, однако пользователь может участвовать только в одном опросе. Поэтому сущности Пользователь и Опрос находятся в отношении «один ко многим».

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

Пользователь может быть автором нескольких анкет, однако анкета может принадлежать только одному автору. Поэтому сущности Пользователь и Анкета находятся в отношении «один ко многим».

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

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

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

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

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

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

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

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

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

Рис. 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 применяется в унаследованных мэйнфреймовых БД и небольших базах данных, располагающихся на ПК.

Страницы: 1, 2, 3, 4, 5, 6, 7, 8