На рисунке 3.1 представлена функциональная схема устройства. Её принципиальное отличие от структурной схемы, представленной ранее, заключается в том, что на данном этапе уже выбран микроконтроллер, датчик.
Датчик температуры встроен в микроконтроллер.
Информация о значение температуры отображается с помощью двух светодиодов LED1 и LED2. Если температура преодолевает пороговое значение, загорается красный светодиод, иначе горит зеленый.
С помощью двух кнопок управления S1 и S2 происходит управление устройством. По нажатию кнопки исходит перезагрузка устройства, а по нажатию кнопки S2 устройство начинает работу.
Разработка программного обеспечения
Выбор среды программирования
В качестве среды разработки выбран программный пакет Code Composer Studio [4] фирмы Texas Instruments Incorporated.
Интегральная среда проектирования, предназначенная для создания программного обеспечения. Представляет собой единый графический интерфейс для пошаговой разработки и отладки программного кода. Интуитивно понятное меню позволяет разработчикам быстро освоиться в программе, а со временем, изучая новые функции, улучшать производительность своих работ.
Функциональная схема компьютера
Среда включает в себя редактор исходных текстов, отладчик, линковщик, компилятор, средства визуализации, симулятор любого встроенного процессора от Texas Instruments, а также целый набор вспомогательных инструментов. Встроенный отладчик приспосабливается к используемым микросхемам, он способен выставлять и работать с многофункциональными контрольными точками.
Менеджер событий останавливает работу центрального процессора или вызывает иные действия, следуя определенным заранее условиям. Среда поддерживает режим трассировки, помогающей проводить отладку программного кода и находить некоторые ошибки «невидимые» для других методов.
Компиляторы C/C++, используя классические методы оптимизации, подстраиваются под конкретный тип микропроцессора для повышения эффективности кода и уменьшения его размера. Интегрированный симулятор делает возможным начать разработку в отсутствии реальной отладочной платы. При этом предлагается широкий выбор средств для визуализации процесса исполнения программного кода. Среда CCS позволяет одновременно работать с несколькими проектами, после закрытия программы все настройки проектов сохраняются и восстанавливаются при повторном запуске.
Алгоритм работы программы
Основной алгоритм работы представлен на рисунке 4.1.
Рисунок 4.1- Алгоритм работы программы
Функциональная организация программы
Программа предназначена для работы с микроконтроллером MSP430G2553 компании Texas Instruments. Работоспособность с другими микроконтроллерами не гарантируется. Программа, загружается на микроконтроллер и предназначается для управления им и управления его периферийными устройствами, необходимыми для измерения температуры. Функционально программа состоит из: основной функции программы(main), функций обработки прерываний(Interrupt ADC10_ISR и Interrupt ta0_isr).
Создание функциональной схемы
Функция main типа void, является основной функцией программы и предназначается для реализации ее работы.
Состоит из: объявления начальных настроек программы и бесконечного цикла.
В начальных настройках происходит инициализация АЦП для работы с встроенным датчиком температуры, осуществляется настройка таймера.
Бесконечный цикл начинается по нажатию кнопки запуска, затем происходит запуск АЦП, которое преобразует информацию, выдаваемую датчиком температуры, в цифровую форму. После завершения работы АЦП включается режим энергосбережения, который прекращается при снятие следующего значения температуры. На основе полученных от АЦП данных происходит расчет значения температуры. В зависимости от этого значения включаются либо красный, либо зеленый светодиоды. Следующая итерация цикла происходит по срабатыванию таймера.
Функция обработки прерывания Interrupt ADC10_ISR типа void предназначена для обработки прерывания от АЦП. Делает ЦПУ активным и активирует все разрешенные тактовые сигналы.
Функция обработки прерывания Interrupt ta0_isr типа void предназначена для обработки прерывания от таймера. Обнуляет значение счетчика и осуществляет выход микроконтроллера из режима энергосбережения.
датчик температура микроконтроллер программный
Источник: studentopedia.ru
Функциональная схема
Процесс проектирования программного обеспечения включает в себя определение структурных компонентов программной системы и связей между ними. Результат уточнения структуры может быть представлен в виде различных схем, дающих наиболее полное представление о проектируемом программном обеспечении. Схемы могут использоваться на различных уровнях детализации, причем число уровней зависит от размеров и сложности задачи обработки данных. Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом.
Функциональная схема — это схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом (ГОСТ 19.701-90). Все компоненты функциональных схем должны быть описаны (табл. 3.2).
Рис. 3.7. Диаграмма потоков данных АИС «Склад оптовой торговли»
Графические обозначения основных блоков алгоритмов
Символ отображает выход во внешнюю среду и вход из внешней среды (начало или конец схемы программы, внешнее использование и источник или пункт назначения данных)
Отображает данные, носитель данных не определен
устройство с прямым доступом
Отображает данные, хранящиеся в запоминающем устройстве с прямым доступом (магнитный диск, магнитный барабан, гибкий магнитный диск)
Отображает данные, представленные на носителе в удобочитаемой форме (машинограмма, документ для оптического или магнитного считывания, микрофильм, рулон ленты с итоговыми данными, бланки ввода данных)
Отображает данные, вводимые вручную во время обработки с устройств любого типа (клавиатура, переключатели, кнопки, световое перо, полоски со штриховым кодом)
Отображает данные, представленные в человекочитаемой форме на носителе в виде отображающего устройства (экран для визуального наблюдения, индикаторы ввода информации)
Отображает функцию обработки данных любого вида (выполнение определенной операции или группы операций, приводящее к изменению значения, формы или размещения информации или к определению, по которому из нескольких направлений потока следует двигаться)
Символ отображает предопределенный процесс, состоящий из одной или нескольких операций или шагов программы, которые определены в другом месте (в подпрограмме, модуле)
На рис. 3.8 приведена функциональная схема программной системы, реализующей операцию продажи товара автоматизированной информационной системы «Склад оптовой торговли».
Рис. 3.8. Пример функциональной схемы программного обеспечения подсистемы реализации АИС «Склад оптовой торговли»
При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов.
Источник: studref.com
Функциональная схема приложения
Функциональная схема, или схема данных – схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Функциональные схемы более информативны, чем структурные.
Все компоненты структурных и функциональных схем должны быть описаны. При структурном подходе особенно тщательно необходимо прорабатывать спецификации межпрограммных интерфейсов, так как от качества их описания зависит количество самых дорогостоящих ошибок. К самым дорогим относятся ошибки, обнаруживаемые при комплексном тестировании, так как для их устранения могут потребоваться серьезные изменения уже отлаженных текстов.
Унифицированный язык объектно-ориентированного моделирования 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 и сетей Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов. Диаграммы деятельности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать.
Диаграммы деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.
Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.
Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения программы.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за компиляцию и сборку системы. Они нужны там, где начинается генерация кода.
Ответьте на контрольные вопросы (ответы пришлите преподавателю):
1. Какие существуют виды схем, описывающих структуру и процесс работы приложения?
2. Что представляет из себя структурная схема?
3. Приведите примеры структурных компонентов программного обеспечения.
4. Какие существуют методики структурного проектирования программного обеспечения?
5. Что такое функциональная схема?
6. В чём преимущество функциональной схемы по сравнению со структурной?
7. При помощи какого языка можно составить описание, моделирующее программную систему?
8. Какие наборы диаграмм используются в UML?
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru