|
|
|
содержание .. 37 38 39 40 ..
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
Средства
верификации
служат
для
оценки
эффективности
исполнения
разрабатываемых
про
-
грамм
и
определения
наличия
в
них
ошибок
и
противоречий
.
Различают
статические
и
динамические
анализаторы
.
В
статических
анализаторах
ПО
исследуется
на
наличие
неопределенных
данных
,
бес
-
конечных
циклов
,
недопустимых
передач
управления
и
т
.
п
.
Динамический
анализатор
функциониру
-
ет
в
процессе
исполнения
проверяемой
программы
;
при
этом
исследуются
трассы
,
измеряются
часто
-
ты
обращений
к
модулям
и
т
.
п
.
Используемый
математический
аппарат
—
сети
Петри
,
теория
массо
-
вого
обслуживания
.
В
последнюю
из
перечисленных
групп
входят
документаторы
для
оформления
программной
до
-
кументации
,
например
,
отчетов
по
данным
репозитория
;
различные
редакторы
для
объединения
,
раз
-
деления
,
замены
,
поиска
фрагментов
программ
и
других
операций
редактирования
.
Проектирование
ПО
с
помощью
CASE-
систем
включает
в
себя
несколько
этапов
.
Начальный
этап
—
предварительное
изучение
проблемы
.
Результат
представляют
в
виде
исходной
диаграммы
потоков
данных
и
согласуют
с
заказчиком
.
На
следующем
этапе
выполняют
детализацию
ограничений
и
функ
-
ций
программной
системы
,
и
полученную
логическую
модель
вновь
согласуют
с
заказчиком
.
Далее
разрабатывают
физическую
модель
,
т
.
е
.
определяют
модульную
структуру
программы
,
выполняют
ин
-
фологическое
проектирование
БД
,
детализируют
граф
-
схемы
программной
системы
и
ее
модулей
.
*3.=+H+7
:=++
384.7-
4
9
384@8://016
,+,-./
.
Важное
значение
в
процессе
разработки
ПО
имеют
средства
спецификации
проектов
ПО
.
Средства
спецификации
в
значительной
мере
определя
-
ют
суть
методов
CASE.
Способы
и
средства
спецификации
классифицируют
по
базовой
методологии
,
используемой
для
декомпозиции
ПО
,
как
сложной
системы
,
и
по
аспектам
моделирования
ПО
.
Различают
два
подхода
к
декомпозиции
ПО
Первый
способ
называют
E7*%=’#*)45*./
или
+&"7%&7"*./
.
Он
основан
на
выделении
функций
и
потоков
данных
.
Второй
способ
–
#23$%&*.;
,
вы
-
ражает
идеи
объектно
-
ориентированного
проектирования
и
программирования
.
Проектирование
ПО
из
готовых
компонентов
,
рассмотренное
в
предыдущей
главе
,
есть
выражение
объектного
подхода
.
Аспектами
моделирования
приложений
являются
функциональное
,
поведенческое
и
информа
-
ционное
описания
.
Практически
все
способы
E7*%=’#*)45*.,
спецификаций
имеют
следующие
общие
черты
:
—
модель
имеет
иерархическую
структуру
,
представляемую
в
виде
диаграмм
нескольких
уровней
;
—
элементарной
частью
диаграммы
каждого
уровня
является
конструкция
вход
-
функция
-
выход
;
—
необходимая
дополнительная
информация
содержится
в
файлах
поясняющего
текста
.
В
большинстве
случаев
функциональные
диаграммы
являются
диаграммами
потоков
данных
(DFD — Data Flow Diagram).
В
DFD
блоки
(
прямоугольники
)
соответствуют
функциям
,
дуги
—
вход
-
ным
и
выходным
потокам
данных
.
Поясняющий
текст
представлен
в
виде
“
словарей
данных
”,
в
кото
-
рых
указаны
компонентный
состав
потоков
данных
,
число
повторений
циклов
и
т
.
п
.
Для
описания
структуры
информационных
потоков
можно
использовать
нотацию
Бэкуса
-
Наура
.
Одна
из
нотаций
для
DFD
предложена
Е
.
Йорданом
.
В
ней
описывают
процессы
(
функции
),
по
-
токи
данных
,
хранилища
и
внешние
сущности
,
их
условные
обозначения
показаны
на
рис
. 6.
1
.
Разработка
DFD
начинается
с
построения
диа
-
граммы
верхнего
уровня
,
отражающей
связи
про
-
граммной
системы
,
представленной
в
виде
единого
процесса
,
с
внешней
средой
.
Декомпозиция
процесса
проводится
до
уровня
,
на
котором
фигурируют
эле
-
ментарные
процессы
,
которые
могут
быть
представ
-
лены
одностраничными
описаниями
алгоритмов
(
миниспецификациями
)
на
терминальном
языке
про
-
граммирования
.
Для
описания
’*E#"/)=’#**.,
моделей
наибольшее
распространение
получили
диаграммы
сущность
-
связь
(ERD — Entity-Relation Diagrams),
в
которых
предусмотрены
средства
для
описания
сущностей
,
атрибутов
и
отношений
.
Спецификации
хранилищ
данных
в
CASE,
как
правило
,
даются
с
помощью
диаграмм
сущность
-
связь
Стандартной
методикой
построения
таких
диаграмм
является
IDEF
1
X.
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
155
%+,
. 6.
)
.
Изображения
элементов
в
нотации
Йордана
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
!#($-$*1$+%’$
модели
описывают
процессы
обработки
информации
.
В
инструментальных
CASE-
системах
их
представляют
в
виде
граф
-
схем
,
диаграмм
перехода
состояний
,
таблиц
решений
,
псевдокодов
(
языков
спецификаций
),
процедурных
языков
программирования
,
в
том
числе
языков
четвертого
поколения
.
В
граф
-
схемах
блоки
,
как
и
в
DFD,
используют
для
задания
процессов
обработки
,
но
дуги
име
-
ют
иной
смысл
—
они
описывают
последовательность
передач
управления
(
вместе
с
специальными
блоками
управления
).
В
диаграммах
перехода
состояний
узлы
соответствуют
состояниям
моделируемой
системы
,
ду
-
ги
—
переходам
из
состояние
в
состояние
,
атрибуты
дуг
—
условиям
перехода
и
инициируемым
при
их
выполнении
действиям
.
Очевидно
,
что
как
и
в
других
конечно
-
автоматных
моделях
,
кроме
графи
-
ческой
формы
представления
диаграмм
перехода
состояний
,
можно
использовать
также
табличные
формы
.
Так
,
при
изоморфном
представлении
с
помощью
таблиц
перехода
состояний
каждому
перехо
-
ду
соответствует
строка
таблицы
,
в
которой
указываются
исходное
состояние
,
условие
перехода
,
ини
-
циируемое
при
этом
действие
и
новое
состояние
после
перехода
.
Близкий
по
своему
характеру
способ
описания
процессов
основан
на
таблицах
(
или
деревьях
)
решений
.
Каждый
столбец
таблицы
решений
соответствует
определенному
сочетанию
условий
,
при
выполнении
которых
осуществляются
действия
,
указанные
в
нижерасположенных
клетках
столбца
.
Таблицы
решений
удобны
при
описании
процессов
с
многократными
ветвлениями
.
В
этих
слу
-
чаях
помогают
также
визуальные
языки
программирования
,
в
которых
для
описания
процессов
ис
-
пользуют
графические
элементы
,
подобные
приведенным
на
рис
. 6.2.
В
псевдокодах
алгорит
-
мы
записываются
с
помощью
как
средств
некоторого
языка
программирования
(
преиму
-
щественно
для
управляющих
операторов
),
так
и
естествен
-
ного
языка
(
для
выражения
содержания
вычислительных
блоков
).
Используются
кон
-
струкции
(
операторы
)
следо
-
вания
,
условные
,
цикла
.
Слу
-
жебные
слова
из
базового
языка
программирования
или
из
DFD
записываются
заглавными
буквами
,
фразы
естественного
языка
—
строчными
.
Языки
четвертого
поколения
предназначены
для
описания
программ
как
совокупностей
заранее
разработанных
программных
модулей
.
Поэтому
одна
команда
языка
четвертого
поколения
может
со
-
ответствовать
значительному
фрагменту
программы
на
языке
3GL.
Примерами
языков
4GL
могут
слу
-
жить
Informix-4GL, JAM, NewEra, XAL.
Миниспецификации
процессов
могут
быть
выражены
с
помощью
псевдокодов
(
языков
специфи
-
каций
),
визуальных
языков
проектирования
или
языков
программирования
,
Объектный
подход
представлен
компонентно
-
ориентированнными
технологиями
разработки
ПО
.
При
объектном
подходе
ПО
формируется
из
компонентов
,
объединяющих
в
себе
алгоритмы
и
данные
и
взаимодействующих
путем
обмена
сообщениями
.
Для
поддержки
объектного
подхода
раз
-
работан
стандартный
язык
моделирования
приложений
UML.
M
.
604
D4@++
8.+0L+0+8+0@:
+
3:8:
DD.DF04@
4
384.7-+84
9:0+>
.
Взаимосвязанная
совокуп
-
ность
методик
IDEF
для
концептуального
проектирования
разработана
по
программе
Integrated
Computer Aided Manufacturing
в
США
.
В
этой
совокупности
имеются
методики
функционального
,
ин
-
формационного
и
поведенческого
моделирования
и
проектирования
,
в
ее
состав
в
настоящее
время
входят
IDEF-
методики
,
представленные
в
приложении
(
табл
.
П
.
1
),
часть
из
которых
имеет
статус
меж
-
дународного
стандарта
.
Методики
IDEF
задают
единообразный
подход
к
моделированию
приложений
,
но
не
затрагива
-
&
.
+
.
)
"#$%!#&’&($"!))$* +($*,#&($"!)&*
156
%+,
. 6.2.
Примеры
описания
операторов
в
визуальных
языках
программирования
%
*#$A&,& +($*,#&($"!)&P !"#$%!#&’&($"!))KH :&:#*%
5
@!"!
6
ют
проблем
единообразного
представления
данных
в
процессах
информационного
обмена
между
раз
-
ными
компьютерными
системами
и
приложениями
.
Необходимость
решения
этих
проблем
в
интегри
-
рованных
АС
привела
к
появлению
ряда
унифицированных
форматов
представления
данных
в
меж
-
компьютерных
обменах
,
среди
которых
наиболее
известными
являются
форматы
IGES, DXF (
в
маши
-
ностроительных
приложениях
), EDIF (
в
электронике
)
и
некоторые
другие
.
Однако
ограниченные
воз
-
можности
этих
форматов
обусловили
продолжение
работ
в
направлении
создания
более
совершенных
методик
и
представляющих
их
стандартов
.
На
эту
роль
в
настоящее
время
претендует
совокупность
стандартов
STEP.
E
.-
4
5+7
:
IDEF0.
Как
отмечено
выше
,
наиболее
известной
методикой
E7*%=’#*)45*#8#
/#-$
-
4’"#()*’9
сложных
систем
является
методика
SADT (Structured Analysis and Design Technique),
поло
-
женная
в
основу
стандарта
IDEF0.
IDEF0 —
это
более
четко
очерченное
представление
методики
SADT. SADT —
методика
,
реко
-
мендуемая
для
начальных
стадий
проектирования
сложных
искусственных
систем
управления
,
про
-
изводства
,
бизнеса
,
включающих
людей
,
оборудование
,
ПО
.
Начиная
с
момента
создания
первой
вер
-
сии
,
методика
успешно
применялась
для
проектирования
телефонных
сетей
,
систем
управления
воз
-
душными
перевозками
,
производственных
предприятий
и
др
.
Разработку
SADT-
модели
начинают
с
формулировки
вопросов
,
на
которые
модель
должна
да
-
вать
ответы
,
т
.
е
.
формулируют
цель
моделирования
.
Далее
строят
иерархическую
совокупность
диа
-
грамм
с
лаконичным
описанием
функций
.
Недостатки
SADT-
моделей
—
их
слабая
формализованность
для
автоматического
выполнения
проектных
процедур
на
их
основе
.
Однако
наличие
графического
языка
диаграмм
,
удобного
для
вос
-
приятия
человеком
,
обусловливает
полезность
и
применимость
методики
SADT.
Описание
объектов
и
процессов
в
SADT (IDEF0)
выполняется
в
виде
совокупности
взаимосвя
-
занных
блоков
(
рис
. 6.3).
Блоки
выражают
функции
(
работы
),
поэтому
их
назва
-
ниями
обычно
являются
глаголы
или
отглагольные
существи
-
тельные
.
Типичные
примеры
функций
:
планировать
,
разрабо
-
тать
,
классифицировать
,
измерить
,
изготовить
,
отредактиро
-
вать
,
рассчитать
,
продать
(
или
планирование
,
разработка
,
классификация
,
измерение
,
изготовление
,
редактирование
,
расчет
,
продажа
).
Число
блоков
на
одном
уровне
иерархии
—
не
более
6,
иначе
восприятие
диаграмм
будет
затруднено
.
Число
уровней
иерархии
не
ограничено
,
но
обычно
их
не
более
5.
Блоки
нумеруются
(
номер
записы
-
вается
в
правом
нижнем
углу
).
Дуги
(
стрелки
)
отображают
множества
объектов
(
данных
),
их
имена
—
существительные
.
Управление
определяет
условия
выполнения
,
примеры
управления
:
требования
,
чертеж
,
стандарт
,
указания
,
план
.
Механизм
выражает
используемые
средства
,
например
:
компьютер
,
оснастка
|