вопросы. общие вопросы. Программа ипрограммирование
 Скачать 1.45 Mb.
|
2. Типовые алгоритмы управления в технических системах2.1. Элементарные составляющие типовых ауК типовым аналоговым АУ (или ЗУ), реализуемым в промышленно выпускаемых регуляторах и системах управления (например, электроприводах), относят следующие: - пропорциональный (П -закон); - интегральный (И -закон); - пропорционально - интегральный (ПИ-закон); - пропорционально - дифференциальный ( ПД -закон) - пропорционально -интегрально--дифференциальный (ПИД – закон) Основными составляющими типовых АУ, реализующими законы любой сложности являются П -закон, И- закон и Д-закон. Последний не является при этом типовым; он может лишь входить в качестве составляющей в более сложные законы, либо использоваться для коррекции динамических свойств устройств или объектов. П -закон управления Запись пропорционального АУ во временной области имеет вид:  (2.1)гдe  - номинальная для каждой системы величина управляющего сигнала; - ошибка управления; х и - заданное и текущее значения управляемой переменной. Эта же запись в приращениях может быть представлена выражением (2.1а)а передаточная функция (ПФ) звена, реализующего П -закон  (2.1b)Сведения, касающиеся частотных и иных характеристик П -звена, можно найти в работах (3-6). К основным же свойствам П -закона относятся: 1) статизм (для того, чтобы появился и сохранялся управляющий сигнал  , необходимо наличие ошибки управления ; поэтому при пропорциональном управлении неизбежна установившаяся ошибка отработки входных сигналов, ограниченных по амплитуде);2) быстродействие (управление мгновенно меняется с появлением отклонения );3) простота реализацией настройки. Этот закон рекомендуется применять для управления объектами невысокого порядка без запаздывания. Повышение коэффициента усиления регулятора приводит к увеличению быстродействия и уменьшению статической ошибки регулирования, но, в общем случае, снижает устойчивость системы. Такая альтернатива дает возможность ставить и решать задачи параметрической оптимизации П закона, нужно, однако, заметить, что в отдельных случаях повышение к может, до определенных пределов, наоборот увеличивать устойчивость. Пропорциональный закон является основой для всех многопараметрических ЗУ, а при решении задач синтеза определение параметра его настройки является, обычно, ключевым этапом. Д-закон управления Во временной области идеальный Д -закон управления описывается дифференциальным уравнением (ДУ) вида  (2.2)или в приращениях  (2.2а)Соответственно, ПФ Д -звена имеет вид  (2.2b)Настроечная константа этого закона -  - определяет интенсивность воздействия по производной.Как, уже указывалось, Д -закон не может выполнять функции управляющего устройства (УУ) или главного регулятора. Это связано о тем. что он реагирует, согласно (2.2), лишь на скорость изменения ошибки и безразличен к ее абсолютному значению в установившемся состоянии (  для ). Однако в составе сложных АУ он значительно повышает быстродействие и уменьшает динамическую ошибку управления за счет ”предсказания” дальнейшего ее поведения, а его корректирующее воздействие в замкнутых контурах обеспечивает снижение или повышение интенсивности изменения корректируемого сигнала в зависимости от знака обратной связи.В чистом виде (идеальный) Д -закон нереализуем [7] так как соответствует предсказанию поведения функций при еще не найденном решении. Однако приближение этого закона может быть получено практически сколь угодно точное. Этот вопрос рассматривается ниже. И -закон управления Данный закон описывается ДУ следующего вида:  (2.3)или эквивалентным ему интегральным уравнением  (2.3а)Здесь  представляет собой настроечную константу И -закона и носит название время интегрирования (в технической литературе прошлых лет применялся термин время изодрома). Увеличение приводит к замедлению нарастания управляющего сигнала при наличии ошибки управления.Для И -звена ПФ описывается обратным (2.2b) выражением  (2.2b)Этот закон часто называют “управление с памятью” или управлением по накопленному опыту изменения ошибки. Его фундаментальные свойством является астатизм первого порядка, т.е. отсутствие установившейся ошибки управления при действии на систему ограниченных по величине входных воздействий (как задающих, так и возмущающих). Это объясняется тем., что управляющий сигнал  , согласно (2.3а), меняется во времени до тех пор, пока . Он как бы "ищет" такое значение управления, которое компенсирует влияние входного воздействия. Однако поисковый характер И -закона определяет также и его основной недостаток -низкое 'быстродействие. Кроме того, включение в замкнутую систему И -звена снижает степень его устойчивости за счет опускания фазочастотной характеристики разомкнутой системы на . Интегральный закон управления рекомендуется применять в тех случаях, когда недопустима установившаяся ошибка, а быстродействие объекта значительно выше требуемого в проектируемой системе. Более подробные сведения о характеристиках и свойствах И -закона можно найти в работах (3-6).Общая оценка элементарных составляющих АУ Итак, пропорциональная составляющая реализует постоянное наблюдение за текущим значением ошибки регулирования и мгновенно вырабатывает управление, стремящееся ее уменьшить. Дифференциальная составляющая следит за тенденцией изменения ошибки регулирования и вырабатывает составляющую закона управления, стремящуюся предвосхитить появление ошибки или уменьшить интенсивность ее нарастания. Наконец, интегральная составляющая запоминает прошедший переходный процесс подавления ошибки и вырабатывает составляющую управления, компенсирующую влияние установившегося на данный отрезок времени значения внешнего воздействия. Из рассмотренных составляющих П и И входят в число самостоятельных типовых законов и реализуются в промышленно выпускаемых регуляторах и системах управления 24)Функциональная методология IDEF0 — методология функционального моделирования (англ. functionmodeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ). Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того, существуют правила сторон: стрелка входа всегда приходит в левую кромку активности, стрелка управления — в верхнюю кромку, стрелка механизма — нижняя кромка, стрелка выхода — правая кромка. Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку. Описание методологии IDEF0 содержится в рекомендациях Р 50.1.028-2001 «Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования». Также отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-процессов и проектов, основанных на моделировании всех процессов: как административных, так и организационных. 25) Методология DFD DFD — общепринятое сокращение от англ. dataflowdiagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем. Исторически сложилось так, что для описания диаграмм DFD используются две нотации — Йордана (Yourdon) и Гейна-Сарсон (Gane-Sarson), отличающиеся синтаксисом. Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям. Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием). Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы. Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Её назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, Диаграмма вариантов использования. 25-Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram – DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов. При создании диаграммы потоков данных используются четыре основных понятия: – потоки данных, – процессы (работы) преобразования входных потоков данных в выходные, – внешние сущности, – накопители данных (хранилища). Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Процессы (работы) служат для преобразования входных потоков данных в выходные. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить документы по от- грузке продукции»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных моделирует данные, которые будут сохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Кроме основных элементов, в состав DFD входят словари данных и миниспецификации. Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая потоки данных, хранилища и процессы, а также все их атрибуты. Мини-спецификации обработки – описывают DFD- процессы нижнего уровня. Фактически мини-спецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех мини-спецификаций является полной спецификацией системы. Диаграммы потоков данных строятся в виде иерархии. Сначала строится контекстная диаграмма. При проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы. Для сложных систем (признаками сложности могут быть наличие большого количества внешних сущностей (десять и более), распределенная природа системы или ее многофункциональность) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному или более потокам данных: входные потоки интерпретируются как воздействия, а выходные потоки – как реакции системы на входные потоки. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев: – наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); – возможности описания преобразования данных процессов в виде последовательного алгоритма; – выполнения процессом единственной логической функции преобразования входной информации в выходную; – возможности описания логики процесса при помощи спецификации небольшого объема (не более 20-30 строк). В качестве языка спецификаций обычно используются структурированный естественный язык или псевдокод. В методологии DFD используются две нотации: Йодана-Де Марко (Yourdan) и Гейна-Сарсона (Gane-Sarson) – табл. 1.1. Следует отметить, что в BPwin формально используется нотация Гейна-Сарсона, но с рядом отступлений: отсутствуют мини-спецификации, отличается изображение функций, контекстная диаграмма не может содержать подсистемы. Таблица 1.1. Элементы методологии DFD в нотациях Гейна-Сарсона и Йодана-Де Марко Сравнивая методологии DFD и IDEF0, можно отметить, что в методологии DFD, кроме расширения изобразительных возможностей диаграмм (за счет хранилищ данных), изменяются правила интерфейсов для стрелок: стрелки могут входить и выходить с любой стороны блока. 26-Унифицированный язык моделирования (UML - Unified Modeling Language) в настоящее время можно рассматривать как стандартный инструмент для создания графического описания (диаграмм) разрабатываемого программного обеспечения. Используя средства UML, можно выполнять визуализацию процесса разработки различных программных систем, а также конструировать, специфицировать и документировать этот процесс. UML с одинаково успешным результатом можно применять как для разработки простых информационных систем, например, информационных систем масштаба предприятия, так и достаточно сложных, таких как распределенные Web-приложений и даже встроенные системы реального времени. Этот язык достаточно выразителен для того, чтобы позволить рассмотреть разрабатываемую систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию, но, с другой стороны, достаточно прост для понимания, изучения и использования. Моделирование, т.е. предварительное планирование, особенно в графическом виде, чрезвычайно важно как для понимания системы в целом, так и для усвоения ее работы при решении отдельных, конкретных задач. Поэтому обычно наличия единственной модели, разработанной на самом раннем этапе анализа, никогда не бывает достаточно. Наоборот, для понимания, как разработчиками, так и заказчиками практически любой программной системы приходится разрабатывать большое количество взаимосвязанных моделей. И на этом этапе возникает множество проблем. Потому как характерной особенностью мышления большинства программистов является то, что размышления о том, как реализовать проект, для них практически всегда подразумевают банальное создание программного кода для этого проекта. Конечно, не будем спорить, некоторые вещи проще и лучше выразить именно в коде на каком-нибудь языке программирования, но так происходит далеко не всегда. Такой подход, когда разработчик программной системы пытается сразу написать программу, не представив предварительно графически свои мысли по поводу ее работы и вариантов использования, чреват рядом неприятностей: ‒ во-первых, вести диалог по обсуждению разработанной модели можно только в том случае, когда участники понимают друг друга, т.е. говорят на одном языке и понимают смысл каждого слова (или элемента диаграммы, как в нашем случае); ‒ во-вторых, наличие модели системы просто необходимо в том случае, когда система выходит за рамки текстового языка программирования, и проиллюстрировать связи и взаимодействия ее компонентов, пользуясь только программным кодом, очень и очень затруднительно; ‒ в-третьих, если все-таки разработчик (системный аналитик) разрабатывал модели системы, но делал это от руки, «на коленке», как говорится, а не официально, документируя все построенные диаграммы с помощью case-средств, то будет очень сложно восстановить эти модели в случае неожиданного отсутствия доступа к этому человеку (например, при его уходе на длительный больничный или, еще того хуже, к конкурентам). Использование UML позволяет решить эти проблемы. Этот язык моделирования - не просто набор графических символов, за каждым этих символов стоит определенная семантика, смысл, которые подразумевают, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим. Причем на месте второго разработчика может выступать не только человек, но и некоторое инструментальное средство. Это решение первой проблемы. Некоторые особенности системы лучше всего моделировать в виде текста, другие - графически. Практика свидетельствует, что во всех интересных системах существуют структуры, которые очень сложно, а иногда и попросту невозможно представить с помощью одного языка программирования. А UML – это графический язык, что позволяет решить нашу вторую проблему. Ну и, наконец, явная графическая модель, состоящая из сравнительно небольшого количества унифицированных элементов, намного облегчает общение как между отдельными разработчиками, так и между разработчиком и заказчиком, что позволяет решить и третью, озвученную выше, проблему. Надеюсь, мы вас убедили в важности предварительного моделирования программных систем. А теперь подробнее рассмотрим, как это просто сделать с помощью case-средств. 27-Словарь UML включает три вида основных конструкций (рис.1): ‒ сущности - абстракции, являющиеся основными элементами модели;-структурные,поведенческие,группирующие,аннотционные ‒ отношения - связи между сущностями; ‒ диаграммы, группирующие представляющие интерес множества сущностей и отношений. 28-В унифицированном языке моделирования определены четыре основных типа отношений, которые являются основными связующими конструкциями и применяются для построения корректных моделей. К этим типам относят: зависимость, ассоциацию, обобщение и реализацию. Рассмотрим типы отношений подробнее. Зависимость (dependency) представляет собой семантическое отношение между двумя сущностями, одна из которых является зависимой от другой. при использовании такого типа отношения изменение независимой сущности может повлиять на семантику зависимой. Для графического отображения зависимости применяют пунктирную линию со стрелкой (рис. 14); возможно также наличие метки. Рис. 14 Пиктограмма зависимости Ассоциация (association) представляет собой структурное отношение, описывающее совокупность смысловых связей между объектами. Разновидностью ассоциации является агрегирование (aggregation) - отношение между целым и его частями. Графически ассоциация изображается в виде сплошной линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей (рис. 15). Рис. 15 Пиктограмма ассоциации Обобщение (generalization) описывает взаимодействие объектов-потомков (child) и объектов-родителей (parent), возможность их взаимозаменяемости. При этом, как и положено в объектно-ориентированном программировании, потомок наследует структуру и поведение своего предка. Графически отношение обобщения представляется в виде линии с незакрашенной стрелкой, указывающей на предка (рис.16). Рис. 16 Пиктограмма обобщения Реализация (realization) представляет собой семантическое отношение между двумя классификаторами, при этом один классификатор определяет некоторое обязательство, а другой гарантирует выполнение этого обязательства. Такой тип отношений может применяться в двух случаях: ‒ между интерфейсами и реализующими их классами или компонентами, ‒ между прецедентами и реализующими их кооперациями. На диаграмме реализация отображается пунктирной линией с незакрашенной стрелкой (рис. 17). 29-Диаграмма в UML — это графическое представление набора элементов, представляющее собой некий связанный граф с вершинами (сущностями) и ребрами (отношениями). Основная цель составления диаграмм – это визуализация разрабатываемой системы с разных точек зрения и в разных обстоятельствах. Теоретически диаграммы программных систем могут содержать любые комбинации сущностей, однако на практике применяется сравнительно небольшое количество типовых комбинаций, соответствующих одному из пяти наиболее необходимых видов архитектуры программной системы. Поэтому в UML определены девять типов диаграмм: 1) диаграмма вариантов использования или диаграмма прецедентов (use case diagram); 2) диаграмма объектов (object diagram); 3) диаграммы взаимодействия: a) диаграмма последовательностей (sequence diagram); b) диаграмма кооперации (collaboration diagram); 4) диаграмма классов (class diagram); 5) диаграмма состояний (statechart diagram); 6) диаграмма деятельности (activity diagram); 7) диаграмма компонентов (component diagram); 8) диаграмма развертывания (deployment diagram). 30-Впервые модели use case были применены в процессе разработки программного обеспечения А. Якобсоном в 1992г. Изначально такие моде- ли были разработаны для проектирования объектно-ориентированного ПО, но успех их оказался столь значительным, что впоследствии произошла интеграция таких моделей во все основные методы и подходы проектирования программных средств. Основная идея создания диаграммы вариантов использования состоит в детализированном описании некоторой задачи, достаточно упрощенном, завершенном и не зависящем от технологии реализации, выраженном на языке данной прикладной области и пользователей системы. Каждый элемент use case в повествовательной форме описывает, в основном, определенное взаимодействие рассматриваемой системы и пользователя, обеспечивая функциональность проектируемой системы и понятное пользователю описание применения этой системы. Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Действующее лицо (Actor) – представляет собой роль (а не конкретных людей), которую пользователь играет по отношению к разрабатываемой программной системе. В некоторых случаях в качестве действующего лица может выступать даже некая внешняя система, которая вступает во взаимосвязь с моделируемой системой на предмет получения информации. Так как варианты использования создаются разработчиками совместно с заказчиком, индивидуально для каждого случая, то стиль написания во многом зависит от сложности проекта, количества и профессионального уровня участников. Но можно рекомендовать несколько общих правил: ‒ наименования разрабатываемых вариантов использования должны быть понятны заказчику, т.е. должны содержать минимальное количество специализированных, технических терминов; ‒ каждый вариант использования должен описывать завершенную ситуацию, причем эта ситуация должна иметь определенную ценность для пользователя системы; ‒ вариант использования должен быть прост, легко читаем и доступен в изучении как для разработчиков, так и для заказчика. ‒ Например, на рисунке 18 приведена основная диаграмма прецедентов для виртуального книжного магазина. По ней легко можно отследить внешних сущностей по отношению к программной системе – актеров (администратор, покупатель, пользователь), и их возможные действия в данной системе. 31-32-любые примеры с интернета Вопрос 34 Особенности Visual Basic, интерфейс Visual Basic |