Билет 6

1. Технология программирования. Структурное и объектно-ориентированное программирование. Процедуры и функции. Локальные и глобальные переменные

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

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

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

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

Изначально понятие технологии как таковой — это 60-е годы прошлого столетия — это период «стихийного» программирования. В этот период отсутствовало понятие структуры программы, типов данных и т.д. Вследствие этого код получался запутанным, противоречивым. Программирование тех лет считалось искусством. Конец 60-х — кризис в программирование.

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

Другим базовым принципом структурного программирования является использование при составлении программ только базовых алгоритмических структур (см. билет 4), запрет на использование оператора GOTO.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функция (в отличие от процедуры) всегда возвращает единственное значение.

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

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

Вызов функции будет следующим:

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

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

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

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

Наконец, последняя процедура.

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

Пример 3. Найти максимальную цифру в записи данного натурального числа.

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

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

Любая подпрограмма может использоваться лишь в пределах области действия ее описания (а описанные в ней объекты — лишь внутри этой подпрограммы). Например, область действия подпрограмм А и В — основная программа. Поэтому из основной программы можно обратиться к подпрограммам А и В. В свою очередь, в подпрограмме В могут быть обращения к подпрограмме А; а из А нельзя обратиться к В, поскольку описание А предшествует описанию В. Подпрограммы А1 и А2 локализованы в подпрограмме А и могут использоваться только в ней; из А2 можно обратиться к А1, но нельзя наоборот.

Из подпрограммы В1 можно обратиться к А, поскольку ее описание является глобальным по отношению к В1, но нельзя обратиться к А1, поскольку область действия описания А1 не распространяется на блок подпрограммы В.

Из подпрограммы В22 можно обратиться только к В21, В1, А.

2. Средствами почтовой программы создать фильтр для автоматического распределения входящих писем по почтовым папкам в зависимости от темы письма

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

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

Описание правила включает:

1) ввод ключевых слов

2) выбор папки, куда будут помещаться указанные сообщения

Последнее — задание названия для правила (либо можно согласиться с предлагаемым по умолчанию).

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

В персональных настройках можно установить фильтры.

3. Задание на подсчет полного набора символов (мощности алфавита), используемого при кодировании информации

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

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

Источник

Структурный подход к разработке ПРОГРАММНОГО обеспечения

Базовыми принципами структурного подхода являются:

o принцип «разделяй и властвуй»;

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

Основными из этих принципов являются:

o абстрагирование — выделение существенных аспектов системы;

o непротиворечивости — обоснованность и согласованность элементов системы;

o структурирование данных — данные должны быть структуро-ване и иерархически организованы.

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

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

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

o трудностей проектируемой системы;

o необходимой полноты ее описания;

o знаний и навыков участников проекта;

o времени, отведенного на проектирование.

Визуальное моделирование очень повлияло на развитие CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в широком смысле. Первоначальное значение этого понятия, ограничено только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.

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

Источник

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

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

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

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

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

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

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

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

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

· принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

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

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

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

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

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Источник

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

Индивидуальные онлайн уроки: Отправьте запрос сейчас: irina@bodrenko.org
Математика (ЕГЭ, ОГЭ), Английский язык (разговорный, грамматика, TOEFL)
Решение задач: по математике, IT, экономике, психологии

Стандартизация, сертификация и управление качеством программного обеспечения

Тема лекции: «Структурный подход к проектированию программного обеспечения».

1.1. Анализ требований и определение спецификаций при структурном подходе.

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

