Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 73

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 73)

Системы реального времени Систпема реального времени (геа1-Вше зузгеш) — это интерактивная система с жесткими временными ограничениями на время отклика. Системы реального времени бывают жесткими и гибкими. Жесткие — это жизненно важные приложения, требующие гарантированного отклика в заданное время. Гибкие системы реального времени тоже должны быть высоконадежными, но для них допустимо редкое нарушение ограничений. Типичные приложения реального времени — это управление процессами, считывание данных, коммуникационные устройства, управляющие устройства и реле перегрузки.

Проектирование систем реального времени — сложная задача, требуюшая решения таких подзадач, как обработка прерываний, распределение по приоритетам и координация работы множества процессоров. К сожалению, системы реального времени часто используются в режимах, близких к предельно допустимым, поэтому для достижения необходимой производительности приходится изменять проект системы. В результате теряется переносимость и удобство обслуживания системы.

Проектирование систем реального времени — это специальная тема, которую мгя в этой книге рассматривать не будем. 14.13. Архитектура сети банкоматов 311 14.12.6. Администратор транзакций Администратор транзакций (сгапзасйоп шапаяег) — это система, основное назначение которой состоит в хранении и выдаче данных. Большинство администраторов транзакций имеют пело с множеством пользователей, которые одновременно считывают и записывают данные. Администратор должен обеспечивать защиту данных от неавторизованного доступа и от случайных сбоев. Администраторы транзакций часто реализуются в виде надстройки над системой управления базами данных (СУБД).

СУБД предоставляет универсальную функциональность для управления данными, которая может бгять использована повторно. В качестве примеров администраторов транзакций можно привести системы бронирования авиабилетов, контроля инвентаря и выполнения заказов. В таких системах доминирует модель классов. Модель состояний бывает важной в отдельных случаях, в частности для описания эволюции объекта, а также ограничений и методов, применяющихся в разные моменты времени. Модель взаимодействия бывает существенной достаточно редко.

Администратор транзакций проектируется в следующей последовательности. 1. Преобразовать модель классов к структурам базы данных (подробнее см. главу 19). 2. Определить параллельные модули — такие, которые не могут использоваться совместно). При необходимости следует добавить новые классы. 3. Определить единицу транзакции — набор ресурсов, которые одновременно задействуются в одной транзакции.

Транзакция всегда выполняется целиком или не выполняется вовсе. 4. Выполнить проектирование параллельного управления транзакциями. Большинство СУБД решают эту задачу. Чаще всего системе следует сделать несколько попыток повторить транзакцию в случае ее отмены. 14.13. Архитектура сети банкоматов Сеть банкоматов — это гибрид интерактивного интерфейса с администратором транзакций.

Системы ввода транзакций — это интерактивные интерфейсы. Их назначение состоит во взаимодействии с человеком для ввода информации, необходимой для формулировки транзакции. Для описания этих систем нужно построить модели классов и состояний. Консорциум и банки представляют собой распределенную систему администрирования транзакций. Их назначение состоит в хранении данных и их обновлении по распределенной сети при определенных условиях.

Для описания этой подсистемы нужно построить ее модель классов. На рис. 14.2 показана архитектура системы банкоматов в целом. Постоянные хранилища данных расположены в компьютерах банков. База данных гарантирует, что данные будут непротиворечивыми, и обеспечивает параллельный доступ к этим данным. Банкомат обрабатывает каждую транзакцию как пакетный преобразователь; счет блокируется до тех пор, пока транзакция не будет завершена, 312 Глава И» Проектирование системы Параллельность возникает из-за наличия множества банкоматов, которые могут быть активны одновременно.

Один банкомат может осушествлять только одну транзакцию в какой-либо момент времени, но в каждой транзакции участвует компьютер консорциума и по крайней мере один банковский компьютер. Как показано на рис. 14.2, транзакция соединяет физические устройства. В процессе проектирования каждая часть становится отдельным классом реализации.

