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

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

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

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

Объектно-ориентированное проектирование — это не волшебная палочка, которая может решить все проблемы такого рода, однако оно помогает моделировать внешние пакеты. Вы должны учитывать вопросы совместимости, стоимости и производительности. Кроме того, нужно сделать систему гибкой в расчете на изменения в будущем (как проектные изменения, так и усовершенствования готового продукта).

Гибкость требует определенных затрат, и именно архитектор должен решать, сколько он готов на нее потратить. Пример с банкоматом. Проблем с производительностью в нашем приложении нет. Поэтому для банкоматов, консорциума и банков подойдут самые обычные компьютеры. 14.6.3. Распределение задач по процессорам Проект системы должен описывать распределение программных подсистем по процессорам. Существует несколько причин, по которым это распределение должно быть формализовано. ° Логистика.

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

Например, высокоскоростные графические устройства требуют установки собственных контроллеров, потому что они порождают большие объемы данных. ° Ограничения на вычислительные ресурсы. Если потребности в вычислительных ресурсах слишком велики, чтобы их мог удовлетворить один процессор, можно установить несколько процессоров. Затраты на взаимодействие можно сократить, назначив задачи, активно обменивающиеся данными, одному процессору.

Независимые подсистемы следует распределять по разным процессорам. 298 Глава 14 ° Проектирование системы Пример с банкоматом. Банкомат не предъявляет серьезных требований к вычислительным или коммуникационным ресурсам. Трафик и вычисления, порождаемые одним пользователем банкомата, относительно невелики. Однако требования логистики в этой задаче нужно учесть.

Если банкомат должен иметь возможность работать автономно в случае отказа сети, у него должен быть собственный процессор и программа. В противном случае, для беспроцессорного терминала, работающего с сетью и выполняющего все вычисления удаленно, логику банкомата можно будет упростить до предела. 14.6.4. Определение физической связности Определив виды и количество аппаратных устройств, вы должны описать их расположение и соединения между ними. ° Топология соединений.

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

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

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

Пример с банкоматом. На рис. 14.2 показаны физические соединения между подсистемами. Все банкоматы соединяются с центральным компьютером консорциума, который также соединен с компьютерами банков. Топология — звезда с компьютером консорциума в центре. 14.7. Управление хранилищами данных 299 14.7. Управление хранилищами данных Существует несколько способов хранения данных, которые могут использоваться независимо или совместно: структуры данных, файлы и базы данных. Разные варианты хранения обладают разными сочетаниями стоимости, времени доступа, емкости и надежности. Например, приложение на персональном компьютере может работать со структурами данных в памяти и с файлами. Система бухгалтерского учета может использовать базу данных для взаимодействия подсистем.

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

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

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

Ниже перечислены типы данных, которые лучше всего хранить в базах данных; ° данные, требующие детального обновления множеством пользователей; ° данные, с которыми должны работать несколько приложений; ° данные, требующие координированного обновления посредством транзакций; ° большие объемы данных, требующие эффективной обработки; ° данные, требующие длительного хранения и имеющие большую ценность для организации; ° данные, которые должны быть защищены от неавторизованного доступа и от злоумьппленников. 300 Глава И е Проектирование системы Объектно-ориентированные базы данных не смогли завоевать популярность на широком рынке. Поэтому их следует рассматривать только в том случае, если вы разрабатываете особое приложение, работающее с данными множества типов или требующее обращения к низкоуровневым примитивам для управления данными.

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

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

С другой стороны, реляционные базы данных достигли определенной зрелости, что сокрагцает затраты на разработку. 14.8. Распределение глобальных ресурсов Проектировщик системы должен указать глобальные ресурсы и определить механизмы управления доступом к ним. Глобальные ресурсы бывают нескольких видов: ° физические устройства: процессоры, ленточные накопители, а также спутники связи; ° пространство: дисковое пространство, экран рабочей станции, кнопки мыши; ° логические названия: идентификаторы объектов, имена файлов, названия классов; ° доступ к общим данным: базы данных. Если ресурс представляет собой физический объект, то он может самостоятельно контролировать доступ к себе при помощи протокола управления доступом.

Если же ресурс представляет собой логическую сущность, то возникает опасность конфликта доступа. Например, один и тот же идентификатор объекта может быть одновременно использован параллельными задачами. Избежать такого конфликта можно при помощи «охраняющего» объекта, которому будет принадлежать каждый глобальный ресурс и который будет управлять доступом к своему ресурсу. Один охраняющий объект может управлять несколькими общими ресурсами. Доступ к любому общему ресурсу возможен только через его охраняющий объект. Отнесение глобального ресурса к некоторому объекту — это признание индивидуальности ресурса.

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

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