— диаграмм потоков данных (DFD — Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

— диаграмм «сущность—связь» ( ERD Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

— диаграмм переходов состояний ( STD — State Transition Diagrams), характеризующих поведение системы во времени;

— функциональных диаграмм (методология SADT);

1.2. Спецификации процессов.

Спецификации процессов могут быть представлены в виде псевдокодов, блок-схем алгоритмов, Flow-форм, диаграмм Насей – Шнейдермана или просто краткого текстового описания.

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

Линейная структура — выполнение операторов последовательно.

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

Циклическая структура — многократное выполнение одинаковой последовательности операторов.

1.3. Схемы алгоритмов.

Для изображения схем алгоритмов разработан ГОСТ 19.701—90 (рисунок 1).

Рисунок 1. Обозначение элементов схем алгоритмов.

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

— следование. Обозначает последовательное выполнение действий (рисунок 2);

Рисунок 2. Базовые алгоритмические структуры: следование.

— ветвление. Соответствует выбору одного из двух вариантов действий (рисунок 3);

Рисунок 3. Базовые алгоритмические структуры: ветвление.

— цикл-пока. Определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла (рисунок 4).

Рисунок 4. Базовые алгоритмические структуры: цикл-пока.

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

— выбор. Обозначает выбор одного варианта из нескольких в зависимости от значения некоторой величины (рисунок 5);

Рисунок 5. Дополнительные структуры алгоритмов: выбор.

— цикл-до. Обозначает повторение некоторых действий до выполнения заданного условия, проверка которого осуществляется после выполнения действий в цикле (рисунок 6);

Рисунок 6. Дополнительные структуры алгоритмов: цикл-до.

— цикл с заданным числом повторений (счетный цикл). Обозначает повторение некоторых действий указанное количество раз (рисунок 7).

Рисунок 7. Дополнительные структуры алгоритмов: цикл с заданным числом повторений.

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

ПЕРЕЧИСЛЕННЫЕ ШЕСТЬ КОНСТРУКЦИЙ БЫЛИ ПОЛОЖЕНЫ В ОСНОВУ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ.

Псевдокод — формализованное текстовое описание алгоритма (текстовая нотация). В литературе были предложены несколько вариантов псевдокодов. Один из них приведен в таблице (рисунок 8).

Рисунок 8. Описания псевдокодов.

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

Каждый символ Flow-формы имеет вид прямоугольника и может быть вписан в любой внутренний прямоугольник любого другого символа. Нотация Flow-форм приведена на рисунке 9.

Рисунок 9. Flow-форм ы для основных конструкций: следование; ветвление; выбор; цикл-пока; цикл-до; счетный цикл.

1.6. Диаграммы Насси — Шнейдермана.

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

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

По сравнению с псевдокодами Flow-формы и диаграммы Насси — Шнейдермана, являясь графическими, лучше отображают вложенность конструкций.

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

Рисунок 10. Условные обозначения диаграмм Насси — Шнейдермана для основных конструкций: а — следование; б — цикл-пока; в — цикл-до; г — ветвление; д — выбор.

1.7. Словарь терминов.

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

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

Обычно описание термина в словаре выполняют по следующей схеме:

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

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

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

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

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

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

Рисунок 11. Д иаграмм ы переходов состояний: терминальное состояние; промежуточное состояние; переход

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

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

На рисунке 13 представлена диаграмма переходов торгового автомата, активно взаимодействующего с покупателем.

Рисунок 13. Диаграмма переходов состояний торгового автомата.

2. МЕТОДОЛОГИЯ SADT.

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

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

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

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

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

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

— строгость и точность отображения.

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

1) уникальность меток и наименований;

2) ограничение количества блоков на каждом уровне декомпозиции;

3) синтаксические правила для графики;

4) связность диаграмм;

5) отделение организации от функции;

6) разделение входов и управлений.

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

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

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

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

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

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

— управление. Выход блока используется как управление для блока с меньшим доминированием (рисунок 15, б),

— обратная связь по входу. Выход блока подается на вход блока с большим доминированием (рисунок 15, в);

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

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

Рисунок 15. Типы влияний блоков: а — вход; б — управление; в — обратная связь по входу; г – обратная связь по управлению; д — выход-исполнитель.

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

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

2.2. Иерархия диаграмм.

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

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

Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень — А0, второй — A1, A2 и т. п., третий — A11, A12, А13 и т. п., где первые цифры — номер родительского блока, а последняя — номер конкретного блока детальной диаграммы.

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

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

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

Рисунок 17. Одновременное выполнение.

Рисунок 18. Соответствие родительской и детальной диаграмм.

Рисунок 19. Пример обратной связи.

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

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

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

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

Рисунок 20. Функциональные диаграммы для программы сортировки массива: диаграмма верхнего уровня.

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

I 1 – размер массива;

R1 — вывод описания метода;

R2 — отсортированный массив.

Рисунок 21. Функциональные диаграммы для программы сортировки массива: уточняющая диаграмма.

3. ДИАГРАММЫ ПОТОКОВ ДАННЫХ ( DFD ). МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ».

3.1. Диаграммы потоков данных (DFD).

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

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

Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Йордана и Гейна — Сарсона (рисунок 22).

Рисунок 22. Обозначения элементов диаграмм потоков данных.

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

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

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

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

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

— правило нумерации. Означает, что при детализации подсистем должна поддерживаться их иерархическая нумерация. Например, подсистемы, детализирующие подсистему с номером 2, получают номера 2.1, 2.2, 2.3 и т. д.

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

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

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

1. Выделение множества требований в основные функциональные группы — процессы.

2. Выявление внешних объектов, связанных с разрабатываемой системой.

3. Идентификация основных потоков информации, циркулирующей между системой и внешними объектами.

4. Предварительная разработка контекстной диаграммы.

5. Проверка предварительной контекстной диаграммы и внесение в нее изменений.

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

7. Проверка основных требований контекстной диаграммы.

8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

9. Проверка основных требований по DFD соответствующего уровня.

10. Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.

11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.

ПРИМЕР 2. Разработаем иерархию диаграмм потоков данных программы сортировки одномерных массивов.

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

Рисунок 23. Контекстная диаграмма программы сортировки массива.

После детализации получилось три процесса: Меню, Сортировка, Вывод результата. Для хранения описаний алгоритмов служит Хранилище алгоритмов. Теперь определим потоки данных. Детализирующая диаграмма потоков данных изображена на рисунке 24. Как мы видим, она несколько отличается от функциональной диаграммы (см. рисунок 21), например, на ней показано хранилище данных для хранения описаний алгоритмов. Это отличие является важным при проектировании баз данных.

Рисунок 24. Детализирующая диаграмма потоков данных программы сортировки одномерного массива (нотация Гейна — Сарсона).

3.2. Диаграммы сущность—связь.

Базовыми понятиями ER-модели данных (ER — Entity-Relationship) являются сущность, атрибут и связь.

Первый вариант модели «сущность—связь» был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм «сущность—связь» исходят из одной идеи — рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов) и взаимосвязей между сущностями.

Поскольку нотация Баркера является наиболее распространенной, в дальнейшем будем придерживаться именно ее.

Основные понятия ER-диаграмм

Сущность — это класс однотипных объектов, информация о которых должна быть учтена в модели.

Сущность имеет наименование, выраженное существительным в единственном числе, и обозначается в виде прямоугольника с наименованием (рисунок 25, а). Примерами сущностей могут быть такие классы объектов, как «Студент», «Сотрудник», «Товар».

Рисунок 25. Обозначения сущности в нотации Баркера: а – без атрибутов; б — с указанием атрибутов; в — с ключевым атрибутом.

Экземпляр сущности — это конкретный представитель данной сущности.

Например, конкретный представитель сущности «Студент» — «Максимов». Причем сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности, для того чтобы различать экземпляры.

Атрибут сущности — это именованная характеристика, являющаяся некоторым свойством сущности.

Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с описательными оборотами или прилагательными).

Примерами атрибутов сущности «Студент» могут быть такие атрибуты: «Номер зачетной книжки», «Фамилия», «Имя», «Пол», «Возраст», «Средний балл» и т. п.

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

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

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

Связь — это отношение одной сущности к другой или к самой себе.

