Лаврищева Е.М., Грищенко В.Н. Сборочное программирование. Основы индустрии программных продуктов
Подождите немного. Документ загружается.
231
Каждая из характеристик (показателей) обладает свойствами и атрибутами,
определяющими разные ее свойства, которые необходимо знать пользователю при
желании использовать соответствующее ПО.
Далее излагается сущность характеристик модели качества М
кач
и соответ-
ствующие формулы для их оценки с учетом m
i
–метрик и веса каждой
метрики w
i
,.
Функциональность – совокупность свойств, определяющих способность
системы предоставлять требуемое множество функций для решения задач в
соответствии с требованиями. В модели качества эта характеристика задается
набором атрибутов q
1
= {a
11
,
a
12
,
a
13
, a
14
,
a
15
,
a
16
}, семантика и оценка которых
приведена ниже.
a
11
: функциональная полнота – свойство компонента, которое определяет
степень достаточности функций для решения задач в соответствии с его
назначением. Данный атрибут можно представить в виде отношения всех
реализованных функций F
с
в компонентной системе (с), к функциям F
т
(т –
требование):
N
K
a
11
=
F
с
/
F
т
.
i=1 j=1
a
12
: корректность – атрибут, который означает степень достижения
правильности каждой функции F
т
, заданной в требовании, и каждой функции F
с
,
реализованной в компонентной системе. При этом система обладает свойством
полной корректности, если F
т
= F
с
, и частичной корректности, если F
т
F
с
. Для
большинства ПС достаточно частичной корректности. Степень корректности – это
степень функциональной корректности:
= 1– (card ( F
т
/ F
с
) /card F
т
.
a
13
: точность – свойство, определяющее получение результатов с необходимой
степенью точности. Данный атрибут
оценивается отношением разности
значений функций F
с
i
(D
i
) и F
т
i
(D
i
) на D
i
входном наборе к значению функции в
соответствии с выражением:
card F
т
=
((F
с
i
(D
i
) – F
т
i
(D
i
))/ F
т
i
(D
i
))/card F
т
.
i =1
a
14:
:
интероперабельность – свойство, обеспечивающее взаимодействие
системы в другой операционной среде;
a
15
: защищенность – атрибут, который показывает возможность компонента
(системы) фиксировать дефекты, а также ошибки, связанные с данными. Оценку
степени защищенности можно провести с помощью выражения a
15
= fal
z
/ fal, где
fal
z
– количество дефектов, от которых компонент защищен; fal – общее
количество дефектов в компоненте или системе;
a
16
: согласованность – атрибут, который показывает степень соблюдения
стандартов, правил и других соглашений.
Таким образом, характеристика функциональность q
1
вычисляется
суммированием ее атрибутов с учетом метрик и их весовых коэффициентов:
6
q
1
=
a
1j
m
1j W 1j
.
j=1
Надежность ПО – определяется как вероятность того, что компоненты
системы или сама система функционируют безотказно в течение фиксированного
232
периода времени в заданных условиях операционного окружения/среды. В модели
качества надежность задается на множестве атрибутов q
2
= {a
21
,
a
22
,
a
23
, a
24
},
которые определяют способность системы преобразовывать исходные данные в
результаты при условиях, зависящих от периода времени жизни системы (износ
и старение не учитываются).
Снижение надежности компонентов происходит из-за ошибок
проектирования. Отказы и ошибки в программных компонентах могут появляться
на заданном промежутке времени функционирования компонента/системы. К
атрибутам надежности относятся.
a
21
: безотказность – свойство системы функционировать без отказов
(программ или оборудования). Если компонент содержит дефект, то во множестве
D={De
e
L} всех дефектов, можно выделить подмножество E
D, для которых
результаты не соответствуют функции F
т
, заданной в требованиях на разработку.
Вероятность р безотказного выполнения компонента на De, случайно выбранном
из D среди равновероятных, равна:
р = 1– card {E}/ card {D}.
Отказ (failure) показывает отклонение поведения системы от предписанного
выполнения предписанных ей функций. Появление отказа может быть причиной
ошибки (fault/ error), вызывающей его. Если ошибка сделана человеком, то
используется термин mistake. Когда различие между fault и failure не критично
используется термин defect, означающий либо fault (причина), либо failure
(действие). Связь между этими понятиями такая: fault error failure.
Существует большое разнообразие видов отказов ПО, типичные из них:
внезапные, постепенные, перемещающиеся (сбои). Причины отказов могут быть
физические, структурные, отказы взаимодействия и др. Они могут возникать
естественным путём, вноситься человеком или внешней операционной средой в
период создания или эксплуатации системы, а также быть постоянными или
носить временный характер.
Наработка на отказ определяет среднее время между появлением угроз,
нарушающих безопасность, и обеспечивает трудно измеримую оценку ущерба,
которая наносится соответствующими угрозами.
Вычисление среднего времени Т наработки на отказ реализуется формулой
De
Т =
t
i
E
/ N,
I=1
где
t
i
E
– интервал времени безотказной работы компонента i –го отказа; N –
количество отказов в системе.
a
22
:
устойчивость к ошибкам показывает на способность программной
системы выполнять функции при аномальных условиях (сбоях аппаратуры,
ошибках в данных и интерфейсах, нарушениях в действиях операторов и др.).
Оценку устойчивости можно получить по формуле
= N
v
/N,
где N
v
– количество разных типов отказов, для которых предусмотрены средства
восстановления; N – общее количество всех отказов в системе.
a
23
: восстанавливаемость – свойство, показывающее способность возобновлять
функционирование системы после отказов для повторного исполнения. Среднее
время восстановления компонента можно определить по формуле
233
De
Т =
t
i
b
/ D,.
I=1
где
t
i
b
– время восстановления работоспособности компонента после i – отказа;
De – количество дефектов и отказов в системе.
a
24
: согласованность – атрибут, который показывает степень соблюдения
стандартов, правил и других соглашений.
Обнаруженные ошибки устраняются, а надежность системы возрастает. Чем
интенсивнее проводится эксплуатация, тем интенсивнее выявляются ошибки, и
обеспечивается рост надежности. Фактором, влияющим на оценку надежности
ПО, относится – угроза, приводящая к снижению безопасности системы и
ущербности всей системы.
В проблеме надежности ПО важное место занимает понятие устойчивости
системы к отказам ПО и возможности восстанавливаться самопроизвольно после
возникновения отказа. Количественная оценка надежности системы имеет вид
4
q
2
=
a
2j
m
2j W 2j.
j=1
Удобство применения – это множество свойств ПС, обеспечивающих условия
использования ее пользователями для получения необходимых результатов. Эта
характеристика определяется на множестве таких эргономичных атрибутов:
a
31
: свойство понимания выражается усилием, затрачиваемым на
распознавание логических концепций и условий применения программной
системы;
a
32
: свойство возможности изучения означает усилия отдельного пользователя
понять, как применяется ПО, как проводиться контроль (например, ввода, вывода
данных), а также процедур и документации;
a
33
: оперативность – реакция системы при выполнении разных операций и их
контроля;
a
34
: согласованность – соответствие программной системы требованиям
стандартов, соглашений, правил, законов и предписаний.
Все атрибуты оцениваются экспертами, которые в зависимости от их уровня
знаний дают соответствующие качественные заключения. Поэтому оценка
данной характеристики зависит от оценок экспертов и имеет вид:
4
q
3
=
a
3j
m
3j W 3j
.
j=1
Эффективность – свойства системы, которые показывают взаимосвязь
между уровнем ее выполнения, количеством используемых ресурсов (аппаратуры,
расходных материалов и др.), услуг штатного обслуживающего персонала и др.
К свойствам относятся:
a
41
: реактивность – время отклика, обработки и выполнения функций
компонентов/системы;
a
42
: эффективность – количество используемых ресурсов при выполнении
функций ПО и продолжительность их вычислений;
a
43
: согласованность – соответствие данного атрибута заданным стандартам,
правилам и предписаниям.
234
Количественная оценка данной характеристики имеет вид
3
q
4
=
a
4j
m
4j W 4j .
j=1
Сопровождаемость – множество свойств, которые отражают усилия,
которые затрачиваются на проведение модификаций, включая корректировку,
усовершенствование и адаптацию системы для новой среды выполнения, а также
требований или функциональных спецификаций. Данная характеристика в модели
качества состоит из следующих атрибутов:
a
52
: анализируемость – свойство, необходимое для проведения диагностики
отказов в ПО и идентификации частей системы с целью модификации;
a
53
: изменяемость – свойство, которое определяет возможность проведения
модификации компонента или системы с удалением ошибок при внесении
изменений, а также дополнения новых возможностей в систему или среду
функционирования;
a
54
:
стабильность – способность системы работать без ошибок и выполнять
необходимые функции без риска проведения ее модификации;
a
53
: тестируемость – свойство, обеспечивающее возможность верификации в
целях проверки правильности и возможного обнаружения разного рода ошибок, а
также валидации требований на соответствие их правильной реализации в системе;
a
54
: согласованность – соответствие данного атрибута определенным
стандартам, соглашениям, правилам и предписаниям.
Количественная оценка данной характеристики проводится экспертным и
аналитическим способом по формуле
3
q
5
=
a
5j
m
5j W 5j
.
j=1
Переносимость – множество атрибутов, указывающих на возможность
системы приспосабливаться к работе в новых условиях среды (организационной,
аппаратной и программной). Перенос на другую платформу или среду связан с
совокупностью действий по обеспечению возможности функционирования в
новой среде, отличной от той, в которой система создавалось. К атрибутам
данной характеристики относятся:
a
61:
адаптивность – способность системы адаптироваться к различным
операционным средам, она оценивается по формуле: a
61 =
Za / Zd, где
Za – затраты на адаптацию к новой операционной среде;
Zd – затраты на разработку новой системы для новой операционной среды;
a
62
: настраиваемость – атрибут, определяющий необходимые затраты на
запуск или инсталляцию программного продукта в другой среде;
a
63
: сосуществование – возможность использования специального ПО или
компонентов среды работать вместе в одной среде;
a
64
: заменяемость – возможность заменять отдельные компоненты другими с
условием обеспечения их взаимодействия (интероперабельности) с другими
программами и не совместной работы в заданных условиях среды;
a
65
: согласованность – соответствие стандартам или соглашениям и правилам
переноса программной системы в другую среду.
235
Количественная оценка данной характеристики с учетом соответствующих
метрик и их весов имеет вид
5
q
6
=
a
6j
m
6j W 6j
.
j=1
Комплексная оценка ПО. Если в требованиях к ПО было установлено
несколько показателей качества, то просчитанный каждый показатель качества
умножается метрику на соответствующий весовой коэффициент, а затем
проводится суммирование по всем показателям. В результате получается
интегральная оценка уровня качества ПО.
Приведенные формулы для оценки показателей качества с использованием
метрик a
i
A и весовых коэффициентов wi
W для каждого атрибута могут
использоваться отдельно для каждого компонента системы. Используя полученные
оценки q
j
характеристик качества применительно к отдельному компоненту (соm),
получаем интегральную оценку качества одного компонента в виде
6
Q
com
= q
j
.
j=1
Если ПС система содержит N–компонентов и для них проведена оценка, то
комплексная оценка качества системы (sys) имеет вид
N
Q
sys
=
Q
l
com
.
l=1
Заметим, имеются и другие подходы к аналитической оценки качества ПО,
приведенные в [6, 140].
8.4.2. МОДЕЛИ ПРЕДСТАВЛЕНИЯ ПРОЕКТНЫХ РЕШЕНИЙ НА ТЛ
К этой категории моделей относятся модели проектных М
ПТД
, ТП, ТЛ, ЖЦ и
эксплуатационных документов М
ЭПД
. Они задают структуру и содержание
проектных решений и соответствующих технологических документов, которые
создаются в ходе разработки ПС по ТЛ.
Модели М
ПТД
формализованного представления проектных решений в ходе
разработки образуют набор моделей, позволяющих осуществлять выполнение
следующих функций разработчика в процессе разработки:
– описания результатов проектных решении в ПТД табличной формы, принятой
в ТПР и в конкретных технологических линиях;
– проведения контроля процесса преобразования состояния программного
объекта и/или фиксации ошибки;
– занесения фрагментов текстов для включения в соответствующие разделы
документов программной документации согласно модели М
ЭТД
.
Выбор формы представления моделей ПТД для конкретной ТЛ зависит от
класса реализуемых объектов. Как показал опыт разработки, при проектировании
ПС, работающих с БД, используются модели типа «сущность – связь», для которых
применяются формы ПТД, более полно отображающие специфику программ их
реализации. Наиболее часто используемая формы ПТД приведены ниже в
таблицах.
236
Таблица 8.2
ТО
Таблица данных Лист
Поряд
ковый
номер
Уров
ень
Иденти
фи
катор
Тип Шаблон
Диапа
зон
Точ
-
ность
Начальное
значение
Приме-
чание
Таблица 8.3
ПМ Логика алгоритма
Лист Листов
1. Назначение
2. Среда
ЯП ОС Хранятся Память Время Системное ПО
3. Использует
4. Формирует
5. Тестирует
Модели М
тд
, М
тп
обеспечивают построение любых видов программ. Модель
процесса (линии) – это типовая структура (карта) процесса (линии) для
формализованного задания последовательности операций (процессов), связь между
которыми задается маршрутом, отображая взаимозависимость операций.
Модели М
гл
и М
тп
служат способом спецификации формируемых ФОТ и
моделирования процессов ЖЦ создаваемого программного объекта. М
тп
имеет вид:
М
тп
= { КТП, ТМШ, М
птд
, ТД
ТП
},
где КТП – структура карты процесса, принятая в ТПР (табл.8.4). для фиксации
операций процесса ЖЦ; ТМШ – графовая форма представления технологического
маршрута; Мптд – зафиксированные для данного ТП из множества ПТД модели
табличных документов, используемые при описании состояния программного
объекта на этом процессе; ТД
ТП
– структура технологических документов ТП для
описания прагматики и семантики процесса разработки соответствующего объекта
и его состояния.
Применяя структуру описания отдельного процесса, модель ТЛ можно пред-
ставить следующим образом: М
ТД
= {{М
i
ТП
} ТМШ
ТП
), i = N,1 .
Т а б л и ц а 8.4
КТП Карта технологического процесса Лист Листов
Код ТП Наименование ТП
ПТД
Исходные Выходные
Методы и средства
выполнения ТО
Код ТО
Наимено
вание
(краткое
содержа
ние)
Код Наиме-
нование
Код Наиме-
нование
Испол-
нитель
Техно-
логичес
-
кие
Инструмен
тальные
1 2 3 4 5 6 7 8 9
. . .
Разработал ФИО Подпись Дата
Принял
Утвердил
237
Здесь элементами модели являются наборы моделей ТП и модель
технологического маршрута линии. Модель ТЛ – абстрактная модель управления
процессом разработки ПС на инженерной основе с обратными связями и
дискретным характером взаимодействия между каждым ТП. ТЛ содержит
управляющую часть, представленную технологическим маршрутом, задающим
связи между процессами, и операционную, задаваемую картами ТП в виде набора
ТО.
Разделение ТЛ на управляющие и операционные элементы способствует ее
настройке на реальные условия, заключающиеся в конкретизации круга
специалистов, уточнении документов и инструментов и составлении сетевого
графика работ в соответствии с технологическим маршрутом.
Данное представление ТЛ определяет характер развития современных гибких
автоматизированных линий приема, передачи и обработки информации в среде
распределенных систем обработки информации (рис. 8.3).
Рис.8.3 Структура программно-технологического комплекса
Модель ЭПД это формализованным представлением принятой в ЕСПД
структуры каждого типа программной документации (ГОСТ 19.501 – 19.507–77),
полученным исходя из анализа требований ГОСТов и специфики представления
238
отдельных функций ПрО набором функционально-ориентированных заготовок.
Для них делается описание, которое затем используется при выводе программы из
ее модели по заготовкам. Эти описания размещаются в соответствующих местах
шаблонов документов.
Другим источником информации для формирования документации по М
ЭПД
являются ПТД, заполняемые в ходе разработки. Модель М
ЭПД
включает набор
подмоделей (структур) конкретных документов ЭПД. и базовых компонентов (М
бк
),
содержащих формальное описание общих для всех ЭПД элементов, т. е.
М
эпд
= { М
бк
. М
оп
, М
рпр
, М
рсрп
, М
ро
},
где М
оп
– модель описания применения; M
рпр
– модель руководства программиста;
М
рсрп
– модель руководства системного программиста;. М
ро
– модель руководства
оператора и др.
Представленный класс технологических моделей может пополняться новыми
моделями. Их состав и структура определяется на ТПР ПС соответствующего
класса и служит основой реализации ТЛ.
Модель жизненного цикла ПС. Процесс разработки ПС определяется
моделью ЖЦ, процессы которой будем отождествлять с технологическими
процессами. Для каждого ТП фиксируются начальное (S
0
), промежуточное (S
i
) и
конечное (S
k
) состояния разрабатываемого программного объекта. Переход объекта
из состояния S
i
; в S
i+1
на ТП связан с выполнением технологических операций этого
ТП. При этом для каждого типа ПП из заданного класса программных систем
может быть выбран свой набор ТП и состояний ТП, определяемых на множестве
исходных данных.
Приведенная на рис.8.2 схема среды проектирования соответствует методу
проектирования ПС сверху-вниз, при котором понятия (i+1)-го уровня (TП
i+1
)
описываются через элементарные понятия i-го уровня и представляют собой
данные, входящие в класс понятий состояния ПС. При этом не исключаются
переходы с одного уровня абстракции на другой (сверху вниз и снизу вверх).
Модель ТП. Выделение состава ТП и содержания технологических операций
зависит от класса ПС, используемой методологии и принятой организации
проведения работ. При определении состава и содержания ТП решается задача
обеспечения инженерной дисциплины разработки, основанной на современных
программных принципах, методах и инструментах, способствующих полному и
адекватному отображению понятий и функций реализуемой предметной области в
элементы состояния S (рис.8.4).
Основная цель выделяемых ТП
i
ТЛ состоит в получении некоторого
полуфабриката ПП (S
i
– состояние ПС), фрагментов ЭПД для проведения
экспертизы уровня и качества в соответствии с моделью качества М
кaч
. Каждый
ТП модели ЖЦ в общем виде определяет состояние элементов ПС, состав
технологических операций, обеспечивающих преобразование исходного состояния
ПС и получение его конечного состояния.
Таким образом, общая технологическая модель (схема) процесса разработки
является отражением модели ЖЦ, способов преобразования состояний ПС и может
быть представлена в виде
М
пр
= (S, ТП
i
, (ТО
j
), ТМ
j
), i = 7 0, , j = k 1, .
Множество состояний S рассматриваемой модели включает в себя:
S
0
– исходное (начальное) состояние – описание требований заказчика,
239
предъявляемых к данному ПС;
S
1
– состояние, включающее набор элементарных состояний, а именно, опи-
саний функций (S
1
1
), архитектуры (S
1
2
), структуры данных (S
1
3
) и т. п. средствами
языков спецификаций L
1
;
S
2
– состояние соответствует техническому проекту и включает описание в
классе языков L
2
алгоритмов функции (S
1
2
), данных (S
2
2
), интерфейсов (S
2
3
),
гипертекстов документации (S
2
4
), оценочных элементов модели качества (S
2
5
) и др.;
S
3
– состояние соответствует рабочему проекту и включает описание в ЯП
(класс L
3
,) текстов программ (S
3
1
), модулей (S
3
2
), тестов (S
3
3
) и т. п.;
S
4
–состояние соответствует отлаженным элементам программного продукта;
S
5
– состояние – это ПС после сборки;
S
6
– состояние ПС, соответствующее программному продукту, которое
испытывается, проверяется на соответствие заданным функциям и значениям
показателей качества;
S
7
; – состояние ПС на процессе сопровождения.
Технологический процесс, входящий в состав М
пр
, – промежуточный
(частичный) процесс, осуществляет преобразование S
i
-
го состояния ПС с
помощью набора ТО
j
ТП
i
данной М
пр
, поддерживаемых ТМ
j
(либо один ТМ
реализует несколько ТО).
Набор операций М
пр
не является фиксированным, он уточняется для каждого
типа ПС и описывается в технологических документах. Среди операций могут быть
типовые, используемые готовыми при создании конкретной технологии разработки
ПС определенного типа. Для обеспечения технологичности разработки в их состав
входят операции управления качеством разработки и формирования документации
на всех процессах ЖЦ в соответствии с системой моделей М
эпд
, определенной
выше.
Модель общего вида любого частичного ТП
i
представлена на рис.8.4.
Рис.8.4. Модель частичного ТП
i
процесса
Состояние объекта S
i
– определяется набором частичных его состояний S
i
1
, ... ,
S
i
k
, подаваемых на вход ТП
i
= {TO
k
}. Данный набор для конкретного ПС конечен.
Управление процессом преобразования состояний объекта S
0
в S
k
может быть
задано в виде графовой модели (соответствует технологическому маршруту), в
вершинах которой находятся процессы (или операции), а ребра задают
всевозможные переходы из одного состояния объекта в другое. Графовая модель
отображает способ ведения разработки с распараллеливанием работ и возвратами
(при ошибках) в предыдущие процессы (рис. 8.5).
240
Рис.8.5. Графовая модель технологического
процесса
Каждый частичный процесс ТП, является абстрактным конечным автоматом,
граф которого совпадает с технологическим маршрутом процесса, множество
состояний S
i
которого определено на совокупности операций {ТО
i
}
ТО данного
процесса.
Переход объекта из состояния S
i
в состояние S
i+1
может быть только под
действием технологического маршрута и осуществляется технологическим
диспетчером посредством выбора из множества операций процесса,
зафиксированных в карте i-го процесса, очередной операции при условии, что
результат предыдущей операции проанализирован и выполнен.
Задача выполнения i-го процесса заключается в переводе автомата из
некоторого промежуточного состояния объекта в другое S
i+1
с выполнением
операций преобразования, качественной или количественной оценки результата
разработки объекта и формирования фрагментов ЭПД по М
ЭПД
.
Таким образом, рассмотренные принципы и метод разработки ТЛ путем их
сборки, предопределили специфику языка формального описания ТЛ, а также
структуру модели качества, проектно–технологических и эксплуатационных
документов. Приведен набор таблиц, которые заполняются необходимыми для
моделей данными в среде программно-технологического комплекса. Предложена
общая структура процессов и линий.
8.5. СРЕДСТВА РАЗРАБОТКИ ФУНКЦИОНАЛЬНЫХ ПРОГРАММ
ПО ТЛ
Средства поддержки любой технологии программирования предполагают наличие
инструментальных ПС и правил их применения. Конкретные инструментальные
средства совместно с соответствующими процедурами их использования будем
называть технологическим модулем (ТМ). В качестве примеров рассмотрены
средства сборки программ ССПМ (прототип – система АПРОП [44, 125, 126]) из
модулей и проектирования методо-ориентированных ППП (прототип–комплекс
АПФОРС [118, 121]).
8.5.1. ТЕХНОЛОГИЧЕСКИЙ МОДУЛЬ СБОРКИ, ТЕСТИРОВАНИЯ
МОДУЛЕЙ ПС
Данный ТМ предназначен для:
– сборки, тестирования и отладки отдельных программных компонентов (ПК)
из модулей, написанных на различных ЯП и автономно отлаженных вне среды
данного ТМ;
– тестирования и отладки программного продукта из собранных и отлаженных
компонентов в среде данного ТМ (рис. 8.6);