Облачные вычисления (cloud computing) являются технологией, которая обеспечивает распределенную обработку данных

2. ОБЗОР ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ	
2.1 Обзор основной терминологии, связанной с облачными сервисами.
Рассмотрим такое понятие как облачные технологии (cloud technologies).  
Облачные вычисления (cloud computing) являются технологией, которая обеспечивает распределенную обработку данных, когда ресурсы и мощности компьютера предоставляются пользователю в виде интернет-сервиса.
Одним из простейших примеров облачных вычислений является электронная почта (e-mail) или сервис онлайн обработки данных (изображения, документы).
Также облачные технологии можно описать как разнообразные средства аппаратного и программного типа, различные методы и инструменты, предоставляющиеся пользователю для того, чтобы он смог реализовать свои цели, задачи, проекты [1].
Структуру облачных технологий можно представить в виде схемы: 


Рисунок 2.1 – Структура облачных технологий.
Лежащая в основе пирамиды инфраструктура представляет собой комплект устройств физического характера (к примеру, серверы, жесткие диски).
Выше, над инфраструктурой, находится платформа, которая и является набором услуг.
На верхушке лежит ПО – программное обеспечение, доступное пользователю по его запросу [2].
Если рассматривать облачные вычисления как некоторый базис-вектор, который был получен в результате синтеза различных технологий и подходов, то получается примерно следующая схема:

Рисунок 2.2 – Схема облачных технологий в виде базис - вектора
На данный момент концепция облачных технологий предлагает своим пользователям оказание услуг следующих типов:
       Storage-as-a-Service («хранениекаксервис»). Один из самых простых сервисов облачных вычислений. По требованию, пользователю предоставляется определенное дисковое пространство. На РС данная услуга представляется в виде дополнительного логического диска или папки.
       Database-as-a-Service («база данных как сервис»). Данный сервис ориентирован на системных администраторов. Дает возможность использовать базы данных так, будто СУБД установлена на локальном компьютере. Это упрощает распространение проектов между пользователями и позволяет сэкономить на физических ресурсах и лицензиях.
       Information-as-a-Service («информация как сервис»). Дает удаленный доступ к различной информации. Важным преимуществом данного сервиса является то, что информация может меняться постоянно, а пользователь в любом случае будет всегда получать актуальную.
       Process-as-a-Service («управление процессом как сервис»). Является удаленным ресурсом, который дает возможность объединять различные данные для создания одного бизнес-процесса.
       Application-as-a-Service («приложение как сервис»). Так же может называться Software-as-a-Service(«программное обеспечение как сервис»). Данный сервис представлен в виде программного обеспечения, которое находится на удаленных серверах. При наличии доступа в Интернет любой пользователь может получить доступ к данному ПО. Большим полюсом услуги этого вида является то, что все обновления происходят на серверах, что избавляет самих пользователей от многих проблем. При этом оплата производится только за пользование сервисом. Примером такой услуги служат GoogleDocs и GoogleCalendar и другие подобные онлайн - программы.
       Platform-as-a-Service («платформа как сервис»). При использовании данного сервиса пользователю предоставляется определенная компьютерная платформа, на которой уже установлена определенная операционная система и необходимое пользователю программное обеспечение.
       Integration-as-a-Service («интеграция как сервис»). Дает возможность получать из «облака» полный интеграционный пакет. Сюда входят программные интерфейсы приложений, а также возможность управления алгоритмами их работы. В этот сервис включены многие услуги и функции различных пакетов централизации, оптимизации и интеграции корпоративных приложений, однако они предоставляются как «облачные вычисления».
       Security-as-a-Service («безопасность как сервис»). При использовании данной услуги предоставляется возможность быстро развернуть продукты, которые позволяют обезопасить использование различных веб-технологий, электронной переписки, локальной сети и т.д. Это дает возможность пользователям данного сервиса экономить ресурсы на развертывании и поддержке собственной системы безопасности.
       Management\Governace-as-a-Service(«администрирование и управление как сервис»). Основной функцией представленного сервиса является возможность управлять и задавать параметры работы одного или нескольких облачных сервисов. Как пример таких параметров, можно привести топологию, виртуализацию и управление ресурсами.
       Infrastructure-as-a-Service («инфраструктура как сервис»). Напоминает услугу platform-as-a-Service («платформа как сервис»), однако в данном случае пользователю предоставляется в пользование целая компьютерная инфраструктура, обычно представленная в виде связанных в сеть виртуальных платформ. В этом случае пользователь сам настраивает эту инфраструктуру под собственные нужды. 
       Testing-as-a-Service («тестирование как сервис»). Не требуя никакого оборудования или программного обеспечения на предприятии, предоставляется возможность производить тестирование локальных или «облачных» систем с использованием тестового программного обеспечения на виртуальных серверах [3].
