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

Рисунок 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 – Архитектура программы при технологии модульного программирования

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

1.3.2 Технологии на основе парадигмы объектно-ориентированного программирования

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

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

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

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

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

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

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

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

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

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

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

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

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