Аннотация
В статье представлен обзор основных методов и технологий, позволяющих экспериментально вывести численные значения свойства открытости информационной системы, используемых на данный момент, а так же обзор предпосылок для создания единого универсального стандарта оценки свойства открытости.
Annotation
In this article is presented the browse of main methods and technologies, that allowing to take numerical values of information system openness property by experiment, used on present time, and also is presented the browse of preconditions of creating the single unified openness property estimation standard.
Ключевые слова: открытые системы, интероперабильность, масштабируемость, переносимость, дружественность, информационный ресурс, оценка свойств открытости.
Введение
Темпы развития информационных технологий, пути и направления их развития, тенденции и перспективы позволяют провести однозначную аналогию с процессом эволюции. В чем суть эволюционного подхода? Из всех существ выживает сильнейший, то есть, по сути, самый приспособленный к условиям окружающей среды. Многие пути развития оказываются тупиковыми, другие - достигают своего эволюционного потолка. Схожим, если не сказать что вообще аналогичным, образом протекают процессы в информатике. Многие технические и программные решения, поначалу казавшиеся перспективными, не выживают, причем дело не только в нерентабельности этих решений для бизнеса и экономики, но и в самой не современности (а чаще - не своевременности) идеи. Так же, достигший своего потолка в 3 Ггц. путь наращивания тактовой частоты процессоров можно назвать тупиковым, равно как и путь наращивания остальных мощностей отдельных элементов. Основной упор в современной информатике делается на программные решения, на контент, на информационные услуги, и как следствие в технологическом плане это отражается на архитектуре и назначении уже непосредственно «железа». Другими словами, мозг начинает главенствовать над мышцей. Но, как в природе наиболее эффективными структурами по мнению одних специалистов является человечество, а по мнению других - муравьи, так и в области информационных технологий есть структура, система, а в общем виде - технология, являющаяся основным претендентом на звание лидера в будущем. Это технология Открытых Систем.
Что такое Открытая Система?
Открытая система (далее (ОС))- это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы. Для пользователя открытые системы обеспечивают следующее:
● новые возможности сохранения сделанных вложений благодаря свойствам эволюции, постепенного развития функций систем, замены отдельных компонентов без перестройки всей системы;
● освобождение от зависимости от одного поставщика аппаратных или программных средств, возможность выбора продуктов из предложенных на рынке при условии соблюдения поставщиком соответствующих стандартов открытых систем;
● дружественность среды, в которой работает пользователь, мобильность персонала в процессе эволюции системы;
● возможность использования информационных ресурсов, имеющихся в других системах (организациях).
То есть, по сути, (ОС) это целый класс программно-аппаратных решений, основная идея которого - прозрачность и простота функционирования. Очень часто к этому классу систем, очевидно по незнанию, ошибочно относят все без разбора версии Unix, мотивируя это тем, что у этих систем «открыт код», по этой же причине сюда относят PHP, HTML и многие другие скриптовые языки программирования, которые по сути не являются даже системами. Но, если в большинстве этих случаев легко отделить открытые системы от всего остального, то зачастую даже специалисты не могут дать однозначного ответа касательно открытости той или иной системы.
По этой причине, а так же по многим другим, были выведены основные свойства, присущие открытым системам:
Масштабируемость трактуется как качество системы, гарантирующее, что в условиях резкого изменения характеристик задач (рост объемов данных, увеличение числа пользователей, усложнение запросов, переход к распределенной обработке данных) система способна к ним адаптироваться.
Интероперабельность есть способность системы к взаимодействию с другими системами.
Дружественность трактуется как легкая управляемость параметрами системы и простота использования ее конечными пользователями. Логичность интерфейса и удобство использования связаны скорей не с моделью, а с пониманием создателей программной системы потребностей пользователя, специфики применения и условий эксплуатации.
Под переносимостью понимается возможность использования системы на различных программно-аппаратных платформах, отличающихся по архитектуре и характеристикам, с сохранением или небольшим изменением её функций.
По отдельности каждое из этих свойств далеко не является достаточным аргументов в пользу открытости системы, однако наличие их всех в совокупности как раз и позволяет охарактеризовать (ОС).
Но как проверить эти свойства? Как в числах, цифрах или графиках выразить дружественность к пользователю? Какие границы могут быть для масштабируемости, и какие необходимы? Как определить круг аппаратных платформ для переносимости и систем для интероперабельности? И самый главный вопрос - как сделать эту систему оценки не только универсальной, но и понятной, скажем, простому пользователю? Именно решение этих вопросов раскрывается в данной работе.
Обоснование необходимости тестирования.
Особенно актуальным для потребителя, будь то крупная корпорация или единичный пользователь, является вопрос о выборе оптимальной системы. Как правило, решение об использовании или не использовании системы принимается на основе соотношения цена \ качество. Возникает необходимость определить качество системы. Помимо надежности и эффективности, для открытых систем необходимо обстоятельно и объективно оценить непосредственно степень «открытости», то есть такие её свойства, как масштабируемость, переносимость, интероперабельность и дружественность, раскрытые выше. Одним из лучших методов такой оценки является экспериментальный, так как он дает наиболее наглядные результаты и показатели.
Тестирование ОС на масштабируемость.
Масштабируемость системы можно характеризовать объемом информации, который система способна обработать в единицу времени. При увеличении количества одновременно работающих пользователей, объем обработанной информации должен пропорционально возрастать при сохранении приемлемого времени выполнения операции. То есть, система должна справляться с растущей нагрузкой.
Исследование масштабируемости позволяет заранее оценить риски, связанные с ростом бизнеса, запланировать покупку более мощного оборудования и программного обеспечения, обеспечивающего требуемую масштабируемость, если тестирование покажет такую необходимость. Нагрузочные испытания позволяют обнаружить и устранить узкие места системы, ошибки проектирования, мешающие масштабированию. Наиболее распространены такие тесты, как:
● Оценка производительности и масштабируемости системы при одновременной работе большого количества пользователей. В данном тесте оценивается масштабируемость системы при одновременной работе большого количества пользователей, то есть ее способность справляться с поступающим объемом информации за приемлемое время.
Математически это сводится к уравнению:
P=Const
Где L - предел производительности (ОС), выраженный в количестве операций, транзакций или объеме обработанной информации в единицу времени; P - средний либо фиксированный (в зависимости от глубины тестирования) объем операций, транзакций или данных для одного пользователя, а N - количество таких пользователей. При одновременной работе нескольких пользователей определяющим является максимальное значение L при растущем N и постоянном P.
● Оценка производительности и масштабируемости системы при пиковых нагрузках. Интенсивность работы тестовых пользователей, зачастую, значительно превышает возможности реальных пользователей. Однако именно такое тестирование позволяет наиболее наглядно оценить производительность в общем и масштабируемость в частности. Тестирование системы на пиковых режимах позволяет оценить ее работоспособность и производительность в ситуации резкого увеличения нагрузки до предельных значений. Хорошо масштабируемая система в таких условиях должна демонстрировать устойчивую работу и приемлемое время выполнения операций.
Математически это выглядит так:
N=Const
Аналогично предыдущему, определяющим является значение L при растущем P и постоянном N.
Однако эти два случая являются частными, в то время как в реальности гораздо чаще используется многосторонний подход, основанный на многофакторном исследовании масштабируемости и производительности системы на протяжении больших промежутков времени.
Подход этот во многом схож с тестированием производительности отдельных программ, что закономерно, потому как определяющими являются показатели производительности и надежности. Набор факторов, по которым оценивается производительность, зависит от специфики и среды использования (ОС). В общем случае такими показателями являются:
Для Internet-ресурсов (сайты, порталы, серверы):
-Среднее время отклика на запрос пользователя
-Максимальное время отклика на запрос пользователя (как минимум не должно превышать TTL соединения и кадров данных)
-Максимальное количество запросов, которые система способна обработать в единицу времени
-Резерв пропускной способности канала при растущем количестве пользователей (в общем случае канал должен быть разгружен, а все запросы помещены в программный буфер)
-Максимальный объем данных, который система способна обработать в единицу времени
Для СУБД (Microsoft MYSQL Server, Interbase, Oracle)
-Максимальное количество транзакций, обрабатываемых в единицу времени.
-Максимальное количество одновременно работающих пользователей
-Среднее время обработки запроса
-Время ожидания при одновременном использовании одних данных (если наличествует распределенная обработка)
Для военных и стратегических систем:
-Максимальное время обработки запроса
-Максимальное время реакции
-Минимальное количество транзакций в единицу времени
Наибольший плюс этого подхода заключается в том, что он совмещает в себе элементы и детерминизма и вероятности. То есть исследование поведения системы в целом дает наиболее полное представление о её возможностях к масштабированию.
На практике это реализуется при помощи создания тестовых пользователей и генераторов запросов. Система во многом напоминает технологию тестовых оракулов в ООП ( см Рис.1)
По сути тестирование заключается измерением конкретных параметров системы при работе в определенном режиме, который задается входными данными.
Входными данными являются: минимальное и максимальное время работы каждого пользователя, минимальное и максимальное количество операций совершаемых каждым пользователем в единицу времени, максимальное и минимальное количество пользователей, минимальный и максимальный объем данных для каждой операции.
Выходными данными являются пробы значений параметров первого рода: объем данных и количество операций, и средние значения на интервалах параметров второго рода (производные) - время и скорость.
Как видно, для каждого параметра устанавливается минимальное и максимальное значение. Так же входным является значение интенсивности, общее либо каждое для своего параметра, которое по сути определяет математическое ожидание параметра на определённом временном промежутке. Таким образом, одновременно, в рамках одного комплексного эксперимента, оценивается масштабируемость системы при изменении количества пользователей, нагрузки, характеристики выполняемых ими задач и объемов данных. Метод позволяет вычислить узкие места в программе связанные не только с оптимальностью алгоритмов, но и механизмами загрузки \ выгрузки данных в память или на диск, промахами в Кеше, задержками и нагрузками, связанными с функционированием самой платформы. Это так же позволяет проверить и измерить такой важный для системы параметр, как Расширяемость, который очень часто включают в понятие масштабируемости. Под расширяемостью обычно понимают адаптивность системы к увеличению мощности аппаратной платформы либо перенос системы на более мощную платформу.
Тестирование ОС на интероперабельность.
Тестирование интероперабельности - исследование, направленное на оценку процессов взаимодействия системы с внешними по отношению к ней компонентами. А именно: специфическое аппаратное обеспечение, драйверы устройств, ПО третьих фирм и т.п. Как правило, речь идет о тестировании характеристик надежности и производительности межсистемных шлюзов, а также об оценке эффективности использованных архитектурных и технических решений.
В общем случае еще на этапе проектирования (ОС) разработчик определяет, с какими системами будет происходить взаимодействие, и для достижения интероперабельности обеспечивает реализацию следующих задач:
Единая трактовка всех типов данных
Взаимодействующие системы должны трактовать все типы данных (включая абстрактные), участвующие во взаимодействии одинаковым образом.
Процедуры преобразования
В случае полного различия взаимодействующих частей в одной из них или в обеих должны присутствовать процедуры преобразования сообщений и типов данных в формат представления друг друга.
Протокол взаимодействия
Протокол должен описывать как, в каких случаях и с помощью чего системы будут взаимодействовать.
В свете этого, актуальными становятся две задачи тестирования интероперабельности:
1) Оценка эффективности взаимодействия (ОС) с системами, предусмотренными на этапе проектирования.
2) Оценка сложности обеспечения взаимодействия (ОС) с системами, не предусмотренными на этапе проектирования.
В понятие эффективности традиционно включают показатели производительности и надежности системы, однако в силу оценить именно интероперабельность эти показатели оцениваются применительно к самому процессу взаимодействия систем.
К показателям производительности относят:
-Время выполнения преобразования типов данных
-Скорость передачи данных между системами
-Скорость работы системы с данными в унифицированном формате
К показателям надежности относят:
-Затраты ресурсов на обеспечение надежности взаимодействия, в особенности при открытости протокола взаимодействия
-Количество ошибок при взаимодействии, связанных с разницей в архитектуре и форматах данных систем.
Второй тип задач относится не к экспериментам, а скорее к проектированию, однако численно сложность обеспечения взаимодействия обычно выражают в денежных и временных ресурсах на разработку, тестирование и развёртывание. Закономерно, что от этого впоследствии будет зависеть и параметры из первой категории задач.
Для итоговой оценки интероперабельности так же важен такой параметр, как отношение производительности и надежности системы с обеспечением интероперабельности, к производительности и надежности системы без неё. То есть фактически, этот параметр определяет относительные потери или находки в эффективности, возникающие из-за интероперабельности.
Оценка дружественности к пользователю интерфейса (ОС).
Решение данной задачи главным образом проистекает из науки, известной как эргономика. Предполагается, что прежде чем создать интуитивно понятный интерфейс, разработчик должен исследовать целевую аудиторию, определить её потребности, выделить несколько классов пользовательских задач и разделить их по сложности и частоте использования. Так же, отталкиваясь от целевой аудитории, разработчик определяется с общим стилем интерфейса, цветовой гаммой, динамичностью и смысловой нагрузкой всех текстов и изображений. В итоге, это позволяет обеспечить выполнение следующих задач:
Учитывая такой круг решаемых задач, не вызывает удивления тот факт, что дружественность к пользователю среди всех параметров открытых систем является наиболее важным. Экспериментальных методов тестирования дружественности к пользователю существует великое множество, и те или иные методы применяются в зависимости от специфики системы, но в общем случае алгоритм эксперимента такой:
На этом этапе важно выбрать пользователей именно из целевой аудитории, учитывая возраст, специальность, личный опыт. Нарушение целостности целевой группы может привести к ложноотрицательным результатам тестирования. В случае же, если система не имеет определённой целевой аудитории, то тестовая группа должна состоять из пользователей всех категорий с сохранение отношений количества пользователей каждого типа. В отдельных, но редких случаях, кто именно будет в экспериментальной группе, вообще не имеет значения.
На данном этапе экспериментатор сам для себя определяет, как, по каким критериям и параметрам, он будет оценивать дружественность интерфейса. Чаще всего для оценки используются следующие параметры и отношения:
- время поиска инструмента в интерфейсе (ОС)
Как пример: для разработчика кнопка «поиск» вполне очевидна, пользователь же может её вообще не заметить
- пути пользователя по интерфейсу
Как пример: разработчик знает свою систему наизусть, пользователь же полагается на интуицию и систему справки
- наиболее часто используемее пользователем функции
Как пример: очень часто бывает, что пользователь предпочитает функции, которые разработчик не закладывал как основные
- количество ошибок при вводе данных и поиске
Как пример: близко расположенные кнопки приводят к случайным нажатиям
-Как ни странно, очень существенным параметром является оценка интерфейса самим пользователем. Плюс этой оценки в том, что пользователь говорит, что именно не так в интерфейсе и как это можно было бы изменить.
3) Разработка системы тестов
На данном этапе экспериментатор определяет набор заданий для проверки указанных выше свойств. Важно, что бы для одной экспериментальной группы задания были одинаковы.
На этом этапе очень важно произвести правильную статистическую обработку данных. Самый основной момент - это выборка экспериментальных значений. Как правило, вычисляется среднее значение для каждого параметра, определяется порог отклонения отдельных значений от среднего, отбрасываются значения, не подходящие по пороговому значению и снова вычисляется среднее значение. Это позволяет обеспечить большую статистическую верность за счет исключения заведомо крайне редких значений. Так же, в отдельных случаях, вводят коэффициент весомости тестовых данных для определенных групп пользователей, либо для каждого. Это позволяет сбалансировать дружественность интерфейса для всех групп целевой аудитории.
Тестирование ОС на переносимость.
Основной целью проведения испытаний (ОС) в проблеме их переносимости является выяснение возможности функционирования объекта испытаний на различных программно-аппаратных платформах. Можно сделать вывод о том, что в настоящее время крайне актуальной проблемой в области информационных технологий и систем выступает проблема переносимости систем между различными аппаратно-программными платформами. Экономический эффект от решения этой проблемы весьма значителен.
При разработке сложных по структуре переносимых (ОС) желательно придерживаться принципа модульности. В этом случае система собирается из функционально замкнутых частей (модулей), которые могут выступать в качестве элементов тестирования. Ввиду того, что каждый из модулей является функционально самодостаточной сущностью, его разработку и тестирование можно проводить независимо от других модулей и системы в целом. Это существенным образом снижает время и стоимость создания системы в целом.
По функциональному признаку модули можно разделить на две группы
● модули ядра системы, которые непосредственно реализуют алгоритм обработки информации;
● модули взаимодействия с внешней средой. Через эти модули идет обмен информацией между ядром системы и другими системами, а также взаимодействие с периферийными устройствами и системными ресурсами.
С точки зрения переносимости важным является способ реализации именно модулей второй группы.
К количественным показателям переносимости, которые можно получить экспериментальным путём, можно отнести следующие величины:
-Затраты времени и ресурсов на перенос системы на другую платформу
-Количество необходимых для этого изменений
-Изменение показателей производительности и надежности при переносе на другую платформу.
Поскольку стоит задача оценить переносимость в целом, её можно разделить на следующие этапы:
- % показатель отношения стоимости изменения системы к стоимости разработки (для каждой платформы) и среднее значение для всего круга платформ в целом
- % показатель изменений необходимых для переноса к общему размеру системы для каждой платформу и среднее значение для всего круга платформ
- (крайне редко) абсолютный показатель изменений необходимых для переноса к общему размеру системы для каждой платформу и среднее значение для всего круга платформ
- на этапе развёртывания: суммарная стоимость затрат, связанная с разницей в аппаратно-программных платформах
Крайне важно в этом методе правильно определить круг аппаратно-программных платформ.
Заключение.
Хотя в данный момент и существует великое множество оценки отдельных параметров и свойств (ОС), Открытость всё же достигается благодаря совокупности всех этих свойств. Как следствие, оценить сам принцип Открытости - вот наиболее важная задача в этой области. Существует много разработок и технологий, направленных на проектирование (ОС), на достижение свойства открытости, однако оценить, в особенности оценить
экспериментально, численно, и самое главное - стандартизировано для всех систем - пожалуй, самая актуальная задача в области тестирования (ОС).
Потому что если мы говорим об Открытых Системах, то открытыми должны быть и способы тестирования.
Библиографический список:
1) Мунипов В.М., Зинченко В.П. Эргономика: человекоориентированное проектирование техники, программных средств и среды: Учебник. -М.: Логос, 2001г.
2) Гуляев Ю.В., Корниенко В.Н., Олейников А.Я., Черепенин В.А. Технология отрытых систем и вычислительный эксперимент в радиоэлектронике. - «Секция Открытых Систем». 5 сентября 2002 год.
3) Технология открытых систем. - n/a. Под ред. А.Я. Олейникова. 2004 г.
4) http://www.belsoft-borlas.ru/methods.html
5) http://www.iskrauraltel.ru/ru/services/professional_services/Pages/default.aspx
6) http://www.infosoftcom.ru/testirovanie