Различают три категории облачных технологий по форме собственности:
       Публичные.
       Частные.
       Гибридные.
Публичное облако. Представляет собой ИТ-инфраструктуру, которая может быть использована одновременно множеством компаний и сервисов. При этом, пользователи не могут управлять или обслуживать «облако» данного типа, и вся ответственность за это лежит на владельце ресурса. Абонентом публичного облака может стать любая компания или индивидуальный предприниматель. В качестве примеров можно привести такие онлайн-сервисы как AmazonEC2, GoogleApp, GoogleDocs, MicrosoftOfficeWeb и т.д.
Частное облако. Это безопасная ИТ-инфраструктура, которая контролируется и используется только одной организацией. Управление частным облаком компания может оставить за собой, или поручить это внешнему подрядчику. Данная ИТ-инфраструктура может располагаться как в помещениях у организации, так и на территории внешнего оператора (или частично у компании и частично у оператора).
Гибридное облако. Данная ИТ-инфраструктура объединяет лучшие качества как публичного, так и приватного облаков для решения поставленной абонентом задачи. По большей части, такой тип облака используется организациями, которые имеют сезонные периоды активности. То есть, когда внутренняя ИТ-инфраструктура (частное облако) не справляется с большим объемом поставленных текущих задач, часть из них переходит на внешнюю ИТ-инфраструктуру (публичное облако). Также может использоваться для предоставления доступа пользователям ресурсов компании через публичное облако.
Основные возможности облачных вычислений:
       Возможность получения доступа к личной информации с любого устройства при наличии выхода в сеть Интернет.
       Независимость от операционной системы, установленной на устройстве пользователя.
       Несколько пользователей могут одновременно просматривать и изменять одну и ту же информацию (например, редактировать документ) с различных устройств.
       Информация, которая находится в «облаке», не привязана физически к устройствам пользователя. 
       Постоянная доступность свежей и обновленной информации при наличии доступа к сети Интернет. 
       Возможность объединять, распространять и корректировать информацию совместно с другими пользователями.
        Масштабируемость или гибкость.
Основные недостатки при использовании облачных вычислений:
       Необходимость в непрерывном соединении. 
       Программное обеспечение и его узконаправленность. 
       Конфиденциальность. Несмотря на то, что облачные технологии являются достаточно защищенным продуктом, постоянно находятся все новые способы обойти это защиту. 
       Безопасность. При проникновении в «облако» злоумышленник получает доступ к огромному хранилищу данных. Так же не исключается проникновение вирусных систем на виртуальных серверах.
       Дороговизна оборудования. 
2.2 Обзор существующих решений на рынке облачных сервисов
Рассмотрим основные решения, сервисы и программы, существующие на данный момент на рынке.
Сервисы:
       ICloud. Данный облачный сервис от компании Apple является полностью автоматическим и бесплатным, однако имеет ряд функциональных ограничений. Он позволяет сохранять различную информацию пользователей (календарь, почта, контакты, медиа-файлы) на серверах и в дальнейшем предоставляет к ним доступ на других устройствах посредством беспроводной технологии Push.
Рассмотрим немного подробнее схему работы технологии Push.
В начале разработчик (в конкретном случае поставщик услуги) регистрирует свое сервер на сервере уведомлений ОС. После этого, посредством объединения уникального IDприложения и уникального номера устройства образуется идентификатор пользователя, который отправляется на сервер владельца приложения. В дальнейшем пользователь обменивается данными с сервером приложения посредством этого идентификатора.
       GooglePlay. Относительно новый сервис, созданный для хранения данных (в основном мультимедийных) на серверах, созданных для хранения цифровой информации. Основным преимуществом данного сервиса является кроссплатформенность, то есть доступность с любого браузера, независимо от операционной системы, установленной на устройстве.
       OnLive. Игровой сервис. Сама игра находится на сервере, где также происходит обработка графики. То есть те процессы, которые на локальной машине обычно обрабатываются процессором и видеокартой, выполняются на серверах поставщика услуги, а устройство пользователя в конечном итоге служит лишь как монитор для передачи изображения. Такая концепция услуги позволяет пользователю экономить как вычислительные, так и финансовые ресурсы.
       XboxLive. Создан для обладателей игровых приставок Xbox 360, и представляет собой, по сути, мультимедийный плеер. 
