Требования к методике выбора архитектуры ИС

Я сознательно говорю именно о выборе, а не о разработке архитектуры. Разработка архитектуры – отдельный вопрос. В данном случае речь идет о выборе одной из архитектур-кандидатов.

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

Ø невозможность оценить качество разработанной архитектуры;

Ø ориентированность на архитектуру программной системы и дистанцирование от того факта, что система состоит не только из программных, но также и технических средств и людей;

Ø разделение процессов технико-экономического обоснования системы, разработки бизнес-процессов и разработки архитектуры системы;

Ø отсутствие привязки к бизнес-целям и целям использования системы.

В результате осмысления имеющихся методик нами были сформулированы следующие требования к методике выбора архитектуры. Методика должна:

Ø отражать связь архитектуры и совокупной стоимости владения;

Ø отражать итерационную природу разработки ИС;

Ø иметь своей целью выбор архитектуры системы в целом, а не только ее программной составляющей;

Ø связывать разработку архитектуры, бизнес-анализ и технико-экономическое обоснование в едином процессе.

III. «Слои» программных приложений

Концепция слоев (layers) — одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои:

Ø код на языке программирования,

Ø функции операционной системы,

Ø драйвера устройств,

Ø набо­р инструкций центрального процессора,

Ø внутренняя логика чипов.

В среде сетевого взаимодействия протокол FTP работает на основе протокола TCP, который, в свою оче­редь, функционирует "поверх" протокола IP, расположенного "над" протоколом Ethernet.

Описывая систему в терминах архитектурных слоев, удобно воспринимать составляющие ее подсистемы в виде "слоеного пирога". Слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот не "осведомлен" о наличии соседнего верхнего слоя. Более того, обычно каждый промежуточный слой "скрывает" нижний слой от верхнего: например, слой 4 пользуется услугами слоя 3, который обращается к слою 2, но слой 4 не знает о существовании слоя 2. (Не в каждой архитектуре слои настолько "непроницаемы", но в большинстве случаев дело обстоит именно так.)

Расчленение системы на слои предоставляет целый ряд преимуществ:

1. Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других слоев (скажем, для создание службы FTP необходимо знать протокол TCP, но не тонкости Ethernet).

2. Можно выбирать альтернативную реализацию базовых слоев (приложения FTP способны работать без каких-либо изменений в среде Ethernet, по соединению РРР или в любой другой среде передачи информации).

3. Зависимость между слоями можно свести к минимуму. Так, при смене среды передачи информации (при условии сохранения функциональности слоя IP) служба FTP будет продолжать работать как ни в чем не бывало.

4. Каждый слой является удачным кандидатом на стандартизацию (например, TCP и IP — стандарты, определяющие особенности функционирования соответствующих слоев системы сетевых коммуникаций).

5. Созданный слой может служить основой для нескольких различных слоев более высокого уровня (протоколы TCP/IP используются приложениями FTP, telnet, SSH и HTTP). В противном случае для каждого протокола высокого уровня пришлось бы изобретать собственный протокол низкого уровня.

Схема расслоения обладает и определенными недостатками.

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

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

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

IV. Архитектуры информационной системы: