Технологии программирования

Нисходящая и восходящая разработка программного обеспечения.

При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют два подхода:

восходящий;

нисходящий.

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

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

увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций;

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

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

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

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

Программирование «с защитой от ошибок».

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



Рис. 8.2. Способы проявления ошибок

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

Детальный анализ ошибок и их возможных ранних проявлений показывает, что целесообразно проверять:

правильность выполнения операций ввода-вывода;

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

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

ошибки передачи - аппаратные средства, например, вследствие неисправности, искажают данные;

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

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

ошибки данных - пользователь вводит неверные данные. Ошибки передачи обычно контролируются аппаратно.

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

Основные подходы программирования, «стихийное» программирование.

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

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

Основные подходы программирования, структурный подход к программированию.

Второй этап - структурный подход к программированию (60-70-с годы XX в.). Структурный подход к программированию представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения. В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40-50 операторов) подпрограмм. С появлением других принципов декомпозиции (объектного, логического и т. д.) данный способ получил название процедурной декомпозиции.

Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Среди наиболее известных языков этой группы стоит назвать PL/1, ALGOL-68, Pascal, С.

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

Основные подходы программирования, объектный подход к программированию.

Третий этап - объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.). Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.

Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т. д.

Основные подходы программирования, компонентный подход и CASE-технологии.

Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model - компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture - общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации.

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

Объект всегда функционирует в составе сервера - динамической библиотеки или исполняемого файла, которые обеспечивают функционирование объекта. Различают три типа серверов:

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

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

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

Процедурное (императивное) программирование

Процедурное (императивное) программирование является отражением архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 40-х годах. Теоретической моделью процедурного программирования служит алгоритмическая система под названием «машина Тьюринга».

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

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

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

необходимостью явного управления памятью, в частности, описанием переменных;

малой пригодностью для символьных вычислений;

отсутствием строгой математической основы;

высокой эффективностью реализации на традиционных ЭВМ.

Функциональное программирование.

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

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

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

Наиболее общие принципы функционального программирования:

1)Унификация понятий <функция> и <значение>. 2)Кроме функций-констант, вполне допустимы функции-переменные.3)Самоприменимость.4)Интегральность ограничений на пространственно-временные характеристики.5)Уточняемость решений.6) Множественность определений.

Функциональное программирование отличается от большинства подходов к программированию тремя важными принципами:

1)Природа данных. Все данные представляются в форме символьных выражений, наз. S-выражениями. 2)Самоописание обработки символьных выражений. Важная особенность функционального программирования состоит в том, что описание способов обработки S-выражений представляется программами, рассматриваемыми как символьные данные.

3)Подобие машинным языкам

Система функционального программирования допускает, что программа может интерпретировать и/или компилировать программы, представленные в виде S-выражений. Это сближает методы функционального программирования с методами низкоуровнего программирования и отличает от традиционной методики применения языков высокого уровня.

38. Декларативное программирование

Декларативная парадигма программирования определяет процесс вычислений посредством описания логики самого вычисления, а не управляющей логики программы.

Декларативное программирование является противоположностью императивного программирования; первое описывает, что необходимо сделать, а второе -- как именно это сделать. Фактически, декларативное программирование часто определяется как любой стиль программирования, не являющийся императивным, т.к. последнему легче дать определение.

Наиболее существенными классами декларативных языков являются функциональные (functional) или аппликативные, и логические (logic) языки. К категории функциональных языков относятся, например, Lisp и Haskell. Самым известным языком логического программирования является Prolog (Пролог).

Объектно-ориентированное программирование

Объемктно-ориентимрованное программимрование (ООП) -- парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, -- прототипов).

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

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

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

Прототип -- это объект-образец, по образу и подобию которого создаются другие объекты.

Абстракция данных 

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

Инкапсуляция 

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

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

Наследование 

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

Полиморфизм 

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

40.Объектно-ориентированные языки программирования.

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

Объявление классов с полями (данными -- членами класса) и методами (функциями -- членами класса).

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

Средства защиты внутренней структуры классов от несанкционированного использования извне. Обычно это модификаторы доступа к полям и методам, типа public, private, обычно также protected, иногда некоторые другие.

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

Полиморфное поведение экземпляров классов за счёт использования виртуальных методов. В некоторых ООП-языках все методы классов являются виртуальными.

Но большинство языков добавляют к указанному минимальному набору те или иные дополнительные средства. В их числе:

Конструкторы, деструкторы, финализаторы.

Свойства (аксессоры).

Индексаторы.

Интерфейсы (например, в Java используются также как альтернатива множественному наследованию -- любой класс может реализовать сколько угодно интерфейсов).

Переопределение операторов для классов.

Часть языков (иногда называемых «чисто объектными») целиком построена вокруг объектных средств -- в них любые данные (возможно, за небольшим числом исключений в виде встроенных скалярных типов данных) являются объектами, любой код -- методом какого-либо класса, и невозможно написать программу, в которой не использовались бы объекты. Примеры подобных языков -- C#, Smalltalk, Java, Ruby. Другие языки (иногда используется термин «гибридные») включают ООП-подсистему в исходно процедурный язык. В них существует возможность программировать, не обращаясь к объектным средствам. Классические примеры -- C++ и Delphi.

Спецификация программного обеспечения при структурном подходе.

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

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

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

Б. требование точности означает, что спецификации должны однозначно восприниматься как заказчиком, так и разработчиком.

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

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

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

Диаграммы переходов состояний.

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

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

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



Рис 11.3. Условные обозначения диаграмм переходов состояний: а - терминальное состояние, б - промежуточное состояние; в - переход

Функциональные диаграммы

Диаграмма функционального моделирования - инструмент разработки функциональных спецификаций в виде диаграмм, фрагментов текста и глоссария, связанных перекрестными ссылками. В состав диаграммы входят:

- блоки, изображающие активность моделируемой системы; и

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

В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга:

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

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

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

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

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

Диаграмма потоков данных

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

ДПД содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные.

На ДПД процесс изображается в виде эллипса, внутри которого помещается имя процесс

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

Хранилище данных - это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа.

ДПД показывает все пути вычисления значений, но не показывает в каком порядке значения вычисляются.

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

Моделирование управляющих процессов с помощью диаграмм потоков данных

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

Управляющий процесс получает с помощью управляющих потоков некоторую информацию о ситуации в системе и инициирует посредством управляющего потока соответствующие процессы.

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

Т-поток (Trigger Flow - тригерный поток) - поток управления, который может только «включать» процесс - следующий управляющий сигнал опять «включит» процесс, даже если процесс уже активен;

А-поток (Activator Flow - активирующий поток) - поток управления, который может как «включать», так и «выключать» управляемый процесс - если процесс включен, то следующий сигнал его выключит;

E/D-поток (Enable/Disable Flow - переключающий поток) - поток управления, который может включать процесс сигналом по одной (Е) линии и выключать - сигналом по другой (D) линии.

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

Рис. 11.16. Узел изменения типа потока данных

Структуры данных и диаграммы отношений компонентов данных

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

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

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

В первую группу входят множества и кортежи. Наиболее существенная характеристика элемента данных в этих структурах - его принадлежность некоторому набору, т. е. отношение вхождения. Данные абстрактные структуры используют, если никакие другие отношения элементов не являются существенными для описываемых объектов

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

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

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

Диаграммы Джексона.

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

Каждая конструкция представляется в виде двухуровневой иерархии, на верхнем уровне которой расположен блок конструкции, а на нижнем - блоки элементов. Нотации конструкций различаются специальными символами в правом верхнем углу блоков элементов. В изображении последовательности дополнительный символ отсутствует. В изображении выбора ставится символ «о» (латинское) - сокращение английского «или» (or). Конструкции последовательности и выбора должны содержать по два или более элементов второго уровня. В изображении повторения в блоке единственного (повторяющегося) элемента ставится символ «*».

Так схема, показанная на рис. 11.22, а, означает, что конструкция A состоит из элементов В, С и D, следующих в указанном порядке. Схема на рис. 11.22, б означает, что конструкция S состоит либо из элемента Р, либо из элемента Q, либо из элемента R. Схема, изображенная на рис. 11.22, в, показывает, что конструкция I может не содержать элементов или содержать один или более элементов X.

Рис. 11.22. Нотация Джексона для представления конструкций: а - последовательность, б - выбор; в - повторение

В случае если необходимо показать, что конструкция повторения должна включать один или более элементов, используют комбинацию из двух структур последовательности и повторения (рис. 11.23).

Скобочные диаграммы Орра

Диаграмма Орра базируется на том же предположении о сходстве структур программ и данных, что и диаграмма Джексона. Отличие состоит лишь в нотации. Автор предлагает для представления конструкций данных использовать фигурные скобки (рис. 11.24).

Рис 11.23. Пример описания конструкции, в которой повторение встречается один или более раз

Рис. 11.24. Скобочная нотация для представления структур данных Орра: а - последовательность; б - выбор; в - повторение

Сетевая модель данных

Сетевые модели данных используют в тех случаях, если отношение между компонентами данных не исчерпываются включением. Для графического представления разновидностей этой модели используют несколько нотаций. Наиболее известны из них следующие: нотация П. Чена; нотация Р. Баркера; нотация IDEF1 (более современный вариант этой нотации - IDEF1X используется в CASE-системах, например, в системе ERWin).

Базовыми понятиями сетевой модели данных являются: сущность, атрибут и связь.

Сущность -- реальный или воображаемый объект, имеющий существенное значение для рассматриваемой предметной области.

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

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

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

Различают три типа отношений: 1х1, 1хМ, МхМ. Кроме того, сущности бывают независимыми, зависимыми и ассоциированными.

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

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

Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.

Проектирование программного обеспечения при структурном подходе

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

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

В любом случае проектирование программного обеспечения начинают с определения его структуры.

Разработка структурной и функциональной схем

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

Структурная схема разрабатываемого программного обеспечения

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

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

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

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

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

Функциональная схема

Функциональная схема или схема данных - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Основные обозначения схем данных по ГОСТ 19. 701-90 приведены в табл. 12. 1.

Функциональные схемы, более информативны, чем структурные. На рис. 12. 3 для сравнения приведены функциональные схемы программных комплексов и систем.

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

Метод пошаговой детализации для проектирования структуры ПО

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

Метод пошаговой детализации реализует нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг при этом включает разложение функции на подфункции.

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

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

Структурные карты Констайна.

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

Рис. 12.8. Обозначения типа вызова: а - последовательный вызов, б - параллельный вызов; в - вызов сопрограммы

Рис. 12.10. Обозначения особых условий вызова: а - циклический; б- условный, в - однократный



Рис 12.11. Обозначение типа связи: а - по данным; б - по управлению

Проектирование структур данных

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

Вид хранимой информации определяет тип соответствующего поля памяти. В качестве элементов данных в зависимости от используемого языка 'программирования могут рассматриваться:

целые и вещественные числа различных форматов; символы; булевские значения: true и false; а также некоторые структурные типы данных, например: ¦сстроки; записи; специально объявленные классы.

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

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

Представление данных в оперативной памяти

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

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

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

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

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

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

Представление данных во внешней памяти

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

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

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

При выборе типа памяти для размещения структур данных следует иметь в виду, что:

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

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

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

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

Проектирование программного обеспечения, основанное на декомпозиции данных Методикой Джексона

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

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

Разработка структуры программы в соответствии с методикой выполняется следующим образом:

строят изображение структур входных и выходных данных;

выполняют идентификацию связей обработки (соответствия) между этими данными;

формируют структуру программы на основании структур данных и обнаруженных соответствий;

добавляют блоки обработки элементов, для которых не обнаружены соответствия;

анализируют и обрабатывают несоответствия, т.е. разрешают «столкновения»;

добавляют необходимые операции (ввод, вывод, открытие/закрытие файлов и т. п.);

записывают программу в структурной нотации (псевдокоде).

Проектирование программного обеспечения, основанное на декомпозиции данных Методикой Варнье-Орра

Методика Варнье-Орра базируется на том же положении, что и методика Джексона, но основными при построении программы считаются структуры выходных данных и, если структуры входных данных не соответствуют структурам выходных, то их допускается менять. Таким образом, ликвидируется основная причина столкновений. В примере 12.4 целесообразно поменять местами оценки и названия предметов, чтобы упростить обработку.

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

Case-технологии, основанные на структурных методологиях анализа и проектирования

К нашему времени накоплен опыт успешного использования большинства известных методологий структурного анализа и проектирования в соответствующих CASE-средствах.

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

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

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

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

UML - стандартный язык описании разработки программных продуктов с использованием объектного подхода

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

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

UML (Unified Modeling Language - унифицированный язык моделирования), который в настоящее время фактически признан стандартным средством описания проектов, создаваемых с использованием объектно-ориентированного подхода. Его создатели использовали в своем языке все лучшее, что появилось в подходах этих авторов во время «войны методов».

Спецификация разрабатываемого программного обеспечения при использовании UML объединяет несколько моделей:

Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя; Логическая модель описывает ключевые абстракции программного обеспечения (классы, интерфейсы и т. п.), т. е. средства, обеспечивающие требуемую функциональность; Модель реализации определяет реальную организацию программных модулей в среде разработки; Модель процессов отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность программного обеспечения.

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

Определение «вариантов использования»

Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы «вариантами использования» или «прецедентами» (use cases).

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

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

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

основные - обеспечивают требуемую функциональность разрабатываемого программного обеспечения;

вспомогательные - обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.):

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

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

Диаграммы вариантов использования

Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования, связь.

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