Структурно функциональная схема программы

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

Содержание

Система автоматизации структурно может быть представлена по-разному.

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

В теории автоматического управления чаще всего имеют дело с функциональной и алгоритмической структурами (схемами).

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

Обычно вначале составляют функциональную схему АСУ, а затем – алгоритмическую.

Структурные схемы ИС

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

Функциональные схемы автоматизации

Допускается применять условные графические обозначения .

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

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

Алгоритмические схемы ИС

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

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

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

Логические выражения, таблицы истинности ,структурная логическая схема

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

Различают следующие виды алгоритмических звеньев:

Статическое звено – звено, преобразующее входной сигнал в выходной мгновенно (без инерции).

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

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

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

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

Арифметическое звено – звено, осуществляющее одну из арифметических операций: суммирование, вычитание, умножение, деление.

Наиболее часто встречающееся в автоматике арифметическое звено – звено, выполняющее алгебраическое суммирование сигналов, называют сумматором.

Логическое звено – звено, выполняющее какую-либо логическую операцию: логическое умножение («И»), логическое сложение («ИЛИ»), логическое отрицание («НЕ») и т.д.

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

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

Функциональные схемы ИС

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

В проектах автоматизации изображают конструктивные структурные схемы с элементами функциональных признаков.

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

Графическое построение схемы должно давать наиболее наглядное представление о последовательности взаимодействия функциональных частей в изделии. На линиях взаимодействия рекомендуется стрелками (по ГОСТ 2.721-74 ) обозначать направления хода процессов, происходящих в изделии.

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

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

Такими функциями могут быть:

• получение информации о состоянии объекта управления;
• преобразование сигналов;
• сравнение сигналов и т.п.

В качестве частей функциональной структуры (схемы) АСУ рассматриваются функциональные устройства. Названия устройств указывают на выполнение определенной функции. Например:

• датчик;
• усилитель;
• блок сравнения;
• управляющий блок;
• исполнительное устройство и т.п.

Конструктивные схемы

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

05.04.2022, 1334 просмотра.

Источник: myfilology.ru

Функциональная схема приложения

Цель занятия: познакомиться с принципами построения структурной и функциональной схем приложения.

Структурная схема приложения

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

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

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

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

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

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

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

Тот же метод позволяет получить структурные схемы с большим количеством уровней. Разбиение на модули выполняется эвристически, исходя из рекомендуемых размеров модулей (20-60 строк) и сложности структуры (2-3 вложенных управляющих конструкции). Для анализа технологичности иерархии модулей используют методики Константайна или Джексона.

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

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

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

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

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

1. вид хранимой информации каждого элемента данных — определяет тип соответствующего поля па­мяти;

2. связи элементов данных и вложенных структур, а также совокупность операций над ними — определя­ют структуры памяти, используемые для представления данных;

3. время хранения данных структуры («время жизни») — учитывается при размещении данных в статической или динамической памяти, а также во внешней памяти.

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

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

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

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

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

Функциональная схема приложения

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

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

Унифицированный язык объектно-ориентированного моделирования 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?

Дата добавления: 2021-04-15 ; просмотров: 480 ; Мы поможем в написании вашей работы!

Поделиться с друзьями:

Источник: studopedia.net

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

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

• Главная
• Информатика
• Структурные и функциональные модели. Программирование, как моделирование

Слайды и текст этой презентации

Слайд 1Структурные и функциональные модели. Программирование как моделирование.
Лагутин

Максим
4 курс Туризм 3группа

Слайд 2Функциональная модель
Функциональная модель предназначена для изучения особенностей

работы (функционирования) системы и её назначения во

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

Слайд 3Структурная модель
Четкого определения структурной модели не существует.

Так, под структурной моделью устройства могут подразумевать:
структурную

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

Слайд 4Под структурной моделью процесса обычно подразумевают характеризующую

его последовательность и состав стадий и этапов

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

Слайд 5Например, — это могут быть упрощенное изображение

звеньев механизма в виде стержней, плоских фигур

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

Слайд 6Состояние прототипа – это совокупность свойств его

составных частей, а также его собственных. Состояние

– «моментальная» фотография прототипа для выбранного момента времени. С течением времени состояние может изменяться – тогда говорят о существовании процесса. В соответствии со сказанным возможно построение модели состояния и модели процессов. Модели первого типа называются структурными моделями, второго типа – функциональными моделями.

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

Слайд 7Как правило, функциональные модели более сложные, поскольку

в них отражаются также сведения о структуре

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

Слайд 8Проектирование технологического процесса изготовления изделия также характеризуется

различными иерархическими уровнями: самый высокий уровень — разработка

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

Слайд 9Описание реальных объектов и процессов в некоторых

формальных терминах принято называть моделированием, а полученную

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

Слайд 10Такое представление позволяет описать и перенести любые

математические модели в среду некоторого языка программирования

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

Слайд 11Составление любой модели проходит несколько этапов. На

первом этапе выполняется словесная постановка задачи. Здесь

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

Слайд 12Дальнейший этап состоит в поиске математического описания

модели или в выборе из нескольких возможных.

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

Слайд 13Последний этап состоит в программировании, то есть

в перенесении полученной математической модели в среду

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

Источник: thepresentation.ru