Тема 5.4 3 Разработка функциональной схемы работы приложения

Федеральное государственное образовательное бюджетное учреждение
высшего образования
«Финансовый университет при правительстве Российской Федерации»
Пермский финансово-экономический колледж – филиал Финансового университета
Тема. Разработка функциональной схемы работы приложения
ОП.04 Основы алгоритмизации и программирования
специальность 09.02.07 Информационные системы и программирование
Преподаватель Ставицкая Е.А.
Пермь – 2022
Содержание
1. Структурная схема приложения ................................................................................... 3
2. Функциональная схема.................................................................................................. 5
3. Унифицированный язык объектно-ориентированного моделирования .................. 5
4. Разработка функциональной схемы работы приложения ......................................... 8
5. Задание для самостоятельной работы ....................................................................... 10
Тема. Разработка функциональной схемы работы приложения
Цель занятия: познакомиться с принципами построения структурной и функциональной схем
приложения.
1. Структурная схема приложения
Процесс проектирования сложного программного обеспечения начинают с уточнения его
структуры, то есть определения структурных компонентов и связей между ними. Результат
уточнения структуры может быть представлен в виде структурной и/или функциональной схем и
описания (спецификаций) компонентов.
Структурной называют схему, отражающую состав и взаимодействие по управлению частей
разрабатываемого программного обеспечения. Структурные схемы пакетов программ
неинформативны, поскольку организация программ в пакеты не предусматривает передачи
управления между ними. Поэтому структурные схемы разрабатывают для каждой программы пакета,
а список программ пакета определяют, анализируя функции, указанные в техническом задании.
Разработку структурной схемы самого простого вида программного обеспечения –
программы, включающей в качестве структурных компонентов только подпрограммы и библиотеки
ресурсов, выполняют методом пошаговой детализации. Структурными компонентами программной
системы (комплекса) служат программы, библиотеки ресурсов, подсистемы, базы данных.
Структурная схема программного комплекса демонстрирует передачу управления от программыдиспетчера соответствующей программе.
Структурная схема программной системы показывает наличие подсистем или других
структурных компонентов. В отличие от программного комплекса, в составе которого работают
независимые программы, отдельные части (подсистемы) программной системы интенсивно
обмениваются данными между собой и с основной программой. Структурная схема программной
системы этого не показывает.
Более полное представление о проектируемом программном обеспечении с точки зрения
взаимодействия его компонентов между собой и с внешней средой дает функциональная схема.
Функциональная схема – схема взаимодействия компонентов программного обеспечения с
описанием информационных потоков, состава данных в потоках и указанием используемых файлов и
устройств. Для изображения функциональных схем используют специальные обозначения,
установленные стандартом. Функциональные схемы более информативны, чем структурные. Все
компоненты структурных и функциональных схем должны быть описаны. Следует тщательно
прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания
зависит количество самых дорогостоящих ошибок, к которым относятся ошибки, обнаруживаемые
при комплексном тестировании.
Структурный подход к программированию изначально предлагал осуществлять
декомпозицию программ методом пошаговой детализации. Результат – структурная схема
программы, то есть многоуровневая иерархическая схема взаимодействия подпрограмм по
управлению. Минимально такая схема отображает два уровня иерархии (показывает общую
структуру программы). Тот же метод позволяет получить структурные схемы с большим
количеством уровней. Разбиение на модули выполняется эвристически, исходя из рекомендуемых
размеров модулей (20-60 строк) и сложности структуры (2-3 вложенных управляющих конструкции).
Для анализа технологичности иерархии модулей используют методики Константайна или Джексона.
На структурной карте Константайна отношения между модулями представляют в виде графа,
вершинам которого соответствуют модули и общие области данных, а дугам – межмодульные
вызовы и обращения к общим областям данных. Различают четыре типа вершин: модуль –
подпрограмма; подсистема – программа; библиотека - совокупность подпрограмм, размещенных в
отдельном модуле; область данных - специальным образом оформленная совокупность данных, к
которой возможно обращение извне. При этом отдельные части программной системы могут
вызываться последовательно, параллельно или как сопрограммы.
Практически одновременно появились методики проектирования программного обеспечения
Джексона и Варнье-Орра, также основанные на декомпозиции данных. Обе методики предназначены
для создания «простых» программ, работающих со сложными, но иерархически организованными
структурами данных. При разработке программных систем предлагается вначале разбить систему на
отдельные программы, а затем использовать эти методики. Они могут использоваться только в том
случае, если данные разрабатываемых программ могут быть представлены в виде иерархии или
совокупности иерархий.
Методика Джексона основана на поиске соответствий структур исходных данных и
результатов. Однако при ее применении возможны ситуации, когда на каких-то уровнях
соответствия отсутствуют. Например, записи исходного файла сортированы не в том порядке, в
котором соответствующие строки должны появляться в отчете. Такие ситуации были названы
«столкновениями».
Методика Варнье-Орра базируется на том же положении, что и методика Джексона, но
основными при построении программы считаются структуры выходных данных и, если структуры
входных данных не соответствуют структурам выходных, то их допускается менять. Таким образом,
ликвидируется основная причина столкновений. Однако на практике не всегда существует
возможность пересмотра структур входных данных: эти структуры уже могут быть строго заданы,
например, если данные получены при выполнении других программ, поэтому эту методику
применяют реже.
Под проектированием структур данных понимают разработку их представлений в памяти.
Основными параметрами, которые необходимо учитывать при проектировании структур данных,
являются:
1. вид хранимой информации каждого элемента данных - определяет тип соответствующего
поля па­мяти;
2. связи элементов данных и вложенных структур, а также совокупность операций над ними определяют структуры памяти, используемые для представления данных;
3. время хранения данных структуры («время жизни») - учитывается при размещении данных
в статической или динамической памяти, а также во внешней памяти.
Различают две базовые структуры организации данных в оперативной памяти: векторную и
списковую. Векторная структура - последовательность байт памяти, которые используются для
размещения полей данных. Последовательное размещение организованных структур данных
позволяет осуществлять прямой доступ к элементам: по индексу (в массивах или строках) или по
имени поля (в записях или объектах). Однако выполнение операций добавления и удаления
элементов для размещения элементов массивов требует осуществления многократных сдвигов
элементов. Расположение векторных представлений в динамической памяти позволяет существенно
увеличить эффективность использования оперативной памяти. Списковые структуры строят из
специальных элементов, включающих помимо информационной части один или несколько
указателей - адресов элементов или вложенных структур, связанных с этим элементом. Размещая их
в динамической памяти, организуют различные внутренние структуры. Обычно векторное
представление используют для хранения статических множеств, таблиц (одномерных и
многомерных: матриц, строк, записей), а также графов, представленных матрицей смежности,
матрицей инцидентности или аналитически. Списковое представление удобно для хранения
динамических (изменяемых) структур и структур со сложными связями.
Современные операционные системы поддерживают два способа организации данных во
внешней памяти: последовательный и с прямым доступом. При последовательном доступе к данным
возможно выполнение только последовательного чтения элементов данных или последовательная их
запись (работа с клавиатурой или дисплеем, обработка текстовых файлов или файлов, формат
записей которых меняется в процессе работы). Прямой доступ возможен только для дисковых
файлов, обмен информацией с которыми осуществляется записями фиксированной длины (двоичные
файлы С или типизированные файлы Pascal). Адрес записи такого файла можно определить по ее
номеру, что и позволяет напрямую обращаться к нужной записи. В оперативной памяти размещают
данные, к которым необходим быс­трый доступ как для чтения, так и для их изменения; во внешней данные, которые должны сохраняться после завершения программы.
Возможно, что во время работы данные целесообразно хранить в оперативной памяти для
ускорения доступа к ним, а при ее завершении – переписывать во внешнюю память для длительного
хранения. Именно этот способ используют большинство текстовых редакторов: во время работы с
текстом он весь или его часть размещается в оперативной памяти, откуда по мере надобности
переписывается во внешнюю память. В подобных случаях разраба­тывают два представления
данных: в оперативной и во внешней памяти.
2. Функциональная схема
Функциональная схема, или схема данных – схема взаимодействия компонентов программного
обеспечения с описанием информационных потоков, состава данных в потоках и указанием
используемых файлов и устройств. Для изображения функциональных схем используют
специальные обозначения, установленные стандартом. Функциональные схемы более
информативны, чем структурные.
Все компоненты структурных и функциональных схем должны быть описаны. При
структурном подходе особенно тщательно необходимо прорабатывать спецификации
межпрограммных интерфейсов, так как от качества их описания зависит количество самых
дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном
тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных
текстов.
3. Унифицированный язык объектно-ориентированного моделирования
Унифицированный язык объектно-ориентированного моделирования Unified Modeling
Language (UML) явился средством достижения компромисса между структурным и функциональным
подходами. Существует достаточное количество инструментальных средств, поддерживающих с
помощью UML жизненный цикл информационных систем, и, одновременно, UML является
достаточно гибким для настройки и поддержки специфики деятельности различных команд
разработчиков.
UML представляет собой объектно-ориентированный язык моделирования, обладающий
следующими основными характеристиками:
- является языком визуального моделирования, который обеспечивает разработку
репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС,
различных групп разработчиков ИС;
- содержит механизмы расширения и специализации базовых концепций языка.
- UML – это стандартная нотация визуального моделирования программных систем, принятая
консорциумом Object Managing Group(OMG) осенью 1997 г., и на сегодняшний день она
поддерживается многими объектно-ориентированными CASE-продуктами.
- UML включает внутренний набор (так называемое «ядро») средств моделирования
(модулей), которые сейчас приняты во многих методах и средствах моделирования. Эти концепции
необходимы в большинстве прикладных задач, хотя не каждая концепция необходима в каждой
части каждого приложения.
Пользователям языка предоставлены возможности:
- строить модели на основе средств ядра, без использования механизмов расширения для
большинства типовых приложений;
- добавлять при необходимости новые элементы и условные обозначения, если они не входят
в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения
для конкретных предметных областей.
Стандарт UML версии 1.1, принятый в 1997 г., содержит следующий набор диаграмм:
1. Структурные (structural) модели:
- диаграммы классов (class diagrams) - для моделирования статической структуры классов
системы и связей между ними;
- диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов
(подсистем) системы;
- диаграммы развертывания (deployment diagrams) - для моделирования физической
архитектуры системы.
2. Модели поведения (behavioral):
- диаграммы вариантов использования (use case diagrams) - для моделирования
функциональных требований к системе (в виде сценариев взаимодействия пользователей с
системой);
- диаграммы взаимодействия (interaction diagrams):
- диаграммы последовательности (sequence diagrams) и диаграммы кооперации (collaboration
diagrams) - для моделирования процесса обмена сообщениями между объектами;
- диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы
при переходе из одного состояния в другое;
- диаграммы деятельности (activity diagrams) - для моделирования поведения системы в
рамках различных вариантов использования, или потоков управления.
Диаграммы вариантов использования показывают взаимодействия между вариантами
использования и действующими лицами, отражая функциональные требования к системе с точки
зрения пользователя. Цель построения диаграмм вариантов использования - это документирование
функциональных требований в самом общем виде, поэтому они должны быть предельно простыми.
Вариант использования представляет собой последовательность действий, выполняемых
системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом).
Вариант использования описывает типичное взаимодействие между пользователем и системой и
отражает представление о поведении системы с точки зрения пользователя. В простейшем случае
вариант использования определяется в процессе обсуждения с пользователем тех функций, которые
он хотел бы реализовать, или целей, которые он преследует по отношению к разрабатываемой
системе.
Диаграмма вариантов использования является самым общим представлением
функциональных требований к системе. Для последующего проектирования системы требуются
более конкретные детали, которые описываются в документе, называемом "сценарием варианта
использования" или "потоком событий" (flow of events). Сценарий подробно документирует процесс
взаимодействия действующего лица с системой, реализуемого в рамках варианта использования.
Основной поток событий описывает нормальный ход событий (при отсутствии ошибок).
Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные
ситуации) и их обработку.
Достоинства модели вариантов использования заключаются в том, что она:
- определяет пользователей и границы системы;
- определяет системный интерфейс;
- удобна для общения пользователей с разработчиками;
- используется для написания тестов;
- является основой для написания пользовательской документации;
- хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и
структурные).
Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов (в
рамках варианта использования или некоторой операции класса). Как правило, диаграмма
взаимодействия охватывает поведение объектов в рамках только одного потока событий варианта
использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они
обмениваются между собой. Существует два вида диаграмм взаимодействия: диаграммы
последовательности и кооперативные диаграммы.
Диаграммы последовательности отражают временную последовательность событий,
происходящих в рамках варианта использования, а кооперативные диаграммы концентрируют
внимание на связях между объектами.
Диаграмма классов определяет типы классов системы и различного рода статические связи,
которые существуют между ними. На диаграммах классов изображаются также атрибуты классов,
операции классов и ограничения, которые накладываются на связи между классами. Вид и
интерпретация диаграммы классов существенно зависит от точки зрения (уровня абстракции):
классы могут представлять сущности предметной области (в процессе анализа) или элементы
программной системы (в процессах проектирования и реализации).
Диаграммы состояний определяют все возможные состояния, в которых может находиться
конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых
событий. Диаграммы состояний не надо создавать для каждого класса, они применяются только в
сложных случаях. Если объект класса может существовать в нескольких состояниях и в каждом из
них ведет себя по-разному, для него может потребоваться такая диаграмма.
Диаграммы деятельности, в отличие от большинства других средств UML, заимствуют идеи
из нескольких различных методов, в частности, метода моделирования состояний SDL и сетей
Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество
параллельных процессов. Диаграммы деятельности являются также полезными при параллельном
программировании, поскольку можно графически изобразить все ветви и определить, когда их
необходимо синхронизировать.
Диаграммы деятельности можно применять для описания потоков событий в вариантах
использования. С помощью текстового описания можно достаточно подробно рассказать о потоке
событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно
понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстово
описание потока событий, но в наглядной графической форме.
Диаграммы компонентов моделируют физический уровень системы. На них изображаются
компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов:
исполняемые компоненты и библиотеки кода.
Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между
отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе
компиляции или выполнения программы.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за
компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
4. Разработка функциональной схемы работы приложения
Цель: Изучить основные понятия и правила при разработке функциональной схемы работы
приложения
На втором этапе разработки приложения для каждого компонента, размещенного на форме,
разработчик должен определить нужную реакцию на те или иные действия пользователя (например,
нажатие кнопки или выбор переключателя).
Функциональная схема работы приложения определяется процедурами, которые выполняются
при возникновении определенных событий, происходящих при взаимодействии пользователя с
управляющими элементами формы. Реакция на события присуща каждой форме и не зависит от
назначения приложения и его особенностей.
Каждый компонент имеет свой набор событий, на которые он может реагировать. Вместе с тем,
существуют две категории стандартных событий, определенных для всех визуальных компонентов:
 события, определенные для всех без исключения визуальных компонентов (табл. 4.1);
 события, характерные только для оконных визуальных компонентов (табл. 4.2).
