Файл: Технология раработки програмного обеспечения УП.pdf

11

2.1 

Анализ

требований

, 

предъявляемых

к

системе

На

первом

этапе,

часто

неоправданно

опускаемом,

опре-

деляются

требования,

которые

позволяют

получить

приемлемое

решение

проблемы.

На

этом

этапе

формулируются

целевое

на-

значение

и

основные

свойства

разрабатываемой

программной

системы.

Процесс

выполнения

работ

и

оформление

результатов

на

этом

этапе

проработаны

гораздо

в

меньшей

степени,

чем

на

других,

и

в

общем

случае

не

являются

объектом

деятельности

профессиональных

программистов.

Если

предметом

разработки

является

не

программная

сис-

тема,

а

более

сложный

объект

(например,

система

управления

технологическим

процессом),

включающий

программы

только

в

качестве

составной

части,

требования

формируются

ко

всему

предмету

разработки.

В

том

случае,

когда

разработка

про-

граммного

обеспечения

является

самоцелью,

обычно

использу-

ются

методы

составления

исходных

описаний.

Одним

из

самых

эффективных

методов

исходных

описаний

является

метод

структурного

анализа,

сущность

которого

сводится

к

декомпо-

зиции

исходного

объекта

на

его

составные

части

(рис.

2.2).

Рис.

2.2

—

Схема

декомпозиции

системы

A

12

Таким

образом,

создается

иерархия

связанных

подсистем

(обязательно

непересекающихся).

В

общем

случае,

анализ

требований,

предъявляемых

к

системе,

должен

быть

сосредоточен

на

интерфейсе

между

чело-

веком

(пользователем)

и

инструментом

(ЭВМ).

При

этом

для

программных

систем

можно

выделить

лишь

базовые

требова-

ния:

−

время

обработки

(работы)

программы;

−

стоимость

обработки;

−

вероятность

ошибки;

−

реакция

на

непредсказуемые

действия

оператора

(за-

щита

от

дурака

и

др.).

При

декомпозиции

требований

следует

делать

различия

между

жесткими

требованиями

и

требованиями,

выполнение

которых

не

является

строго

обязательным.

Особое

внимание

следует

уделять

пространственно-вре

-

менным

ограничениям

и

средствам

системы,

которые

в

буду-

щем

могут

претерпеть

изменения.

К

важнейшим

требованиям

относятся

ресурсные

требова-

ния

и

затраты

на

реализацию

системы.

Фактически,

анализ

требований

завершается

составлени-

ем

развернутого

технического

задания

на

систему,

которое

в

терминологии

классического

САПР

называется

аван-проектом.

2.2 

Определение

спецификаций

На

этапе

определения

спецификаций

осуществляется

точ-

ное

описание

функций,

реализуемых

ЭВМ,

а

также

задаются

структура

входных

и

выходных

данных,

методы

и

средства

их

размещения.

Определяются

алгоритмы

обработки

данных.

Центральным

вопросом

определения

спецификаций

явля-

ется

проблема

организации

базы

данных.

При

этом

решается

комплекс

вопросов,

имеющих

отношение

к

структуре

файлов,

организации

доступа

к

ним,

модификации

и

удалению.

В

случае,

когда

новая

система

создается

на

основе

суще-

ствующих,

составной

частью

спецификаций

является

схема

(ал-

горитм)

приведения

существующей

базы

данных

к

новому

формату.

Такое

преобразование

может

потребовать

разработку

13

специальной

программы,

которая

становится

ненужной

после

ее

первого

и

единственного

использования.

Все

эти

вопросы

должны

быть

отражены

в

функциональ-

ных

спецификациях,

которые

представляют

собой

документ,

являющийся

основополагающим

в

процессе

разработки

систе-

мы,

так

как

содержит

конкретное

описание

последней.

Чем

под-

робней

составлены

спецификации,

тем

меньше

вероятность

возникновения

ошибок.

В

спецификациях

должны

быть

представлены

данные

для

тестирования

элементов

системы

и

системы

в

целом.

Это

тре-

бование

является

объективным

и

обязательным,

т.к.

на

данном

этапе

на

параметры

тестирования

не

будет

оказывать

влияние

конкретная

реализация

системы.

Так

как

функциональные

спецификации

описывают

при-

нятые

решения

в

целом,

данный

документ

можно

использовать

для

начальных

оценок

временных

затрат,

числа

специалистов

