Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 88
Текст из файла (страница 88)
Мы полагаем, что каждый ответчик подсоединен кпередатчику, который посылает сообщения на проходящий мимо него поезд;компьютер к ответчику местоположения не подсоединен. Все группы путевыхустройств (каждое из которых логически состоит из интерфейса ипереключателя) управляются компьютером, который можетвзаимодействовать с проходя-Рис.
12-3. Диаграмма процессов системы управления движениемщим поездом или с наземным контроллером через их передатчики иприемники. Каждый наземный контроллер присоединяется через глобальнуюсеть к диспетчерскому центру (который входит в систему управленияоперациями). Для обеспечения бесперебойного обслуживания мы решилиразместить на каждом диспетчерском центре два компьютера: основной ирезервный (второй включится в случае отказа основного компьютера).
Всвободное время резервный компьютер может использоваться дляобслуживания других, низкоприоритетных пользователей.На эксплуатационном уровне система управления движением можетсодержать сотни компьютеров: по одному на каждый поезд, по одному накаждый блок интерфейса путевых устройств и по два на каждыйдиспетчерский центр.
На диаграмме процессов показаны только некоторыекомпьютеры, так как излишне показывать повторяющиеся компонентыконфигурации.Как уже говорилось в главах 6 и 7, здравый смысл подсказывает, чтопри разработке большого проекта огромную роль играют разумность иясность интерфейсов между ключевыми частями системы. Особенно этоважно для интерфейса между программной и аппаратной частями системы. Вначале работы над проектом интерфейс может быть определен не полностью,но он должен быть достаточно быстро формализован, чтобы различные частисистемы можно было разрабатывать, тестировать и интегрироватьодновременно. Хорошо определенный интерфейс позволяет производитьсборку системы без существенных переделок ее частей.
Кроме того, мы нерассчитываем, что все разработчики, участвующие в проекте, будут одинаковосильны в программировании. Поэтому мы должны поручить спецификацииключевых абстракций и механизмов сильнейшим системным архитекторамКлючевые абстракции и механизмыВ результате изучения требований к системе управления движениемстановится очевидно, что мы должны решить четыре основные подзадачи:•сеть•база данных•интерфейс "человек/компьютер"•управление аналоговыми устройствами в реальном времени.Как мы пришли к выводу, что именно в этих подзадачахсконцентрирован основной риск разработки?Систему связывает воедино распределенная сеть передачи данных.
Спомощью радио передаются сообщения: между ответчиками и поездами,между поездами и наземными контроллерами, между поездами и блокамиинтерфейсов путевых устройств, между наземными контроллерами ипутевыми устройствами. Кроме того, сообщения должны передаваться междудиспетчерскими центрами и отдельными наземными контроллерами.Надежная работа всей системы обеспечивается своевременным и надежнымприемом и передачей сообщений.Кроме того, система должна одновременно хранить информацию оместоположении и планируемых маршрутах множества поездов.
Мы должныподдерживать постоянно обновляемую информацию и гарантировать еецелостность даже в случае попыток одновременно записать и считатьинформацию из разных мест сети. Следовательно, нам нужна распределеннаябаза данных.Проектирование человеко-машинного интерфейса ставит еще однугруппу задач. Дело в том, что пользователями системы в основном являютсямашинисты и диспетчеры; но никто из них не обязан обладатьпрофессиональными навыками работы с компьютером.
Пользовательскийинтерфейс операционных систем, таких как UNIX или Windows, пригоден (побольшей части) для специалиста-программиста, но считается слишкомвраждебным для конечных пользователей таких сред, как система управлениядвижением. Следовательно, все формы взаимодействия должны бытьспроектированы в расчете на эту особую группу пользователей.Наконец, система управления движением должна взаимодействовать сразнообразными датчиками и исполнительными механизмами. Неостанавливаясь здесь на природе этих устройств, отметим, что принципыуправления ими не зависят от конкретного типа устройства и должны бытьвыбраны однотипными во всей системе.Каждая из этих четырех подзадач включает целый ряд обособленныхвопросов.
Системные архитекторы должны найти ключевые абстракции имеханизмы каждой задачи, и тогда мы сможем пригласить экспертов длярешения каждой отдельной подзадачи независимо от других. Однако, нианализ, ни проектирование не удастся завершить за один проход, - круг закругом анализ будет обнаруживать новые архитектурные проблемы, решениекоторых потребует нового анализа.
Таким образом, разработка будетнеизбежно пошаговой и итеративной.Из краткого проблемного анализа четырех главных подзадач мывидим, что существуют три высокоуровневые ключевые абстракции:• Поезда Локомотивы и вагоны.• ПутиПрофиль пути, его качество и путевые устройства.• Планы Расписания, приказы, устранение накладок,назначениеполномочии и подбор бригад.Каждый поезд характеризуется текущим положением на путях иможет иметь только один активный план движения.
Аналогично, в каждойточке пути может быть самое большое один поезд. Каждый план относитсятолько к одному поезду, но ко многим точкам пути.Мы можем выделить ключевой механизм для каждой из четырех(почти независимых) подзадач:•передача сообщений•планирование движения поездов•отображение информации•сбор данных от датчиков.Эти четыре механизма составляют душу нашей системы.
Ониявляются наиболее сложными и рискованными частями проекта. Важно,чтобы мы поручили лучшим системным архитекторам поэкспериментироватьс различными подходами и постепенно создать среду, на базе которой болеемолодые разработчики сделают все остальное.12.2. ПроектированиеКак уже отмечалось в главе 6, создание архитектуры подразумеваетвыявление основной структуры классов и спецификацию общихвзаимодействий, которые оживляют классы. Сконцентрировав вниманиепрежде всего на этих механизмах, мы с самого начала выявляем элементынаибольшего риска и нацеливаем на них все усилия системных архитекторов.Результаты этой фазы дают хорошую основу (в виде классов ивзаимодействий), на базе которой строятся функциональные элементы нашейсистемы.В данном разделе мы подробно рассмотрим семантику каждого изчетырех выделенных ключевых механизмов.Механизм передачи сообщенийПод сообщением здесь мы не имеем в виду активизацию методов, какэто принято в объектно-ориентированных языках программирования.
Вданном случае понятие взято из словаря предметной области, из самоговысокого уровня абстракции. Вот несколько примеров сообщений в системеуправления движением: сигнал запуска путевому устройству, сообщение опрохождении поезда через определенный пункт пути, приказ диспетчерамашинисту. Все эти виды сообщений могут передаваться внутри системыуправления движением на двух уровнях:•между компьютерами и устройствами•между компьютерами.Сейчас нас интересует второй уровень передачи сообщений.
Так каксистема включает территориально распределенную сеть, мы должны учестьтакие факторы, как помехи, отказы оборудования и секретность передачиинформации.Первый шаг при определении сообщений в системе - анализвзаимодействия каждой пары сообщающихся компьютеров (см. рис. 12-3). Длякаждой такой пары мы должны задать три вопроса: (1) Какую информациюобрабатывает каждый компьютер? (2) Какая информация будет передаваться содного компьютера на другой? (3) К какому уровню абстракции будетотноситься эта информация? Эмпирического ответа на эти вопросы нет. Мыдолжны действовать итеративно, пока не придем к уверенности, чтоопределены правильные сообщения и в системе связи нет "узких" мест(которые могут возникать из-за перегрузки линий связи или, например, из-затого, что сообщение разбивается на слишком мелкие пакеты).Очень важно, чтобы на данном этапе проектирования внимание былососредоточено на сути, а не на форме сообщений. Слишком часто системныеархитекторы начинают проектирование с выбора битового представлениясообщений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
