3.2.Инструментальное по

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

1. анализ - определение требований к будущей программной системе;

2. проектирование - разработка модели программной системы;

3. программирование или кодирование - реализация программной системы на ЭВМ;

4. отладка - тестирование системы до начала эксплуатации с целью поиска и исправления ошибок, допущенных на этапах 1-3 при ее разработке;

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

После этапа сопровождения как правило снова начинается этап анализа следующей версии данного программного средства и т. д. Поэтому говорят о жизненном цикле или о спиралевидном развитии современного ПО ЭВМ.

Этапы 1-2 обеспечиваются главным образом системными аналитиками, этап 3 - программистами, этап 4 - тестерами (специалистами по поиску ошибок), этап 5 - настройщиками (специалистами по настройке систем под конкретные задачи) и тьюторами (специалистами по обучению персонала).

3.2.1.Развитие методологии анализа и проектирования по

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

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

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

Блок-схемы - это представление алгоритма при помощи представленных здесь (Рисунок 3 .38) и других аналогичных значков.

начало/конец процесса	линия процесса
действие	ввод/вывод
условие	соединение линий процесса

Рисунок 3.38. Основные значки блок-схем.

Рассмотрим пример применения блок-схем (Рисунок 3 .39) при проектировании алгоритма нахождения наименьшего общего делителя двух целых положительных чисел M и N. Согласно методу, предложенному древнегреческим математиком Евклидом, следует на каждом шаге большее из двух чисел заменять их разностью, а шаги эти циклически повторять до тех пор, пока оба числа не станут равными. Полученное число и есть наименьший общий делитель для исходной пары чисел.

Например, для пары чисел M=42 и N=24 имел бы место следующий пошаговый процесс:

Рисунок 3.39. Пример блок-схемы алгоритма

Шаг 1: для M=42 и N=24 берем новое M=42-24=18.

Шаг 2: для M=18 и N=24 берем новое N=24-18=6.

Шаг 3: для M=18 и N=6 берем новое M=18-6=12.

Шаг 4: для M=12 и N=6 берем новое M=12-6=6.

Процесс заканчивается при M=N=6, это и есть наименьший общий делитель для 42 и 24.

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

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

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

		M
A		B		C

Рисунок 3.40. Алгоритмическая декомпозиция (уров. абстракции 1).

Необходимость разработки все более и более сложных систем постепенно привела к несостоятельности и эту методологию. Развитием структурно-модульной методологии стала объектно-ориентированная методология (см. "Объектно-ориентированный анализ").

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

		A
A1		A2		A3

		B
B1		B2		B3

		C
C1		C2		C3

Рисунок 3.41. Алгоритмическая декомпозиция (уров. абстракции 2).

Пусть уровень абстракции 1 содержит единственную схему (Рисунок 3 .40): Главный алгоритм M вызывает подпрограммы A, B, C. Следовательно, единственная схема на данном уровне абстракции содержит 4 компонента.

Пусть уровень абстракции 2 содержит три указанные ниже схемы (Рисунок 3 .41):

Алгоритм A вызывает подпрограммы A1, A2, A3.

Алгоритм B вызывает подпрограммы B1, B2, B3.

Алгоритм C вызывает подпрограммы C1, C2, C3.

Далее рассматриваются уровни абстракции 3, 4, … Каждый алгоритм из вышеуказанного примера должен быть представлен в виде блок-схем.