1.2. Подходы к анализу проблем проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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