Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 89
Текст из файла (страница 89)
В реальной задаче преждевременный выбор низкоуровневогопредставления обязательно приведет к изменениям в дальнейшем и затронетвсех, кто пользовался этим представлением. Кроме того, на ранней стадиипроектирования у нас пока нет полной информации, как будут использоватьсяданные сообщения, и, следовательно, мы не можем судить, какоепредставление будет оптимальным по размеру и времени передачи.Концентрируя внимание на сути сообщений, мы рассмотрим всеклассы сообщений. Другими словами, нужно определить назначение и смыслкаждого сообщения, а также перечислить операции их обработки.На диаграмме классов на рис.
12-4 показаны некоторые наиболееважные сообщения в системе управления движением. Заметим, что всесообщения в конечном счете являются экземплярами абстрактного классаMessage, который инкап-Рис. 12-4. Диаграмма классов сообщенийсулирует поведение, общее для всех сообщений. Три класса следующегоуровня представляют главные категории сообщений: сообщение о состояниипоезда, сообщение о плане движения поезда, сообщение путевого устройства.Каждый из этих трех классов будет детализирован в дальнейшем. В результатепроектирования должны появиться десятки специализированных классов.Таким образом, существование обобщающих абстрактных классовчрезвычайно важно; без них мы получили бы сотни несвязанных между собойи, следовательно, сложных в использовании модулей, каждый из которыхреализовывал бы специализированный класс, По мере проектирования мыбудем выявлять другие важные группы сообщений и создавать для нихспециализированные промежуточные классы.
К счастью, изменения виерархии классов не должны волновать клиентов, использующих классы.Прежде всего нам следует стабилизировать интерфейсы ключевыхклассов сообщений. Начинать этот процесс лучше всего с основных классовиерархии. Начнем с введения двух следующих типов;//номер, обозначающий уникальный идентификатор пакетаtypedef unsigned int Packetid;//номер, обозначающий уникальный сетевой идентификаторtypedet unsigned Int NodeId;Теперь дадим определение абстрактного класса Message:class Message {public:Message () ;Message(NodeId sender);Message(const Message&);virtual `Message () ;virtual Message& operator=(const Message&);virtual Boolean operator==(const Message&);Boolean operator!=(const Message&);PacketId id() const;Time timeStamp() const;NodeId sender() const;virtual Boolean isIntact() const = 0;};Этот класс отвечает за установку уникального идентификаторасообщения, отметки времени, идентификатора отправителя, целостностьсообщения (а именно, класс проверяет, является ли оно синтаксически исемантически законным сообщением системы).
Последнее поведениепоказывает, что сообщение - это нечто большее, чем просто запись данных.Как обычно сообщения должны еще обеспечивать операции копирования,переименования и проверки на равенство.Когда наш проект будет содержать интерфейсы всех наиболее важныхсообщений. мы сможем написать программы, основанные на этих классах, длямоделирования создания и приема потоков сообщений. Такие программыможно использовать для тестирования различных частей системы.Диаграмма классов на рис.
12-4, бесспорно, неполна. На практике впервую очередь необходимо разрабатывать наиболее важные сообщения, а всеостальные добавлять по мере того, как будут обнаруживаться менее общиеформы взаимодей-Рис. 12-5. Передача сообщенийствия. Использование объектно-ориентированного проектированияпозволит нам последовательно добавлять эти сообщения без нарушениясуществующих частей системы, так как возможность изменений учтена ссамого начала.Если мы удовлетворены структурой классов, то можно начатьпроектирование самого механизма передачи сообщений.
Здесь возникают двеконкурирующих между собой цели: придумать механизм, который обеспечитнадежную доставку сообщении, но сделает это на достаточно высоком уровнеабстракции, так, чтобы клиенту не надо было заботиться о способе доставкисообщения. Такой механизм передачи сообщений позволит клиентамограничиться упрощенным представлением о процессе передачи.На рис. 12-5 показан результат проектирования механизма передачисообщений.
Как видно на диаграмме, чтобы послать сообщение, клиентсначала создает новое сообщение м, затем передает его диспетчеру своегоузла, который ставит сообщение в очередь для последующей отправки.Заметьте, что наш проект предусматривает для клиента возможностьожидания, если диспетчер узла не может осуществить отправку вовремя.Диспетчер получает сообщение как параметр и затем пользуется услугамиобъекта Transporter (передатчик), который обеспечивает необходимыйформат сообщения и его рассылку по сети.Мы сделали эту операцию асинхронной, чтобы клиент не ждал, покасообщение будет отправлено по радио, что требует времени для кодирования,декодирования и повторных передач из-за помех.
В конечном счете объектListener (слушатель) принимает сообщение, преобразует его в принятуюформу для диспетчера своего узла, который создает параллельное сообщениеи ставит его в очередь. Получатель может заблокировать начало очередисообщений, ожидая прихода следующего сообщения, которое передается какпараметр синхронной операции nextMessage.При проектировании диспетчера мы располагаем его на прикладномуровне сетевой модели ISO OSI [4]. Это позволит всем клиентам,передатчикам и приемникам работать на самом высоком уровне абстракции иобщаться друг с другом в терминах, специфических для данного приложения.Мы ожидаем, что окончательная реализация описанного механизмабудет, вероятно, несколько более сложной. Например, может потребоватьсяшифровать и дешифровать сообщение и использовать коды обнаружения иисправления ошибок, чтобы обеспечить надежную связь в условиях помех налиниях связи и возможных отказов оборудования.Планирование расписания поездовМы уже говорили, что концепция плана движения поезда являетсяцентральной для функционирования системы управления движением.
Каждыйпоезд имеет один активный план, а каждый план предназначен только одномупоезду. Он может содержать много различных приказов и точек на пути.Наш первый шаг состоит в точном определении того, из каких частейсостоит план поезда. Для этого мы должны перечислить всех потенциальныхклиентов плана и выявить способ его использования каждым из них.Например, некоторым клиентам может быть разрешено составлять планы,другим - корректировать планы, а остальные смогут только читать планы. Вэтом смысле план выступает как хранилище информации, связанной смаршрутом одного отдельного поезда и действиями во время движения.Примером таких действий может быть отцепление или подцепление вагонов.На рис. 12-6 приведены стратегические проектные решения,касающиеся структуры класса TrainPlan.
Как и в главе 10, мы используемдиаграмму классов, чтобы показать части, из которых состоит план движенияпоезда (подобно тому, как это делается на традиционных диаграммах"сущность-связь"). Мы видим, что каждый план содержит одну бригаду, номожет включать в себя много приказов и действий. Мы ожидаем, что этидействия будут упорядочены во времени и что с каждым действием связанатакая информация, как время, местоположение, скорость, ответственное лицо,приказы. Например, план может содержать следующие действия:ВремяПоложениеСкорость08001100Как указано40 миль/ч1300PuebloColoradoSpringsDenver1600PuebloКак указано40 киль/чОтветственное ПриказлицоНачальник депоПокинуть депоОтцепить 30вагоновОтцепить 20вагоновВернуться вдепоИз рис.
12-6 видно, что класс TrainPlan имеет один статическийобъект типа UniqueId, так называемое магическое число, однозначноидентифицирующее каждый экземпляр класса TrainPlan.Как это делалось для класса Mеssage и его подклассов, можно впервую очередь спроектировать наиболее важные элементы плана движенияпоезда; детали будут проясняться по мере того, как мы будем использоватьплан для разных клиентов.Одновременное наличие огромного числа активных и неактивныхпланов поездов возвращает нас к проблеме базы данных, о которой мы ужеговорили. Диаграмма классов на рис. 12-6 может служить наброскомлогической схемы этой базы данных.
При этом возникает следующий вопрос:где хранится план поезда?В совершенном мире, где нет помех или задержек при передаче и гденеограничены ресурсы компьютеров, лучше всего было бы разместить всепланы движения поездов в единой центральной базе данных. Такой подходобеспечивает существование единственного экземпляра каждого плана.Однако реальные условия делают это решение неэффективным: неизбежнызадержки при передаче, производительность процессоров ограничена. Такимобразом, скорость доступа к плану, которыйРис. 12-6. Диаграмма классов TrainPlan (план движения поезда)расположен в диспетчерском центре, с поезда, не будет отвечатьтребованиям реального времени.
Однако, с помощью программногообеспечения можно создать иллюзию централизованной базы данных. Нашерешение заключается в том, что планы поездов будут располагаться накомпьютерах диспетчерского центра, а копии этих планов будут по меренеобходимости распределяться по узлам сети. Для обеспеченияэффективности компьютер каждого поезда может хранить копию своегоплана. Таким образом, бортовое программное обеспечение может получитьнужные сведения с пренебрежимо малой задержкой. Если план изменяется врезультате действий диспетчера или (что менее вероятно) по решениюмашиниста, наше программное обеспечение должно гарантировать, что всекопии этого плана обновятся, причем за разумное время.На рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