Процедура, связанная с несколькими событиями для различных компонент, называется общим
обработчиком и вызывается при возникновении любого из связанных с ней событий.
Для создания процедуры обработки события нужно:
 выделить на форме компонент;
 перейти на страницу событий Инспектора Объектов;
 выделить событие, для которого будет создаваться процедура-обработчик события;
Таблица 4.1. События, общие для всех визуальных компонентов
Событие
OnClick
OnDblClick
Момент возникновения и параметры процедур
Возникает при нажатии левой клавиши мыши в области компонента или при
нажатии клавиши , если на компонент установлен фокус
Возникает при двойном нажатии левой клавиши мыши в области компонента
OnDragDrop
Возникает в случае, когда пользователь «отпустил» перетаскиваемый объект.
Параметр source соответствующей процедуры-обработчика содержит указатель
на объект, который был «отпущен», а параметр sender - на объект, принявший
«перетаскиваемый»
OnDragOver
Возникает в случае, когда пользователь «перетаскивает» объект для его
размещения в рамках другого компонента
OnEndDrag
Возникает в конце процедуры «перетаскивания» объекта. Параметр sender
соответствующей процедуры-обработчика указывает на «перетаскиваемый»
объект, а параметр Target — на его образ в рамках принимающего компонента
OnMouseDown
Возникает при нажатии любой клавиши мыши в области компонента.
Параметр Button соответствующей процедуры-обработчика этого события
позволяет определить, какая клавиша была нажата, параметр shift — были ли
нажаты клавиши , или вместе с клавишей мыши, а параметры х и y содержат
координаты курсора мыши в момент нажатия клавиши
OnMouseMove
Возникает при «буксировке» манипулятора «мышь» (т. е. при его
перемещении при нажатой левой клавише). Параметр shift соответствующей
процедуры-обработчика определяет, были ли нажаты клавиши , или вместе с
клавишей мыши, а параметры х и y содержат координаты курсора мыши в
момент нажатия клавиш.
OnMouseUp
Парное для OnMouseDown. Возникает, когда ранее нажатая клавиша мыши
отпущена. Имеет те же параметры, что и OnMouseDown