На данный момент одной из самых востребованных услуг является «программное обеспечение как сервис» (SaaS). Концепция данной платформы уже была рассмотрена выше, поэтому рассмотрим наиболее известные решения.
       GoogleDocs(на данный момент называется GoogleДиск). Это бесплатный онлайн-офис, включающий в себя текстовый и табличный редакторы, платформу для создания презентаций и работы с ними, а также сервис для облачного хранения файлов с функцией файлообмена. Данное программное обеспечение является веб-ориентированным, что позволяет пользователям получать доступ к своим файлам через любой браузер.
       MicrosoftOfficeWebApps. Представляет собой альтернативу GoogleDocs. 
Оба сервиса тесно связаны с электронной почтой и файловыми хранилищами. 
Наиболее известными файловыми хранилищами являются:
       Dropbox. При помощи данного сервиса пользователь получает возможность создать общую папку с файлами, объединяя информацию с различных устройств. Очень важной особенностью данного сервиса является наличие истории загрузок, так что даже после удаления файла, остается возможность его восстановить.
       WindowsLiveSkyDrive. Имеет функцию быстрой загрузки изображений и предпросмотра. 
       GoogleDisk. Наиболее распространенное облачное хранилище.
С недавнего времени средства антивирусной защиты также стали использовать облачные технологии. Рассмотрим самый известный на данный момент антивирус.
PandaCloudAntivirus.Является бесплатным антивирусом и позволяет минимизировать влияние антивирусной защиты на ресурсы компьютера. Все основные операции (такие как анализ, удаление зараженных файлов, блокировка и т.д.) производятся за счет вычислительных ресурсов облачных технологий [2]. 
2.3 Обзор особенностей систем мониторинга инфраструктуры хранения
Мониторинг дает возможность провести анализ статуса и использования разных компонентов инфраструктуры хранения. Данный анализ позволяет оптимизировать использование ресурсов. Также процесс мониторинга включает в себя контроль среды инфраструктуры хранения и операционной среды основных компонентов, таких как массивы хранения данных и серверы.
Основными параметрами для мониторинга компонентов инфраструктуры хранения являются:
       Доступность.
       Емкость.
       Производительность.
       Безопасность.
Доступность. Данный термин означает досягаемость компонента для выполнения требуемой операции. Компонент называется доступным, если в любой момент времени он функционирует правильно и без сбоев. 
Емкость. Емкостью называют суммарность доступных ресурсов инфраструктуры хранения. Простым примером мониторинга емкости может служить проверка свободного пространства в файловой системе, доступного пользователю места на почтовом ящике или наличие свободных портов на коммутаторе. При недостаточной емкости в инфраструктуре хранения может произойти ухудшение эффективности, или даже могут возникнуть проблемы с доступом к самому приложению[4].
Производительность. Мониторинг производительности позволяет оценить эффективность различных элементов инфраструктуры хранения. Примером мониторинга производительности может служить отслеживание времени отклика сети.
Безопасность. Данный параметр помогает выявить и отследить возможные сбои в работе системы, и предотвратить неразрешенный доступ, как случайный, так и умышленный.
Рассмотрим главные компоненты, которые следует проверять на доступность, емкость, производительность и безопасность:
 Хосты.
 Сети хранения данных.
 Хранения данных.
Хост. Пользователи хранят и извлекают свои данные посредством приложений. Устройства, на которых запускают эти приложения, и называют хостами. Хостом может быть как обычный компьютер, так и группа серверов. 
Сеть хранения данных нуждается в постоянном мониторинге для обеспечения необходимой связи сервера с массивом хранения. 
Хранение данных. Устройство хранения – очень важный компонент в среде хранения данных. Сбой в процессе обработки данных может привести к остановке или нарушению операции непрерывного бизнеса [5]. 

2.4 Обзор существующих решений в области облачных решений
В работе П.А.Михайлова и Г.И.Радченко «Методы моделирования и оценки производительности облачных систем» предлагается собственное решение для симуляции алгоритмов планирования в частных облачных платформах на основе системы CloudSim.
Тестирование разработанной модели показало, что модель корректна и пригодна для дальнейшей разработки. 
В дальнейшем данную статью можно использовать при разработке исследуемой в данной работе модели.
В исследованиях Коновалова А.Л. «Моделирование облачных технологий в вычислительных системах» предложена модель облачной системы, учитывающая наличие нескольких вычислительных кластеров с выделенными ресурсами, подключенных к центральному диспетчеру. Данная модель реализована с помощью симулятора дискретных событий NS-3, для которого выбраны модули, поддерживающие протоколы TCP/IP и BGP/OSPF, сеть CSMA/CD, эмуляцию хоста и простую схему маршрутизации. С его помощью проведены симуляции, которые для типичных наборов задач показали необходимость явного учета планировщиком облачной системы сети и передаваемых данных между вычислительными задачами.
В.А. Карбовский в своей работе «Интеллектуальная система активного мониторинга ресурсов облачной среды» рассматривает особенности применения интеллектуальных технологий предметно-ориентированного тестирования корректности выполнения пакетов, а также работоспособности ресурсов публичных сред облачных вычислений на основе платформы CLAVIRE.
В статье Гудковой И.А. и Масловской Н.Д. «Вероятностная модель для анализа задержки доступа к инфраструктуре облачных вычислений с системой мониторинга» рассматривается модель доступа к облачной инфраструктуре с системой мониторинга. Так же построен рекуррентный алгоритм расчета стационарного распределения вероятностей, который в дальнейшем будет реализован при построении проектируемой модели.
В исследованиях студента Севастопольского государственного университета Сапрыкина И.И. рассматривается моделирование облачных акторов при реализации сервисов Platform-as-a-Service.
Автор проектирует лишь один вид модели предоставления облачных услуг.  Рассмотрев необходимые характеристики моделируемых акторов системы, он строит модель с использованием дискретно-событийного подхода, который используется при представлении динамики системы как последовательности (прибытие, задержка, захват ресурса, разделение, и т.д.) над определенными сущностями (в данном случае это заявки, исходящие от облачных потребителей)[6].
Однако данная модель имеет ряд недостатков, основными из которых является неточность, малое число исследуемых характеристик и отсутствие модуля визуализации результирующих данных.
Вывод. Не смотря на широкое распространение облачных вычислений, построение модели мониторинга состояния облачной инфраструктуры все еще остается актуальным вопросом.

 СТРУКТУРНОЕ МОДЕЛИРОВАНИЕ
Методология SADT (Structured Analysisand Design Technique –структурный анализ и проектирование) является совокупностью различных метолов, процедур или правил, предназначенных для создания функциональной модели рассматриваемой системы. Функциональная модель отображает в себе структуру, действия системы и связи между ними.
Основой данного структурного подхода при разработке различных систем является разбиение (декомпозиция) разрабатываемой системы на отдельные автоматизируемые функции. Эти функции также делятся на подфункции и так далее. Этот процесс декомпозиции повторяется до того момента, пока не определятся конкретные процедуры. Во время этого процесса изначальная система не теряет своей целостности и все ее компоненты взаимосвязаны.
При использовании методологии IDEF0 преследуется цель построения функциональной схемы рассматриваемой системы, которая описывает все требуемые процессы с той точностью, которая необходима для качественного моделирования функционирования этой системы.


Структурная модель приложения.
Рассматривается модель мониторинга состояния облачной инфраструктуры.

Рисунок 3.1 – Контекстная диаграмма предметной области
Целью построения приведенной выше модели является описание концепции взаимодействия элементов облачной инфраструктуры для построения имитационной модели.
Входные данные:
– Входной поток заявок;
– Параметры облачной инфраструктуры.
Выходные данные:
–  Параметры качества IT-сервисов;
– Статистика обработки заявок в системе.
Ресурсы, необходимые для выполнения работы:
– Среда моделирования;
– ЛПР.
Управляющие данные:
– Регламенты работы облачной инфраструктуры;
– Случайные внешние воздействия.


Рисунок 3.2 – Результат декомпозиции контекстной диаграммы А0

