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

РЕФЕРАТ

по дисциплине МДК.03.01 Технология разработки программного обеспечения

на тему «Анализ требований и определение спецификаций программного обеспечения»

Подготовил: студент 3-го курса

специальности

«Программирование в компьютерных системах»

Комаренко Леонид Алексеевич

 

 

Проверил: преподаватель

Стародубцев Виталий Николаевич

«___» _________ 201___ г.

Оценка: «_______________»

__________________________

(подпись)

 

 

Москва-2016

Содержание

 

Введение
1. Определение требований к программным продуктам
1.1. Функциональные требования
1.2. Эксплуатационные требования
2. Выбор архитектуры программного обеспечения
3. Структура и формат данных. Статические, полустатические и динамические структуры
3.1. Классификация структур данных
3.2. Простые структуры данных
3.3. Статические структуры данных
3.4. Полустатические структуры данных
3.5. Динамические структуры данных
4. Модульное программирование
4.1. Понятие модуля
4.2. Основные характеристики программного модуля
4.3. Модульная структура программных продуктов
4.4. Методы разработки при мольном программировании
5. Анализ требований и определение спецификаций про структурном подходе
5.1. Спецификация процессов
5.2. Словарь терминов
5.3. Диаграммы переходов состояний (SDT)
5.4. Функциональные диаграммы
5.5. Диаграммы потоков данных (DFD)
5.6. Диаграммы сущность-связь

 

6. Анализ требований и определение спецификаций при объектном подходе
6.1. Некоторые теоретические сведения о UML- унифицированном языке моделирования
6.2. Определение прецедентов (вариант использования)
6.3. Построение концептуальных модели предметной области
6.4. Описание поведения системы. Диаграммы последовательностей, деятельности и состояний
Заключение
Список используемых источников

 

 

Введение

В настоящее время в условиях развивающегося информационного общества с учетом всеобщего применения и распространения компьютерных и телекоммуникационных технологий и систем, а также в связи с реализацией объявленной ранее Президентом РФ программы на создание в стране единого образовательного и информационного пространства появление учебного пособия, освещающего теоретические и практические вопросы разработки программного обеспечения, особенно актуально. Согласно «Концепции информатизации сферы образования Российской Федерации» и положениям Федеральной целевой программы «Электронная Россия» одной из особенностей перспективной системы образования в нашей стране является опережающее образование, в рамках которого изучаются последние достижения в области информатизации, ее средства, методы, а также перспективы дальнейшего развития и практического использования. В представленном реферате достаточно полно изложены понятия жизненного цикла программного обеспечения, процесс его производства: методы, технология и инструментальные средства, тестирование, отладка и сопровождение программ. Именно поэтому только на базе основных понятий и определений в области разработки программных средств возможно освещение проблем документирования, проектирования программного обеспечения; рассмотрение вопросов технологического цикла разработки программных систем.

 

1. Определение требований к программным продуктам

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

1.1. Функциональные требования

Функциональные требования описывают сервисы, предоставляемые программной системой, ее поведение в определенных ситуациях, реакцию на те или иные входные данные и действия, которые система позволит выполнять пользователям. Иногда сюда добавляются сведения о том, чего система делать не должна [37, 61].

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

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

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

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

Функциональная спецификация состоит из трех частей:

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

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

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

 

1.2. Эксплуатационные требования

Характеристики разрабатываемого программного обеспечения, проявляемые в процессе его использования. К таким характеристикам относят [1]:

• правильность — функционирование в соответствии с техническим заданием. Это требование является обязательным для всякого программного продукта, но поскольку никакое тестирование не дает гарантии 100%-ной правильности, речь может идти об определенной вероятности наличия ошибок. Вероятность сбоя системы управления космическими полетами должна быть близка к нулю;

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

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

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

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

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

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

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

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

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

• повторная в ходимость — возможность повторного выполнения без перезагрузки с диска. Данное требование обычно предъявляется к программному обеспечению, резидент­но загруженному в оперативную память (например, драйверы);

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

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

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

Простые структуры данных служат основой для построения более сложных структур. Их называют также примитивными или базовыми структурами (типами данных). К ним относятся: числовые, битовые, логические, символьные, перечисляемые, интервальные, указатели. Структура простых типов данных для языка Pascal приведена на рис. 3.2 (в других языках программирования набор и размеры простых типов могут отличаться от приведенного на рисунке). Размер каждого типа данных указан на рисунке в байтах через запятую от названия типа. Как уже было сказано, разные типы данных имеют различный формат представления их в машинной памяти. На рис. 3.3—3.5 приведены примеры форматов числовых типов данных.

На рис. 3.4 S обозначает знаковый разряд числа (если £=0, то число положительное, если S= 1 — число отрицательное).

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

Рис. 3.2. Структура простых типов PASCAL

Младший байт

Старший байт

7 0 а

7 0

б

15 8

Знак числа

Порядок

Знак порядка

Мантисса

Рис. 3.3. Формат машинного представления беззнаковых чисел: а — тип byte; б — тип word

 

Знак числа

Порядок

Знак порядка

Мантисса

а

Рис. 3.5. Формат представления вещественных чисел: а — с порядком; б — с характеристикой

Векторы

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

С физической точки зрения элементы вектора размещаются в памяти в подряд расположенных ячейках памяти (рис. 3.6). Под элемент вектора выделяется количество байт памяти, определяемое базовым типом элемента этого вектора. Тогда размер памяти, отводимой для размещения вектора, будет определяться следующим соотношением: S= k* Sizeof(™n), где к — количество элементов (длина) вектора, a Sizeof(™n) —- размер памяти, необходимой для хранения одного элемента вектора.

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

