Интерфейс прикладного программирования

Если вы - разработчик, собирающий систему из компонентов, то вам часто нужно знать интерфейсы прикладного программирования (API - Application Pro­gramming Interface), которыми можно пользоваться для «склейки» разных частей API - это способы стыковки различных программ в системе, моделируемые с по­мощью интерфейсов и компонентов.

API - это, по сути дела, интерфейс, реализуемый одним или несколькими ком­понентами. Разработчику интересен только сам интерфейс, а не то, каким именно компонентом он реализован, - конечно, при условии, что какой-то компонент его все-таки реализует. Но с точки зрения управления конфигурацией системы осо­бенности реализации важны, поскольку, когда вы публикуете API, необходимо быть уверенным в том, что присутствует хоть какая-то реализация этого API. UML позволяет вам моделировать обе точки зрения.

Операций, ассоциированных с любым семантически богатым API, существует довольно много, и нет необходимости визуализировать их все сразу. Вместо этого следует оставить операции на заднем плане модели и пользоваться интерфейсами как дескрипторами, с помощью которых эти операции можно отыскать. При же­лании построить исполняемую систему, использующую данный API, вам потре­буется добавить ряд деталей, чтобы имеющиеся в вашем распоряжении средства разработки могли успешно откомпилировать код. Помимо сигнатур всех опера­ций, вы, наверное, захотите привести примеры, поясняющие, как следует исполь­зовать каждый интерфейс.

Моделирование API производится так:

1. Идентифицируйте стыковочные узлы в своей системе и промоделируйте каждый из них в виде интерфейса, собрав вместе соответствующие атрибуты и операции.

2. Раскрывайте только те свойства интерфейса, которые важно визуализировать в данном контексте. Остальные свойства спрячьте, поместив их в спецификацию интерфейса для справки.

3. Реализацию каждого API моделируйте только в той мере, насколько это важно для понимания конфигурации конкретной физической реализации системы

На рис. 25.7 раскрыты API исполняемо программы, фигурирующей на двух предыду .щих рисунках. Вы видите четыре интерфейс;

lApplication, IModels,IRenderim и IScripts.

Исходный код

Чаще всего компоненты используются ДЛ< моделирования физических частей, состав ляющих реализацию. Сюда же относите! моделирование вспомогательных элементе!

развернутой системы: таблиц, файлов, документов и API. Другое назначение ком­понентов - моделирование конфигурации всех файлов, содержащих исходный код, из которых с помощью средств разработки были созданы исполняемые части. Это компоненты, являющиеся рабочими продуктами процесса разработки.

Графическое моделирование исходного кода особенно полезно для визуализации зависимостей между различными файлами при компиляции, а также для управле­ния разбиением файлов на относительно независимые группы и последующим их объединением в ходе ветвления процесса разработки. Таким образом, компоненты UML можно использовать в качестве графического интерфейса к средствам кон­троля версий и управления конфигурацией.

Для большинства систем состав файлов с исходным кодом диктуется требуе­мыми средой разработки решениями, которые вы приняли относительно структури­рования файлов. В этих файлах хранятся детали реализации классов, интерфейсов, коопераций и других логических элементов, которые впоследствии преобразуются в физические двоичные компоненты с помощью средств разработки. Как правило, средства разработки определяют способ организации исходного кода (например, для каждого класса обычно используется один или два файла), но необходимость в визуализации отношений между файлами все равно остается. Методы группиров­ки файлов в пакеты и методы управления версиями диктуются решениями о стра­тегии внесения изменений в систему.

Моделирование исходного кода осуществляется следующим образом:

1. В зависимости от того, какие ограничения накладывают средства разработки, смоделируйте файлы, в которых будут храниться все логические элементы, а также зависимости между ними при компиляции.

2. Если нужно привязать модели к средствам контроля версий и управления конфигурацией, включите для каждого управляемого файла помеченные значения, такие как номер версии, имя автора и информацию о выборке и возврате файла в депозитарий.

3. По мере возможности оставляйте управление отношениями между файлами инструментам разработки, используя UML только для визуализации и документирования отношений.

Например, на рис. 25.8 показаны некоторые исходные файлы, из которых стро­ится библиотека render. dll. Вы видите четыре заголовочных файла (render. h, rengine. h, poly. h и colortab. h), представляющих спецификации некоторых классов, а также файл render. срр, представляющий собой реализацию одного из этих классов.

По мере увеличения размера модели вы обнаружите, что многие файлы с ис­ходными текстами объединяются в концептуально и семантически связанные группы. Скорее всего, система разработки поместит эти группы файлов в отдель­ные каталоги. В UML для моделирования таких групп можно использовать па­кеты (см. главу 12).

UML позволяет визуализировать отношение между классом и соответствующим исходным файлом, а также отношение между исходным файлом и исполняемой про­граммой или библиотекой. Для этого используются отношения трассировки (см. гла­вы 5 и 10). Однако такие детали требуется прорабатывать сравнительно редко.

Советы

Моделируя компоненты в UML, помните, что вы моделируете физические ас­пекты системы. Хорошо структурированный компонент обладает следующими свойствами:

• предоставляет четкую абстракцию некоторой сущности, которая является частью физического аспекта системы;

• предоставляет реализацию небольшого, хорошо определенного набора интер­фейсов;

• включает набор классов, которые, действуя совместно, реализуют семантику интерфейсов изящно и экономно;

• слабо связан с другими компонентами; как правило, компоненты моделиру­ются только совместно с отношениями зависимости и реализации.

Изображая компонент в UML, руководствуйтесь следующими правилами:

• применяйте свернутую форму интерфейса, если только не возникает острой необходимости раскрыть операции, предлагаемые этим интерфейсом;

• показывайте только те интерфейсы, которые необходимы для понимания назначения компонента в данном контексте;

• в тех случаях, когда вы используете компоненты для моделирования библио­тек и исходного кода, указывайте помеченные значения, относящиеся к кон­тролю версий.