Рассмотрим подробнее некоторые блоки представленной выше схемы. 
Виртуальные машины создают уровень абстракции между операционной системой и базовыми аппаратными устройствами. На одном физическом сервере может быть установлено любое количество виртуальных серверов, в зависимости от возможностей аппаратных устройств. Каждый виртуальный сервер воспринимается операционной системой как физическая машина. Индивидуальные виртуальные серверы могут перезапускаться, обновляться или выходить из строя, не влияя при этом на работу других виртуальных серверов той же физической машины.
Frontend. Основной задачей является обеспечение связи между виртуальными машинами и брокером. Frontend составляют два компонента: внешние порты и внешние контроллеры.
Внешние порты.  Создают подключение виртуальных машин к брокеру. Для каждого такого подключения во внешнем порте находятся алгоритмы обработки соответствующего транспортного протокола.
Внешние контроллеры. По внутренней шине данных они направляют информацию на брокер и обратно. Благодаря использованию очереди команд, контроллеры производят оптимизацию обработки ввода/вывода.
Backend. Обеспечивает интерфейс между брокером и системой мониторинга. Аналогично frontend состоит из внутренних портов и внутренних контроллеров. 
Брокер. Является сущностью, которая управляет использование, производительность и предоставление облачных услуг, а также устанавливающая отношения между облачными провайдерами и облачными потребителями.
Вывод. В данном разделе построена структурная модель разрабатываемой системы и проведен обзор основных блоков модели.


 СИСТЕМНЫЙ АНАЛИЗ ОБЪЕКТА ПРОЕКТИРОВАНИЯ

      На данный момент при анализе и синтезе сложных программных систем всё чаще используется системный подход. Важным для системного подхода является определение структуры системы – совокупности связей между элементами системы, отражающих их взаимодействие. Совокупность элементов и связей между ними позволяет судить о структуре системы.
      Принципы системного анализа – это некоторые положения общего характера, являющиеся обобщением опыта работы человека со сложными системами. Общепринятых формулировок на настоящее время нет, но все формулировки, так или иначе, описывают одни и те же понятия.
      Наиболее часто, к основным причисляют следующие принципы системного анализа: принцип конечной цели, принцип измерения, принцип единства, принцип связности, принцип модульности, принцип иерархии, принцип функциональности, принцип развития, принцип сочетания централизации и децентрализации, принцип учета неопределенности и случайностей. Пренебрежение этими принципами при проектировании любой нетривиальной технической системы, в том числе и программной, непременно приводит к потерям того или иного характера, от увеличения затрат в процессе проектирования до снижения качества и эффективности конечного продукта.
      Выполним более детальную разработку модели системы, используя основные принципы системного анализа.

      4.1Принцип конечной цели
Основой этого принципа, которому в итоге должна быть подчинена система, является достижение конечной цели. Так, применительно к заданной задаче, цель определяется как конечная модель тракта передачи данных, которую необходимо смоделировать, и вывод в графический интерфейс результатов работы данной модели, используя ограниченные ресурсы (к примеру данные о количестве и состоянии каналов передачи данных). Без ясного понимания цели любое решение может оказаться бессмысленным. Принцип конечной цели включает несколько правил:
       для проведения системного анализа требуется вначале сформулировать цель исследования; расплывчатые, не полностью определённые цели влекут за собой неверные выводы;
       первоначально нужно определить конечную цель, на основе которой и будет проводиться системный анализ, что позволит определить основные существенные свойства исследования, показатели качества и критерии оценки;
       любые изменения, вносимые в систему (например синтез систем или изменение состояния каналов передачи данных), должны оцениваться относительно того, помогают или мешают они достижению конечной цели;
       конечная цель разрабатываемой системы обычно задается системой, для которой разрабатываемая система является подсистемой; для данной задачи надсистемой модели тракта передачи данных является модель информационной сети, а точнее - локальная сеть передачи сообщений.
Входными данными будут являться:
– Входной поток заявок;
– Параметры облачной инфраструктуры.
Внутреннее состояние системы представляет собой характеристики  и возможности данного ПК.
 Выходными данными в этом случае будут являться: 
–  Параметры качества IT-сервисов;
– Статистика обработки заявок в системе.
Таким образом, результатом применения принципа конечной цели является получение набора статистики об основных показателях качества функционирования облачных вычислений.

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

      4.3Принцип связности
