
- •Оглавление
- •9. Тестирование программных продуктов …………………..263
- •10. Отладка программного обеспечения …………………..287
- •11.Составление программной документации …………………..300
- •Предисловие
- •Введение
- •1. Технология программирования. Основные понятия и подходы
- •1.1. Технология программирования и основные этапы ее развития
- •1.2. Проблемы разработки сложных программных систем
- •1.3. Блочно-иерархический подход к созданию сложных систем
- •1.4. Жизненный цикл и этапы разработки программного обеспечения
- •1.5. Эволюция моделей жизненного цикла программного обеспечения
- •1.6. Ускорение разработки программного обеспечения. Технология rad
- •1.7. Оценка качества процессов создания программного обеспечения
- •Контрольные вопросы
- •2. Приемы обеспечения технологичности программных продуктов
- •2.1. Понятие технологичности программного обеспечения
- •2.2. Модули и их свойства
- •2.3. Нисходящая и восходящая разработка программного обеспечения
- •2.5. Стиль оформления программы
- •2.6. Эффективность и технологичность
- •2.7. Программирование «с защитой от ошибок»
- •2.8. Сквозной структурный контроль
- •Контрольные вопросы и задания
- •3. Определение требований к программному обеспечению и исходных данных для его проектирования
- •3.1. Классификация программных продуктов по функциональному признаку
- •3.2. Основные эксплуатационные требования к программным продуктам
- •3.3. Предпроектные исследования предметной области
- •3.4. Разработка технического задания
- •1.Введение
- •2. Основание для разработки
- •3. Назначение
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •1. Введение
- •2. Основание для разработки
- •3. Назначение
- •4. Требования к программе или программному изделию
- •5. Требования к программной документации
- •3.5. Принципиальные решения начальных этапов проектирования
- •Контрольные вопросы и задания
- •4. Анализ требований и определение спецификаций программного обеспечения при структурном подходе
- •4.1. Спецификации программного обеспечения при структурном подходе
- •4.2. Диаграммы переходов состояний
- •4.3. Функциональные диаграммы
- •4.4. Диаграммы потоков данных
- •4.5. Структуры данных и диаграммы отношений компонентов данных
- •4.6. Математические модели задач, разработка или выбор методов решения
- •Контрольные вопросы и задания
- •5. Проектирование программного обеспечения при структурном подходе
- •5.1. Разработка структурной и функциональной схем
- •5.2. Использование метода пошаговой детализации для проектирования структуры программного обеспечения
- •5.3. Структурные карты Константайна
- •5.4. Проектирование структур данных
- •5.5. Проектирование программного обеспечения, основанное на декомпозиции данных
- •5.6. Case-технологии, основанные на структурных методологиях анализа и проектирования
- •Контрольные вопросы и задания
- •6. Анализ требований и определение спецификаций программного обеспечения при объектном подходе
- •6.2. Определение «вариантов использования»
- •Типичный ход событий (окончание)
- •Альтернатива
- •6.3. Построение концептуальной модели предметной области
- •6.4. Описание поведения. Системные события и операции
- •Контрольные вопросы и задания
- •7. Проектирование программного обеспечения при объектном подходе
- •7.1. Разработка структуры программного обеспечения при объектном подходе
- •7.2. Определение отношений между объектами
- •7.3. Уточнение отношений классов
- •7.4. Проектирование классов
- •7.5. Компоновка программных компонентов
- •7.6. Проектирование размещения программных компонентов для распределенных программных систем
- •7.7. Особенность спиральной модели разработки. Реорганизация проекта
- •Контрольные вопросы и задания
- •8. Разработка пользовательских интерфейсов
- •8.1. Типы пользовательских интерфейсов и этапы их разработки
- •8.2. Психофизические особенности человека, связанные с восприятием, запоминанием и обработкой информации
- •8.3. Пользовательская и программная модели интерфейса
- •8.4. Классификации диалогов и общие принципы их разработки
- •8.5. Основные компоненты графических пользовательских интерфейсов
- •8.6. Реализация диалогов в графическом пользовательском интерфейсе
- •8.7. Пользовательские интерфейсы прямого манипулирования и их проектирование
- •8.8. Интеллектуальные элементы пользовательских интерфейсов
- •Контрольные вопросы и задания
- •9. Тестирование программных продуктов
- •9.1. Виды контроля качества разрабатываемого программного обеспечения
- •9.2. Ручной контроль программного обеспечения
- •9.3. Структурное тестирование
- •9.4. Функциональное тестирование
- •9.5. Тестирования модулей и комплексное тестирование
- •9.6. Оценочное тестирование
- •Контрольные вопросы и задания
- •10. Отладка программного обеспечения
- •10.1. Классификация ошибок
- •10.2. Методы отладки программного обеспечения
- •10.3. Методы и средства получения дополнительной информации
- •10.4. Общая методика отладки программного обеспечения
- •Контрольные вопросы
- •11. Составление программной документации
- •11.1. Виды программных документов
- •11.2. Пояснительная записка
4.3. Функциональные диаграммы
Функциональныминазывают диаграммы, в первую очередь отражающиевзаимосвязи функцийразрабатываемого программного обеспечения. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделированияSADT(StructuredAnalysisandDesignTechnique- технология структурного анализа и проектирования) в 1973 г. [58].
Примечание. Методология SADT предполагает, что модель может основываться либо на функциях системы, либо на ее предметах (данных, оборудовании, информации и т. п.). В обоих случаях используют схожие графические нотации, но в первом случае блок соответствует
функции, а во втором - элементу данных. Соответствующие модели принято называть активностными моделями и моделями данных. Полная модель включает построение обеих моделей, обеспечивающих более полное описание программного обеспечения, однако широкое распространение получили только активностные (функциональные) модели. На основе методологии SADT в дальнейшем была построена известная методология описания сложных систем IDEFO (Icam DEFinition - нотация ICAM), которая является основной частью программы ICAM (Integrated Computer-Aided Manufacturing - интегрированная компьютеризация производства), проводимой по инициативе ВВС США.
Отображение взаимосвязи функций активностной модели осуществляется посредством построения иерархии функциональных диаграмм,схематически представляющих взаимосвязи нескольких функций. Каждый блок такой диаграммы соответствует некоторой функции, для которой должны быть определены: исходные данные, результаты, управляющая информация и механизмы ее осуществления - человек или технические средства.
Все перечисленные выше связи функции представляются дугами, причем тип связи и ее направление строго регламентированы. Дуги, изображающие каждый тип связей, должны подходить к блоку с определенной стороны (рис. 4.7), а направление связи должно указываться стрелкой в конце дуги.
Физически дуги исходных данных, результатов и управления представляют собой наборы данных, передаваемые между функциями. Дуги, определяющие механизм выполнения функции, в основном используются при описании спецификаций сложных информационных систем, которые включают как автоматизированные, так и ручные операции. Блоки и дуги маркируются текстами на естественном языке.
Блоки на диаграмме размещают по «ступенчатой» схеме в соответствии с последовательностью их работы или доминированием,которое понимается как влияние, оказываемое одним блоком на другие. В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга:
• вход - выход блока подается на вход блока с меньшим доминированием, т. е. следующего (рис. 4.8, а);
• управление - выход блока используется как управление для блока с меньшим доминированием (следующего) (рис. 4.8, б);
• обратная связь по входу - выход блока подается на вход блока с большим доминированием (предыдущего) (рис. 4.8, в);
• обратная связь по управлению - выход блока используется как управляющая информация для блока с большим доминированием (предыдущего) (рис. 4.8, г);
• выход-исполнитель - выход блока используется как механизм для другого блока (рис. 4.8, д).
Дуги могут разветвляться и соединяться вместе различными способами. Разветвление означает, что часть или вся информация может использоваться
в каждом ответвлении дуги. Дуга всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если ветвь дуги после ветвления не помечена, то непомеченная ветвь содержит весь набор данных. Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 4.9).
Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня детализации: диаграммы каждого следующего уровня уточняют структуру родительского блока. Построение модели начинают с единственного блока, для которого определяют исходные данные, результаты, управление и механизмы реализации. Затем он последовательно детализируется с использованием метода пошаговой детализации (см. § 1.3). При этом рекомендуется каждую функцию представлять не более чем 3—7-ю блоками. Во всех случаях каждая подфункция может использовать или продуцировать только те элементы данных, которые использованы или продуцируются родительской функцией,причем никакие элементы не могут быть опущены, что обеспечивает непротиворечивость построенной модели.
Стрелки, приходящие с родительской диаграммы или уходящие на нее, нумеруют, используя символы и числа. Символ обозначает тип связи: I- входная, С – управляющая, М – механизм,R- результат. Число - номер связи по соответствующей стороне родительского блока, считая сверху вниз и слева направо.
Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень - АО, второй - Al,A2 и т. п., третий - А11, А12, А13 и т.п., где первые цифры - номер родительского блока, а последняя - номер конкретного субблока родительского блока.
Детализацию завершают после получения функций, назначение которых хорошо понятно как заказчику, так и разработчику. Эти функции описывают, используя естественный язык или псевдокоды.
В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и строят словарь данных, в котором определяют структуры и элементы данных, показанных на диаграммах.
Таким образом, в результате получают спецификацию, которая состоит из иерархии функциональных диаграмм, спецификаций функций нижнего уровня и словаря, имеющих ссылки друг на друга.
Пример 4.2. Разработку функциональных диаграмм продемонстрируем на примере уточнения спецификаций программы построения таблиц/графиков функций одной переменной.
Диаграмма, показанная на рис. 4.10, а, является диаграммой верхнего уровня. На ней хорошо видно, что является исходными данными для программы. и каких результатов работы от нее ожидают.
Диаграмма, представленная на рис, 4.10. б,уточняет функции программы. На ней показаны четыре блока: Ввод/выбор функции и ее разбор. Добавление функции в список. Построение таблицы значений и Построение графика функции.
Для каждого блока определены исходные данные, управляющие воздействия и результаты. Согласно правилам наименования входов/выходов, имеющих продолжение на родительской диаграмме, на диаграмме использованы следующие обозначения:
I1 - функция,
I2 -отрезок,
I3 -шаг,
Cl- вид график/таблица,
Rl- график функции на отрезке,
R2 - таблица значений функции на отрезке.
Словарь в этом случае должен содержать описание всех данных, используемых в системе.
Функциональную модель целесообразно применять для определения спецификаций программного обеспечения, не предусматривающего работу со сложными структурами данных, так как она ориентирована на декомпозицию функций.