Николай Соловьев - Системы автоматизации разработки программного обеспечения Страница 3

Последовательность технологических операций, характерная для технологий процедурного программирования, представлена на рисунке 1.7.

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

Рисунок 1.7 – Последовательность операций технологии процедурного программирования и их исполнители

На верхнем уровне рисунка 1.8 изображена архитектура таких программ.

Сложность программ в машинных кодах ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и место нахождения данных в физической памяти.

Появление АССЕМБЛЕРА и высокоуровневых языков FORTRAN, ALGOL позволило повысить сложность разрабатываемых ПО за счет использования подпрограмм. Однако слабым местом такой архитектуры было то, что при увеличении количества подпрограмм возрастала вероятность искажения части данных, которые не делились на глобальные и данные подпрограмм.

Рисунок 1.8 – Развитие архитектуры программ при технологиях процедурного и структурного программирования

Кроме того, разрабатываемое ПО с локальными данными по прежнему ограничивалось возможностью программиста отслеживать процессы их обработки. Это предопределило возникновение первого «кризиса программирования» (60-е годы ХХ-го века) – колоссальные успехи в области развития средств вычислительной техники пришли в противоречие с низкой производительностью труда программистов, отсюда проекты устаревали раньше, чем были готовы к внедрению. Появление операционных систем снизило остроту проблем. Однако оставалась разработка ПО «снизу-вверх» – подход при котором сначала разрабатывались сравнительно простые подпрограммы, из которых затем пытались построить сложную программу.

Отсутствие четких моделей описания подпрограмм и методов их проектирования, создание каждой подпрограммы превращалось в непростую задачу: интерфейсы подпрограмм получались сложными и при сборке программного продукта выявлялось большое количество ошибок согласования (80 % времени разработки ПО уходило на тестирование).

Таким образом, эволюция технологий разработки ПО является объективной реальностью и определяется необходимостью преодоления проблем, связанных с ростом сложности ПО, отсутствием автоматизированных средств описания программных систем, потребностью в коллективной разработке и увеличению степени повторяемости программного кода.

1.2.3 Вопросы и задания для самоконтроля

1 Дайте определение технологии проектирования ПО?

2 Что понимают под архитектурой ПО? 3 Что представляют собой модели ПО?

4 В каких случаях строятся модели?

5 Что является центральным процессом моделирования? Что включает в себя язык моделирования?

6 Перечислите последовательность операций технологии процедурного программирования.

7 Какие объекты включает в себя технологические операции?

8 Дайте определение методу проектирования.

9 В чем заключается сущность стихийного программирования?

10 Перечислите и поясните последовательность операций технологий процедурного программирования и их исполнителей.

1.3 Базовые технологии разработки программного обеспечения

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

1.3.1 Технологии на основе парадигмы структурного программирования

Дальнейший рост сложности разрабатываемого ПО потребовал структурирования данных и, как следствие, в языках появилась возможность определения пользовательских типов данных. Кроме того, анализ причин возникновения большинства ошибок технологии процедурного программирования позволил сформулировать новый подход к программированию, который был назван «структурным».

Сущность структурного подхода к разработке АИС заключается в декомпозиции проектируемой системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. В отличии от используемого ранее процедурного подхода к декомпозиции, структурный подход предполагает представление задачи в виде иерархии подзадач простейшей структуры (40..50 операторов). Проектирование осуществляется «свреху-вниз» и подразумевает реализацию общей идеи за счет разработки интерфейсов подпрограмм, а также специальный метод проектирования алгоритмов – метод пошаговой детализации.

При этом последовательность технологических операций, характерная для технологий структурного программирования, практически не изменилась (см. рисунок 1.8).

Все наиболее распространенные технологии структурного подхода базируются на ряде общих принципов:

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

– принцип иерархического упорядочивания – принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

– принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

– принцип структурирования данных – заключается в том, что данные должны быть структурированы и иерархически организованы.

Поддержка принципов структурного программирования заложено в основу так называемых структурных языков программирования – Pascal, C, PL/1.

В структурном анализе используются модели, иллюстрирующих функции, выполняемые системой, и модели, описывающие отношения между данными:

– SADT (Structured Analysis and Design Technique) – функциональные модели;

– DFD (Data Flow Diagrams) – диаграммы потоков данных;

– ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».

Технология SADT разработана Дугласом Россом и на ее основе принят известный стандарт IDEF0 (Icam DEFinition), который является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий). Технология возникла под влиянием PLEX, концепции клеточной модели человекоориентированных функций Хори, общей теории систем, технологий программирования и кибернетики.

SADT представляет собой совокупность концепций, нотаций и правил, предназначенных для построения функциональной модели объекта предметной области.

Элементы этой технологии основываются на концепции графического представление блочного моделирования – SADT-диаграммы отображают функции в виде блоков, взаимодействующих друг с другом посредством интерфейсных дуг. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

На рисунке 1.9 представлена основная нотация SADT-модели любой предметной области.

Рисунок 1.9 – Функциональный блок и интерфейсные дуги

Правила SADT включают:

– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

– связность диаграмм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен);

– разделение входов и управлений (правило определения роли данных) и отделение организации от функций, т.е. исключение влияния организационной структуры на функциональную модель.

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

Рисунок 1.10 – Декомпозиция диаграмм SADT-модели

Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме. Пример SADT-модели показан на рисунках 1.11 и 1.12, полученные в CASE-среде ВРwin.

Рисунок 1.11. – Исходная диаграмма SADT-модели

Рисунок 1.12 – Декомпозиция исходной диаграммы SADT-модели

Технология DFD. Графическая модель системы определяется как иерархия диаграмм потоков данных (ДПД), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы АИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее нецелесообразно.