Дипломная работа: Автоматизация "личного кабинета" консультанта по недвижимости (на примере организации Росинформ)
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
38
Компонент (component) — физически существующая часть системы,
которая обеспечивает реализацию классов и отношений, а также
функционального поведения моделируемой программной системы.
Компонент предназначен для представления физической организации
ассоциированных с ним элементов модели. Дополнительно компонент может
иметь текстовый стереотип и помеченные значения, а некоторые компоненты –
собственное графическое представление. Компонентом может быть
исполняемый код отдельного модуля, командные файлы или файлы,
содержащие интерпретируемые скрипты.
Компонент служит для общего обозначения элементов физического
представления модели и может реализовывать некоторый набор интерфейсов.
Для графического представления компонента используется специальный
символ – прямоугольник со вставленными слева двумя более мелкими
прямоугольниками (Рисунок 7.) Внутри объемлющего прямоугольника
записывается имя компонента и, возможно, дополнительная информация. Этот
символ является базовым обозначением компонента в языке UML.
Рисунок 7. Графическое изображение компонента
Графическое изображение компонента ведет свое происхождение от
обозначения модуля программы, применявшегося некоторое время для
отображения особенностей инкапсуляции данных и процедур.
Модуль (module) — часть программной системы, требующая памяти для
своего хранения и процессора для исполнения.
39
В этом случае верхний маленький прямоугольник ассоциировался с
данными, которые реализует этот компонент (иногда он изображается в форме
овала). Нижний маленький прямоугольник ассоциировался с операциями или
методами, реализуемыми компонентом. В простых случаях имена данных и
методов записывались явно в маленьких прямоугольниках, однако в языке
UML они не указываются.
Поскольку компонент как элемент модели может иметь различную
физическую реализацию, иногда его изображают в форме специального
графического символа, иллюстрирующего конкретные особенности
реализации. Строго говоря, эти дополнительные обозначения не
специфицированы в нотации языка UML. Однако, удовлетворяя общим
механизмам расширения языка UML, они упрощают понимание диаграммы
компонентов, существенно повышая наглядность графического представления.
Для более наглядного изображения компонентов были предложены и
стали общепринятыми следующие графические стереотипы (Рисунок 8):
- Во-первых, стереотипы для компонентов развертывания, которые
обеспечивают непосредственное выполнение системой своих функций. Такими
компонентами могут быть динамически подключаемые библиотеки Web-
страницы на языке разметки гипертекста и файлы справки.
- Во-вторых, стереотипы для компонентов в форме рабочих
продуктов. Как правило – это файлы с исходными текстами программ.
Рисунок 8. Варианты графического изображения компонентов
на диаграмме компонентов
40
Эти элементы иногда называют артефактами, подчеркивая при этом их
законченное информационное содержание, зависящее от конкретной
технологии реализации соответствующих компонентов. Более того,
разработчики могут для этой цели использовать самостоятельные обозначения,
поскольку в языке UML нет строгой нотации для графического представления
артефактов.
Другой способ спецификации различных видов компонентов —
указание текстового стереотипа компонента перед его именем. В языке UML
для компонентов определены следующие стереотипы:
- <<file>> (файл) – определяет наиболее общую разновидность
компонента, который представляется в виде произвольного физического файла.
- <<executable>> (исполнимый) – определяет разновидность
компонента-файла, который является исполнимым файлом и может
выполняться на компьютерной платформе.
- <<document>> (документ) – определяет разновидность
компонента-файла, который представляется в форме документа произвольного
содержания, не являющегося исполнимым файлом или файлом с исходным
текстом программы.
- <<library>> (библиотека) – определяет разновидность компонента-
файла, который представляется в форме динамической или статической
библиотеки.
- <<source>> (источник) – определяет разновидность компонента-
файла, представляющего собой файл с исходным текстом программы, который
после компиляции может быть преобразован в исполнимый файл.
- <<table>> (таблица) – определяет разновидность компонента,
который представляется в форме таблицы базы данных.
Допустимо предлагагать собственные графические стереотипы для
изображения тех или иных типов компонентов.
41
Интерфейсы
Следующим графическим элементом диаграммы компонентов являются
интерфейсы. В общем случае интерфейс графически изображается
окружностью, которая соединяется с компонентом отрезком линии без стрелок.
При этом имя интерфейса, которое рекомендуется начинать с заглавной буквы
"I", записывается рядом с окружностью. Семантически линия означает
реализацию интерфейса, а наличие интерфейсов у компонента означает, что
данный компонент реализует соответствующий набор интерфейсов .
Кроме того, интерфейс на диаграмме компонентов может быть
изображен в виде прямоугольника класса со стереотипом << interface>> и
секцией поддерживаемых операций. Как правило, этот вариант обозначения
используется для представления внутренней структуры интерфейса.
При разработке программных систем интерфейсы обеспечивают не
только совместимость различных версий, но и возможность вносить
существенные изменения в одни части программы, не изменяя другие.
Различают два способа связи интерфейса и компонента. Если компонент
реализует некоторый интерфейс, то такой интерфейс называют
экспортируемым или поддерживаемым, поскольку этот компонент
предоставляет его в качестве сервиса другим компонентам. Если же компонент
использует некоторый интерфейс, который реализуется другим компонентом,
то такой интерфейс для первого компонента называется импортируемым.
Особенность импортируемого интерфейса состоит в том, что на диаграмме
компонентов это отношение изображается с помощью зависимости.
Зависимости между компонентами
Отношение зависимости служит для представления факта наличия
специальной формы связи между двумя элементами модели, когда изменение
одного элемента модели оказывает влияние или приводит к изменению другого
элемента модели. Отношение зависимости на диаграмме компонентов
изображается пунктирной линией со стрелкой, направленной от клиента или
зависимого элемента к источнику или независимому элементу модели.
42
Зависимости могут отражать связи отдельных файлов программной
системы на этапе компиляции и генерации объектного кода. В других случаях
зависимость может указывать на наличие в независимом компоненте описаний
классов, которые используются в зависимом компоненте для создания
соответствующих объектов. Применительно к диаграмме компонентов
зависимости могут связывать компоненты и импортируемые этим компонентом
интерфейсы, а также различные виды компонентов между собой.
В этом случае рисуют стрелку от компонента-клиента к
импортируемому интерфейсу. Наличие такой стрелки означает, что компонент
не реализует соответствующий интерфейс, а использует его в процессе своего
выполнения. При этом на этой же диаграмме может присутствовать и другой
компонент, который реализует этот интерфейс. Отношение реализации
интерфейса обозначается на диаграмме компонентов обычной линией без
стрелки.
Так, например, изображенный ниже фрагмент диаграммы компонентов
представляет информацию о том, что компонент с именем Control зависит от
импортируемого интерфейса IDialog, который, в свою очередь, реализуется
компонентом с именем DataBase . При этом для второго компонентa этот
интерфейс является экспортируемым. Изобразить связь второго компонентa
DataBase с этим интерфейсом в форме зависимости нельзя, поскольку этот
компонент реализует указанный интерфейс.
На диаграмме компонентов могут быть также представлены отношения
зависимости между компонентами и реализованными в них классами. Эта
информация имеет значение для обеспечения согласования логического и
физического представлений модели системы. Разумеется, изменения в
структуре описаний классов могут привести к изменению этой зависимости.
Ниже приводится фрагмент зависимости подобного рода, когда исполнимый
компонент Control .exe зависит от соответствующих классов.
В этом случае из диаграммы компонентов не следует, что классы
реализованы данным компонентом. Если требуется подчеркнуть, что
Источник: https://baza.diplomsite.ru/previewfile/2504