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

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

В 1980-90 гг. для проектирования ПО большого объема предложена к использованию технология объектно-ориентированная программирования (ООП). ООП определяется как технология, основанная на представлении программной архитектуры в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию объектов.

Такая технология требует переосмысления роли фундаментальных понятий прикладных информационных технологий – модели и алгоритма(рисунок 1.19).

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

Именно модель представляет объект исследования и определяет характер формального аппарата, используемого для описания задачи и выполнения необходимых преобразований информации. Модель объекта вычислений определяет ЧТО надо вычислить, а алгоритм определяет КАК нужно вычислять. Простая истина – прежде, чем определить КАК , необходимо сформулировать ЧТО является объектом решения, т.е. построить модель, очевидна для всякой науки, использующей математику.

Рисунок 1.19 – Определения модели и алгоритма

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

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

Этап характеризуется появлением объектных языков программирования – Object Pascal, C++, в основе которых лежат следующие основные концепции:

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

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

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

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

Инкапсуляция– это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.

Наследование– это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью.

Полиморфизм– это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

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

Другой характерной особенностью технологии ООП является архитектура программы, представленная на рисунке 1.20.

Реализацией технологии ООП в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение технология быстрой разработки приложений RAD (Rapid Application Development).

Основные принципы (концепции) технологии RAD:

– разработка приложений итерациями;

– необязательность полного завершения работ на каждом из этапов ЖЦ;

– обязательное вовлечение пользователей в процесс разработки АИС;

– необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

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

– тестирование и развитие проекта одновременно с его разработкой;

– ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

Рисунок 1.21 – Архитектура программы при технологии ООП

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

– небольшую команду программистов (от 2 до 10 человек);

– короткий производственный график (от 2 до 6 мес.);

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

Этапы спиральной модели ЖЦ программных систем, выполняемых в соответствии с технологией RAD, представлены на рисунке 1.22.

Рисунок 1.22 – ЖЦ АИС по технологии RAD

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

На этапе проектированияпользователи принимают участие в техническом проектировании системы под руководством специалистов-разработчиков. CASEсредства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная схема (модель). Каждая функция рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этом этапе формируется список необходимой документации.