2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 79
Текст из файла (страница 79)
В конечном счете логические чертежи превращаются в реалии из мира битов – исполняемые программы, библиотеки, таблицы, файлы и различныедокументы. При этом обнаруживается, что некоторые из этих артефактов приходится создавать «с нуля», но находятся и способыповторного использования старых артефактов.В UML диаграммы артефактов используются в целях визуализации статического аспекта физических артефактов и их связей,а кроме того, описания их деталей для конструирования, как показано на рис. 30.1.«»артефактРис. 30.1. Диаграмма артефактовТермины и понятияДиаграмма артефактов показывает набор артефактов и связеймежду ними.
Изображается в виде графа с вершинами и дугами(ребрами).Термины и понятия415Общие свойстваОбщиеУ диаграммы артефактов, как и у всех диаграмм, есть имя и грасвойства всех фическое наполнение. От остальных типов диаграмм она отличаетдиаграммся своим содержимым.обсуждаются в главе 7.СодержимоеАртефактыобсуждаются в главе 26,интерфейсы –в главе 11,связи – в главах 5 и 10,пакеты –в главе 12,подсистемы –в главе 32,экземпляры – в главе 13, диаграммыклассов –в главе 8,представленияреализациив контекстесистемнойархитектуры – в главе 2.Диаграммы артефактов обычно содержат артефакты, а такжесвязи зависимости, обобщения, ассоциации и реализации.
Подобно другим диаграммам, могут содержать примечания и ограничения.Общее применениеДиаграммы артефактов применяются для моделирования статического представления реализации системы. Это представление в первую очередь поддерживает управление конфигурациейчастей системы, состоящих из артефактов, которые могут бытьсобраны разными способами для построения работающей системы.Когда моделируется статическое представление реализациисистемы, то диаграммы артефактов обычно используются однимиз следующих четырех способов:1. Для моделирования исходного кода.
В большинстве современных объектноFориентированных языков программирования код пишется в интегрированных средах разработки,сохраняющих исходные тексты в файлах. Диаграммы артефактов можно применять для моделирования конфигурации этих файлов, которые представляют собой рабочиепродукты, и установки вашей системы управления конфигурацией.2. Для моделирования исполняемых версий.
Версия (release) – этоотносительно полный и согласованный набор артефактов,поставляемый внутреннему или внешнему пользователю.Версия в данном понимании сосредоточена на тех частях, которые необходимы для поставки работающей системы. Примоделировании версий с помощью диаграмм артефактов происходят визуализация, специфицирование и документирование решений, принятых относительно физических составляющих системы, то есть артефактов размещения.416Свойствосохраняемости,или устойчивости(persistence),обсуждается в главе 24,моделирование логических схембаз данных –в главе 8.Диаграммы артефактовТипичные приемы моделирования3.
Для моделирования физических баз данных. Представьтесебе физическую базу данных как конкретную реализациюсхемы, существующую в мире битов. Схемы, по сути, описывают API для доступа к хранимой информации; модельже физической базы представляет способы хранения информации в таблицах реляционной базы или на страницахобъектноFориентированной базы данных. Для представления этих и иных физических баз данных можно использовать диаграммы артефактов.4.
Для моделирования адаптируемых систем. Некоторые системы достаточно статичны: их компоненты появляются на сцене, принимают участие в исполнении, а затем покидают ее.Другие системы более динамичны: они включают в себя мобильных агентов, или артефакты, мигрирующие с целью балансирования нагрузки и восстановления после сбоев.
Поведение таких систем моделируется диаграммами артефактовсовместно с некоторыми другими диаграммами UML.с их зависимостями. Например, вы могли бы выполнить обратноепроектирование набора исходных файлов для визуализации сложной системы зависимостей между ними при компиляции. Можнопойти и в другом направлении, специфицировав связи между исходными файлами и затем передав эту модель на вход инструментукомпиляции, такому как программа make в UNIX. Аналогичноможно использовать диаграммы артефактов для визуализации истории набора исходных файлов, хранящихся в системе управленияконфигурацией. Получая из этой системы информацию (например,о том, сколько раз некий файл извлекался для редактирования напротяжении определенного периода времени), вы можете использовать ее для «раскраски» диаграммы артефактов, что поможет выявить среди исходных файлов «горячие точки», в которых архитектура системы чаще всего подвергается модификациям.Чтобы смоделировать исходный код системы, необходимо: Применяя прямое или обратное проектирование, идентифицировать набор представляющих интерес файлов исходного кода и смоделировать их как артефакты со стереотипомfile.
Для крупных систем использовать пакеты, чтобы показатьгруппы исходных файлов. Рассмотреть возможность показа с помощью помеченныхзначений такой информации, как номер версии файла, егоавтор, дата последнего изменения. Для управления этимизначениями применять инструментальные средства. Смоделировать зависимости компиляции между исходнымифайлами с помощью связей зависимости. Опять же, для тогочтобы сгенерировать эти зависимости и управлять ими, понадобятся инструментальные средства.Типичные приемы моделированияМоделирование исходного кодаПри разработке программ на языке Java исходный код обычносохраняется в файлах с расширением .java.
Программы, написанные на C++, обычно хранят исходный код в заголовочных файлахс расширением .h и файлах реализации с расширением .cpp. При использовании языка IDL для разработки приложений COM+ илиCORBA, единственный, с точки зрения проектирования, интерфейсраспадается на четыре исходных файла: сам интерфейс, клиентский заместитель (proxy), серверную заглушку (stub) и классFмост(bridge). По мере роста объема приложения, на каком бы языке онони было написано, эти файлы приходится организовывать в группы. Затем, на стадии сборки приложения, вы, вероятно, станете создавать различные варианты одних и тех же файлов для каждой новой промежуточной версии и захотите поместить все это в системууправления конфигурацией.СтереотипВ большинстве случаев нет необходимости моделировать данный аспект системы непосредственно.
Вместо этого вы позволиfile для арте среде разработки отслеживать эти файлы и их связи. Иногда,тефактовобсуждает- однако, небесполезно визуализировать исходные файлы и свяся в главе 26. зи между ними с помощью диаграмм артефактов. Применяемыетаким образом диаграммы артефактов обычно содержат толькоартефакты – рабочие продукты со стереотипами файлов – вместе417Стереотипзависимостиtrace обсуждаетсяв главе 10.В качестве примера на рис. 30.2 показаны пять файлов исходного кода.
Файл signal.h – заголовочный. Представлены три еговерсии, начиная с последней и заканчивая первой. Каждая версияпомечена значением, указывающим ее номер.Заголовочный файл signal.h используется двумя другими –interp.cpp и signal.cpp. Первый из них при компиляции зависитот другого заголовочного файла, irq.h. В свою очередь, файл device.cpp зависит от interp.cpp. Имея перед глазами такую диаграмму,легко проследить, что произойдет в случае изменений. В частности, изменение исходного файла signal.h потребует перекомпиляции трех других файлов – signal.cpp, interp.cpp и, как следствие,device.cpp.
Из той же диаграммы видно, что irq.h не коснутся преобразования.Диаграммы артефактов418{version = 3.5}«Типичные приемы моделированиябольшую важность и вместе с тем усложняется, поскольку изменение некоторых артефактов в одном приложении может отразитьсяна работе других.По этой причине для визуализации, специфицирования, конструирования и документирования исполняемых версий (включаяартефакты размещения, формирующие каждую версию, и связимежду этими артефактами) используются диаграммы артефактов.Вы можете применять их для прямого проектирования новой системы и для обратного проектирования существующей.Создавая диаграммы артефактов, подобные той, что изображена на рис.
30.2, вы на самом деле просто моделируете часть сущностей и связей, которые представляют реализацию вашей системы.По этой причине каждая диаграмма артефактов должна сосредотачивать внимание только на одном текущем наборе артефактов.Чтобы смоделировать исполняемую версию, необходимо:{version = 4.0}»«»{version = 4.1}Рис. 30.2. Моделирование исходного кодаПодобные диаграммы легко генерируются путем обратногопроектирования на основе информации, хранящейся в системеуправления конфигурацией среды разработки.Моделирование исполняемой версииВыпуск версий простого приложения не составляет труда –единственная исполняемая программа сбрасывается на диск, и пользователи просто запускают ее.
Для подобных приложений диаграммыартефактов не требуются: там нечего визуализировать, специфицировать, конструировать и документировать.Выпуск версий более сложных приложений всеFтаки предполагает трудозатраты, иногда немалые. Кроме главной исполняемойпрограммы (обычно файла с расширением .exe), нужен ряд вспомогательных модулей (обычно это файлы с расширением .dll, есливы работаете в контексте COM+, либо .class или .jar – при работес языком Java), баз данных, файлов подсказки и ресурсных файлов. Для распределенных систем, вероятно, понадобится несколькоисполняемых программ и других файлов, разбросанных по разнымузлам. Если вы работаете с системой приложений, одни артефакты могут оказаться уникальными, а другие будут использоватьсяв нескольких приложениях.
По мере развития системы управлениеконфигурацией всего этого множества артефактов приобретает все419МеханизмырасширенияUML обсуждаютсяв главе 6,интерфейсы – в главе 11. Идентифицировать набор артефактов, подлежащих моделированию. Обычно это выборка либо вся совокупность артефактов, размещенных на одном узле, или же ряд артефактов,распределенных по узлам системы. Рассмотреть стереотипы каждого артефакта в наборе. Для большинства систем обнаружится ограниченное число разныхвидов артефактов (таких как исполняемые программы, библиотеки, таблицы, файлы и документы).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
