2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 71
Текст из файла (страница 71)
Если же речь идет о чемFтобудкии небоскреба долговечном, то стоимость ошибок и переделок высока; в этом слуобсуждает- чае построение логической и физической моделей – разумный способ снизить степень риска.ся в главе 1.«artifact»Рис. 26.1. АртефактыБазовые понятияАртефакт – это физическая часть системы, которая существует на уровне платформы реализации. Изображается в форме прямоугольника с ключевым словом «artifact» внутри.ИменаКаждый артефакт должен обладать именем, отличающим егоот других артефактов. Имя представляет собой текстовую строку; взятая в отдельности, она называется простым именем. Имя,Артефакты370Имяартефактадолжнобытьуникальнымв пределахвключающего его узла.предваренное именем пакета, в котором находится данный артефакт,называется квалифицированным.
Обычно, изображая артефакт, указывают только его имя. Как и в случае с классами, вы можете дополнять пиктограммы артефактов помеченными значениями или дополнительными разделами, чтобы уточнить подробности (см. рис. 26.2).квалифицированныеимена«artifact»«artifact»fraudagent.dll«artifact»system::dialog.dllБазовые понятия371сводится к простому выбору: если моделируемая вами сущность«живет» непосредственно на узле, применяйте артефакт; в противном случае используйте класс. Подтверждением тому служит и второе отличие.Третье отличие предполагает связь между классами и артефактами.
В частности, артефакт – это физическая реализация наборалогических элементов, таких как классы и кооперации. Как показано на рис. 26.3, связь между артефактом и классами, которые онреализует, может быть показана явно с помощью материализации.артефакт«artifact»manifestsFraudAgentFraudPolicyPatternSearch«manifest»«manifest»Рис.
26.2. Простые и квалифицированные имена артефактовНа заметку. Имя артефакта представляет собой текст, содержащий в любом количестве буквы латинского алфавита, цифрыи ряд знаков препинания (за исключением таких, как двоеточия, которые применяются для отделения имени артефактаот имени включающего его пакета). Имя может записыватьсяв несколько строк.
На практике в качестве имен артефактоввыступают существительные, взятые из словаря реализациии, в зависимости от целевой операционной системы, включающие расширения (такие как java или dll).Артефакты и классыКлассыобсуждаютсяв главах 4и 9, взаимодействия –в главе 16.И классы, и артефакты являются классификаторами.
Однакомежду ними есть существенная разница: классы представляют логические абстракции, а артефакты –физические сущности, которые существуют в мире битов.В силу этого артефакты могут располагаться на узлах, а классы – нет; артефакты представляют физическую упаковку битов на платформе реализации; классы могут иметь атрибуты и операции. Артефакты могутреализовывать классы и методы, но сами по себе не имеютатрибутов и операций.Первое отличие наиболее важно.
Когда моделируется система, решение о том, нужно ли использовать классы или артефакты,Рис. 26.3. Артефакты и классыВиды артефактовМожно выделить три вида артефактов:1. Артефакты размещения (deployment artifacts) необходимы и достаточны для формирования исполняемой системы.Примеры – динамические библиотеки (DLL) и исполняемыепрограммы (EXE). Определение артефакта UML достаточно широко, чтобы вместить классические объектные модели, такие как .NET, CORBA и Enterprise Java Beans, а равнои альтернативные объектные модели (возможно, включающие динамические WebFстраницы, таблицы баз данных, исполняемые программы, использующие собственные коммуникационные механизмы);2.
Артефакты рабочих продуктов (work product artifacts), по существу, представляют собой результаты процесса разработки. Примеры – файлы исходного кода и файлы данных,из которых создаются артефакты размещения. Артефактытакого рода напрямую не участвуют в исполняемой системе, но являются продуктами разработки, используемымидля ее создания;Артефакты3723. Артефакты исполнения (execution artifacts) создаются в результате работы системы. Примеры – объект .NET, которыйсоздается из DLL.Стандартные элементыМеханизмырасширенияUML обсуждаютсяв главе 6.Механизмы расширения UML применимы к артефактам.
Чащевсего для расширения свойств артефактов (таких, например, какспецификация версии артефакта разработки) используются помеченные значения, а для определения новых видов артефактов (например, специфичных для конкретной операционной системы) –стереотипы.Перечислим предопределенные стандартные стереотипы UML,применимые к артефактам:1. Executable – специфицирует артефакт, который может бытьвыполнен на узле;2. Library – специфицирует статическую или динамическуюбиблиотеку объектов;3. File – специфицирует артефакт, который представляет документ, содержащий исходный код или данные;4. Document – специфицирует артефакт, представляющий документ.Другие стереотипы могут быть определены для конкретныхплатформ и систем.Типичные приемы моделированияМоделирование исполняемых программи библиотекЧаще всего цель применения артефактов заключается в моделировании артефактов размещения, составляющих реализацию системы.
Если вы устанавливаете простую систему, реализация которойсостоит всего лишь из одного исполняемого файла, нет необходимости ни в каком моделировании артефактов. Если же система состоитиз нескольких исполняемых программ и ассоциированных с нимиобъектных библиотек, моделирование артефактов помогает визуализировать, специфицировать, конструировать и документироватьпринятые решения относительно ее физической организации. Моделирование артефактов еще более важно, если требуется контролировать версии и управлять конфигурацией частей системы.Типичые приемы моделированияНа подобныерешениявлияети топологияцелевойсистемы(см.
главу 27).373Для большинства систем артефакты размещения основываютсяна решениях относительно того, как должна быть сегментированафизическая реализация системы. На такие решения влияет множество соображений технического характера (в частности, выбранныесредства операционной системы), удобства управления конфигурацией (например, вероятность изменения некоторых частей системыпо прошествии времени), а также неоднократного использования(повторное применение ряда артефактов другими системами).Чтобы смоделировать исполняемые программы или библиотеки, необходимо: Идентифицировать разбиение физической системы на части.Рассмотреть влияние технических требований, требованийуправления конфигурацией и повторного использования. Смоделировать любые исполняемые программы и библиотеки как артефакты, используя соответствующие стандартныеэлементы.
Если ваша реализация представляет новые видыартефактов, создайте специальные стереотипы. Обращать внимание на соединения частей системы, моделируя интерфейсы, которые одни артефакты используют,а другие реализуют. Смоделировать связи между исполняемыми программами,библиотеками и интерфейсами для реализации вашего замысла. Чаще всего понадобится моделировать зависимостимежду этими частями, чтобы визуализировать воздействиеизменений.В качестве примера на рис.
26.4 показан набор артефактов, составляющих персональный инструмент измерения производительности,который запускается на отдельном компьютере. Здесь изображеныодна исполняемая программа (animator.exe) и четыре библиотеки(dlog.dll, wframe.dll, render.dll и raytrce.dll); все они используют стандартные элементы UML, описывающие, соответственно, исполняемые программы библиотеки. Кроме прочего, данная диаграммапредставляет зависимости между артефактами.ПакетыПо мере роста ваших моделей вы обнаружите, что многие артеобсужфакты,концептуально и семантически близкие, имеют тенденциюдаютсясобиратьсяв группы. Для моделирования таких кластеров артефакв главе 12.товвUMLможноиспользовать пакеты.МоделиДлякрупныхсистем, которые размещаются на несколькихрованиекомпьютерах,можетпонадобиться моделирование способа расразмещенияпределенияартефактовс указанием узлов, на которых они нахообсуждаетдятся.ся в главе 27.Артефакты374Типичые приемы моделирования375библиотеками и интерфейсами системы.
Чаще всего оказывается важным моделирование зависимостей между этими частями, позволяющее визуализировать влияние изменений.«artifact»Логическоеи физическоемоделирование базданныхобсуждаетсяв главах 8и 30 соответственно.Обратимся к рис. 26.5, который базируется на рис. 26.4. Здесьпоказаны таблицы, файлы и документы, являющиеся частями установленной системы, окружающими исполняемый файл animator.exe. Имеются в наличии один документ (animator.hlp), один простойфайл (animator.ini) и одна таблица базы данных (shapes.tbl). Такжеданный пример иллюстрирует некоторые пользовательские стереотипы и пиктограммы артефактов.Рис.
26.4. Моделирование исполняемых программ и библиотекМоделирование таблиц, файлов и документовМоделирование исполняемых программ и библиотек, составляющих физическую реализацию системы, полезно, но часто обнаруживается, что существует множество вспомогательных артефактов,которые не являются ни исполняемыми файлами, ни библиотеками, хотя не менее важны для физического размещения системы.Например, реализация может включать файлы данных, вспомогательную документацию, скрипты, файлы протоколов, файлы инициализации, а также файлы, используемые при установке/удалении системы. Моделирование подобных артефактов – важная частьуправления конфигурацией системы.
К счастью, для этого хорошоподходят артефакты UML.Чтобы смоделировать таблицы, файлы и документы, необходимо: Идентифицировать вспомогательные артефакты, являющиеся частью физической реализации системы. Смоделировать эти сущности в виде артефактов. Если вашареализация представляет новые виды артефактов, понадобится ввести соответствующие стереотипы. При необходимости обозначить связи между этими вспомогательными артефактами и другими исполняемыми программами,{version = 5.0.1}Рис. 26.5.
Моделирование таблиц, файлов иМоделирование баз данных значительно усложняется, когда выначинаете иметь дело со множеством таблиц, триггеров и хранимыхпроцедур. Чтобы визуализировать, специфицировать, конструировать и документировать эти средства, вам придется смоделироватьлогическую схему наряду с физической базой данных.Артефакты376Советы и подсказкиНа рис. 26.6 показаны некоторые файлы исходного кода, используемые для построения библиотеки render.dll из предыдущих примеров. Рисунок включает четыре заголовочных файла (render.h,rengine.h, poly.h и colortab.h), которые представляют исходный кодспецификации определенных классов.
Также имеется файл реализации (render.cpp), представляющий реализацию одного из этих заголовков.Моделирование исходного кодаГлавное назначение артефактов – моделирование физическихчастей реализации. Второе по важности их применение – моделирование конфигурации всех файлов исходного кода, которые нужны средству разработки для построения исполняемых артефактов.Эти файлы представляют собой артефакты продуктов процессаразработки.Моделирование исходного кода в графическом виде полезно,в частности, для визуализации зависимостей компиляции междуфайлами исходного кода, а также для управления расщеплениеми слиянием групп этих файлов при распараллеливании и соединении самого процесса разработки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
