Моделирование надежности программного обеспечения

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

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

В данном курсовом проекте требуется описать модель надежности программного обеспечения, для конфигурирования базы данных торгового предприятия.

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

Разрабатываемая мной программа в рамках дипломного проекта, должна иметь высокий коэффициент стойкости к отказам и иметь средства быстрого устранения таковых, если они имели место быть.

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

Для описания выше определенной модели будем использовать язык моделирования UML, используемый в среде Microsoft Visio.

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

Наиболее известными визуальными моделями, используемыми для проектирования компьютерных систем и их программных обеспечений, являются диаграммы языка UML и стандарта IDEF0, таблицы и диаграммы стандарта IDEF1X. Эти визуальные модели имеют математическую основу в виде теорий графов, множеств и матриц.

Диаграммы и таблицы языка UML и стандартов IDEF0, IDEF1X недостаточно эффективно моделируют веб-системы и их компоненты, поскольку они представляют собой модульные системы, состоящие из взаимосвязанных модулей. Наши исследования показали, что веб-системы и веб-компоненты (например, веб-страницы, веб-документы, веб-курсы) моделируются паттерновыми (модульными) сетями. Паттерновые сети это новый вид семантических сетей. Они обладают четко выраженными модульными свойствами и поэтому эффективно моделируют веб-системы и их компоненты. Мы построим паттерновые сети во второй части Курса. А теперь займемся языком UML.

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

Самое главное, что дал UML — это возможность широкой стандартизации языков программирования. Известно, что в разных языках программирования используются одинаковые операции и методы, но они имеют разные названия и символьные обозначения. Язык UML позволяет стандартизовать как сами операции и методы языков программирования, так и их терминологию.

Для реализации модели выбрана среда Microsoft Visio.

Восемь лет назад, когда продукт Visio вошел в арсенал Microsoft, он был уже очень популярен в своей категории ПО — средств деловой графики. Через год корпорация впервые представила пакет под своей торговой маркой — Microsoft Visio 2000. С самого начала Visio числился в семействе Microsoft Office, хотя все это время стоял в нем особняком и продавался только автономно, не входя в наборы офисных приложений. Наверное, именно этим объясняется тот факт, что до недавнего времени российское отделение продвижением Microsoft Visio практически не занималось, и для многих его потенциальных пользователей в нашей стране этот продукт остается почти неизвестным.

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

Электронные таблицы также уступают по своим возможностям изощренным средствам бизнес-аналитики, решения учетных задач на предприятии или выполнения математических вычислений. Но при этом для огромного круга массовых задач именно Excel не только подходит по функционалу, но и гораздо удобнее по причине своей простоты и доступности.

Развивая аналогию с электронными таблицами, можно сказать, что если Excel ориентирован на работу с табличными численными данными, то Visio предназначен для визуализации разнородных информационных структур с разнообразными взаимосвязями. Пользователь может применять как ручные, так и автоматические методы рисования по некоторым исходным данным (например, по табличному описанию штата сотрудников организации или по описанию топологии иерархической системы компьютерной сети). Но в любом случае он получает изображения в некотором заданном стиле или стандарте. В состав Visio входит обширный набор шаблонов — блок-схем бизнес-процессов, схем сетей, диаграмм рабочих процессов, моделей баз данных и диаграмм ПО, — которые можно использовать для визуализации и рационализации бизнес-процессов, отслеживания работы над проектами и использования ресурсов, оптимизации систем, составления схем организационных структур, карт сетей и планов зданий. Однако функции Visio выходят далеко за пределы просто визуализации данных: в профессиональную редакцию пакета включены средства моделирования и визуального проектирования при решении целого ряда распространенных ИТ-задач, в том числе при разработке программных систем.

Visio поддерживает обширный набор шаблонов — блок-схемы бизнес-процессов, схемы сетей, диаграммы рабочих процессов, модели баз данных и диаграммы ПО. Их можно использовать для визуализации и рационализации бизнес-процессов, отслеживания хода работы над проектами и использования ресурсов, оптимизации систем, составления схем организационных структур, карт сетей и планов зданий.

Шаблоны дают возможность быстро приступить к работе. Office Visio 2007 содержит ряд средств, с помощью которых специалисты из сферы ИТ и бизнеса могут создавать различные диаграммы в соответствии со своими потребностями. Новые шаблоны выпуска Профессиональный, например, шаблон ITIL или «Схема потока создания стоимости», расширяют диапазон доступных диаграмм. С помощью стандартных символов Microsoft SmartShapes и мощных функций поиска можно быстро найти нужную фигуру, где бы она ни находилась.

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

В начале работы с образцами схем в выпуске Office Visio Professional 2007 легко найти новые образцы, открыв новое окно «Приступая к работе» и воспользовавшись категорией «Образцы». Из образцов схем, интегрированных с данными, специалисты могут почерпнуть идеи для создания собственных диаграмм, понять, каким образом данные образуют контекст различных типов диаграмм, а также выбрать, какой шаблон использовать.

Новая функция автосоединения в Office Visio 2007 — соединение фигур без рисования соединителей — позволяет соединять фигуры, равномерно располагать их и выравнивать одним щелчком мыши. При перемещении соединенных фигур они остаются соединенными, а соединители автоматически изменяют путь между фигурами.

