Исправление ошибок СПО
В любой достаточно сложной программе непременно имеются ошибки и дефекты, количество
которых обычно неизвестно. Многие крупные производители ПО создают и оплачивают работу
отдела контроля качества (QA — Quality assurance), который контролирует соответствие процесса
разработки ПО определенным требованиям, выполнение которых позволяет снизить вероятность
появления ошибок в ПО (например, требованиям стандарта DO-178B, который применяется при
разработке ПО для авиационных систем). Тем не менее, в настоящее время отсутствуют методы,
позволяющие полностью гарантировать отсутствие ошибок в достаточно сложном ПО (существуют
формализованные критерии сложности ПО).
Пользователь закрытой частной программы, столкнувшись с ошибкой, не всегда может
выявить её причину и исправить ошибки (поскольку ему недоступны ни исходные тексты
программы, ни даже отладочная информация), но, скорее всего, способен описать ошибку и условия,
в которых она происходит. И может сообщить об ошибке производителю программы, и если там
решат, что ошибка действительно в программе, а не в работе пользователя, о ней будет сообщено
разработчикам. В итоге пользователь может долго ожидать исправления ошибки в последующих
260
версиях
программы.
Нередко
обновление
собственнической
программы
приравнивается
производителем к приобретению новой копии, что влечет за собой соответствующие издержки и
нарушение закона о защите прав потребителей.
У типичной свободной программы (то есть, некоммерческой и/или разрабатываемой
небольшой компанией или частным лицом) обычно нет оплачиваемого отдела контроля качества.
Значит, пользователь может столкнуться с ещё большим количеством ошибок, чем в типичной
коммерческой проприетарной программе. Тем актуальнее для него возможность сообщить об ошибке
разработчикам программы. Раньше в сопровождающей программу документации было принято
указывать электронный адрес, по которому разработчики принимали сообщения об ошибках (bug
report). Некоторые вводили стереотипную форму для таких сообщений, чтобы облегчить и
автоматизировать их обработку. Уже это требует существенно более высокой связности сообщества
во всём мире, существенно большей, чем достаточно для закрытой разработки. Для открытого
проекта круг и взаимное расположение потенциальных разработчиков не ограничены ничем, поэтому
эффективность разработки в гораздо большей степени зависит от того, насколько просто всем членам
сообщества договариваться между собой, а также от «сознательности» пользователей.
Чем больше у свободной программы активных пользователей, готовых вносить исправления и
дополнения и делиться ими, тем надёжнее работает и быстрее развивается программа. Причём такая
свободная модель отслеживания и исправления ошибок для программы, у которой тысячи активных
пользователей, может оказаться гораздо более эффективной, чем у любой проприетарной программы:
ни одна компания не может себе позволить такой огромный штат сотрудников в отделе контроля
качества. Поэтому действительно популярная свободная программа может оказаться гораздо
надёжнее проприетарных аналогов.
Большинство современных свободных программ пишется группой разработчиков. Даже если
начинал писать программу один человек и она оказалась интересной, к разработке могут
присоединиться активные пользователи. Нужно заметить, что преимущества свободной разработки
для пользователя не следует преувеличивать. Не все свободные программы в равной степени
доступны для изменения пользователям, и это совершенно не связано с лицензией на их
распространение. Важный фактор здесь — объём программы: если в ней десятки тысяч строк (как,
например, в OpenOffice.org), то даже квалифицированному пользователю потребуется слишком
много времени, чтобы разобраться, что к чему.
Место свободных программ на сегодняшнем рынке ПО очень значительно, и многие
коммерческие и государственные предприятия используют свободное ПО прямо или опосредованно.
Собственно, опосредованно все пользователи Интернета задействуют, например, свободную
программу BIND, предоставляющую службу DNS. Многие организации, особенно предоставляющие
услуги через Интернет, используют свободный web-сервер Apache, от работы которого
непосредственно зависит их прибыль, не говоря уже о серверах на платформе Linux. Главный
недостаток с точки зрения коммерческого пользователя: разработчики свободных программ не несут
никаких обязательств по качеству программы, кроме моральных.
Структура платформы алгоритмов и программ
Рассмотрим основные этапы проектирования платформы СПО.
На первом этапе проектирования важно создать необходимые предпосылки для развития
платформы СПО, в качестве равноправной составляющей сбалансированной программной среды.
Далее необходимо сформировать сбалансированную модель программной среды платформы на
основе СПО, а также ПО с открытым исходным кодом, включающим функционал проприетарного
ПО.
Одним из важнейших этапов проектирования платформы СПО является этап организации базы
знаний о хранящихся алгоритмах и программах, предварительно определив и классифицировав тот
или иной алгоритм или ПО по уровням взаимодействия представленных схематично на рисунке 1.
Следующий этап - разработка и сбор программных средств или ОС. Он включает
формирование лицензионной корпоративной политики в области использования программных
средств и баз данных.
В этап регистрации разработанных ПО входит процесс интеграции разработанных
программных средств.
261
Рисунок 1 – Уровни взаимодействия между пользователем, прикладным программным обеспечением,
операционной системой и аппаратным обеспечением
Подробное описание рисунка 1 представлено в источнике [8].
Информационная система платформы алгоритмов и программ
Структурные компоненты информационной системы платформы СПО РК представлены в виде
схемы на рисунке 2.
Данная схема составлена автором, ее описание представлено ниже.
1. Регистрация ПО - компонент, регистрирующий ПО разработанное в РК, а также внутри
платформы СПО РК. Примерное разделение регистрируемое ПО по тематикам:
- общесистемное ПО: офисный пакет OpenOffice.org; средство просмотра PDF AdobeReader;
средство просмотра DjVu Evince; редактор растровой графики GIMP; редактор векторной графики
Inkscape; браузеры Mozilla Firefox, Chromium, Opera; FTP-клиенты FileZilla, gFTP; терминальный
клиент tsclient; доступ к удаленным рабочим столам Vinagre; программа просмотра изображений
Picasa;
аудиоплеер
Audacious;
видеоплееры
Rhythmbox,
VLC;
файловые
менеджеры
GNOMECommander, MidnightCommander;
- среды разработки: eclipse, Android Studio 0.1, VisualAge; веб среда apache;
- математическое ПО: Triangle; среда для численных вычислений Octave; программа для
создания двух- и трёхмерных графиков gnuplo; системы компьютерной алгебры Sage, Maxima; пакет
прикладных математических программ Scilab; язык программирования для статистической обработки
данных R; программное обеспечение для анализа и визуализации научных данных SciDAVis;
- а также, другие тематические направления.
2. Развитие и интеграция – компонент, отвечающий за развитие и интеграцию СПО в РК.
Функционал данного компонента основан на:
- развитии платформы СПО РК;
- интеграция СПО в области, использующие проприетарное ПО;
- оказание помощи в переходе к СПО;
- справочно-консультационная служба СПО.
ПО направленное на
увеличение удобства
пользования
Прикладные программы
(Libre Office, Mozilla
Firefox и т.д.)
ПО входящее в состав ОС
и обеспечивающие ее
работу
ПО для обеспечения
взаимосвязи с
оборудованием
262
Рисунок 2 - Структурные компоненты информационной системы платформы СПО РК
3. Разработка ПО – компонент, отвечающий за разработку ПО в РК, в функционал данного
компонента должны войти:
- создание корпоративных сборок на базе официальных открытых ОС c учетом прикладной
направленности;
- взаимодействие с официальными серверами базовых ОС;
- создание Live-DVD, позволяющий пользователю в течении короткого времени загрузить с
него систему и получить доступ к требуемым программам без необходимости их установки;
- удаленный доступ к дополнительному ПО с целью включения его в текущую корпоративную
сборку.
4. Техническая поддержка – компонент, занимающийся технической поддержкой:
- управление версиями ПО;
- отслеживание и устранение ошибок;
- управление ПО.
5. Демонстрация СПО - компонент демонстрации ПО и разработок. В данный компонент
должны быть включены:
- создание и актуализация каталога информационных страниц о ПО, описание достоинств и
недостатков, документация, ссылки на загрузку;
- демонстрационные сервера и виртуальные машины, позволяющие пользователям оценить ПО;
- предоставление доступа пользователей к дистрибутивам СПО.
Процесс перехода к использованию СПО
Ниже поэтапно представлен процесс перехода к использованию СПО:
1. Аудит используемого программного и аппаратного обеспечения (оценка его надежности,
эффективности и соответствия его текущего состояния к решаемым задачам);
Развитие и
интеграция
Демонстра-
ция СПО
Техническая
поддержка
Разработка
ПО
Регистрация
ПО
Информа-
ционная
система
платформы
СПО РК
263
2. Расчет экономической целесообразности перехода на СПО;
3. Подбор ПО (или же выбор корпоративной сборки);
4. Подготовка пользователей к переходу;
5. Подготовка курсов для обучения пользователей;
6. Учебные и методические материалы по курсу должны быть доступны пользователю в
компоненте «техническая поддержка» информационной системы платформы СПО РК;
7. Перевод серверной инфраструктуры на СПО;
8. Параллельное использование кроссплатформенных приложений;
9. Перенос данных;
10. Перевод компьютеров пользователей на ОС СПО (Linux,Unix).
ЛИТЕРАТУРА
1. Что такое свободная программа? // Электронные ресурсы: http://www.gnu.org/philosophy/free-sw.ru.html
2. August
2011
Web
Server
Survey.
//
Электронные
ресурсы:
http://news.netcraft.com/archives/2011/08/05/august-2011-web-server-survey-3.html
3. Home Page WikiMediaFoundation. // Электронные ресурсы: https://wikimediafoundation.org/wiki/Home
4. Министерство юстиции Бельгии мигрирует на GNU/Linux и OpenOffice. // Электронные ресурсы:
http://www.nixp.ru/news/Министерство-юстиции-Бельгии-мигрирует-на-GNU/Linux-и-OpenOffice.html
5. http://government.consultant.ru/page.aspx?8411;1536480 .
6. Исследование российского рынка СПО. Часть 3. «Тенденции развития рынка СПО в России». //
Электронные ресурсы http://www.opennet.ru/docs/RUS/fss_history3/
7. 2013 Будущее Open Source - результаты седьмого ежегодного опроса. // Электронные ресурсы:
http://www.mjskok.com/resource/2013-future-open-source-7th-annual-survey-results
8. Программное
обеспечение.
//
Электронные
ресурсы:
http://ru.wikipedia.org/wiki/
Программное_обеспечение
Косынбай Е.Б., Тусупова Б.Б., Мамырова А.К.
Қазақстан Республикасында еркіндіқ программалық қамтамасын платформасын жобалауы
Түйіндеме.
Жумыста
қарастырылады
Қазақстан
Руспубликасында
еркіндіқ
программалық
қамтамасынын даму проблемалары.
Түйін сөздер: Программалық қамтама, ерқіндіқ ПК, сертификация, авторлық құқық, ақпараттық жүйе.
Kossynbay Е.B., Tussupova B.B., Mamyrova A.K.
Design of the platform of the free software in Kazakhstan
Summary. In operation it is considered problems of development of the free software in the Republic of
Kazakhstan.
Key words. Software, free software, certification, copyright, information system.
УДК 667.251.8.147(043)
Кошимбаев Ш.К., Иманбекова У.Н.
Казахский национальный технический университет имени К.И.Сатпаева
г. Алматы, Республика Казахстан
uli.08@mail.ru
МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ МЕДНЫХ ШТЕЙНОВ
В МЕТАЛЛУРГИЧЕСКИХ АГРЕГАТАХ
Аннотация. Оперативное управление комплексом технологических операций медеплавильного
производства сводиться к оперативной корректировке графика работы конверторного отделения, занимающего
центральное положение в технологической семе. Принимаемые при этом решения определяются сложившейся
производственной ситуацией, учитывающей текущее состояние процесса и агрегатов металлургического цеха,
характеристики сырья, плановые задания сводятся к следующим альтернативам:
1)
сохранение ранее принятого графика работы конверторного отделения;
2)
изменение графика работы путем перераспределения штейна между сдельными конверторами;
3) изменение графика путем переливов массы из конвертора в конвертор;
4) изменение графика путем изменения состава штейна.
Ключевые слова: семиотическое моделирование, конверторное отделения, металлургический цех,
микромодели, алгоритм управления.
264
Количество обоснованное оптимальное управление комплексом возможно лишь на основе
математической модели, позволяющей осуществлять, в соответствии с некоторым критерием, выбор
управленческих решений и предвидеть следствия их реализации. Однако такая модель оказалось бы
чрезмерно сложной для построения на ее основе приемлемого для практики алгоритма управления.
Отметим принципиальную особенность рассмотренной задачи управления: большое число конверторных
ситуаций, характеризующих объект управления, и малое число возможных решений по управлению.
Одним из наиболее рациональных методов решения задач такого рода является метод ситуационного
управления [1].
Суть метода состоит в разбиении множества ситуаций на непересекающихся подмножества,
число которых соответствует числу альтернативных решений по управлению. Каждое подмножество
объединяет все ситуации, для которых, с точки зрения критерия управления сводится к задаче
классификации по множеству неизвестных признаков.
Выделение отдельных подмножеств множества конкретных ситуаций осуществляется на основе
макромодели объекта управления, отражающей лишь наиболее существенные его свойства. Получение
макромодели осуществляется на основе процедуры обобщения микромоделей, содержащих
детальное описание функционирования объекта [2].
Микро описание объекта управления осуществляется при помощи - модельного языка,
включающего множество базовых понятий
задано множество бинарных
отношений
Элементами множества П являются объекты (признаки), совокупность
состояний (значений) которых, изменяющаяся во времени, определяет собой конкретную
производственную ситуацию [3]. Элементами множества R являются отношения, устанавливающие
взаимосвязи между отдельными базовыми понятиями. Таким образом, микро описание объекта
управления имеет вид синтагматической цепи - троек вида
, объединенных знаками
логического умножения. Учитывая, что связи между отдельными базовыми понятиями в общем
случае носят динамический характер, представим микро описания объекта в виде массива, элементы
которого зависят от дискретного времени n=1,2,...
1, если в n-й момент времени понятия
и
связаны между собой
отношением
0 – в противном случае.
Модель объекта управления, построенная на уровне микро описания, или на первом уровне
модельного языка, является чрезмерно подробным описанием, мгновенной "фотографией" объекта.
Для иллюстрации приведем микро описание двух фрагментов конкретных ситуаций:
а) "запас концентрата № 8 составляет 10 единиц", б) "процесс в конверторе №1 находится в
состоянии 1-го периода". Введем следующие базовые понятия и бинарные отношения: al - запас, а2 -
концентрат, а3 - 8, а4 - конвертор, а6 - процесс, а7- 1, а8 -период, - иметь имя, - иметь значение, -
быть в состоянии, - находиться в тогда микро описание имеет вид:
a)
б)
построение макро описания объекта управления осуществляется путем последовательного
обобщения микро описаний конкретных ситуаций, соответствующих отдельным моментам времени
функционирования объекта. Обобщение микро ситуаций осуществляется с помощью грамматик модельного
языка. Грамматики предназначены для порождения производственных (обобщенных) ситуаций на
втором и последующем уровнях языка. В процессе обобщения с помощью правил корреляционной
грамматики происходит выделение общих, существенных связей между понятиями [4]. Этот процесс
осуществляется поэлементным осреднением массивов
, характеризующих микро
описания последовательно сменяющихся конкретных ситуаций:
,
где
- массив, характеризующий обобщенную к n - му шагу ситуацию. По окончании процедуры
осреднения формируется массив , учитывающий лишь существенные связи между понятиями
265
,
, j=
здесь 0<ε<1- заранее заданное пороговое значение.
В отличие от массивов
связи которых носят динамический характер и изменяются от
ситуации к ситуации, массив характеризуется наличием связей, которые носят устойчивый характер,
т. е. проявляются во многих ситуациях.
Обобщению подлежит и отношение, образующие непрерывные ветвящиеся структуры, синтагмы
которых имеет общие крайние члены. Обобщение понятия приводит к образованию понятий более
высокого порядка, таких как "любой концентрат", "конверторный участок", "богатый по содержанию
меди штейн" и т. д. Легко увидеть, что данные понятия представляют собой логическое обобщение
базовых понятий (понятия нулевого порядка). Вообще говоря, обобщение понятий 0,1, ... i-го порядка
могут быть получены понятия i+1 - го порядка.
При построении обобщенных ситуаций необходимо участие человека, который оценивает каждое
обобщение по результатам понятия решений на наборе типовых контрольных ситуаций. Если решение
неудовлетворительно, то происходит усечение связей. Это приводит к тому, что постепенно в модели
остаются лишь полезные связи и обобщения. Обобщение происходит до тех пор, пока число обобщенных
описаний ситуации не станет соизмеримым с числом различных решений по управлению объектом.
При завершении процедуры обобщения словарь понятий и отношений корректируется с учетом
вновь
образованных
понятий.
Конкретные
ситуации
описываются
с
использованием
скорректированного словаря и изображаются в ЦВМ с помощью трехмерных массивов
,
представляющих собой более высокий уровень описания объекта по сравнению с
.
Обобщение массивов
позволяет получить еще более высокий уровень описания объекта
управления и т. д.
Данная поэтапная процедура повторяется до тех пор, пока на некотором υ - м уровне описания
число выделенных автономных структур трехмерного массива
не станет равно числу возможных
решений по управлению, после чего между ними устанавливается взаимное однозначное соответствие.
Одновременно устанавливаются связи между автономными структурами массивов различных уровней
описания.
Формирование решений по управлению на основе семиотической модели осуществляется по
следующей схеме. Вычисляются предикаты (логические функции), устанавливающие связь между
автономными структурами модели некоторого описания и единицами модели следующего по порядку
высшего уровня:
=
),S=1,2,…,
ξE
здесь
-предикат S-й автономной структуры 1-го уровня описания, образованный соединением
соответствующих элементов микро описания знаками
и
.
- предикат t- й автономной
структуры r-го уровня описания (r≥2), (образованный соединением предикатов, соответствующих
автономных структур r- 1-го уровня описания знаками и .
Таким образом, микро описание конкретной ситуации "возбуждает" отдельные автономные
структуры массива
, которые, в свою очередь, "возбуждения" одной из автономных структур
конечного массива
и т.д. До "возбуждения"одной из автономных структур конечного
массива Х
v
[п], что однозначно определяет управленческое решение.
Применение данного алгоритма при управлении технологическими операциями конкретного
отделения связано со сбором исходной информации для построения семиотической модели. Такая
информация
представляет
собой
собокупность микро
описания конкретных ситуаций в
металлургическом цехе, для каждой из которых указано оптимальное решение [5]. Однако сложность
объекта затрудняет получение интересующей нас информации. В то же время, опытные специалисты,
непосредственно связанные с данным объектом, могут иметь вполне определенные качественные
представления об основных закономерностях его функционирования, применимости конкретных
управленческих решений в данной производственной ситуации и т. п. Эти представления в
совокупности, несомненно, содержат ценную информацию.
266
Сбор и формализация информации, содержащейся в мнениях и навыках специалистов,
осуществляется методами экспериментальных оценок. Эти методы основаны на анкетировании и
статистическом анализе его результатов.
Разрабатываемые анкеты в каждом конкретном случае должны обеспечивать получение максимума
необходимой информации, быть удобными для заполнения, рациональны с точки зрения машинной
обработки.
Ограниченное число опрошенных обусловливает необходимость оценки достоверности
полученных путем анкетирования выводов методами математической статистики. Статистический анализ
результатов анкетирования направлен на проверку гипотез о наличии согласованности опрошенных,
о значимости осредненного результата опроса и т. д.
Первоначальное множество U управляющих решений, предложенных для ранжирования, состояло
из девяти элементов: 1 - увеличить содержание Си в штейне, 1 -уменьшить содержание Си в штейне, 3 -
увеличить расход дутья по отделению, 4 -уменьшить расход дутья по отделению, 5 - перелить массу
из конвертора в конвертор, 6 -перераспределить штейн между плавками, 7 - увеличить набор штейна, 8 -
уменьшить набор штейна на плавку, 9 - отсутствие управляющего воздействия.
Результаты опроса обрабатывается следующим образом:
1. Подсчитывается сумма рангов по каждому управленческому решению.
где
- ранг (присвоенное число) i - го фактора у j - го специалиста.
2. Подсчитывается средняя сумма рангов
1. Вычисляются, разности между суммой рангов каждого фактора и средней
суммой рангов
квадраты этих разностей суммируется
4.
Вычисляется коэффициент конкорации, характеризующий степень согласованности мнений
опрошенных
где
- число повторений v - го ранга в j - м ранкировании.
5. Вычисляется значение критерия
6. Находится табличное значение критерия х
2
для доверительной вероятности Р° и числа
степеней свободы к = п-1. х
2
\Р°,К)
7. Если х
2
>х
2
(Р°,К), то с вероятностью Р° можно утверждать, что существует определенная
согласованность мнений специалистов в оценке данной ситуации.
Результат построения ситуационной модели представляет собой систему предикатов,
обеспечивающую выбор управляющих воздействий по конверторному отделению для каждой
сложившейся производственной ситуации.
Достарыңызбен бөлісу: |