Компьютер консорциума или банка может одновременно обрабатывать несколько транзакций. Это не создает каких-либо новых проблем, так как база данных синхронизирует одновременный доступ к любому счету. Компьютеры консорциума и банков будут работать в режиме управления событиями. Каждый из них накапливает входные события в очереди и обрабатывает их по одному в порядке получения. Компьютер консорциума предоставляет минимально необходимую функциональность: он передает сообшения от банкоматов банковским компьютерам и от банковских компьютеров банкоматам. Этот компьютер должен быть достаточно мошным, чтобы обрабатывать все транзакции.

Допустимо в редких случаях блокировать транзакции (из-за перегрузки), отправляя пользователю соответствующее уведомление. Банковский компьютер — единственное устройство, которое должно выполнять нетривиальные процедуры, но и они главным образом сводятся к обновлению данных в базе. Единственная сложность может возникнуть из-за необходимости обработки ошибок.

Банковские компьютеры должны иметь достаточную мощность для обработки транзакций в прогнозируемом «худшем варианте», и их дисковое пространство должно быть достаточным для записи всех транзакций в журнал. Система должна поддерживать операции добавления и удаления банкоматов и банковских компьютеров. Каждый физический модуль должен предусматривать собственную защиту от отказа или отключения от сети. База данных обеспечивает защиту от потери данных. Однако следует предусмотреть возможность отказа во время транзакции: ни клиент, ни банк не должны при этом потерять деньги. Это может потребовать реализации сложного протокола подтверждения. В случае обрыва соединения банкомат должен выводить соответствующее сообщение. Банкомат должен обрабатывать и другие отказы, такие как полный расход наличных или бумаги для чеков.

В финансовых системах наивысший приоритет имеет безопасность транзакций. Если цельность транзакции попадает под малейшее сомнение, банкомат должен прервать ее и выдать пользователю соответствуюшее сообшение. 14.14. Резюме После проведения анализа приложения, но перед проектированием классов проектировшик системы должен выбрать базовый подход к решению задачи. Самая высокоуровневая стратегия построения системы называется архитектурой системы. На начальном этапе планирования новой системы необходимо оценить ее производительность. Вы должны иметь хотя бы приблизительное представление о том, что вам предстоит. Требования к производительности системы должны 14.14. Резюме 313 быть разумными, и вы должны быть уверены, что вас не ждут неприятные сюрпризы в процессе разработки.

Затем нужно подготовить план повторного использования. Повторное использование часто называют основным преимуществом объектно-ориентированной технологии, но оно не вытекает из одного только факта применения этой технологии. Есть два важных аспекта повторного использования. Большинство разработчиков должны беспокоиться об использовании существующих моделей, библиотек, каркасов и образцов, пригодных для их приложений. Элитные разработчики могут создавать артефакты, которые будут использоваться другими людьми. Система может быть разделена на горизонтальные слои и вертикальные разделы.

Каждый слой определяет свой абстрактный мир, который может полностью отличаться от других слоев. Каждый слой является клиентом по отношению к слою или слоям ниже его и сервером по отношению к вышележащему слою или слоям. Разделы отличаются друг от друга предоставляемыми сервисами. Применение простых топологий, таких как конвейер или звезда, позволяет уменьшить сложность системы.

Большинство систем представляют собой комбинации слоев и разделов. Объекты, которым присуща неотъемлемая параллельность, выполняются одновременно. Такие объекты нельзя объединять в один поток управления. Для их реализации нужно использовать разные аппаратные устройства или, по крайней мере, разные задачи на одном процессоре. Объекты, не являющиеся параллельными, можно объединять в один поток управления и выполнять в одной задаче. Количество процессоров и специализированных устройств должно быть таким, чтобы производительность системы отвечала предъявленным требованиям. Вы должны распределять объекты по аппаратным устройствам, чтобы использование этих устройств было сбалансированным, а выполнение объектов отвечало требованиям параллельности.

Для этого нужно оценить пропускную способность вычислительной подсистемы и предусмотреть поддержку очередей при настройке оборудования. Для ресурсоемких вычислений можно использовать специализированное оборудование. Одной из целей деления аппаратной сети на разделы является сокращение трафика между физически раздельными модулями.

Характеристики

Список файлов книги