Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 90
Текст из файла (страница 90)
12-7 показано, как происходит передача и обновление копийплана. Первичная копия плана движения находится в централизованной базеданных в диспетчерском центре и может быть разослана по любому числуузлов сети. КогдаРис. 12- 7. План движения поездакакой-либо клиент (используя операцию get с уникальным UniqueIdв качестве аргумента) запрашивает план, первичная версия копируется ипосылается клиенту. В базе данных регистрируется местоположение копии, асама копия плана сохраняет связь с базой данных. Теперь предположим, что врезультате действий машиниста появилась необходимость изменить пландвижения поезда.
Сначала изменяется копия плана, находящаяся на поезде.Затем сообщение об изменениях посылается в централизованную базу данныхна диспетчерский центр. После того, как план изменился в базе данных,сообщения об изменениях рассылаются всем остальным клиентам, которыеимеют у себя копии данного плана.Этот механизм правильно работает и в том случае, когда изменения вплан движения вносит диспетчер; при этом сначала изменяется копия плана вбазе данных, а затем сообщения об изменениях рассылаются но сетиостальным клиентам. Как в обоих случаях осуществляется передачаизменении? Для этого мы используем механизм передачи сообщений,разработанный нами ранее.
Заметим, что в результате проектирования мыдобавили новое сообщение: изменение плана движения поезда. Такимобразом, механизм передачи планов движения базируется на ужесуществующем низкоуровневом механизме передачи сообщений.Использование готовой коммерческой СУБД на диспетчерскихкомпьютерах позволит обеспечить резервирование данных, восстановление,ведение контрольного журнала и секретность информации.Отображение информацииИспользование готовых технологических решений для базы данныхпозволяет нам сосредоточиться на специфике задачи. Такого же результатаможно добиться и в механизмах отображения информации, если использоватьстандартные графические средства, например, Microsoft Windows или ХWindows.
Использование готовых графических программных средствподнимает уровень абстракции нашей системы настолько, что разработчикамне надо беспокоиться об отображении информации на уровне пикселей. Крометого, очень важно инкапсулировать проектные решения о графическомпредставлении различных объектов.Рассмотрим, например, отображение информации о профиле икачестве участков пути.
Требуется, чтобы изображение появлялось в двухместах: в диспетчерском центре и на поезде (где отображается путь тольковпереди поезда). Предполагая, что мы имеем некоторый класс, экземплярыкоторого представляют участки пути, можно рассмотреть два подхода квизуализации этого объекта. В соответствии с первым подходом, создаетсяспециальный объект, управляющий отображением, который преобразуетсостояние объекта в визуальную форму.
Согласно второму подходу мыотказываемся от специального внешнего объекта и в каждый наш объектвключаем информацию о том, как его отображать. Мы считаем, что второйподход предпочтительней, так как он проще и лучше отражает сущностьобъектной модели.Однако, этот подход не лишен недостатков. Мы, вероятно, получиммножество разновидностей отображаемых объектов, каждый из которыхсоздан разными группами разработчиков. Если реализовывать каждыйотображаемый объект отдельно, то возникают избыточный код.несогласованность стиля и вообще большая путаница.
Правильнеепроанализировать все разновидности отображаемых объектов, определить,какие у них общие элементы и создать набор промежуточных классов,который обеспечит отображение этих общих элементов. В свою оче-Pиc. 12-8. Отображение информацииредь, промежуточные классы могут быть построены на основекоммерческих низкоуровневых графических пакетов.На рис. 12-8 показано проектное решение о реализации всехотображаемых объектов с помощью общих утилит класса.
Эти утилитыпостроены на основе низкоуровневого интерфейса Windows, который скрыт отвсех высокоуровневых классов. На самом деле, процедуры Windows APIтрудно воплотить в одном классе или утилите. Наша диаграмма немногоупрощена; вероятно, реализация потребует услуг нескольких классов WindowsAPI и утилит отображения на дисплее компьютера в поезде.Основное достоинство предлагаемого подхода заключается в том, чтоуменьшается влияние изменений, возникающих при перераспределении ролиаппаратуры и программ. Например, если нам надо заменить наши дисплеи наболее (менее) мощные, придется подправить процедуры только в классеTrainDisplayUtilities. Без такой декомпозиции нам бы пришлось вноситьизменения в каждый отображаемый объект при любых изменениях на нижнемуровне.Механизм опроса датчиковВыше мы говорили, что система управления движением должнавключать в себя большое количество разнообразных датчиков. Например, накаждом поезде датчики следят за температурой масла, количеством топлива,дроссельной установкой, температурой воды, нагрузкой на двигатель и т.
д.Активные датчики путевых устройств сообщают текущее положение своихпереключателей и передают сигналы. Все значения, возвращаемые датчиками- разные, но их обработка может производиться сходным образом. Допустим,что наш компьютер использует ввод-вывод по фиксированным адресампамяти. Тогда данные каждого датчика читаются из определенной областипамяти и только потом интерпретируются способом, зависящим отконкретного датчика. Большинство датчиков должно опрашиватьсяпериодически.
Если значение находится в заданных пределах, оно сообщаетсякакому-то клиенту, и больше ничего не происходит. Если же отсчет датчикавышел за установленные пределы, об этом могут быть оповещены и другиеклиенты. Наконец, если отсчет вышел далеко за допустимые границы(например, давление масла на локомотиве поднимается до опасного уровня),может понадобиться какой-то звуковой сигнал тревоги и уведомлениеспециальных клиентов для принятия решительных мер.Воспроизведение этого поведения для каждого датчика не толькоутомительно и чревато ошибками, но и раздувает объем кода. Если мы ссамого начала не выделим общие для всех датчиков характеристики, торазличные разработчики предложат свои решения одной и той же задачи. Это,в свою очередь, приведет к сложностям при сопровождении системы.
Поэтомудля выявления общих свойств необходимо провести анализ всех периодическиопрашиваемых аналоговых датчиков и предложить общий механизм ихопроса, приемлемый для всех.Мы уже решали аналогичную задачу в главе 8, применительно кметеорологической станции. Там мы создали иерархию классов датчиков иописали механизм их опроса. Есть все основания воспользоватьсяполученным ранее решением и в нашей нынешней задаче.Это хороший пример повторного использования проектных решении вразличных прикладных областях.12.3. ЭволюцияМодульная архитектураМы уже говорили о том, что модульность для больших системнеобходима, но не достаточна; для задач такого масштаба, как системауправления движением, нужно сосредоточиться на декомпозиции поподсистемам. На ранних стадиях эволюции мы должны разработатьмодульную архитектуру системы, представляющую физическую структуру еепрограммного обеспечения.Проектирование программного обеспечения для очень больших системдолжно начинаться до полного завершения проектирования аппаратныхсредств.
Написание программы занимает, как правило, даже больше времени,чем разработка аппаратуры. Кроме того, по ходу процесса функциональностьможет перераспределяться между аппаратной и программной частями.Поэтому зависимость от аппаратуры должна быть максимально изолирована,так, чтобы программные средства можно было начать проектировать безпривязки к аппаратуре. Это означает также, что разработка должнаосновываться на идее взаимозаменяемых подсистем. В системах управления иконтроля, таких, как система управления движением, нужно сохранитьвозможность задействовать новые аппаратные решения, которые могутпоявиться в процессе разработки программного обеспечения.На ранних этапах мы должны разумно провести декомпозициюпрограммного обеспечения, чтобы субподрядчики, ответственные заразличные части системы, могли работать одновременно (возможно дажеиспользуя различные языки программирования).
Как уже говорилось в главе 7,существует много причин нетехнического характера, определяющихфизическую декомпозицию больших систем. Наиболее важен вопросвзаимодействия различных групп разработчиков. Отношения междусубподрядчиками складываются обычно на достаточно ранних стадиях жизнисистемы, часто до получения информации, достаточной для выбораправильной декомпозиции системы.Желательно, чтобы системные архитекторы поэкспериментировали снесколькими альтернативными декомпозициями на подсистемы для того,чтобы быть уверенными в правильности глобального решения пофизическому проектированию.
Можно задействовать прототипирование вбольших масштабах с имитацией подсистем и моделированием загрузкипроцессора, маршрутизации сообщений и внешних событий.Прототипирование и моделирование могут послужить основой длянисходящего тестирования по мере создания системы.Как выбрать подходящую декомпозицию на подсистемы? В главе 4отмечено, что объекты на высоком уровне абстракции обычно группируются всоответствии с их функциональным повелением. Еще раз подчеркнем, что этоне противоречит объектной модели, так как термин функциональный мы несвязываем жестко с понятием алгоритма. Мы говорим о функциональностикак о внешнем видимом и тестируемом поведении, возникающем в результатесовместной деятельности объектов. Таким образом, абстракции высокогоуровня и механизмы, о которых говорилось ранее, хорошо подходят на рольподсистем.
Мы можем сначала допустить существование таких подсистем, аих интерфейс разработать через некоторое время.На диаграмме модулей на рис. 12-9 представлены проектные решенияверхнего уровня модульной архитектуры системы управления движением.Каждый уровень здесь соответствует выделенным ранее четырем подзадачам:сеть передачи данных, база данных, аналоговые устройства управления вреальном времени, интерфейс "человек/компьютер".Рис. 12-9. Диаграмма модулей верхнего уровня системы управлениядвижениемСпецификация подсистемЕсли мы рассмотрим внешнее представление любой из подсистем, тообнаружим, что она обладает всеми характеристиками объекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