и

других

ресурсов,

необходимых

для

проведения

работ.

В

общем

случае,

спецификации

определяют

те

функции,

которые

должна

выполнять

система,

не

указывая,

каким

обра-

зом

это

достигается.

Составление

подробных

алгоритмов

на

этом

этапе

преждевременно

и

может

вызвать

нежелательные

осложнения.

2.3 

Проектирование

На

стадии

проектирования

разрабатываются

алгоритмы,

задаваемые

спецификациями,

и

формируется

общая

структура

вычислительной

системы.

При

этом

система

разбивается

(при

необходимости)

на

составные

части

таким

образом,

чтобы

от-

ветственность

за

реализацию

каждой

составной

части

можно

было

бы

возложить

на

одного

разработчика

(или

группу

испол-

нителей).

При

этом

для

каждого

определенного

таким

образом

модуля

системы

должны

быть

сформированы

предъявляемые

к

нему

требования:

−

реализуемые

функции;

−

размеры;

−

время

выполнения

и

др.

14

В

целом

соотношения

«требования

—

спецификация

—

проектирование»

можно

проиллюстрировать

следующей

схемой

(рис.

2.3).

Рис.

2.3

—

Схема

проектирования

программных

систем

Прежде

всего

Заказчик

анализирует

и

формулирует

тре-

бования

реальности,

которые

находят

отображение

в

требова-

ниях,

предъявляемых

к

программной

системе.

Однако

ЭВМ

не

способна

решить

задачу

непосредственно,

реальные

данные

не-

обходимо

каким-то

образом

закодировать

и

ввести

в

ЭВМ.

По-

добная

модель

решаемой

задачи

представляет

собой

абстракт-

ное

выражение

реального

мира

и

отражается

в

спецификациях.

Если

спецификации

программы

определены,

возникает

необходимость

в

описании

процесса

обработки

информации,

что

относится

к

этапу

проектирования.

Поскольку

программа

должна

использоваться

для

реальной

задачи,

то

на

этапе

реали-

зации

проекта

(кодирование,

тестирование)

осуществляется

перевод

формального

проекта

в

выполняемую

программу.

И

наконец,

пользователь

может

сравнить

планируемую

функцию

программы

с

реализованной

функцией.

Эти

функции

очень

редко

совпадают

полностью.

Таким

образом,

сопровож-

дение

замыкает

цикл

проектирования

и

позволяет

изменить

сис-

темные

требования,

спецификации,

проекты

программ

и

т.п.

В

процессе

проектирования

системы,

по

мере

выполнения

спецификаций

на

определенные

подмодули,

последние

пред-

Реальный

мир

Абстракция

(формализация)

Требования

(1)

Спецификация

(2)

Проектирование

(3)

Реализация

(4)

15

ставляются

в

виде

древовидной

схемы,

показывающей

вхожде-

ние

элементов

системы

(рис.

2.4).

Рис.

2.4

—

Структурная

схема

компилятора 

Такая

схема

называется

базисной,

и

она

не

адекватна

спе-

цификациям.

Поскольку

в

начале

этапа

проектирования

реше-

ние

ряда

функциональных

задач

зачастую

не

определено,

про-

цесс

разбиения

на

подзадачи

может

быть

весьма

сложным.

В

проектировании

программных

систем

обычной

является

ситуа-

ция,

когда

Заказчик

не

знает,

что

точно

он

хочет.

Особенно

это

относится

к

процессам,

слабо

поддающимся

формализации

(ме-

дицина,

системы

военного

назначения

и

т.д.).

По

мере

разра-

ботки

проекта

Заказчик

меняет

спецификации.

Если

это

проис-

ходит

часто,

разработка

системы

существенно

усложняется.

Выход

из

таких

ситуаций

будет

нами

далее

проанализирован.

2.4 

Кодирование

Данный

этап

является

наиболее

простым,

а

его

реализа-

ция

существенно

облегчается

при

использовании

алгоритмиче-

ских

языков

высокого

уровня.

Кодирование

—

это

этап

разра-

ботки

программного

обеспечения,

доставляющий

наименьшее

беспокойство

разработчику.

По

имеющимся

статистическим

данным

64 %

всех

ошибок

вносятся

на

этапах

проектирования

и

Управляющая

программа

Генератор

кода

Синтаксический

анализатор

Вывод

на

печать

Программа

таблицы

символа

Блок

сканирования

Чтение