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