А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 24
Описание файла
PDF-файл из архива "А.М. Вендров - Объектно-ориентированный анализ и проектирование", который расположен в категории "". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из 7 семестр, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 24 страницы из PDF
3.25. Конфигурация системы регистрации с распределениемпроцессов по узламКлассы-сущности с учетом соображений производительности изащиты данных могут разбиваться на ряд классов. Основанием дляразбиения является наличие в классе атрибутов с различной частотойиспользования или видимостью. Такие атрибуты, как правило, выделяютсяв отдельные классы.Что касается управляющих классов, то классы, реализующие простуюпередачу информации от граничных классов к сущностям, могут бытьудалены. Сохраняются классы, выполняющие существенную работу поуправлению потоками событий (управление транзакциями, распределеннаяобработка и т.д.).Полученныеврезультатеуточненияклассыподлежатнепосредственной реализации в коде системы.144Рис.
3.26. Кооперативная диаграмма "Зарегистрироваться на курсы" Основной поток событий145Рис. 3.27. Кооперативная диаграмма "Зарегистрироваться на курсы" подчиненный поток "Создать график"Уточнение операций и атрибутовОбязанности классов, определенные в процессе анализа идокументированные в виде операций "анализа", преобразуются воперации, которые будут реализованы в коде. При этом:• каждой операции присваивается краткое имя, характеризующее еерезультат;146• определяется полная сигнатура операции (в соответствии снотацией, принятой в языке UML;• создается краткое описание операции, включая смысл всех еепараметров;• определяется видимость операции: public, private или protected;• определяется область действия операции: экземпляр (операцияобъекта) или классификатор (операция класса);• может быть составлено описание алгоритма выполнения операции(с использованием диаграмм деятельности в виде блок-схем, атакже диаграмм взаимодействия различных объектов привыполнении операции).Уточнение атрибутов классов заключается в следующем:• кроме имени атрибута, задается его тип и значение по умолчанию(необязательное);• учитываются соглашения по именованию атрибутов, принятые впроекте и языке реализации;• задается видимость атрибутов: public, private или protected;• при необходимости определяются производные (вычисляемые)атрибуты.Пример уточнения операций и атрибутов приведен на рис.
3.28.Рис. 3.28. Класс Student с полностью определенными операциями иатрибутами147Моделирование состояний для классовЕсли в системе присутствуют объекты со сложной динамикойповедения, то можно построить модель, описывающую состоянияобъектов и переходы между ними. Эта модель представляется в видедиаграмм состояний.В качестве примера, связанного с системой регистрации, рассмотримповедение объекта класса CourseOffering. Диаграмма состояний строится внесколько этапов:1.
Идентификация состояний. Признаками для выявления состоянийявляются изменение значений атрибутов объекта или создание иуничтожение связей с другими объектами. Так, объект CourseOfferingможет находиться в состоянии Open (прием на курс открыт) до тех пор,пока количество зарегистрировавшихся на него студентов не превышает10, а как только оно станет равным 10, объект переходит в состоянииClosed (прием на курс закрыт). Кроме того, объект CourseOffering можетнаходиться в состоянии Unassigned (его никто не ведет, т.е., отсутствуетсвязь с каким-либо объектом Professor) или Assigned (такая связьсуществует).2. Идентификация событий. События связаны, как правило, свыполнением некоторых операций. Так, в классе CourseOffering врезультате распределения обязанностей при анализе вариантаиспользования "Выбрать курсы для преподавания" определены двеоперации - addProfessor и removeProfessor, связанные с выбором курсанекоторым профессором (созданием новой связи) и отказом от выбранногокурса (разрывом связи).
Этим операциям ставятся в соответствие двасобытия - addProfessor и removeProfessor.3. Идентификация переходов между состояниями. Переходывызываются событиями. Таким образом, состояния Unassigned и Assignedсоединяются двумя переходами (рис. 3.29).Дальнейшая детализация поведения объекта CourseOffering приведет кпостроению диаграммы состояний, показанной на рис. 3.30. На даннойдиаграмме использованы такие возможности моделирования состояний,как композитные состояния (composite state) и историческое состояние(history state).
В данном случае композитными состояниями являются Openи Closed, а вложенными состояниями - Unassigned, Assigned, Cancelled(курс отменен), Full (курс заполнен) и Committed (курс включен врасписание). Композитные состояния позволяют упростить диаграмму,уменьшая количество переходов, поскольку вложенные состояниянаследуют все свойства и переходы композитного состояния.148Рис. 3.29. Переходы между состояниямиИсторическое состояние (обозначенное на диаграмме окружностью сбуквой "Н") - это псевдосостояние, которое восстанавливает предыдущееактивное состояние в композитном состоянии. Оно позволяеткомпозитному состоянию Open запоминать, какое из вложенныхсостояний (Unassigned или Assigned) было текущим в момент выхода изOpen, для того, чтобы любой из переходов в Open (add student или removestudent) возвращался именно в это вложенное состояние, а не в начальноесостояние.Построение диаграмм состояний может оказать следующеевоздействие на описание классов:• события могут отображаться в операции класса (например,события, связанные с изменением количества студентов,записавшихся на курс, могут быть отображены в операцииaddStudent и removeStudent класса CourseOffering);• особенности конкретных состояний могут повлиять на деталивыполнения операций;• описание состояний и переходов может помочь при определенииатрибутов класса (например, значение количества студентов,записавшихся на курс (numStudents), может быть добавлено в классCourseOffering в качестве производного атрибута).149Рис.
3.30. Диаграммы состояний с композитными состояниямиУточнение связей между классамиВ процессе проектирования связи между классами (ассоциации,агрегации и обобщения) подлежат уточнению.• Ассоциации между граничными и управляющими классамиотражаютсвязи,динамическивозникающиемеждусоответствующими объектами в потоке управления.
Для такихсвязей достаточно обеспечить видимость классов, поэтому онипреобразуются в зависимости.• Если для некоторых ассоциаций нет необходимости вдвунаправленной связи, то вводятся направления навигации.• Агрегации, обладающие свойствами композиции, преобразуются всвязи композиции.150Пример преобразования связей в соответствии с даннымирекомендациями для классов варианта использования "Зарегистрироватьсяна курсы", приведен на рис. 3.31. Ассоциация между управляющим играничным классами преобразована в зависимость. Агрегация междуклассами Student и Schedule обладает свойствами композиции.Направления навигации на ассоциациях между классами Schedule иCourseOffering введены по следующим соображениям: нет необходимостив получении списка графиков, в которых присутствует какой-либо курс, иколичество графиков относительно мало по сравнению с количествомконкретных курсов.Рис.
3.31. Пример преобразования ассоциаций и агрегацийСвязи обобщения могут преобразовываться в ситуациях с такназываемой метаморфозой подтипов. Например, в случае с системойрегистрации студент может переходить с очной формы обучения навечернюю, т.е., объект Student может менять свой подтип. При такомизменении придется модифицировать описание объекта в системе. Чтобы151избежать этой модификации и тем самым повысить устойчивость системы,иерархия наследования реализуется с помощью классификации, какпоказано на рис.
3.32.Рис. 3.32. Преобразование обобщения3.4.3. Проектирование баз данных.Проектирование БД [11, 12] зависит от типа используемой дляхранения данных СУБД - объектной или реляционной. Для объектных БДникакого проектирования не требуется, поскольку классы-сущностинепосредственно отображаются в БД. Для реляционных БД классысущности объектной модели должны быть отображены в таблицыреляционной БД. Совокупность таблиц и связей между ними может бытьпредставлена в виде диаграммы классов, которая, по существу, являетсяER-диаграммой.
Набор правил, применяемых при отображении классов втаблицы БД, фактически совпадает с правилами преобразованиясущностей и связей, принятыми в модели «сущность-связь».152Эти правила сводятся в основном к следующим:1. Каждая простая сущность, не являющаяся подтипом и не имеющаяподтипов, превращается в таблицу. Имя сущности становится именемтаблицы.2. Каждый атрибут становится возможным столбцом с тем же именем;может выбираться более точный формат. Столбцы, соответствующиенеобязательным атрибутам, могут содержать неопределенные значения;столбцы, соответствующие обязательным атрибутам, - не могут.3.
Уникальный идентификатор сущности превращается в первичныйключ таблицы. Если имеется несколько альтернативных уникальныхидентификаторов, выбирается наиболее используемый. Если сущность неимеет собственного идентификатора, то в качестве первичного ключаиспользуется копия уникального идентификатора сущности, находящейсяна дальнем конце связи, в которой данная сущность играет рользависимой.4. Если тип бинарной связи между сущностями - один-к-одному икласс принадлежности обеих сущностей является обязательным, то из двухсвязанных сущностей формируется одна таблица. Первичным ключом этойтаблицы может быть идентификатор любой из двух сущностей.5. Если тип бинарной связи - один-к-одному и класс принадлежностиодной сущности является обязательным, а другой - необязательным, тоформируются две таблицы (под каждую сущность), при этомидентификатор каждой сущности должен служить первичным ключомсоответствующей таблицы.
Кроме того, идентификатор сущности, длякоторой класс принадлежности является необязательным, добавляется вкачестве атрибута в таблицу, выделенную для сущности с обязательнымклассом принадлежности.6. Если тип бинарной связи - один-к-одному и класс принадлежностини одной сущности не является обязательным, то формируются тритаблицы: по одной для каждой сущности (при этом идентификатор каждойсущности должен служить первичным ключом соответствующей таблицы)и одна для связи. Таблица связи включает в качестве атрибутов по одномуидентификатору от каждой сущности.7. Если тип бинарной связи - один-ко-многим и класс принадлежностисущности с мощностью "n" является обязательным, то формируются дветаблицы (под каждую сущность), при этом идентификатор каждойсущности должен служить первичным ключом соответствующей таблицы.Кроме того, идентификатор сущности с мощностью "1" добавляется вкачестве атрибута в таблицу, выделенную для сущности с мощностью "n".8.
Если тип бинарной связи - один-ко-многим и класс принадлежностисущности с мощностью "n" является необязательным, см. правило 6.9. Если тип бинарной связи - многие-ко-многим, см. правило 6.10. Для представления N-арной связи требуется N+1 таблица.Например, в случае тернарной связи формируются четыре таблицы, по153одной для каждой сущности и одна для связи. Таблица связи будет иметьсреди своих атрибутов ключи от каждой сущности.11. Для связи "супертип-подтип" возможны два способапреобразования:a. все подтипы в одной таблице;b. для каждого подтипа - отдельная таблица.При применении способа (а) для супертипа создается таблица, а дляподтипов могут создаваться представления (view). В таблицу добавляетсяпо крайней мере один столбец, содержащий код типа; он становитсячастью первичного ключа.При использовании способа (b) для каждого подтипа супертипвоссоздается с помощью операции объединения (UNION) - из всех таблицподтипов выбираются общие столбцы - столбцы супертипа.Преимущества способа (а): все данные хранятся вместе,обеспечивается легкий доступ к супертипу и подтипам, требуется меньшетаблиц.Недостатки способа (а): усложняется логика работы с разныминаборамистолбцовиограничениями,возможноснижениепроизводительности (в связи с блокировками общей таблицы), столбцыподтипов должны допускать неопределенные значения.Преимущества способа (b): наглядное соответствие схемы БД имодели «сущность-связь», приложения работают только с нужнымитаблицами.Недостатки способа (b): формируется слишком много таблиц,возможно снижение производительности при выполнении операцииобъединения, невозможны модификации супертипа.В технологии Rational Unified Process, в частности, для такогоотображения используется специальный инструмент - Data Modeler.