Архитектурное проектирование. Структурирование системы: модель репозитория, модель клиент/сервер, модель абстрактной машины. Достоинства и недостатки, область применения.

Модель репозитория. Такой подход применим к системам, в которых форма данных хорошо структурирована.

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

2. С другой стороны, подсистемы должны быть согласованы с моделью репозитория
данных. Это всегда приводит к необходимости компромисса между требованиями,
предъявляемыми к каждой подсистеме. Компромиссное решение может понизить
их производительность. Если форматы данных новых подсистем не подходят под
согласованную модель представления данных, интегрировать такие подсистемы
сложно или невозможно.

3. Подсистемам, в которых создаются данные, не нужно знать, как эти данные используются в других подсистемах.

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

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

6. С другой стороны, к разным подсистемам предъявляются разные требования, касающиеся безопасности, восстановления и резервирования данных. В модели ре-
позитория ко всем подсистемам применяется одинаковая политика.

7. Модель совместного использования репозитория прозрачна: если новые подсистемы совместимы с согласованной моделью данных, их можно непосредственно интегрировать в систему.

8. Однако сложно разместить репозиторий па нескольких машинах, поскольку могут воз-
никнуть проблемы, связанные с избыточностью и нарушением целостности данных.

Модель архитектуры клиент/сервер — это модель распределенной системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента.

1. Набор автономных серверов, предоставляющих сервисы другим подсистемам. Например, сервер печати, который предоставляет услуги печати, файловые серверы, предоставляющие сервисы управления файлами, и сервер-компилятор, который предлагает сервисы по компилированию исходных кодов программ.

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

3. Сеть, посредством которой клиенты получают доступ к сервисам. Клиенты получают доступ к сервисам, предоставляемым сервером, посредством удаленного вызова процедур. Во время работы серверы и клиенты обмениваются данными, однако при обмене большими объемами данных могут возникнуть проблемы, связанные с пропускной способностью сети. Правда, с развитием все более быстрых сетей эта проблема теряет свое значение.

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

Модель архитектуры абстрактной машины (иногда называемая многоуровневой моделью) моделирует взаимодействие подсистем. Она организует систему в виде набора уровней, каждый из которых предоставляет свои сервисы. Каждый уровень определяет абстрактную машину, машинный язык которой (сервисы, предоставляемые уровнем) используется для реализации следующего уровня абстрактной машины. Например, наиболее распространенный способ реализации языка программирования состоит в определении идеальной "языковой машины" и компилировании программ, написанных на данном языке, в код этой машины. На следующем шаге трансляции код абстрактной машины конвертируется в реальный машинный код. Хорошо известным примером такого похода может служить модель OSI' сетевых протоколов.

Многоуровневый подход обеспечивает пошаговое развитие систем — при разработке какого-либо уровня предоставляемые им сервисы становятся доступны пользователям. Кроме того, такая архитектура легко изменяема и переносима на разные платформы. Изменение интерфейса любого уровня повлияет только на смежный уровень. Так как в многоуровневых системах зависимости от машинной платформы локализованы на внутренних уровнях, такие системы можно реализовать на других платформах, поскольку потребуется изменить только самые внутренние уровни.

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