- •Последовательность проектирования асоиу.
- •Информационно-логическая модель
- •Модели описания и анализа потоков информации на основе графов
- •Распределение модулей и подсистем по процессорам и задачам.
- •Замена программ аппаратуры.
- •Распределение модулей и подсистем по процессорам.
- •Управление хранилищами данных.
- •Управление пограничными ситуациями
- •Распространённые архитектуры систем.
Распространённые архитектуры систем.
Рассмотрим несколько типов архитектур, обычно используемых в существующих системах. Эти типы ориентированы на определенные типы систем. В связи с этим проектируя систему определенного вида, имеет смысл обратить внимание на соответствующие архитектуры.
Первый тип систем это системы пакетной обработки. В таких системах обработка данных производится один раз для каждого набора входных данных. Согласно ГОСТ 15971-90 (системы обработки информации термины и определения) режим пакетной обработки (Batch processing) – это режим выполнения совокупности задач, при котором все они выполняются системой обработки информацией в основном автоматически без синхронизации с событиями вне этой системы обработки информации (СОИ) в частности без связи с лицами представившими задание на выполнение. То есть, пришел на сервер пакет данных и описание что с ним делать. При разработке систем пакетной обработки часто выполняют след шаги: 1) разбиваем полное преобразование информации на фазы, каждая из которых исполняет некоторую часть преобразования, система описывается диаграммой потока данных, которая строится при разработке функциональной или информационно логической модели. 2) Определяем классы промежуточных объектов между каждой парой последовательных фаз, при чем каждая фаза знает об объектах расположенных на объектной диаграмме до и после нее. Они представляют входные и выходные данные этой фазы. 3) Составляем объектную модель каждой фазы по тому же принципу. Разбиваем фазы на под фазы, пока не получим что то легко описываемое.
06-11-2012
При выборе или разработке алгоритма учитывают ряд факторов, в том числе:
Временная сложность алгоритма. Как правило ее рассматривают в худшем случае. Эта функция от размеров входных и выходных данных равная максимальному количеству элементарных операций проделываемых алгоритмом для решения экземпляра задачи указанного размера. Во многих задачах размер выходных данных не превышает или пропорционален размеру входных данных. По этому временную сложность рассматривают только на основе входных данных. Аналогично понятие временной сложности в худшем случае определяется понятием временной сложностью в лучшем случае. Так же рассматривают понятие среднее время работы алгоритма. Чтобы определить временную сложность приходиться вначале определить, что считается элементарной итерацией и построить зависимость числа элементарных итераций от размеров данных. В классической теории алгоритмов размер данных так же можно определять по-разному. В зависимости от используемой кодировки условия задачи. Поэтому нахождение точных значений временной сложности часто бывает практически не выполнимой задачей. Заметим, что при увеличении размера входных данных вклад составляющих низкого порядка в общую функцию сложности становится пренебрежимо малым. Поэтому чаще всего рассматривают порядок роста времени работы алгоритма в зависимости от роста размера входных данных. Для оценки сложности может использоваться рассмотрение не всех, а наиболее затратных или сложных операций, которые не попадают под понятие элементарных, но иногда важнее знать например не просто число шагов алгоритма а количество вычислений функций с плавающей точкой или операций пересылки данных между вычислительными устройствами. Порядок роста характеризуется асимптотической сложностью алгоритма. Порядок алгоритма это функция доминирующая над точным значением временной сложности. Функция f(n) имеет порядок O(g(n)) если существуют такие константы K и n0, что для любых n>n0 f(n) <=K*g(n). На ряду с оценкой О(g(n))выделяют также оценку Omega(g(n)) которая характеризует уже нижнюю асимптотическую границу. Если оценки О( ) и Omega( ) для некоторой функции совпадают то говорят об оценке Tetta( ). Она одновременно является и верхней и нижней границей. Рассмотрим особенности применения оценок алгоритмов. Сортировка выборов: порядок требуемого числа пересылок включая те, которые требуются для выбора минимального элемента в худшем случае составляет O(n^2), но порядок среднего числа пересылок O(n*ln(n)). Сортировка вставками в лучшем случае для выполнения алгоритма с массивом из n элементов требуется n-1 сравнение и ноль пересылок. Существует такая особенность применения оценок сложности алгоритмов, что меньший порядок алгоритма вовсе не означает его большую эффективность в конкретном случае. Это лишь показывает, что начиная с некоторого достаточно большого входных данных один алгоритм начинает уступать другому. Опять же порядок определяется с точностью до константы и реальная величина этой константы может оказать существенное влияние. Допустим одну задачу у нас решает 2 алгоритма первый имеет квадратическую сложность, второй линейную. Видим, что в данном примере линейный алгоритм лучше квадратичного только начиная с размера данных n’. Но задачи меньшего размера квадратичный алгоритм решает быстрее. В частности если вспомним быструю сортировку, то на этапе рекурсивной сортировки маленьких подмассивов она оказывается уже не такой эффективной в том числе из за затратной рекурсии. Поэтому часто используют комбинированные алгоритмы. Для сортировки достаточно крупных подмассивов используют быстрые сортировки а для маленьких более простые. Далее для оценки действует следующее правило: если последовательно исполнять 2 алгоритма, то соответственно их сложности суммируются. Однако итоговый порядок определяется никак сумма порядков, а как наибольший из порядков слагаемых. Поэтому всегда следует соотносить оценку порядка роста и планируемый размер входных данных. В частности, существует класс так называемых псевдо полиномиальных алгоритмов, которые проявляют свой экспоненциальный характер только при очень больших n.
По аналогии с временной сложностью определяют пространственную сложность алгоритма. Только здесь речь идет не о числе операций и времени выполнения, а о необходимом размере памяти. Необходимо оба аспекта сложности рассматривать согласованно. Поскольку можно написать быстродействующий алгоритм, требующий огромного объема памяти или же сложный алгоритм, справляющийся значительно меньшими объемами. Еще один аспект который сюда подходит это особенности кодирования условий задачи, решаемой алгоритмом. Вы можете написать быстрый алгоритм воспроизведения несжатого видео, который потребует количество оперативной памяти превышающее среднее для класса компьютеров. С другой стороны можно разработать способ кодирования видеоинформации и включить дополнительный алгоритм кодирования и декодирования для воспроизведения, уменьшив объем оперативной памяти и увеличив нагрузку на процессор. Здесь же мы можем потребовать чтобы весь видео поток полностью сохранялся соответственно как минимум теряем в объемах жесткого диска, а можем хранить непосредственно только воспроизводимый фрагмент.
Понятность алгоритма и легкость его реализации. Во-первых, с точки зрения технологии программирования нужно стремится к наиболее понятному и легко сопровождаемому коду. Иногда ради этого идут на небольшое уменьшение в эффективности. В частности используют рекурсию, которая облегчает описание и понимание алгоритма, но создает некоторые накладные расходы. Заметим в прочем, что далеко не всегда применение более простых и понятных вариантов алгоритма возможно. Например, в силу ограничений аппаратных устройств и языков программирования на поддержку рекурсии и элементов объектно-ориентированного программирования. В частности если писать под видео карты то с рекурсией могут возникнуть большие проблемы.
Сильно стыкуется с третьим. Гибкость. Большая часть программного обеспечения со временем подвергается модификации. Высоко эффективные алгоритмы как правило сложны для понимания и модификации. Существуют два основных пути. А) Составление алгоритмов по модульному принципу, когда можно заранее предугадать относительно каких типовых процедур или операций стоит ждать изменений; B) Готовить сразу два алгоритма первый алгоритм просто в реализации пусть и недостаточно эффективный, может использоваться в системе на первых порах пока происходит модификация и доводка сложного алгоритма. После того как он готов простая версия подменяется эффективной. Но уже имея простую версию мы получаем возможность комплексного тестирования или даже первоначального внедрения.
Алгоритмы не разрывно связаны с применяемыми структурами данных. Одну и ту же задачу можно решать по разному в зависимости от используемых массивов данных структур записей вариантов классов. В результате на первый взгляд невыполнимая задача при правильной организации информации может быть решена эффективно. Простой пример: Есть огромный массив данных может быть иерархически организованных(системный реестр) и требуется найти группы повторяющихся записей в нем. Простое сравнение по принципу каждый с каждым практически не выполнимо. Вместо этого эффективней по некоторым признакам выделять группы данных в пределах которых есть смысл проводить точное сравнение. Например по длине записей по типу хранящихся данных, по первому символу букве байту и уже затем, если только не худший случай что весь массив одинаковый, мы можем проводить сравнение в прямую. Разбиение на группы можно воспроизводить уже потом не за один шаг. Естественно такой алгоритм уже потребует новой структуры данных, которая будет содержать описание проверяемых групп. В частности тип признака сходства, значение признака сходства массив ссылок на элементы анализируемого массива(на записи анализируемого массива). Одним из способов упрощения и оптимизации алгоритмов является введение вспомогательных служебных классов, которые не имеют аналогов в реальном мире, но которые связаны с особенностями реализации и позволяют существенно ее упростить. Например классы связанные со списками стеками протоколами сокетом политиками безопасности и т.д. Во многих случаях бывает полезным внести некоторые изменения в структуру имеющейся модели. Эти изменения сводятся к введению новых дополнительных классов и перераспределению операций между классами.
Систему удобно строить так чтобы основной объем информации обрабатывался в непосредственной близости от источника. Закладывая проект распределенной системы следует учитывать возможность роста нагрузки на нее. При этом совершенно не допустипо для крупно масштабных систем пользоваться подходами, которые зарекомендовали себя в меньшем масштабе. Программная компонента при этом является .Достигается применением протокола двухфазной транзакции. Чтобы отвязать запрос от конкретной ссылки используется так называемые синонимы. Одного и того же иснонима.
Обработка распределенных запросов. Сложность в обработке распределенных запросов по сравнению с локальными обусловлена тем, что необходимо оптимизировать потоки запрашиваемой информации между локальными узлами. Например: две таблицы хрянятся каждяая на своем узле. В первой 10000 строк. Во второй 100. Допустим, выполняется запрос на объединение2 таблиц. Для его нормального выполнения необходимо чтобы 2 таблицы оказались на одном узле. Значит какую то из них нужно передать по сети. Естественно это должна быть таблица меньшего размера. Тем не менее остается открытым вопрос на какой конкретно узел поступил запрос от конечного пользователя.По идее если он обращался на узел где хроанится меньшая таблица то чтобы не пересылать результат запроса Объем данных передаваемых между узлами. По скольку эти полезные механизмы как правило реализуются через расширения языка SQL написанных специально для данного постовщика. Специальные подходы это как правило использование шлюзов. Что позволяет приложениям оперировать базами данных в чужом формате как будто это собственные базы данных. Как правило шлюзы применяются когда необходимо обеспечить взаимодействие вновь создаваемых и унаследованных баз данных. Таким образом шлюзы это в первую очередь средства облегчающие данных между базами разных поставщиков, но не в коем случае не универсальные средства обеспечения …
Фактически каким образом использовать базы данных от разных поставщиков в едином пространстве или вообще перейти к однородной среде решает в каждом конкретном случае проектировщик.
