Компонентная модель организации программных систем. Семакин М.М. - 7 стр.

        2. ТРЕБОВАНИЯ К ПРОГРАММНОМУ КОМПОНЕНТУ
      Общие требования:
      1. Программные компоненты должны быть доступны средствам выбранного языка
         сборки.
      2. Все компоненты должны поддерживать системные методы.
      3. Следует избегать случаев, когда компонент напрямую вызывает метод другого
         компонента (т.к. это приводит к образованию «жесткой связи»).
      4. Свойства компонента являются одновременно и индикаторами его состояния,
         т.е. при изменении внутренних данных, необходимо обновлять соответствую-
         щие свойства.
      5. Все компоненты должны отвечать общей системе документирования.

      Для обеспечения совместимости компонента с языком сборки будем считать, что
достаточно выполнения следующих требований:
      1) стандартизованная модель вызова внешних функций, общая структура переда-
         ваемых параметров и возвращаемого результата;
      2) ограничения на типы данных (параметры и результаты функций, свойства ком-
         понента);
      3) все методы и свойства компонента должны быть представлены в виде таблицы,
         где каждой строке сопоставлен именованный индекс.

      Назначением системных методов является унификация способов создания, преоб-
разования типов и удаления компонентов, а также получение управляющей информации.
      Системные методы:
      1) alloc – конструктор внутренних ресурсов компонента, результатом является де-
скриптор выделенных ресурсов, или пустое значение в случае ошибки или при отсутствии
внутренних ресурсов (например, если компонент реализуется средствами языка сборки).
Входными параметрами являются параметры конструктора компонента. Перечень вход-
ных параметров должен быть документирован, необходимо также, осуществлять обяза-
тельную проверку правильности входных параметров;
      2) delete – деструктор внутренних ресурсов компонента. Входными параметрами
являются задокументированные параметры управления освобождением ресурсов (жела-
тельно избегать использование параметров для удаления ресурсов, или обрабатывать их
только в крайних случаях либо на этапе отладки);
      3) new – конструктор компонента. Создание копии (экземпляра) компонента, при
этом выделяются внутренние ресурсы (см. метод alloc) и конструируется публикуемая
структура методов и свойств компонента.

      Для избежания «жестких связей» можно использовать следующие приемы про-
граммирования компонентов:
      1. Создание общих библиотек функций. Здесь удобно реализовать следующие ви-
         ды функций: преобразование типов данных, извлечение информации из бинар-
         ных данных, вычисление формул, обобщенные алгоритмы (например, алгорит-
         мы Брезенхема, хэш-функции, обработка текста, и т.п.).
      2. Реализация методов редактирования структур данных средствами языка сборки.
         Удобно перенести «обязанности» по созданию и управлению информационной
         схемой системы на подсистему адаптации под решаемые задачи, обеспечивая
         тем самым независимость компонентов и высокий уровень декомпозиции задач.
      3. Введение промежуточного или «оберточного» компонента. Промежуточный
         компонент предназначен для связывания двух или нескольких отдельных ком-

                                          7