Имеется возможность по одной сущности находить другие, связанные с ней. Например, связи между сущностями могут выражаться следующими фразами — «СОТРУДНИК может иметь несколько ДЕТЕЙ», «СОТРУДНИК обязан числиться точно в одном ОТДЕЛЕ». Графически связь изображается линией, соединяющей две сущности (рисунок 26).

Рисунок 26. Пример связи между сущностями.

Каждая связь имеет одно или два наименования.

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

Связь может иметь один из следующих типов — рисунок 27.

Рисунок 27. Типы связей.

Связь типа один-к-одному означает, что один экземпляр первой сущности связан точно с одним экземпляром второй сущности. Такая связь чаще всего свидетельствует о том, что мы неправильно разделили одну сущность на две.

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

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

Каждая связь может иметь одну из двух модальностей связи (рисунок 28).

Рисунок 28. Модальности связей.

Связь может иметь разную модальность с разных концов, как на рисунке 26. Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рисунке 26 читается так: слева направо: «Сотрудник может иметь несколько детей»; справа налево: «Ребенок должен принадлежать точно одному сотруднику».

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

— хранить информацию о покупателях;

— печатать накладные на отпущенные товары;

— следить за наличием товаров на складе.

Выделим все существительные в этих предложениях — это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

• Покупатель — явный кандидат на сущность.

• Накладная — явный кандидат на сущность.

• Товар — явный кандидат на сущность

• (?) Склад — а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

• (?) Наличие товара — это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями — «покупатели могут покупать много товаров» и «товары могут продаваться многим покупателям». Первый вариант диаграммы выглядит, как показано на рисунке 29.

Рисунок 29. Первый вариант ER-диаграммы.

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

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

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

Рисунок 30. Промежуточный вариант ER-диаграммы.

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

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

• каждый товар имеет наименование, цену, а также характеризуется единицами измерения;

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

• каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

— Юридическое лицо — термин риторический, мы не работаем с физическими лицами. Не обращаем внимания;

— Наименование покупателя — явная характеристика

— Адрес — явная характеристика покупателя;

• Банковские реквизиты — явная характеристика покупателя;

• Наименование товара — явная характеристика товара;

• (?) Цена товара — похоже, что это характеристика товара.

Отличается ли эта характеристика от цены в накладной?

• Единица измерения — явная характеристика товара;

• Номер накладной — явная уникальная характеристика накладной;

• Дата накладной — явная характеристика накладной;

• (?) Список товаров в накладной — список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;

• (?) Количество товара в накладной — это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной»;

• (?) Цена товара в накладной — опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше — это одно и то же?

• Сумма накладной — явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;

• Наименование склада — явная характеристика склада.

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

Таким образом, имеется две цены — цена товара в накладной и текущая цена товара.

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

Для этого требуется дополнительная сущность.

Этой сущностью и будет сущность «Список товаров в накладной».

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

Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности «Список товаров в накладной».

Точно так же поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму (рисунок 31).

Рисунок 31. Окончательный вариант ER-диаграммы.

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

[1] Благодатских В.А., Волнин В.А., Поскакалов К.Ф. Стандартизация разработки программных средств. Учебное пособие /Под ред. О.С. Разумова. М.: Финансы и статистика, 2005. – 288 с., ил.

[2] Брауде Э. Технология разработки программного обеспечения. СПб.: Питер, 2004. – 655 с.: ил.

[3] Вигерс К. Разработка требований к программному обеспечению /Пер. с англ. – М.: ИТД «Русская Редакция», 2004. – 576.: ил.

[4] Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. Учебное пособие /Под ред. Л.Г. Гагариной. – М.: ИД «Форум»: ИНФРА- М, 2008. – 400 с.: ил. – (Высшее образование).

[5] Котов С.Л., Палюх Б.В., Федченко С.Л. Разработка, стандартизация и сертификация программных средств и информационных технологий и систем. Учебное пособие. Тверь.: ТГТУ, 2006. – 104 с.

Источник