2.3. Анализ требований к системе

Проектирование архитектуры начинается с анализа требований. На этой фазе проектировщик должен:

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

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

3. Разработать ряд внутренних протоколов проекта. Эти протоколы должны охватывать следующие стороны проекта:

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

Именование: должны быть сформулированы и запротоколированы правила формализованного присвоения имен всем элементам данных, используемым в проекте.

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

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

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

Контроль изменений: контроль над изменениями и своевременное внесение изменений в документацию должны выполняться с начальных стадий проектирования.

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

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

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

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

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

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

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