@Имя — адрес вектора или адрес первого элемента вектора

Двумерные массивы

Двумерный массив (матрица) — это вектор, каждый элемент которого вектор. Поэтому то, что справедливо для вектора, справедливо и для матрицы (аналогично для я-мерных массивов).

 

Множества

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

Множество в памяти (рис. 3.7) хранится как массив битов, в котором каждый бит указывает, является ли элемент принадлежащим объявленному множеству или нет. Таким образом, максимальное число элементов множества 256, а данные типа множество могут занимать не более 32 байт.

 

Рис. 3.7. Представление множества в памяти:

@S — адрес данного типа множество

 

Размер памяти (в байтах), выделяемых под множество, вычисляется по формуле: S- (max div 8) - (min div 8) + 1, где max и min — верхняя и нижняя границы базового типа данного множества, a div —- целочисленное деление.

Записи

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

Пример записи — набор сведений о сотруднике кафедры.

Объект «сотрудник» может обладать следующими свойствами:

• табельный номер — целое положительное число;

• фамилия-имя-отчество — строка символов и т. д.;

• пол — символ;

• ученая степень — строка символов;

• заработная плата — вещественное число;

• и др.

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

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

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

Рис. 3.8. Представление в памяти переменной типа запись в виде последовательности полей

Рис. 3.9. Размещение в памяти переменной типа запись в виде указателей

Связные линейные списки

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

На рис. 3.10 приведена структура односвязного списка. Здесь поле INF информационное поле, содержащее данные, NEXT — указатель на следующий элемент списка. Голова списка — указатель на начало списка. Указатель на следующий элемент последнего элемента списка содержит значение nil, это яв­ляется признаком последнего элемента.

 

Рис. 3.10. Структура односвязного списка

Двусвязные списки

Обработка односвязного списка не всегда удобна, так как невозможно двигаться в противоположную сторону. Такую возможность обеспечивает двусвязный список, каждый элемент которого содержит два указателя: на следующий и предыдущий элементы. Структура линейного двусвязного списка приведена на рис. 3.11, где поле NEXT — указатель на следующий элемент, поле PREV — указатель на предыдущий элемент. Первый и по­следний элементы такого списка содержат nil в указателе на предыдущий и последующий элементы соответственно.

Рис. 3.11. Структура двусвязного списка

Модульное программирование

Для обеспечения технологичности разрабатываемого программного обеспечения применяется модульное программирование [37].

Понятие модуля

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

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

Модуль характеризуют:

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

• функциональная завершенность. Модуль выполняет набор определенных операций для реализации каждой отдельной функции, достаточных для завершения начатой обработки данных;

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

• слабые информационные связи с другими программными модулями. Обмен информацией между отдельными модулями должен быть минимален;

• размер и сложность программного элемента в разумных рамках.

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

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

Метод восходящей разработки

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

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

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

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

 

Метод нисходящей разработки

Как и в предыдущем методе, сначала строится модульная структура программы в виде дерева. Затем проектируются и реализуются модули программы, начиная с модуля самого верхнего уровня — головного, далее разрабатываются модули уровнем ниже и т. д. При этом переход к программированию какого-либо модуля осуществляется только в том случае, если уже запрограммирован модуль, который к нему обращается. Затем производится их поочередное тестирование, и отладка в таком нисходящем порядке. При таком порядке разработки про­граммы вся необходимая глобальная информация формируется своевременно, т. е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу, при этом все модули, к которым может обращаться головной, заменяются их имитаторами (так называемыми «заглушками» [45]). Каждый имитатор модуля является простым программным фрагментом, реализующим сам факт обращения к данному модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, подходящего результата. Далее производится тестирование следующих по уровню модулей. Для этого имитатор выбранного для тестирования модуля заменяется самим модулем, и добавляются имитаторы модулей, к которым может обращаться тестируемый модуль. При таком подходе каждый модуль будет тестироваться в «естественных» состояниях ин­формационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей.

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

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

 

Конструктивный подход

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

 

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

Спецификация программы

(головного модуля)

Рис. 3.12. Первый шаг формирования модульной структуры программы при конструктивном подходе

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

 

Спецификация программы

(головного модуля)

Рис. 3.13. Второй шаг формирования модульной структуры программы при конструктивном подходе

Архитектурный подход

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

Нисходящая реализация

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

 

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

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

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

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

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

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

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

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

Таблица 3.2. Обозначение элементов схем алгоритмов

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

• следование. Обозначает последовательное выполнение действий (рис. 3.15, а);

• ветвление. Соответствует выбору одного из двух вариантов действий (рис. 3.15, б);

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

(рис. 3.15, в).

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

б — ветвление; в — цикл-пока

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

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

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

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

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

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

Псевдокоды

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

а

Табл. 3.3.

Flow-формы

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

До <Условие>

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

а — следование; б — ветвление; в — выбор; г — цикл-до; д — цикл-до;

е — счетный цикл.

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

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

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

• термин;

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

• краткое описание.

Пример:

Термин Web-сайт

Категория Интернет-программирование

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

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

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

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

В качестве примера рассмотрим методологию SADT, предложенную Дугласом Россом. На ее основе разработана, в частности, известная методология IDEFO (Icam DEFinition). Методология SADT представляет собой набор методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

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

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

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

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

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

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

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

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

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