2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 80
Текст из файла (страница 80)
Для визуальногопредставления этих стереотипов можно воспользоваться механизмами расширения UML. Для каждого артефакта в наборе рассмотреть его связь с окружающими его артефактами. Чаще всего это интерфейсы,которые экспортирует (реализует) один артефакт и импортируют (используют) другие. Если нужно раскрыть соединения в системе, – явно смоделировать эти интерфейсы. Еслиже необходимо представить модель на более высоком уровнеабстракции, раскрыть эти связи, показывая только зависимости между артефактами.В качестве примера на рис. 30.3 представлена модель частиисполняемой версии автономного робота. Основное вниманиеобращено на артефакты размещения, ассоциированные с функциями перемещения робота и вычислительными операциями. Вывидите один артефакт – driver.dll, который материализует компонент Driving (Перемещение), экспортирующий интерфейс IDrive (),импортируемый компонентом Path (Путь), материализуемым другим артефактом, path.dll.
Зависимость между компонентами Pathи Driving указывает на зависимость между артефактами path.dllи driver.dll, которые реализуют их. На диаграмме присутствует ещеДиаграммы артефактов420Path«manifest»«manifest»Driving{version = 8.1.3.2}Рис. 30.3. Моделирование исполняемой версииодин артефакт – collision.dll, который также материализует компонент, хотя эти подробности и скрыты (показана лишь прямая зависимость path.dll от collision.dll).В данной системе участвует множество других артефактов.Однако диаграмма сосредоточена на тех артефактах размещения,которые непосредственно относятся к процессу движения робота.Заметьте, что при такой компонентной архитектуре вы могли бызаменить конкретную версию driver.dll на другую – при условии,что она реализует те же (и, возможно, какиеFто дополнительные)интерфейсы, – и path.dll мог бы поFпрежнему правильно работать.Моделирование физической базы данныхМоделирование схемылогическойбазы данныхобсуждается в главе 8.Логическая схема базы данных охватывает словарь хранимых данных системы вместе с семантикой их связей.
Физически все эти сущности сохраняются в базе данных – либо в реляционной, либо в объектноFориентированной, либо в гибридной(объектноFреляционной) – для последующего извлечения. UMLтак же хорошо приспособлен к моделированию физических базданных, как и к моделированию их логических схем.Отображение логической схемы базы данных на объектноFориентированную базу достаточно прямолинейно, поскольку даже сложные цепочки наследования могут быть сохранены без какогоFлибопреобразования. Однако отобразить логическую схему на реляционную базу не так просто. Если имеет место наследование, приходится принимать решения относительно того, как отображатьТипичные приемы моделированияПроектированиефизическихбаз данныхне входитв круг тем,рассматриваемыхв этой книге, – здесьмы сосредотачиваемвниманиена показеотдельныхприемов моделированиябаз данныхи таблицв UML.421классы на таблицы.
Обычно применяется либо одна из трех ниженазванных стратегий, либо их комбинация:1. Спуск (push down) – определяется отдельная таблица для каждого класса. Это простой, но примитивный подход, поскольку он вызывает проблемы сопровождения при добавленииновых дочерних классов или модификации существующихродительских;2. Подъем (pull up) – все цепочки наследования свертываютсятак, что реализации любого класса в иерархии имеют одинаковое состояние.
Недостаток в том, что во многих экземплярах приходится хранить избыточную информацию;3. Расщепление таблиц (split tables) – данные родительскогои дочернего класса разносятся по разным таблицам. Такойподход лучше отображает структуру наследования, но егонедостаток состоит в том, что для доступа к данным приходится соединять многие таблицы.Проектируя физическую базу данных, необходимо также решить, как следует отображать операции, определенные в логической схеме. ОбъектноFориентированные базы данных обеспечиваютдостаточно прозрачное отображение, но что касается реляционных,здесь приходится решать, как реализовать эти логические операции.
Опять же, существует несколько вариантов:1. Простые операции создания, выборки, обновления и удаления реализуются стандартными вызовами SQL или ODBC;2. Более сложное поведение (такое как бизнесFправила) отображается на триггеры и хранимые процедуры.С учетом приведенных соображений для моделирования физической базы данных необходимо: Идентифицировать присутствующие в модели классы, которые представляют логическую схему базы данных.
Выбрать стратегию отображения этих классов на таблицы.Следует рассмотреть и физическое распределение баз данных. Необходимо проанализировать физическое размещениеданных в системе – от этого тоже зависит выбор стратегии. Создать диаграмму артефактов для визуализации, специфицирования, конструирования и документирования отображения, в которой артефакты имеют стереотип таблицы. По возможности использовать инструментальные средствадля преобразования логической схемы в физическую.На рис.
30.4 показан набор таблиц базы данных, взятых из информационной системы учебного заведения. Вы видите одну базу –school.db, изображенную в виде артефакта со стереотипом database.422Диаграммы артефактовТипичные приемы моделированияАтрибутlocationобсуждаетсяв главе 24,диаграммыобъектов –в главе 14.Рис. 30.4. Моделирование физической базы данныхОна состоит из пяти таблиц: student (студент), class (класс), instructor(инструктор), department (отдел) и course (курс). В соответствующейлогической схеме базы данных нет наследования, поэтому отобразить ее на физическую несложно.Хотя в данном примере это не показано, вы можете специфицировать содержимое каждой таблицы.
Артефакты могут иметь атрибуты, поэтому общая идиома при моделировании физической базыданных заключается в использовании атрибутов для специфицирования столбцов каждой таблицы.Аналогичным образом артефакты могут иметь операции, которые позволяют отображать хранимые процедуры.423специфицировать местоположение экземпляра артефакта,пометив его атрибутом location, который можно отобразитьна диаграмме артефактов. Если нужно смоделировать действия, вызывающие миграциюартефакта, создать с этой целью соответствующую диаграмму взаимодействия, которая будет содержать экземплярыартефактов. Изменение местоположения артефакта можнопроиллюстрировать, нарисовав один экземпляр несколькораз, но с разными значениями состояния, включая его местоположение.На рис.
30.5 представлено моделирование репликации базы данных, уже рассматривавшейся выше (см. рис. 30.4). Здесь мы видимдва экземпляра артефакта school.db. Оба анонимны и имеют разныепомеченные значения местоположения (location). Также присутствует примечание, которое явно указывает, какой экземпляр кудареплицируется.Server BServer AМоделирование адаптируемых системВсе диаграммы артефактов, показанные до сих пор, использовались для моделирования статических представлений. Их артефакты проводили всю свою жизнь на одном узле. Хотя эта ситуациявстречается чаще всего, иногда, особенно при работе со сложнымираспределенными системами, все же приходится моделировать и динамические представления.
Например, можно представить систему,которая реплицирует свои базы данных на несколько узлов, переключаясь на резервный сервер в случае отказа главного. Аналогично при моделировании глобальной распределенной системы, работающей в режиме 24х7 (то есть 7 дней в неделю, 24 часа в сутки),вы, скорее всего, столкнетесь с мобильными агентами – артефактами, которые мигрируют с одного узла на другой для обслуживаниянекоторой транзакции.
Чтобы смоделировать такие динамическиепредставления, вам понадобится использовать комбинацию диаграмм артефактов, объектов и взаимодействия.Для моделирования адаптируемой системы необходимо: Рассмотреть физическое распределение артефактов, которые могут мигрировать с одного узла на другой. Вы можетеreplicateРис. 30.5. Моделирование адаптируемых системЕсли необходимо показать подробности каждой базы данных,их можно изобразить в канонической форме – в виде артефакта состереотипом database.ДиаграммыХотя на этом рисунке это не показано, можно использоватьвзаимодейст- и диаграмму взаимодействия для моделирования динамики перевий обсужключения с главной базы данных на резервную.даютсяв главе 19.Прямое и обратное проектированиеПрямое и обратное проектирование артефактов довольно просто, потому что артефакты сами по себе – физические сущности(исполняемые программы, библиотеки, таблицы, файлы и разнообразные документы), а потому близки к работающей системе.При прямом проектировании класса или кооперации вы на самом424Диаграммы артефактовделе проектируете артефакт, который представляет исходный код,двоичную библиотеку или исполняемую программу для этого класса или кооперации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
