После определения сущностей следует определить необходимые атрибуты -- они описывают сущности решения.
При реализации физического дизайна атрибуты обычно превращаются в столбцы таблиц базы данных.
Логическая модель данных представляется в виде диаграмм “сущность-связь” (ERD), предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD, а также диаграммы атрибутов и диаграммы декомпозиции. Эти диаграммные техники используются прежде всего для проектирования реляционных баз данных (хотя также могут с успехом применяться и для моделирования как иерархических, так и сетевых баз данных).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр.
Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (имеет, определяет, может владеть и т.п.).
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
· обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
· использование этой информации различными приложениями.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются связи. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовать следующие типы отношений:
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. Модель пользовательского интерфейса
При проектировании приложения важно выбрать наиболее подходящую модель пользовательского интерфейса, так как это влияет на процесс развертывания, способы взаимодействия пользователей с данными, пути поддержки текущего состояния на протяжении диалога приложения и пользователя. К наиболее распространенным моделям и технологиям реализации пользовательского интерфейса относятся:
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