Диаграммы в выпуске Office Visio стали более интеллектуальными благодаря возможности связывать их с данными, что дает более полное представление о процессе, проекте или системе. Визуальное исследование информации позволяет выявить важные тренды, проблемные места или исключения и принять надлежащие меры. Анализ бизнес-данных с возможностью их детализации и создания различных представлений обеспечивает глубокое проникновение в суть вопроса.

Концептуальная модель

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

Согласно этим допущениям вероятность безотказной работы ПО как функция времени ti равна

(1.1)

где интенсивность отказов

. (1.2)

Здесь Cd — коэффициент пропорциональности;

N — первоначальное количество ошибок.

В (1.1) отсчет времени начинается от момента последнего (i — 1)-го отказа программы.

По методу максимума правдоподобия на основании (1.1), обозначая через k номер прогнозируемого отказа, получим, что функция правдоподобия имеет вид

. (1.3)

Логарифмическая функция правдоподобия имеет вид

(1.4)

Отсюда условия для нахождения экстремума

(1.5)

. (1.6)

Из (1.6) получим

. (1.7)

Подставим (1.7) в (1.5). Получим:

. (1.8)

При известных значениях k; t1, t2, …, tk из (1.7) и (1.8) можно найти значения параметров модели Cd и N, а затем интенсивность отказов, время от последнего до следующего отказа tk+1, вероятность безотказной работы через время tk+1 после последнего отказа.

Преимущества и недостатки модели. Основным преимуществом модели является простота расчетов. Недостаток этой модели состоит в том, что при неточном определении величины N интенсивность отказов программы может стать отрицательной, что приводит к бессмысленному результату. Кроме того, предполагается, что при исправлении обнаруженных ошибок не вносятся новые ошибки, что тоже не всегда выполняется.

Пример расчета. Пусть в ходе отладки зафиксированы интервалы времени t1=10, t2=20, t3=25 часов между отказами программы. Необходимо определить вероятность отсутствия следующего (четвертого) отказа.

Первоначальное количество ошибок N находим методом подбора. Если N=3, то есть, обнаружены все ошибки, то в левой части (1.8) имеем:

;

а в правой части:

.

Если N=4, левая и правая части соответственно равны 152 и 150. Если N=5, соответственно 210 и 205.

Следовательно, наименьшую ошибку при решении (1.8) обеспечит N=4, откуда по формуле (1.7):

.

Из (1.2) получаем

.

Следовательно, среднее время до следующего отказа составляет:

часов.

Тогда, подставляя найденные значения l4 и t4 в (1.1), получим вероятность отсутствия четвертого отказа:

.

Также необходимо заметить, что на каждой фазе сопровождения и версионной отладки вероятности отказа будут стремиться к нулю. Отобразим для наглядности этот процесс графически (Рисунок 1).

Рисунок 1 — График вероятностей отказа версий ПО Как видно из графика, вероятность отказа имеет тенденцию к уменьшению при исправлении ошибок и увеличивается при предъявлении новых требований по функционалу и нового тестирования продукта.

Диаграмма вариантов использования

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

Разработка диаграммы вариантов использования преследует цели:

определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;

сформулировать общие требования к функциональному поведению проектируемой системы;

разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;

подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Изобразим диаграмму вариантов использования (Рисунок 2).

Рисунок 2 — Диаграмма вариантов использования

Диаграмма классов

Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

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

Изобразим диаграмму классов (Рисунок 3).

моделирование автосоединение microsoft visio

Рисунок 3 — Диаграмма классов

Диаграмма состояний

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

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

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

Рисунок 4 — Диаграмма состояний

Диаграмма деятельности

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций.

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

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

Рисунок 5 — Диаграмма деятельности

Заключение

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

При определении требований по разработке новой версии программы, данная модель позволяет свести к минимуму обнаружение ошибок при тестировании и наискорейшее внедрение в производство.

Список использованных источников

и литературы

1. Бронштейн И. Н. Справочник по математике для инженеров и учащихся втузов [Текст] / И. Н. Бронштейн, К. А. Семендяев. — М.: Наука, 2007. — 708 с.

2. Кремер Н. Ш. Высшая математика для экономистов: учебник для студентов вузов. [Текст] / Н. Ш. Кремер, 3-е издание — М.: ЮНИТИ-ДАНА, 2006. C.412.

3. Калиткин Н. Н. Численные методы. [Электронный ресурс] / Н. Н. Калиткин. — М.: Питер, 2001. С. 504.

4. Модели информационных систем [Электронный ресурс] - Режим доступа: http://ru. wikipedia.org/wiki/ Модели информационных систем

5. Семакин И. Г. Основы программирования. [Текст] / И. Г. Семакин, А. П. Шестаков. — М.: Мир, 2006. C.346.

6. Симанков В. С. Основы моделирования систем [Текст] / В. С. Симанков, Т. Т. Зангиев, И. В. Зайцев. — Краснодар: КубГТУ, 2002. — 160 с.

7. Степанов П. А. Компьютерное моделирование. [Электронный ресурс] / П. А. Степанов, А. В. Бржезовский. — М.: ГУАП, 2003. С. 79.

8. Хювенен Э. Delphi — самоучитель программиста [Текст] / Э. Хювенен, Й. Сеппянен. — М.: Мир, 1990. — 460 с.