2.4. Проектирование архитектуры системы

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

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

На этом же этапе появляются и первые версии интерфейсов между подсистемами.

Хорошим стилем проектирования является сокрытие сложности внутри подсистем ради упрощения интерфейсов между ними.

После определения подсистем может быть выполнено распределение задач по подсистемам.

Распределение задач позволяет сформировать требования к коммуникациям между ними.

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

1. Результаты декомпозиции системы на подсистемы и перечисление функций каждой из подсистем.

2. Спецификацию данных в интерфейсах между подсистемами.

3. Спецификацию интерфейсов ввода/вывода к объектам внешней среды.

4. Спецификацию преобразований данных, выполняемых в каждой из подсистем: список входных данных, алгоритмы преобразования, список выходных данных.

5. Анализ требований надежности и предложения по реализации этих требований (дублирование сообщений, отказоустойчивые модули).

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

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

2.5. Оценка результатов проектирования архитектуры

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

1. Функциональная согласованность подсистем

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

• Реализует ли подсистема автономную функцию?

• Можно ли обеспечить восстановление после ошибок рестартом всей подсистемы?

• Пересекают ли интерфейс только данные или еще и сигналы управления?

• Как много элементов данных пересекают интерфейс?

2. Тестируемость подсистем

Этот показатель говорит о том, насколько полно можно проверить подсистему изолированно от других подсистем. Следующий список вопросов помогает оценить степень тестируемости подсистемы:

• Достаточно ли точно определены временные характеристики интерфейса, чтобы их можно было смоделировать на тестовом оборудовании?

• Наблюдаемы ли сообщения ввода/вывода?

• Можно ли установить состояние подсистемы извне, чтобы уменьшить число тестовых последовательностей?

• Будут ли одни и те же входные сигналы вести к тем же самым результатам на выходе?

• Существуют ли механизмы проверки отказоустойчивости подсистемы?

• Можно ли реализовать эффективное встроенное самотестирование подсистемы?