ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9466
Скачиваний: 184
приложений
) -
технология
,
организующая
доступ
к
данным
разных
компьютеров
с
учетом
балансировки
нагрузки
сети
.
Все
указанные
технологии
реализуют
компонентный
подход
,
заложенный
в
СОМ
.
Так
,
с
точки
зрения
СОМ
элемент
управления
ActiveX -
внутренний
сервер
,
поддерживающий
технологию
OLE-automation.
Для
программиста
же
элемент
ActiveX - «
черный
ящик
»,
обладающий
свойствами
,
методами
и
событиями
,
который
можно
использовать
как
строительный
блок
при
создании
приложений
.
Технология
CORBA,
разработанная
группой
компаний
ОМС
(Object Management Group -
группа
внедрения
объектной
технологии
программирования
),
реализует
подход
,
аналогичный
СОМ
,
на
базе
объектов
и
интерфейсов
CORBA.
Программное
ядро
CORBA
реализовано
для
всех
основных
аппаратных
и
программных
платформ
и
потому
эту
технологию
можно
использовать
для
создания
распределенного
программного
обеспечения
в
гетерогенной
(
разнородной
)
вычислительной
среде
.
Организация
взаимодействия
между
объектами
клиента
и
сервера
в
CORBA
осуществляется
с
помощью
специального
посредника
,
названного
VisiBroker,
и
другого
специализированного
программного
обеспечения
.
Отличительной
особенностью
современного
этапа
развития
технологии
программирования
,
кроме
изменения
подхода
,
является
создание
и
внедрение
автоматизированных
технологий
разработки
и
сопровождения
программного
обеспечения
,
которые
были
названы
CASE-
технологиями
(Computer-Aided Software/System Engineering -
разработка
программного
обеспечения
/
программных
систем
с
использованием
компьютерной
поддержки
).
Без
средств
автоматизации
разработка
достаточно
сложного
программного
обеспечения
на
настоящий
момент
становится
трудно
осуществимой
:
память
человека
уже
не
в
состоянии
фиксировать
все
детали
,
которые
необходимо
учитывать
при
разработке
программного
обеспечения
.
На
сегодня
существуют
CASE-
технологии
,
поддерживающие
как
структурный
,
так
и
объектный
(
в
том
числе
и
компонентный
)
подходы
к
программированию
.
Появление
нового
подхода
не
означает
,
что
отныне
все
программное
обеспечение
будет
создаваться
из
программных
компонентов
,
но
анализ
существующих
проблем
разработки
сложного
программного
обеспечения
показывает
,
что
он
будет
применяться
достаточно
широко
.
1.2.
Проблемы
разработки
сложных
программных
систем
Большинство
современных
программных
систем
объективно
очень
сложны
.
Эта
сложность
обуславливается
многими
причинами
,
главной
из
которых
является
логическая
сложность
решаемых
ими
задач
.
Пока
вычислительных
установок
было
мало
,
и
их
возможности
были
ограничены
,
ЭВМ
применяли
в
очень
узких
областях
науки
и
техники
,
причем
,
в
первую
очередь
,
там
,
где
решаемые
задачи
были
хорошо
детерминированы
и
требовали
значительных
вычислений
.
В
наше
время
,
когда
созданы
мощные
компьютерные
сети
,
появилась
возможность
переложить
на
них
решение
сложных
ресурсоемких
задач
,
о
компьютеризации
которых
раньше
никто
,
и
не
думал
.
Сейчас
в
процесс
компьютеризации
вовлекаются
совершенно
новые
предметные
области
,
а
для
уже
освоенных
областей
усложняются
уже
сложившиеся
постановки
задач
.
Дополнительными
факторами
,
увеличивающими
сложность
разработки
программных
систем
,
являются
[10]:
•
сложность
формального
определения
требований
к
программным
системам
;
•
отсутствие
удовлетворительных
средств
описания
поведения
дискретных
систем
с
большим
числом
состояний
при
недетерминированной
последовательности
входных
воздействий
;
•
коллективная
разработка
;
•
необходимость
увеличения
степени
повторяемости
кодов
.
Сложность
определения
требований
к
программным
системам
.
Сложность
определения
требований
к
программным
системам
обусловливается
двумя
факторами
.
Во
-
первых
,
при
определении
требований
необходимо
учесть
большое
количество
различных
факторов
.
Во
-
вторых
,
разработчики
программных
систем
не
являются
специалистами
в
автоматизируемых
предметных
областях
,
а
специалисты
в
предметной
области
,
как
правило
,
не
могут
сформулировать
проблему
в
нужном
ракурсе
.
Отсутствие
удовлетворительных
средств
формального
описания
поведения
дискретных
систем
.
В
процессе
создания
программных
систем
используют
языки
сравнительно
низкого
уровня
.
Это
приводит
к
ранней
детализации
операций
в
процессе
создания
программного
обеспечения
и
увеличивает
объем
описаний
разрабатываемых
продуктов
,
который
,
как
правило
,
превышает
сотни
тысяч
операторов
языка
программирования
.
Средств
же
позволяющих
детально
описывать
поведение
сложных
дискретных
систем
на
более
высоком
уровне
,
чем
универсальный
язык
программирования
,
не
существует
.
Коллективная
разработка
.
Из
-
за
больших
объемов
проектов
разработка
программного
обеспечения
ведется
коллективом
специалистов
.
Работая
в
коллективе
,
отдельные
специалисты
должны
взаимодействовать
друг
с
другом
,
обеспечивая
целостность
проекта
,
что
при
отсутствии
удовлетворительных
средств
описания
поведения
сложных
систем
,
упоминавшемся
выше
,
достаточно
сложно
.
Причем
,
чем
больше
коллектив
разработчиков
,
тем
сложнее
организовать
процесс
работы
[8].
Необходимость
увеличения
степени
повторяемости
кодов
.
На
сложность
разрабатываемого
программного
продукта
влияет
и
то
,
что
для
увеличения
производительности
труда
компании
стремятся
к
созданию
библиотек
компонентов
,
которые
можно
было
бы
использовать
в
дальнейших
разработках
.
Однако
в
этом
случае
компоненты
приходится
делать
более
универсаль
-
ными
,
что
в
конечном
итоге
увеличивает
сложность
разработки
.
Вместе
взятые
,
эти
факторы
существенно
увеличивают
сложность
процесса
разработки
.
Однако
очевидно
,
что
все
они
напрямую
связаны
со
сложностью
объекта
разработки
-
программной
системы
.
1.3.
Блочно
-
иерархический
подход
к
созданию
сложных
систем
Практика
показывает
,
что
подавляющее
большинство
сложных
систем
как
в
природе
,
так
и
в
технике
имеет
иерархическую
внутреннюю
структуру
.
Это
связано
с
тем
,
что
обычно
связи
элементов
сложных
систем
различны
как
по
типу
,
так
и
по
силе
,
что
и
позволяет
рассматривать
эти
системы
как
некоторую
совокупность
взаимозависимых
подсистем
.
Внутренние
связи
эле
-
ментов
таких
подсистем
сильнее
,
чем
связи
между
подсистемами
.
Например
,
компьютер
состоит
из
процессора
,
памяти
и
внешних
устройств
,
а
Солнечная
система
включает
Солнце
и
планеты
,
вращающиеся
вокруг
него
.
В
свою
очередь
,
используя
то
же
различие
связей
,
можно
каждую
подсистему
разделить
на
подсистемы
и
т
.
д
.
до
самого
нижнего
«
элементарного
»
уровня
,
причем
выбор
уровня
,
компоненты
которого
следует
считать
элементарными
,
остается
за
исследователем
.
На
элементарном
уровне
система
,
как
правило
,
состоит
из
немногих
типов
подсистем
,
по
-
разному
скомбинированных
и
организованных
.
Иерархии
такого
типа
получили
название
«
целое
-
часть
».
Поведение
системы
в
целом
обычно
оказывается
сложнее
поведения
отдельных
частей
,
причем
из
-
за
более
сильных
внутренних
связей
особенности
системы
в
основном
обусловлены
отношениями
между
ее
частями
,
а
не
частями
как
таковыми
.
В
природе
существует
еще
один
вид
иерархии
-
иерархия
«
простое
-
сложное
»
или
иерархия
развития
(
усложнения
)
систем
в
процессе
эволюции
.
В
этой
иерархии
любая
функционирующая
система
является
результатом
развития
более
простой
системы
.
Именно
данный
вид
иерархии
реализуется
механизмом
наследования
объектно
-
ориентированного
программирования
.
Будучи
в
значительной
степени
отражением
природных
и
технических
систем
,
программные
системы
обычно
являются
иерархическими
,
т
.
е
.
обладают
описанными
выше
свойствами
.
На
этих
свойствах
иерархических
систем
строится
блочно
-
иерархический
подход
к
их
исследованию
или
созданию
.
Этот
подход
предполагает
сначала
создавать
части
таких
объектов
(
блоки
,
модули
),
а
затем
собирать
из
них
сам
объект
.
Процесс
разбиения
сложного
объекта
на
сравнительно
независимые
части
получил
название
декомпозиции
.
При
декомпозиции
учитывают
,
что
связи
между
отдельными
частями
должны
быть
слабее
,
чем
связи
элементов
внутри
частей
.
Кроме
того
,
чтобы
из
полученных
частей
можно
было
собрать
разрабатываемый
объект
,
в
процессе
декомпозиции
необходимо
определить
все
виды
связей
частей
между
собой
.
При
создании
очень
сложных
объектов
процесс
декомпозиции
выполняется
многократно
:
каждый
блок
,
в
свою
очередь
,
декомпозируют
на
части
пока
не
получают
блоки
,
которые
сравнительно
легко
разработать
.
Данный
метод
разработки
получил
название
пошаговой
детализации
.
Существенно
и
то
,
что
в
процессе
декомпозиции
стараются
выделить
аналогичные
блоки
,
которые
можно
было
бы
разрабатывать
на
общей
основе
.
Таким
образом
,
как
уже
упоминалось
выше
,
обеспечивают
увеличение
степени
повторяемости
кодов
и
,
соответственно
,
снижение
стоимости
разработки
.
Результат
декомпозиции
обычно
представляют
в
виде
схемы
иерархии
,
на
нижнем
уровне
которой
располагают
сравнительно
простые
блоки
,
а
на
верхнем
-
объект
,
подлежащий
разработке
.
На
каждом
иерархическом
уровне
описание
блоков
выполняют
с
определенной
степенью
детализации
,
абстрагируясь
от
несущественных
деталей
.
Следовательно
,
для
каждого
уровня
используют
свои
формы
документации
и
свои
модели
,
отражающие
сущность
процессов
,
выполняемых
каждым
блоком
.
Так
для
объекта
в
целом
,
как
правило
,
удается
сформулировать
лишь
самые
общие
требования
,
а
блоки
нижнего
уровня
должны
быть
специфицированы
так
,
чтобы
из
них
действительно
можно
было
собрать
работающий
объект
.
Другими
словами
,
чем
больше
блок
,
тем
более
абстрактным
должно
быть
его
описание
(
рис
. 1.8).
При
соблюдении
этого
принципа
разработчик
сохраняет
возможность
осмысления
проекта
и
,
следовательно
,
может
принимать
наиболее
правильные
решения
на
каждом
этапе
,
что
называют
локальной
оптимизацией
(
в
отличие
от
глобальной
оптимизации
характеристик
объектов
,
которая
для
действительно
сложных
объектов
не
всегда
возможна
).
Примечание
.
Следует
иметь
в
виду
,
что
понятие
сложного
объекта
по
мере
совершенствования
технологий
изменяется
,
и
то
,
что
было
сложным
вчера
,
не
обязательно
останется
сложным
завтра
.
Итак
,
в
основе
блочно
-
иерархического
подхода
лежат
декомпозиция
и
иерархическое
упорядочение
.
Важную
роль
играют
также
следующие
принципы
:
•
непротиворечивость
—
контроль
согласованности
элементов
между
собой
;
•
полнота
-
контроль
на
присутствие
лишних
элементов
;
•
формализация
-
строгость
методического
подхода
;
•
повторяемость
-
необходимость
выделения
одинаковых
блоков
для
удешевления
и
ускорения
разработки
;
•
локальная
оптимизация
-
оптимизация
в
пределах
уровня
иерархии
.
Совокупность
языков
моделей
,
постановок
задач
,
методов
описаний
некоторого
иерархического
уровня
принято
называть
уровнем
проектирования
.
Каждый
объект
в
процессе
проектирования
,
как
правило
,
приходится
рассматривать
с
нескольких
сторон
.
Различные
взгляды
на
объект
проектирования
принято
называть
аспектами
проектирования
.
Помимо
того
,
что
использование
блочно
-
иерархического
подхода
делает
возможным
создание
сложных
систем
,
он
также
:
•
упрощает
проверку
работоспособности
,
как
системы
в
целом
,
так
и
отдельных
блоков
;
•
обеспечивает
возможность
модернизации
систем
,
например
,
замены
ненадежных
блоков
с
сохранением
их
интерфейсов
.
Необходимо
отмстить
,
что
использование
блочно
-
иерархического
подхода
применительно
к
программным
системам
стало
возможным
только
после
конкретизации
общих
положений
подхода
и
внесения
некоторых
изменений
в
процесс
проектирования
.
При
этом
структурный
подход
учитывает
только
свойства
иерархии
«
целое
-
часть
»,
а
объектный
-
использует
еще
и
свойства
иерархии
«
простое
-
сложное
».
1.4.
Жизненный
цикл
и
этапы
разработки
программного
обеспечения
Жизненным
циклом
программного
обеспечения
называют
период
от
момента
появления
идеи
создания
некоторого
программного
обеспечения
до
момента
завершения
его
поддержки
фирмой
-
разработчиком
или
фирмой
,
выполнявшей
сопровождение
.
Состав
процессов
жизненного
цикла
регламентируется
международным
стандартом
ISO/1EC
12207: 1995 «Information Technologe - Software Life Cycle Processes» («
Информационные
технологии
-
Процессы
жизненного
цикла
программного
обеспечения
»). ISO - International
Organization for Standardization -
Международная
организация
по
стандартизации
.
ГЕС
-
International Electrotechnical Commission -
Международная
комиссия
по
электротехнике
.
Этот
стандарт
описывает
структуру
жизненного
цикла
программного
обеспечения
и
его
процессы
.
Процесс
жизненного
цикла
определяется
как
совокупность
взаимосвязанных
действий
,
преобразующих
некоторые
входные
данные
в
выходные
.
На
рис
. 1.9
представлены
процессы
жизненного
цикла
по
указанному
стандарту
.
Каждый
процесс
характеризуется
определенными
задачами
и
методами
их
решения
,
а
также
исходными
данными
и
результатами
.
Процесс
разработки
(development process)
в
соответствии
со
стандартом
предусматривает
действия
и
задачи
,
выполняемые
разработчиком
,
и
охватывает
работы
по
созданию
программного
обеспечения
и
его
компонентов
в
соответствии
с
заданными
требованиями
,
включая
оформление
проектной
и
эксплуатационной
документации
,
а
также
подготовку
материалов
,
необходимых
для
проверки
работоспособности
и
соответствия
качества
программных
продуктов
,
материалов
,
необходимых
для
обучения
персонала
,
и
т
.
д
.
По
стандарту
процесс
разработки
включает
следующие
действия
:
•
подготовительную
работу
-
выбор
модели
жизненного
цикла
(
см
.
далее
),
стандартов
,
методов
и
средств
разработки
,
а
также
составление
плана
работ
;
•
анализ
требовании
к
системе
-
определение
ее
функциональных
возможностей
,
пользовательских
требований
,
требований
к
надежности
и
безопасности
,
требований
к
внешним
интерфейсам
и
т
.
д
.;
•
проектирование
архитектуры
системы
-
определение
состава
необходимого
оборудования
,
программного
обеспечения
и
операций
,
выполняемых
обслуживающим
персоналом
;
•
анализ
требований
к
программному
обеспечению
-
определение
функциональных
возможностей
,
включая
характеристики
производительности
,
среды
функционирования
компонентов
,
внешних
интерфейсов
,
спецификаций
надежности
и
безопасности
,
эргономических
требований
,
требований
к
используемым
данным
,
установке
,
приемке
,
пользовательской
документации
,
эксплуатации
и
сопровождению
;
•
проектирование
архитектуры
программного
обеспечения
-
определение
структуры
программного
обеспечения
,
документирование
интерфейсов
его
компонентов
,
разработку
предварительной
версии
пользовательской
документации
,
а
также
требований
к
тестам
и
плана
интеграции
;
•
детальное
проектирование
программного
обеспечения
–
подробное
описание
компонентов
программного
обеспечения
и
интерфейсов
между
ними
,
обновление
пользовательской
документации
,
разработка
и
документирование
требований
к
тестам
и
плана
тестирования
компонентов
программного
обеспечения
,
обновление
плана
интеграции
компонентов
;
•
кодирование
и
тестирование
программного
обеспечения
–
разработку
и
документирование
каждого
компонента
,
а
также
совокупности
тестовых
процедур
и
данных
для
их
тестирования
,
тестирование
компонентов
,
обновление
пользовательской
документации
,
обновление
плана
интеграции
программного
обеспечения
;
•
интеграцию
программного
обеспечения
-
сборку
программных
компонентов
в
соответствии
с
планом
интеграции
и
тестирование
программного
обеспечения
на
соответствие
квалификационным
требованиям
,
представляющих
собой
набор
критериев
или
условий
,
которые
необходимо
выполнить
,
чтобы
квалифицировать
программный
продукт
,
как
соответствующий
своим
спецификациям
и
готовый
к
использованию
в
заданных
условиях
эксплуатации
;
•
квалификационное
тестирование
программного
обеспечения
-
тестирование
программного
обеспечения
в
присутствии
заказчика
для
демонстрации
его
соответствия
требованиям
и
готовности
к
эксплуатации
;
при
этом
проверяется
также
готовность
и
полнота
технической
и
пользовательской
документации
•
интеграцию
системы
-
сборку
всех
компонентов
системы
,
включая
программное
обеспечение
и
оборудование
;
•
квалификационное
тестирование
системы
-
тестирование
системы
на
соответствие
требованиям
к
ней
и
проверка
оформления
и
полноты
документации
;
•
установку
программного
обеспечения
-
установку
программного
обеспечения
на
оборудовании
заказчика
и
проверку
его
работоспособности
;
•
приемку
программного
обеспечения
-
оценку
результатов
квалификационного
тестирования
программного
обеспечения
и
системы
в
целом
и
документирование
результатов
оценки
совместно
с
заказчиком
,
окончательную
передачу
программного
обеспечения
заказчику
.
Указанные
действия
можно
сгруппировать
,
условно
выделив
следующие
основные
этапы
разработки
программного
обеспечения
[10] (
в
скобках
указаны
соответствующие
стадии
разработки
по
ГОСТ
19.102-77 «
Стадии
разработки
»):