Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 91
Текст из файла (страница 91)
Каждаяподсистема имеет уникальную, хотя и статичную, идентичность и большоечисло возможных состояний, а также демонстрирует очень сложноеповедение. Подсистемы используются как хранилища других классов, утилитклассов и объектов; таким образом, они лучше всего характеризуютсяэкспортируемыми ресурсами. На практике при использовании C++ этиресурсы представляются в форме каталогов, содержащих логически связанныемодули и вложенные подсистемы.Диаграмма модулей на рис. 12-9 полезна, но не полна, так как каждаяиз подсистем на ней слишком велика для реализации одним небольшимколлективом разработчиков. Мы должны раскрыть внутреннее представлениеподсистем верхнего уровня и провести их декомпозицию.Рассмотрим для примера подсистему NetworkFacilities (сеть).
Мырешили разбить ее на две другие подсистемы, одна из которых - закрытая(RadioCommunication (радиосвязь)), а другая - открытая (Messages(сообщения)). Закрытая подсистема скрывает детали своего программногоуправления физическими устройствами, в то время как открытая подсистемаобеспечивает поддержку спроектированного ранее механизма передачисообщений.Подсистема, названная Databases (базы данных), построена наоснове ресурсов подсистемы NetworkFacilities и служит для реализациимеханизма планов движения поезда, который мы описали выше. Мысоставляем эту подсистему из двух экспортируемых открытых подсистем,TrainPlanDatabase (база данных планов поездов) и TrackDatabase (базаданных путей). Для действий, общих для этих двух подсистем, мыпредусмотрим закрытую подсистему DatabaseManager (менеджер базданных).Подсистема Devices (устройства) также естественно разбивается нанесколько небольших подсистем.
Мы решили сгруппировать программы,относящиеся ко всем путевым устройствам, в одну подсистему, а программы,связанные с активными механизмами и датчиками локомотива, - в другую.Эти две подсистемы доступны клиентам подсистемы Devices, и обе онипостроены на основе ресурсов подсистем TrainPlanDatabase и Messages.Таким образом, мы спроектировали подсистему Devices для реализациимеханизма датчиков, который описан выше.Наконец, мы представляем подсистему верхнего уровняUserApplications (прикладные программы) в виде нескольких небольшихподсистем, включая EngineerApplications (программы для машиниста) иDispatcherApplications (программы для диспетчера), чтобызафиксировать разную роль двух главных пользователей системы управлениядвижением.
Подсистема EngineerApplications содержит ресурсы,которые обеспечивают взаимодействие машиниста и компьютера, в частности,анализ системы сбора и отображения информации о состоянии локомотива исистемы управления энергией. Подсистема DispatcherApplicatlonaобеспечивает интерфейс "диспетчер/компьютер". ПодсистемыEngineerApplications и DispatcherApplications разделяют общиезакрытые ресурсы, экспортируемые из подсистемы Displays (отображение),которая реализует описанный ранее механизм отображения.В результате проектирования мы получили четыре подсистемыверхнего уровня и десять подсистем следующего уровня, в которыхразмещены все введенные ранее ключевые абстракции и механизмы.
Важно,что в терминах этих подсистем можно планировать работу, управлятьконфигурациями и версиями. Как говорилось в главе 7, отвечать за каждуютакую подсистему может один человек, в то время как разрабатывать ее будетмножество программистов. Ответственный за подсистему детализирует еепроект и реализацию и управляет ее интерфейсом с другими подсистемами натом же уровне абстракции.
Так, за счет декомпозиции сложной задачи нанесколько более простых, становится возможным управление разработкойсложных проектов.В главе 7 уже демонстрировалась возможность несколькиходновременных представлений разрабатываемой системы. Наборсовместимых версий подсистем образует релиз, и таких релиэов может бытьмножество - по одному на каждого разработчика, еще один - длятестирования, один - для опробования пользователями и т.
д. Отдельныепроектировщики могут для своих нужд создавать собственные стабильныерелизы и интегрировать в них те части, за которые они отвечают, до передачиих остальным. Так создается механизм непрерывной интеграции нового кода.Основой успеха является тщательное конструирование интерфейсовподсистем. После того как интерфейсы определены, они должны тщательнооберегаться. Как мы определяем внешнее представление подсистемы? Нужнокаждую подсистему рассматривать как объект. Поэтому мы ставим те жевопросы, которые задавали в главе 4 для значительно более простых объектов:Какие состояния имеет объект? Какие действия над ним может выполнитьклиент? Каких действий он требует от других объектов?Например, рассмотрим подсистему TrainPlanDatabase.
Онастроится на основе трех других подсистем (Messages, TrainDatabase,TrackDatabase) и имеет нескольких важных клиентов - подсистемыWaysideDevices (путевые устройства), LocomotiveDevices (устройствана локомотиве), EngineerApplications и DispatcherApplications.Подсистема TrainPlanBatabase относительно проста - она содержит всепланы поездов. Конечно, хитрость в том, что эта подсистема должнаподдерживать механизм распределенной передачи планов движением поезда.Снаружи клиент видит монолитную базу данных, но изнутри мы знаем, что насамом деле база данных - распределенная, и поэтому должны основывать се намеханизме передачи сообщений подсистемы Messages.Какие действия можно выполнять с помощью TrainPlanDatabase?Все обычные для базы данных операции: добавление, удаление и изменениезаписей, запросы.
Так же как в главе 10, нужно зафиксировать все проектныерешения об этой подсистеме в форме классов C++, которые снабдят насобъявлениями операций.На этой стадии нам следует продолжить процесс проектирования длякаждой подсистемы. Еще раз отметим, что вероятность того, что всеинтерфейсы окажутся правильными с первого раза, очень мала. К счастью, каки для небольших объектов, опыт подсказывает, что большинство изменений,которые мы произведем в интерфейсах, не затронет верхних уровней(совместимость снизу вверх), если мы хорошо поработали, описывая каждуюподсистему в объектно-ориентированном стиле.12.4. СопровождениеДобавление новых функцийПрограммное обеспечение сопровождается и постояннодорабатывается, что особенно справедливо для таких больших систем, какнаша.
Действительно, до сих пор можно встретить программы, разработанныелет двадцать назад (просто патриархальные по компьютерным меркам). Чембольше пользователей применяет систему управления движением и чем лучшемы адаптируем проект к новым требованиям, тем чаще клиенты будутнаходить новые неожиданные применения для существующих механизмов,создавая потребность во включении в систему новых функций.Рассмотрим единственное добавление к нашим требованиям:обработку платежной ведомости. Предположим, анализ показал, что работа сплатежными ведомостями железнодорожной компании осуществляется сиспользованием аппаратуры, выпуск которой прекращен, поэтому возниксерьезный риск безвозвратной потери всей системы платежей в результатенескольких критических поломок. В этом случае можно объединитьобработку платежной ведомости с системой управления движением.
Дляначала надо понять, как эти две несвязанные задачи будут сосуществовать;можно рассматривать их как разные приложения, причем обработкаплатежной ведомости будет происходить в фоновом режиме.Дальнейший анализ показывает, что от интеграции обработкиплатежной ведомости может быть получена огромная польза. Вспомним, чтопланы поездов содержат информацию о распределении бригад.Следовательно, мы можем проанализировать запланированное идействительное распределение бригад, вычислить рабочее время,сверхурочные часы и т. п.
Получая эту информацию непосредственно, мыможем обрабатывать платежную ведомость дешевле и быстрее.Что добавление этой функции затрагивает в нашем проекте? Оченьнемногое. Новую подсистему можно добавить в подсистемуUserApplications. Оттуда новой подсистеме будут видны все важныемеханизмы, которые нужны для ее функционирования.
Признак хорошоспроектированной объектно-ориентированной системы: значительныедополнения к требованиям могут быть учтены довольно просто путемнадстройки новых функций над существующими механизмами.Предположим, мы хотим ввести более существенное изменение:добавить экспертную систему, помогающую диспетчеру при определениимаршрутов и реагирующую на чрезвычайные ситуации. Как это требованиеотразится на нашем проекте? Незначительно.
Мы можем разместить новуюподсистему между подсистемами TrainPlanDatabase иDispatcherApplications, так как база знаний, созданная для экспертнойсистемы, подобна по содержанию TrainPlanDatabase; кроме того,подсистема DispatcherApplications является единственным клиентомэкспертной системы. Нам предстоит разработать некоторый новый механизм,чтобы доводить рекомендации до конечного пользователя. Например, мыможем использовать метафору информационной доски, как это делалось вглаве 11.Изменение аппаратных средствМы уже говорили, что аппаратные средства развиваются быстрее, чемпрограммное обеспечение. Более того, всегда будут причины, вынуждающиенас выбрать в ходе проектирования такие аппаратные решения, о которыхпотом мы будем сожалеть.42 Поэтому рабочая аппаратура в больших системахустаревает гораздо раньше программы.
Например, после нескольких летэксплуатации мы можем заменить дисплеи на всех поездах и во всехдиспетчерских центрах. Как это может повлиять на существующий проект?Если во время разработки мы сохраняли интерфейсы подсистем па высокомуровне абстракции, это изменение аппаратуры приведет лишь кнезначительным изменениям в программе. Мы подправим толькосовокупность процедур, относящуюся к дисплеям, не затрагивая другиеподсистемы, которые вообще ничего не знают об особенностях конкретныхрабочих станций. Это достигается благодаря тому, что поведение всехрабочих станций скрыто в подсистеме Displays.
Таким образом, подсистемадействует как стена абстракций, которая защищает остальных клиентов отнаших трудностей, вызванных разнообразием дисплеев.Аналогично, радикальные изменения в стандартах телекоммуникациизатронут нашу реализацию в очень ограниченном отношении. Наш проектгарантирует, что только подсистема Massages связана с сетевымикоммуникациями. Таким образом, фундаментальные изменения в сети неотразятся ни на каком высокоуровневом клиенте; подсистема Messagesзащищает их от капризов сетевой моды.Итак, воображаемые изменения, которые мы вводили, не смоглиразрушить структуру созданного нами проекта.
Это - верный признак хорошоспроектированной объектно-ориентированной системы.Дополнительная литератураТребования к системе управления движением основываются наПродвинутой системе управления поездами (Advanced Train Control System),описанной Марфи (Murphy) [С 1988].Передача и проверка сообщений присутствует практически во всехсистемах управления и контроля. Плинта, Ли и Риссман (Plinta, Lee, andRissman) [С 1989] дали блестящее изложение этих вопросов и предложилимеханизм передачи сообщений по процессорам в распределенной системе,безопасный с точки зрения типов.Ибо книги лишь до некоторой степенирождаются в мозгах и печенках их авторов.Большая часть их приходит откуда-то еще,так что мы, авторы, просто сидим упишущих машинок, ожидая, когда книгаслучится.ГИ ЛЕФРАНСУА(GUYLEFRANCOIS)Дети (Of Children)ПослесловиеОбъектно-ориентированное проектирование - проверенная технология.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
