необходима свобода в выборе аппаратной или программной реализации той или иной функции: позднее может оказаться, что нужна дополнительная аппаратура, или что данную функцию можно реализовать программно.
На рис. 12-3 показано целевое аппаратное обеспечение для системы управления движением; здесь используются наши обозначения для диаграмм процессов. Эта архитектура процессов соответствует схеме на рис. 12-1. В частности, предусмотрен один бортовой компьютер на каждом поезде, соединяющий систему сбора и передачи информации о локомотиве, систему управления энергией, бортовой дисплей и устройство управления данными. Мы предполагаем, что некоторые бортовые устройства, такие, как дисплей, обладают минимальным интеллектом, но, возможно, не все они программируемые. Мы полагаем, что каждый ответчик подсоединен к передатчику, который посылает сообщения на проходящий мимо него поезд; компьютер к ответчику местоположения не подсоединен. Все группы путевых устройств (каждое из которых логически состоит из интерфейса и переключателя) управляются компьютером, который может взаимодействовать с проходящим поездом или с наземным контроллером через их передатчики и приемники. Каждый наземный контроллер присоединяется через глобальную сеть к диспетчерскому центру (который входит в систему управления операциями). Для обеспечения бесперебойного обслуживания мы решили разместить на каждом диспетчерском центре два компьютера: основной и резервный (второй включится в случае отказа основного компьютера). В свободное время резервный компьютер может использоваться для обслуживания других, низкоприоритетных пользователей.
На эксплуатационном уровне система управления движением может содержать сотни компьютеров: по одному на каждый поезд, по одному на каждый блок интерфейса путевых устройств и по два на каждый диспетчерский центр. На диаграмме процессов показаны только некоторые компьютеры, так как излишне показывать повторяющиеся компоненты конфигурации.
Как уже говорилось в главах 6 и 7, здравый смысл подсказывает, что при разработке большого проекта огромную роль играют разумность и ясность интерфейсов между ключевыми частями системы. Особенно это важно для интерфейса между программной и аппаратной частями системы. В начале работы над проектом интерфейс может быть определен не полностью, но он должен быть достаточно быстро формализован, чтобы различные части системы можно было разрабатывать, тестировать и интегрировать одновременно. Хорошо определенный интерфейс позволяет производить сборку системы без существенных переделок ее частей. Кроме того, мы не рассчитываем, что все разработчики, участвующие в проекте, будут одинаково сильны в программировании. Поэтому мы должны поручить спецификации ключевых абстракций и механизмов сильнейшим системным архитекторам
Ключевые абстракции и механизмы
В результате изучения требований к системе управления движением становится очевидно, что мы должны решить четыре основные подзадачи:
• сеть
• база данных
• интерфейс 'человек/компьютер'
• управление аналоговыми устройствами в реальном времени.
Как мы пришли к выводу, что именно в этих подзадачах сконцентрирован основной риск разработки?
Систему связывает воедино распределенная сеть передачи данных. С помощью радио передаются сообщения: между ответчиками и поездами, между поездами и наземными контроллерами, между поездами и блоками интерфейсов путевых устройств, между наземными контроллерами и путевыми устройствами. Кроме того, сообщения должны передаваться между диспетчерскими центрами и отдельными наземными контроллерами. Надежная работа всей системы обеспечивается своевременным и надежным приемом и передачей сообщений.
Кроме того, система должна одновременно хранить информацию о местоположении и планируемых маршрутах множества поездов. Мы должны поддерживать постоянно обновляемую информацию и гарантировать ее целостность даже в случае попыток одновременно записать и считать информацию из разных мест сети. Следовательно, нам нужна распределенная база данных.
Проектирование человеко-машинного интерфейса ставит еще одну группу задач. Дело в том, что пользователями системы в основном являются машинисты и диспетчеры; но никто из них не обязан обладать профессиональными навыками работы с компьютером. Пользовательский интерфейс операционных систем, таких как UNIX или Windows, пригоден (по большей части) для специалиста- программиста, но считается слишком враждебным для конечных пользователей таких сред, как система управления движением. Следовательно, все формы взаимодействия должны быть спроектированы в расчете на эту особую группу пользователей.
Наконец, система управления движением должна взаимодействовать с разнообразными датчиками и исполнительными механизмами. Не останавливаясь здесь на природе этих устройств, отметим, что принципы управления ими не зависят от конкретного типа устройства и должны быть выбраны однотипными во всей системе.
Каждая из этих четырех подзадач включает целый ряд обособленных вопросов. Системные архитекторы должны найти ключевые абстракции и механизмы каждой задачи, и тогда мы сможем пригласить экспертов для решения каждой отдельной подзадачи независимо от других. Однако, ни анализ, ни проектирование не удастся завершить за один проход, - круг за кругом анализ будет обнаруживать новые архитектурные проблемы, решение которых потребует нового анализа. Таким образом, разработка будет неизбежно пошаговой и итеративной.
Из краткого проблемного анализа четырех главных подзадач мы видим, что существуют три высокоуровневые ключевые абстракции:
• Поезда Локомотивы и вагоны.
• Пути Профиль пути, его качество и путевые устройства.
• Планы Расписания, приказы, устранение накладок, назначение полномочии и подбор бригад.
Каждый поезд характеризуется текущим положением на путях и может иметь только один активный план движения. Аналогично, в каждой точке пути может быть самое большое один поезд. Каждый план относится только к одному поезду, но ко многим точкам пути.
Мы можем выделить ключевой механизм для каждой из четырех (почти независимых) подзадач:
• передача сообщений
• планирование движения поездов
• отображение информации
• сбор данных от датчиков.
Эти четыре механизма составляют душу нашей системы. Они являются наиболее сложными и рискованными частями проекта. Важно, чтобы мы поручили лучшим системным архитекторам поэкспериментировать с различными подходами и постепенно создать среду, на базе которой более молодые разработчики сделают все остальное.
12.2. Проектирование
Как уже отмечалось в главе 6, создание архитектуры подразумевает выявление основной структуры классов и спецификацию общих взаимодействий, которые оживляют классы. Сконцентрировав внимание прежде всего на этих механизмах, мы с самого начала выявляем элементы наибольшего риска и нацеливаем на них все усилия системных архитекторов. Результаты этой фазы дают хорошую основу (в виде классов и взаимодействий), на базе которой строятся функциональные элементы нашей системы.
В данном разделе мы подробно рассмотрим семантику каждого из четырех выделенных ключевых механизмов.