посредством двойного нажатия кнопки мыши в области значения события получить доступ в
модуль формы, где Lasarus автоматически создаст заготовку процедуры-обработчика;
в месте, где будет установлен текстовый курсор, написать код, который должен выполняться
при возникновении события.

Итак, для обеспечения выполнения функций приложения необходимо:


задать в Инспекторе Объектов значения свойств и процедур обработки событий;
написать программный код для заданных процедур обработки событий.
Таблица 4.2. События оконных визуальных компонентов
Событие
Момент возникновения и параметры процедуры
OnEnter
Возникает, когда компонент получает фокус ввода
OnExit
Возникает при потере фокуса компонентом
OnKeyDown
Возникает при нажатии любой клавиши на клавиатуре. Параметр Key
соответствующей процедуры-обработчика имеет тип word и может содержать коды
виртуальных клавиш. Параметр shift передает информацию о нажатии клавиш , , и о
нажатии клавиш мыши
OnKeyPress
Возникает при нажатии клавиши на клавиатуре. Параметр Key соответствующей
процедуры-обработчика имеет тип char и содержит ASCII-код нажатой клавиши. Для
клавиш, которые не имеют ASCII-кодов (например, , или ), событие не возникает
OnKeyUp
Парное для OnKeyDown. Возникает, когда пользователь отпускает нажатую ранее
клавишу. Имеет те же параметры, что и OnKeyDown
5. Задание для самостоятельной работы
Ответьте на контрольные вопросы (ответы пришлите преподавателю в Модус):
1. Какие существуют виды схем, описывающих структуру и процесс работы приложения?
2. Что представляет из себя структурная схема?
3. Приведите примеры структурных компонентов программного обеспечения.
4. Какие существуют методики структурного проектирования программного обеспечения?
5. Что такое функциональная схема?
6. В чём преимущество функциональной схемы по сравнению со структурной?
7. При помощи какого языка можно составить описание, моделирующее программную
систему?
8. Какие наборы диаграмм используются в UML?
9. Какие категории стандартных событий существуют для всех визуальных компонентов
функциональной схемы работы приложения?
10. Что необходимо сделать для обеспечения выполнения функций приложения?
Максимальная оценка - 5б