Рассматривая любую часть разрабатываемой системы совместно с ее окружением означает так же выявление связей между элементами системы и с внешней средой. Следуя этому принципу, систему первоначально следует рассматривать как часть (подсистему) большей системы, называемой суперсистемой или старшей системой.
Совокупность подсистем проектируемой программной системы и их связей – данными, которыми эти подсистемы обмениваются друг с другом  и с внешней  средой - образует её структуру.
В нашем случае разрабатываемая система – это модель мониторинга состояний, которая является подсистемой модели облачных вычислений. В свою очередь модель мониторинга состояний облачных вычислений также состоит из нескольких подсистем, перечисленных в пункте 4.2. 

      4.4  Принцип модульности
Модульность – очень важный аспект всех отлажено работающих больших систем.
Для того чтобы справиться со сложностью любой задачи, ее разбивают на более простые подзадачи, совокупность решений которых является решением сложной задачи. На данный момент для разработки сложных программных систем наиболее широко используется объектно-ориентированный подход к программированию (ООП).
 Объектно-ориентированный подход основан на систематическом использовании моделей для языково-независимой разработки программной системы. 
В проектируемой системе  целесообразно  выделить следующие модули:
– модуль генерации входных данных;
– модуль обработки и распределения  данных;
– модуль сбора статистики;
– модуль вывода результатов обработки данных в графический интерфейс.
Выходные данные одного модуля являются входными данными другого модуля. Благодаря такому подходу решение задачи проектирования значительно упрощается, однако целостность структуры не нарушается. 

      4.5 Принцип иерархии
Если  рассматривать принцип иерархии относительно процесса разработки программных систем, то он реализуется двумя основными свойствами ООП: наследованием и полиморфизмом.
Наследование – это возможность создания иерархии классов, когда потомки наследуют все свойства своих предков, могут их изменять и добавлять новые.
Полиморфизм – возможность использовать в различных классах иерархии одно имя для обозначения сходных по смыслу действий и гибко выбирать требуемое действие во время выполнения программы.
Результатом применения принципа иерархии являются иерархии классов.
В проектируемой системе можно выделить две иерархии объектов:
– объекты, предназначенные для формирования запросов от интерфейсной части к программной части и разбора ответов на них;
– объекты, предназначенные для обработки поступивших запросов от интерфейсной части в программной части и формирования ответов на них.  

4.6 Принцип функциональности
Функции системы в целом рассмотрены в связи с принципом конечной цели. Рассмотрим функции подсистемы: 
1) Подсистема, обеспечивающая генерации входных данных по заданным законам распределения. Функцией данной подсистемы является моделирование генерации чисел для определения входных данных. В частности, для объявления информации о потоке входящих заявок.
2)Подсистема обработки и распределения  данных. Функцией данной подсистемы является обработка заявок и распределение их или на следующую подсистему, либо в конец очереди. 
3)Подсистема сбора статистики. Функцией подсистемы является сбор и обработка статистики состояний системы. 
4)Подсистема определения базового события. Функция считывания информации о состоянии очередного канала передачи данных и определение дальнейших действий.
5) Подсистема вывода результатов обработки данных в графический интерфейс. Функцией данной подсистемы является вывод полученной статистики в графический интерфейс. В данном случае построение графиков.
4.7  Принцип развития
Этот  принцип предполагает учет  изменяемости  системы,  ее  способности  к развитию, адаптации, расширению, замене частей, накапливанию информации. В основу синтезируемой системы требуется закладывать возможность развития, наращивания и  усовершенствования.
Проектируемая система может быть расширена за счёт добавления новых алгоритмов решаемых задач, за счёт введения функций оценки пространственной эффективности алгоритма.
 Так же система может расширяться помощью синтеза с другими подсистемами своей суперсистемы. 

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

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

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



 МЕТОД АНАЛИЗА ИЕРАРХИЙ
При создании модели мониторинга состояний облачной инфраструктуры возникает необходимость выбора среды имитационного моделирования. В результате отбора было выбрано 5 альтернатив:
     А1: Simplex3;
     A2: Simulink Matlab;
     A3: Repast;
     A4: NS2;
     A5: Anylogic.
