Текст книги "Системы автоматизации разработки программного обеспечения"

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

Сущность структурного подхода к разработке АИС заключается в декомпозиции проектируемой системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. В отличии от используемого ранее процедурного подхода к декомпозиции, структурный подход предполагает представление задачи в виде иерархии подзадач простейшей структуры (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. Графическая модель системы определяется как иерархия диаграмм потоков данных (ДПД), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы АИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процессы становятся элементарными и детализировать их далее нецелесообразно.

Основными нотациями ДПД являются: внешние сущности; системы/подсистемы; процессы; накопители данных; потоки данных. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.

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

Рисунок 1.13 – Внешняя сущность

Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой АИС.

На рисунке 1.14 изображена контекстная диаграмма подсистемы (системы). Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы – предложения с подлежащим и соответствующими определениями и дополнениями.

Рисунок 1.14 – Подсистема

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

Рисунок 1.15 – Процесс

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

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

Рисунок 1.16 – Накопитель данных

Накопитель данных идентифицируется буквой "D" и произвольным числом. Накопитель данных в общем случае является прообразом будущей базы данных и описание хранящихся в нем данных должно быть увязано с информационной моделью.

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

Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (рисунок 1.17). Каждый поток данных имеет имя, отражающее его содержание. Средой, использующей DFD-модели, является ВРwin, пример реализации которой показан на рисунке 1.17.

Рисунок 1.17 – Диаграмма потоков данных

Дальнейший рост сложности АИС потребовал разграничения доступа к глобальным данным программы. В результате технология структурного программирования получила развитие, отражением которого становится модульное программирования (70 гг. ХХ в.).

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

Архитектура программы при технологии модульного программирования показана на рисунке 1.18.

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

Эту технологию поддерживают современные версии высокоуровневых языков Turbo Pascal, С + и др.

Практика показала, что структурный подход в сочетании с модульным программированием позволяет получать достаточно надежные программные продукты, размер которых не превышает 100 000 операторов.

Рисунок 1.18 – Архитектура программы при технологии модульного программирования

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

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

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

Результаты этапа:

– общая информационная модель системы;

– функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

– точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

– прототипы экранов, отчетов, диалогов.

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

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

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

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

Таблица 1.1 – Характеристика приложений, реализуемых по технологии RAD

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

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

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

– изменение реализации одного объекта требует перекомпиляции всего программного продукта.

Таким образом, технология RAD эффективна для программных проектов средней сложности под конкретного заказчика. Разработка сложных программных систем (операционные системы, системы реального масштаба времени), т.е. программы с большим процентом уникального кода, требуют более высокого уровня планирования и жесткой дисциплины проектирования.

Для преодоления указанных недостатков ООП получил развитие компонентно-ориентированная парадигма программирования.

1 Что послужило формированию нового дохода к программированию который был назван «структурным».

2 В чем заключается сущность структурного подхода?

3 Охарактеризуйте технологию SADT. Перечислите правила SADT.

4 Охарактеризуйте технологию DFD. Дайте определение внешней сущности.

5 В чем заключается технология модульного программирования? Поясните архитектуру при технологии модульного программирования.

6 Поясните архитектуру программы при объектно – ориентированной технологии.

7 Дайте определение понятиям модель и алгоритм.

8 Перечислите последовательность операций технологии ООП.

9 Перечислите этапы спиральной модели ЖЦ АИС по технологии RAD. Охарактеризуйте каждый этап ЖЦ.

10 Перечислите недостатки характерные технологии RAD.