В качестве критериев выбора отобраны следующие пункты:
 К1: Стоимость;
 К2: Масштабируемость;
 К3: Поддержка кода моделирования;
 К4: Документация;
 К5: Гибкость.
     Иерархию выбора требуется представить в виде следующей структуры:
     
     Рисунок 1. – Структура иерархии
     Целью, то есть первый уровень иерархии в данной задаче является оптимальный выбор среды моделирования из множества альтернатив: А1, А2, А3, А4, А5.
     Определим второй уровень иерархии – критерии выбора. Выберем 5 критериев и проиндексируем их:
К1: Стоимость;
К2: Масштабируемость;
К3: Поддержка кода моделирования;
К4: Документация;
К5: Гибкость.
     Под критериями понимается:
     К1: Стоимость – система моделирования может быть чьей-то собственностью, бесплатным ПО или быть свободно распространяемым ПО с открытым исходным кодом;
     К2: Масштабируемость: низкая - n?10;средняя - n?100; хорошая – n>100; превосходная – n>1000, где n – число устройств в сети.
     К3: Поддержка кода моделирования – возможность использовать язык программирования или некоторый формальный язык для описания моделей, где последние представляются в конечном итоге в виде исходного кода;
     К4: Документация – наличие доступного руководства и обучающей литературы;
     К5: Гибкость – возможность воспроизведения различных ситуаций во всем диапазоне изменения условий и параметров.
     На втором этапе МАИ расставим приоритеты критериев в квадратную матрицу парных сравнений второго уровня, которая представляет собой квадратную матрицу размерностью nxn, где n - количество критериев. На пересечении критериев находится величина определяющая отношение пересекаемых критериев. Матрица имеет свойство обратной симметричности: a_ij=1/a_ij, где i – номер строки, j – номер столбца,  i,j = (1,n) ?. 
     Матрицу заполним по таблице 1 и по принципу отношения строки к столбцу, то есть если в ячейке матрицы на пересечении критериев стоит значение больше единицы, это значит что критерий по строке предпочтительнее критерия по столбцу.

Таблица 5.1– Шкала относительной важности

     В результате построения квадратной матрицы парных сравнений второго уровня получим:
     К=?(К_i\К_j&?(К_1&К_2&К_3&К_4&К_5 )@?(К_1@К_2@К_3@К_4@К_5 )&|?(1&2&3&4&1@1/2 &1&2&3&1@1/3&1/2&1&2&1/5@1/4&1/3&1/2&1&1/7@1&1&5&7&1)| )
     Значение компонент вектора локальных приоритетов рассчитывается по формуле
                                                                           x_i=b_i/B,                                                            (5.1)
     где b_i=?(n&?_(j=1)^n?a_ij )–геометрическое среднее в каждой строке матрицы А;
     B=?_(i=1)^n?b_i  – сумма b_i.
     При этом справедливо равенство
                                                       ?_( i=1)^n??x_i=1,                                                                            (5.2)?
     где n – число критериев.
     Рассчитаем значения вектора локальных приоритетов по формуле 5.1.
b_1=?(5&a_1,1?a_1,2?a_1,3?a_1,4?a_1,5 )=?(5&1?2?3?4?1)=?(5&24)=1,8882;
     b_2=?(5&1/2?1?2?3?1=)?(5&3)=1,2457;
     b_3=?(5&1/3?1/2?1?2?1/5)  = ?(5&0,066666666)=0,5818;
     b_4=?(5&1/4?1/3?1/2?1?1/7)  = ?(5&0,00595238)=0,3589;
     b_5=?(5&1?1?5?7?1)  = ?(5&35)=2,0362.
     B=1,8882+1,2457+0,5818+0,3589 +2,0362=6,1108.
     x_1=b_1/B=1,8882/6,1108=0,309;
     x_2=  1,2457/6,1108=0,2039;
     x_3=  0,5818/6,1108=0,0952;
     x_4=  0,3589/6,1108=0,0587;
     x_5=  2,0362/6,1108=0,3332.
     Из полученных результатов можно выделить один наиболее важный критерий для ЛПР (лицо, принимающее решение): критерий К5 «Гибкость» равный 0,3332.
     Проверим корректность вычислений, используя равенство (5.2).
     ?_(i=1)^5??x_i= ? 0,3090+0,2039+0,0952+0,0587+0,3332=1.
     Раве.......................