Привет, Вы узнаете про событийное программирование, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое событийное программирование , настоятельно рекомендую прочитать все из категории Стили и методы программирования.
Событие, сообщение, демон
Упомянутое ранее (утверждение (5.2)) качество
Подготовка информации для действий в ходе распознавания условий применимости действий, (13.1)
пожалуй, является критическим моментом для разделения случаев использования сентенциального и событийного программирования. Проверка приоритетов и выбор действия с наивысшим приоритетом в качестве активного точно так же, как отождествление метавыраженияв сентенциальном случае, запрятана в атомарные действия программной системы, но при проверке приоритетов программист не получает никакой полезной информации для проведения выбранного действия. Если какая-то полезная информация и получается будущим действием, то она задается отдельно и императивно, в параметрах сообщения, вызывающего событие. В свою очередь, наличие либо практическое отсутствие такой информации определяет разницу двух ипостасей событийного программирования: программирования отсобытий и от приоритетов.
ПРАВИЛА ПРОГРАММИРОВАНИЯ
Следует заметить, что есть еще одна особенность, общая для двух стилей: сентенциального и событийного.
Отделение проверки условий от выполнения действий (13.2)
Это представляется общей характеристикой технологических решений для стилей, где условия глобальны.
До сих пор мы ничего не говорили о том, какие события возможны при программировании в событийно-ориентированном стиле. Исторически этот стиль как определенный художественный прием сформировался в области разработки операционных систем, где естественно связывать понятие события с прерываниями. Прерывание — это сигнал от одного из устройств (может быть, и от самого процессора), который говорит о том, что произошло нечто, на что следует обратить внимание. Когда происходит прерывание, операционная система распознает, какая причина его вызвала, и далее формирует событие как информационный объект, вызывающийреакцию программной системы. Возможны разные способы реагирования на события, в том числе и передача его для обработки той программе, при выполнении которой возникло прерывание, породившее это событие.
Из потребности такой обработки, собственно говоря, и сформировался событийно-ориентированный стиль программирования. Наиболее очевидная область его адекватного применения — реализация интерактивных взаимодействий программы с пользователем и решение других подобных задач (например, тех, которые требуют опроса датчиков состояния каких-либо технологических процессов).
В частности, при взаимодействии с пользователем чаще всего достаточно таких событий, как нажатие на клавишу, перемещение курсора мыши, указание световой кнопки и т. п. Не случайно именно те прерывания, которые способна перенаправить операционная система для обработки на уровень пользовательской программы, стали основой для выработки систем событий, реакция на которые задается в событийно-ориентированном стиле. События этого рода можно передать от одного обработчика к другому, не нарушая условий адекватного применения данного стиля: для этого достаточно объявить такое перенаправление события порождением нового события.
ООП на простых примерах. Объектно-ориентированное программирование
Но требуется также генерация событий, не связанных с прерываниями. К примеру, программируя в событийно-ориентированном стиле, естественно объявить событием ситуацию, когда значение одной переменной становится больше другой. Однако такого рода свойства вычислительного процесса никак не отражаются в системе прерываний, а потому обычные языковые средства событийно-ориентированного программирования (например, в Delphi), часто провозглашаемые как универсальные, здесь не помогут. Необходимы иные механизмы, которые уводят программиста из области шаблонов проектов, стандартизующих обработку событий.
Об этом обстоятельстве, ограничивающем применимость подхода, предпочитают умалчивать, и, как обычно бывает в подобных ситуациях, при беглом знакомстве с соответствующими средствами могут возникнуть ни на чем не основанные ожидания с последующими разочарованиями и даже отторжением стиля, хорошо работающего на своем месте.
Примером языка, до некоторой степени ориентированного на событийно-ориентированное программирование, может служить Perl.
Событийный стиль удобен не только на уровне конкретного программирования. Часто концептуальное осмысление задачи полезно проводить в терминах системы событий, а уж затем решать, как реализовывать систему: непосредственно использовать события как средство управления, моделировать событийное взаимодействие имеющимися средствами или вообще отказаться от этого механизма в данной разработке.
В качестве иллюстрации этого тезиса опишем с позиций событийного стиля программирования взаимоотношения между синтаксическим анализом и вычислениями семантики программы. Реализация этих взаимоотношений — обычная задача, решаемая при разработке любого транслятора.
В событийном описании этой задачи в качестве событий системы естественно рассматривать распознавание во входном потоке (транслируемом тексте) синтаксических единиц, то есть конструкций языка. Такое событие требует в качестве обработчика семантическую подпрограмму, связанную с распознаваемой конструкцией. Следовательно, выявлены два автономных процесса:синтаксический анализ, задающий генерацию событий, и семантическая обработка, осуществляемая как последовательность вызовов семантических подпрограмм-реакций, упорядоченная событиями . Об этом говорит сайт https://intellect.icu . Коль скоро есть концептуальное разделение процессов, его можно воплотить в реальной системе в событийном стиле. Это решение влечет за собой следующее.
- Необходимость рассмотрения в качестве событий двух фактов: начала и завершения распознавания конструкции, поскольку именно с ними, а не с конструкцией в целом связываются семантические действия.
- Для обсуждаемой задачи существенно, что события возникают не в произвольном порядке, их множество имеет вполне определенную структуру. Не удивительно, что эта структура в точности соответствует синтаксической структуре текста: например, событиезавершения распознавания конструкции не может возникать раньше, чем возникнет событие начала конструкции.
- Следствием этой структуры является понятие ожидания вполне определенных, а не произвольных событий. Если ожидание не оправдалось, то это можно считать событием еще одного вида: ошибочная ситуация. Количество таких событий в точности равно числу наборов ожидаемых событий.
При событийном программировании разделение процессов генерации и обработки событий влечет за собой их полную независимость. В практике программирования транслирующих систем это качество считается не очень удобным, и вместо событийного механизма обычно используется схема сопрограммного взаимодействия с так называемым синтаксическим управлением: синтаксический анализатор сам вызывает нужные семантические программы, когда распознает необходимость сделать это (в событийном стиле это означает генерацию соответствующего события ). Нет никакого противоречия между двумя схемами, и единственное различие между ними в том, что при синтаксическом управлении ожидание события оказалось возможным подменить прямым вызовом подпрограммы. Иными словами, в схеме трансляции удается статически, до выполнения программы вычислить события, наступление которых требует вызова их обработчиков (семантических подпрограмм). Вообще, сопрограммное взаимодействие можно трактовать как статически вычисленнуюсобытийность 1 .
Разумеется, рамки событийного программирования много шире тех случаев, когда можно статически определять необходимость активизации обработчика. Полезно объединение генерации событий с их обработкой, и за счет него можно растворять события в программе. В частности, и по этой причине следует рассматривать событийное программирование как самостоятельный стиль.
Но интересны и такие случаи, когда объединение, хотя и возможно, но не делается. Конкретный пример — XML/XSL технология, для которой разделение структуры и интерпретации текста считается принципиальным: это позволяет строить съемные системы обработки, иметь несколько независимых таких систем для разного назначения. В своей сфере применения многовариантность имеет большие преимущества, но, как всегда, перенос принципов данной технологии куда угодно чреват уже не раз отмеченной неадекватностью.
Программирование от приоритетов
Обсуждая событийное программирование, мы упомянули о том, что при программировании в этом стиле может возникнуть потребность в упорядочивании выполнения нескольких конкурирующих между собой реакций на события. Достаточно универсальным средством удовлетворения этой потребности является приписывание реакциям приоритетов: сначала выполняются те реакции, которые имеют больший приоритет. Этот прием, как выявилось на практике, пригоден для решения достаточно широкого круга задач. Он стал основой для формирования самостоятельного варианта событийного стиля: программирования от приоритетов.
Данная ипостась стиля порождена практическими потребностями. Она предназначена для организации работы многих взаимодействующих процессов, динамически порождаемых и исчезающих. Фундаментальных теоретических исследований в области программирования отприоритетов почти нет. В частности, в классической работе Хоара [ 29 ] , в которой рассматривается управление взаимодействующими процессами, предполагается, что программа написана в традиционном структурном стиле и никаких попыток приспособить ее к обстановке, где имеется много процессов, нет 2 .
Стиль программирования от приоритетов не реализован систематически в виде законченного языка (в качестве некоторой попытки можно привести проект Joule, см. http://www.agorics.com/Library/joule.html), но часто используется в прикладных языках скриптов для управления процессами или событиями либо в распределенных системах, либо на полуаппаратном уровне (так называемые встроенные программы, являющиеся частью специализированного прибора или устройства).
В программировании от приоритетов, как и в сентенциальном программировании, порядок расположения операторов в программе не играет принципиальной роли, зато важен приоритет оператора, то есть некоторое значение, принадлежащее в самом общем случае частично-упорядоченному множеству и почти всегда рассматриваемое как элементарное. После завершения очередного оператора среди оставшихся выбирается оператор с максимальным приоритетом. Если таких операторов с равными или несравнимыми приоритетаминесколько, то, вообще говоря, в идеале надо было бы выбирать один из них недетерминированно.
Об операторах, имеющих приоритеты, можно говорить, когда программирование от приоритетов реализовано в специально предназначенном для этого стиля языке. Если же приходится моделировать программирование от приоритетов в обычном языке, то в качестве таких операторов могут выступать иные структурные единицы текста программы. В объектно-ориентированном языке, как правило, это методы объектов. Для краткости, в рамках настоящего параграфа мы будем говорить об операторах, имея в виду только что сделанное замечание.
При назначении приоритетов важно различать случаи, когда они задаются для операторов как элементов текста программы и когдаприоритеты вводятся для динамических структурных единиц, то есть для тех элементов процесса вычислений, которые возникают в ходе выполнения программы, но связаны с тем или иным оператором, приоритет которого определяется в рамках конкретного экземпляра (например, объекта). Таким образом выстраиваются разные системы приоритетов, причем во втором случае система приоритетоввынужденно оказывается динамической.
На практике обычно используют жесткую дисциплину, базирующуюся на порядке операторов в программе. Часто управление поприоритетам соединяется с так называемой системой демонов, то есть процедур, вызываемых при выполнении некоторого условия, а не в тот момент, когда при движении по тексту программы мы подошли к их явному вызову (сидит такой демон в засаде и выжидает момент, когда можно будет начать исполняться). И текущий «нормальный» процесс, и проснувшиеся демоны имеют свои приоритеты, и демонначнет исполняться, даже если он активизирован, лишь в том случае, если среди активных не осталось процесса с большим, чем у демона,приоритетом. Эта схема реализована, в частности, в системе UNIX.
Уместно отметить, что событийно-ориентированное программирование порою может рассматриваться как вырожденный случай стиля программирования от приоритетов: для каждого экземпляра структурной единицы, способной реагировать на события, выставляется (бесконечно большой) приоритет, если этот экземпляр фактически должен активизировать реакцию, и не выставляется приоритет(выставляется бесконечно малый приоритет ), если экземпляр не должен реагировать на событие. Общий случай стиля событийно-ориентированного программирования также близок к стилю программирования от приоритетов, если считать, что всем обработчикамсобытия, которые должны быть выполнены при его появлении, присвоены приоритеты, соответствующие фактическому порядку их выполнения. Когда такой порядок неизвестен, можно считать, что всем активизируемым обработчикам присвоены равные приоритеты.
Кардинальное различие между программированием от событий и от приоритетов состоит в принципах задания управления. В случае программирования от событий установлена прямая связь между событием и реакцией: если условие срабатывания открывает для обработчика возможность быть выполненным, то он обязательно будет выполнен в ответ на соответствующее событие. При программировании от приоритетов ситуация иная: задавая демону даже наивысший приоритет, можно лишь надеяться на то, что он сработает раньше других, причем, возможно, даже без появления какого бы то ни было события. Если абстрагироваться от механизма управления при оперировании с приоритетами и событиями, то можно считать эти два стиля вариантами одной сущности.
Варианты событийного программирования от событий и приоритетов хорошо совмещаются, взаимно дополняя друг друга, когда целесообразна следующая архитектурная схема разработки программного проекта. От событий строятся фрагменты системы, которые отвечают за реакцию на каждое из событий, реализуемую разными обработчиками, а программирование этих обработчиков ведется отприоритетов.
Рассмотрим написанный в двух вариантах на двух условных языках пример программы с приоритетами.
3: Цикл пока не будет все сделано < 5: Подготовка данных; 10: Обработка текущих изменений; >4: Демон ; 8: Демон ; 12: Демон ;
Источник: intellect.icu
23. Событийно-ориентированное программирование.
Событийно-ориентированное программирование (event-driven programming) — это парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).
Событийно-ориентированное программирование можно также определить как способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события.
Событийно-ориентированное программирование, как правило, применяется в трех случаях:
- при построении пользовательских интерфейсов (в том числе графических);
- при создании серверных приложений в случае, если по тем или иным причинам нежелательно порождение обслуживающих процессов;
- при программировании игр, в которых осуществляется управление множеством объектов.
СОП можно также определить как способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события.
Как правило, в реальных задачах оказывается недопустимым длительное выполнение обработчика события, поскольку при этом программа не может реагировать на другие события.
При каждом движении мыши, нажатии на ее кнопки или клавиши на клавиатуре генерируется событие. События могут также генерироваться системным таймером или пользовательскими программами. Существуют также «визуальные» события: например, сдвинув или закрыв одно из окон, мы открыли часть окна, находившегося внизу. Этому окну посылается событие, говорящее, что ему нужно перерисовать часть себя.
Каждое событие представляет собой структуру данных, которая содержит код, обозначающий тип события: движение мыши, нажатие кнопки и т.д., а также поля, различные для различных типов событий: для «мышиных» событий это текущие координаты мыши и битовая маска, обозначающая состояние кнопок (нажата/отпущена). Для клавиатурных событий это код нажатой клавиши — обычно, ASCII для алфавитноцифровой клавиатуры и специальные коды для стрелок и других «расширенных» клавиш — и битовая маска, обозначающая состояние различных модификаторов, таких как SHIFT, CNTRL, ALT, и т.д. для визуальных событий это координаты прямоугольника, который нужно перерисовать, и так далее.
Все события помещаются в очередь в порядке их возникновения.
В системе существует понятие обработчика событий. Обработчик событий представляет собой об ект, то есть структуру данных, с которой связано несколько программных модулей — методов. Один из методов вызывается при поступлении события и называется callback (дословно — «вызов назад»).
Представим себе простой об ект, такой как меню. При нажатии на кнопку мыши в области этого меню вызывается callback. Он разбирается, какой из пунктов меню был выбран, и вызывает соответствующую функцию обработки этого пункта. Таким образом, вместо последовательно исполняющейся программы, время от времени вызывающей систему для исполнения той или иной функции, мы получаем набор callback’ов, вызываемых системой в соответствии с желаниями пользователя. Отсюда, видимо, и происходит термин «callback» — это «системный вызов, идущий в обратном направлении».
Специальная программа, менеджер событий, непрерывно просматривает очередь и передает поступающие события обработчикам. События, связанные с экранными координатами, передаются обработчику, ассоциированному с соответствующим окном. Клавиатурные события передаются фокусу клавиатуры — текущему активному обработчику.
33. Бизнес-процесс. Средства анализа и моделирования. Автоматизация бизнес-процессов.
Бизнес-процесс — это совокупность взаимосвязанных мероприятий или задач, направленных на создание определённого продукта или услуги для потребителей. В качестве графического описания деятельности применяются блок-схемы бизнес-процессов.
Существуют три вида бизнес-процессов:
- Управляющие — бизнес-процессы, которые управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
- Операционные — бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение,Производство, Маркетинг и Продажи.
- Поддерживающие — бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, АХО.
Бизнес-процесс начинается со спроса потребителя и заканчивается его удовлетворением. Процессно-ориентированные организации стараются устранять барьеры и задержки, возникающие на стыке двух различных подразделений организации при выполнении одного бизнес-процесса.
Бизнес-процесс может быть декомпозирован на несколько подпроцессов, процедур и функций, которые имеют собственные атрибуты, однако также направлены на достижение цели основного бизнес-процесса. Такой анализ бизнес-процессов обычно включает в себя составление карты бизнес-процесса и его подпроцессов, разнесенных между определенными уровнями активности.
Бизнес-процессы должны быть построены таким образом, чтобы создавать стоимость и ценность для потребителей и исключать любые необязательные или вовсе лишние активности. На выходе правильно построенных бизнес-процессов увеличиваются ценность для потребителя и рентабельность (меньшая себестоимость производства товара или услуги).
Бизнес-процессы могут подвергаться различному анализу в зависимости от целей моделирования. Анализ бизнес-процессов может применяться при бизнес-моделировании, функционально-стоимостном анализе, формировании организационной структуры, реинжиниринге бизнес-процессов, автоматизации технологических процессов.
Одним из методов анализа текущей деятельности является составление модели бизнес-процесса «как есть» (англ. as is). После этого модель бизнес-процесса подвергается критическому анализу или обрабатывается специальным программным обеспечением. По результатам анализа формируется модель бизнес-процесса «как должно быть» (англ. to be) и план мероприятий по внедрению необходимых изменений.
Существует множество нотаций, применяемых для моделирования бизнес-процессов, например:
Источник: studfile.net
Лекции по дисциплине _Разработка программных модулей_. Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование Ульяновск
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 98.34 Kb.
Тема 4 Событийно-управляемое программирование
Основные принципы событийно-управляемого программирования
Событийно-ориентиированное программиирование (англ. event-driven programming; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь, сенсорный экран), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета).
СОП можно также определить как способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события.
Как правило, в реальных задачах оказывается недопустимым длительное выполнение обработчика события, поскольку при этом программа не может реагировать на другие события. В связи с этим при написании событийно-ориентированных программ часто применяют автоматное программирование.
Под событием в языке программирования обычно понимается способ внедрения того или иного фрагмента в программный код с целью изменения поведения программы.
Как только происходит изменение среды вычислений из числа представляющих интерес для разработчика или пользователя программного обеспечения, активизируется событие и выполняется соответствующий фрагмент кода.
В целом, с точки зрения практического программирования, обработка события подобна вызову процедуры, причем в роли параметров выступают те или иные характеристики среды вычислений.
Любой современный интерфейс пользователя (или, в математической терминологии, среда вычислений) построен на основе обработки событий (onClick, onMouseMove, onMouseOver и т.д.). События, которые осуществляют взаимодействие с каналами локальных сетей, операционной системой, сторонними приложениями и т.д. могут также активизироваться по времени.
В соответствии со схемой двухуровневой концептуализации, первый уровень может означать, например, инициацию пользователем события «щелчок левой кнопкой мыши», а второй — изменение состояния объекта меню при выборе соответствующего пункта меню. Как видим, сначала возможный индивид становится действительным (т.е. происходит активация события), а затем осуществляется означивание объекта программы (изменяется текущая позиция меню). Фрагментом кода программы в таком случае является метод, изменяющий текущую позицию меню, который активизируется, исходя из значения первого соотнесения (т.е. конкретизации события). Таким образом, на основе механизма событий осуществляется управление программой.
Элементы управления
Почти все современные графические интерфейсы общего назначения строятся по модели WIMP — Window, Icon, Menu, Pointer (окно, иконка, меню, указатель). Внутри окон рисуются элементы графического интерфейса, которые для краткости будут называться виджетами (widget — штучка). Меню могут располагаться в различных частях окна, но их поведение достаточно однотипно: они служат для выбора действия из набора предопределенных действий.
Программа, реализующая графический интерфейс, событийно ориентирована. Она ждет от интерфейса событий, которые и обрабатывает сообразно своему внутреннему состоянию. Эти события возникают в элементах графического интерфейса (виджетах) и обрабатываются прикрепленными к этим виджетам обработчиками. Сами виджеты имеют многочисленные свойства (цвет, размер, расположение), выстраиваются в иерархию принадлежности (один виджет может быть хозяином другого), имеют методы для доступа к своему состоянию.
Расположением виджетов (внутри других виджетов) ведают менеджеры расположения. Виджет устанавливается на место по правилам менеджера расположения. В Tk имеются три типа менеджеров расположения: простой упаковщик (pack), сетка (grid) и произвольное расположение (place).
Рассмотрим некоторые классы виджетов библиотеки Tk :
1. Button (Кнопка) Простая кнопка для вызова некоторых действий
2. Canvas (Рисунок) Основа для вывода графических примитивов.
3. Checkbutton (Флажок) Кнопка, которая умеет переключаться между двумя состояниями при нажатии на нее.
4. Entry (Поле ввода) Поле, в которое можно ввести строку текста.
5. Frame (Рамка) Виджет, который содержит в себе другие визуальные компоненты.
6. Label (Надпись) Виджет может показывать текст или изображение.
7. Listbox (Список) Прямоугольная рамка со списком, из которого пользователь может выделить один или несколько элементов.
8. Menu (Меню) Элемент, с помощью которого можно создавать всплывающие (popup) и ниспадающие (pulldown) меню.
9. Radiobutton (Селекторная кнопка) Кнопка для представления одного из альтернативных значений. Такие кнопки, как правило, действует в группе.
10. Scrollbar (Полоса прокрутки) Полоса прокрутки служит для отображения величины прокрутки в других виджетах.
11. Text (Форматированный текст) Этот прямоугольный виджет позволяет редактировать и форматировать текст с использованием различных стилей.
15. Toplevel (Окно верхнего уровня) Показывается как отдельное окно и содержит внутри другие виджеты.
Диалоговые окна.
Пакет tkinter содержит несколько модулей, предоставляющих доступ к уже готовым диалоговым окнам. Это окна различных сообщений, выбора по принципу «да-нет», открытия и сохранения файлов и др. Рассмотрим примеры окон из модулей messagebox и filedialog пакета tkinter.
Модули пакета необходимо импортировать отдельно. То есть вы импортируете содержимое tkinter (например, from tkinter import *) и отдельно входящий в состав пакета tkinter модуль.
- import tkinter.messagebox → tkinter.messagebox.askyesno()
- from tkinter.messagebox import * → askyesno()
- from tkinter import messagebox → messagebox.askyesno()
- from tkinter import messagebox as mb (вместо mb может быть любой идентификатор) → mb.askyesno()
Окно выбора «да» или «нет» – askyesno:
Нажатие «Да» в диалоговом окне возвращает в программу True, «Нет» вернет False (также как закрытие окна через крестик). Таким образом в коде можно обработать выбор пользователя. В данном случае если последний соглашается, то данные переносятся из поля в метку.
Опции title и message являются позиционными, так что можно указывать только значения: askyesno(«Вопрос», «Перенести данные?»).
Подобные окна генерируются при использовании функции askokcancel с надписями на кнопках «ОК» и «Отмена», askquestion (возвращает не True или False, а строки ‘yes’ или ‘no’), askretrycancel («Повторить», «Отмена»), askyesnocancel («Да», «Нет», «Отмена»).
Другую группу составляют окна с одной кнопкой, которые служат для вывода сообщений различного характера. Это showerror, showinfo и showwarning.
Рассмотрим две функции из модуля filedialog – askopenfilename и asksaveasfilename. Первая предоставляет диалоговое окно для открытия файла, вторая – для сохранения. Обе возвращают имя файла, который должен быть открыт или сохранен, но сами они его не открывают и не сохраняют. Делать это уже надо программными средствами самого Python.
Опция filetype позволяет перечислить типы файлов, которые будут сохраняться или открываться, и их расширения.
Обработчики событий
В tkinter с помощью метода bind между собой связываются виджет, событие и действие. Например, виджет – кнопка, событие – клик по ней левой кнопкой мыши, действие – отправка сообщения. Другой пример: виджет – текстовое поле, событие – нажатие Enter, действие – получение текста из поля методом get для последующей обработки программой. Действие оформляют как функцию или метод, которые вызываются при наступлении события.
При вызове метода bind событие передается в качестве первого аргумента.
Название события заключается в кавычки, а также в угловые скобки . События описывается с помощью зарезервированных ключевых слов.
- – клик левой кнопкой мыши
- – клик средней кнопкой мыши
- – клик правой кнопкой мыши
- – двойной клик левой кнопкой мыши
- – движение мыши
- и т. д.
Для событий с клавиатуры буквенные клавиши можно записывать без угловых скобок (например, ‘a’).
Для неалфавитных клавиш существуют специальные зарезервированные слова. Например, — нажатие клавиши Enter, — пробел. (Заметим, что есть событие , которое не имеет отношения к нажатию клавиши Enter, а происходит, когда курсор заходит в пределы виджета.)
Введение в графику
В tkinter от класса Canvas создаются объекты-холсты, на которых можно «рисовать», размещая различные фигуры и объекты. Делается это с помощью вызовов соответствующих методов. При создании экземпляра Canvas необходимо указать его ширину и высоту. При размещении геометрических примитивов и других объектов указываются их координаты на холсте. Точкой отсчета является верхний левый угол.
Сначала в программе ниже создается холст.
c = Canvas (width=200, height=200, bg=’white’) На нем с помощью соответствующих методов размещаются примитивы.
Метод create_line рисует отрезки. Сначала указываются координаты начала (x1, y1), затем – конца (x2, y2).
c.create_line(10, 10, 190, 50)
c.create_line(100, 180, 100, 60, fill=’green’, width=5, activefill=’lightgreen’)
Свойство activefill определяет цвет отрезка при наведении на него курсора мыши.
Создание прямоугольников методом create_rectangle:
c.create_rectangle(10, 10, 190, 60)
c.create_rectangle(60, 80, 140, 190, fill=’yellow’, outline=’green’, width=3)
Первые координаты – верхний левый угол, вторые – правый нижний. Методом create_polygon рисуется произвольный многоугольник путем задания координат каждой его точки:
c.create_polygon(100, 10, 20, 90, 180, 90)
c.create_polygon(40, 110, 160, 110, 190, 180, 10, 180, fill=’orange’)
Для удобства координаты точек можно заключать в скобки:
c.create_polygon((40, 110), (160, 110), (190, 180), (10, 180), fill=’orange’)
Метод create_oval создает эллипсы. При этом задаются координаты гипотетического прямоугольника, описывающего эллипс. Если нужно получить круг, то соответственно описываемый прямоугольник должен быть квадратом.
c.create_oval(50, 10, 150, 110, width=2)
c.create_oval(10, 120, 190, 190, fill=’grey70′, outline=’white’)
Более сложные для понимания фигуры получаются при использовании метода create_arc. В зависимости от значения опции style можно получить сектор (по умолчанию), сегмент (CHORD) или дугу (ARC). Также как в случае create_oval координаты задают прямоугольник, в который вписана окружность (или эллипс), из которой «вырезают» сектор, сегмент или дугу. Опции start присваивается градус начала фигуры, extent определяет угол поворота.
c.create_oval(10, 10, 190, 190, fill=’lightgrey’, outline=’white’)
c.create_arc(10, 10, 190, 190, start=0, extent=45, fill=’red’)
c.create_arc(10, 10, 190, 190, start=180, extent=25, fill=’orange’)
c.create_arc(10, 10, 190, 190, start=240, extent=100, style=CHORD, fill=’green’)
c.create_arc(10, 10, 190, 190, start=160, extent=-70, style=ARC, utline=’darkblue’,
width=5)
Тема 5 Модульный принцип разработки ПО.
Основные критерии оптимизации модулей
Оптимизация программного кода — это модификация программ, выполняемая оптимизирующим компилятором или интерпретатором с целью улучшения их характеристик, таких как производительности или компактности, — без изменения функциональности.
Поэтому возникает две задачи. Первая задача: подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС. Отсюда вторая задача: определить момент окончания отладки ПС (или отдельной его компоненты). Признаком возможности окончания отладки является полнота охвата пропущенными через ПС тестами (т.е. тестами, к которым применено ПС) множества различных ситуаций, возникающих при выполнении программ ПС, и относительно редкое проявление ошибок в ПС на последнем отрезке процесса тестирования.
Для каждого модуля, подвергаемого тестированию, разрабатывается тестовое окружение, включающее в себя драйвер и заглушки, готовятся тест-требования и тест-планы, описывающие конкретные тестовые примеры.
Основная цель модульного тестирования – удостовериться в соответствии требованиям каждого отдельного модуля системы перед тем, как будет произведена его интеграция в состав системы. При этом в ходе модульного тестирования решаются четыре основные задачи.
1. Поиск и документирование несоответствий требованиям – это классическая задача тестирования, включающая в себя не только разработку тестового окружения и тестовых примеров, но и выполнение тестов, протоколирование результатов выполнения, составление отчетов о проблемах.
2. Поддержка разработки и рефакторинга низкоуровневой архитектуры системы и межмодульного взаимодействия. Даже при классической схеме тестирования модульные тесты могут выявить проблемы в дизайне системы и нелогичные или запутанные механизмы работы с модулем.
3. Поддержка рефакторинга модулей – эта задача связана с поддержкой процесса изменения системы. Достаточно часто в ходе разработки требуется проводить рефакторинг модулей или их групп – оптимизацию или полную переделку программного кода с целью повышения его сопровождаемости, скорости работы или надежности.
4. Поддержка устранения дефектов и отладки — эта задача сопряжена с обратной связью, которую получают разработчики от тестировщиков в виде отчетов о проблемах. Подробные отчеты о проблемах, составленные на этапе модульного тестирования, позволяют локализовать и устранить многие дефекты в программной системе на ранних стадиях ее разработки или разработки ее новой функциональности.
Информационная закрытость. Связность. Виды связности
Информационная закрытость означает следующее:
1) все модули независимы, обмениваются только информацией, необходимой для работы;
2) доступ к операциям и структурам данных модуля ограничен.
- обеспечивается возможность разработки модулей различными, независимыми коллективами;
- обеспечивается легкая модификация системы (вероятность распространения ошибок очень мала, так как большинство данных и процедур скрыто от других частей системы).
Связность модуля (Cohesion) — это мера зависимости его частей. Связность — внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования, то есть тем «черней» его ящик (капсула, защитная оболочка модуля), тем меньше «ручек управления» на нем находится и тем проще эти «ручки».
Для измерения связности используют понятие силы связности (СС). Существует 7 типов связности:
1. Связность по совпадению (СС=0). В модуле отсутствуют явно выраженные внутренние связи.
2. Логическая связность (СС=1). Части модуля объединены по принципу функционального подобия. Например, модуль состоит из разных подпрограмм обработки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм.
Недостатки: сложное сопряжение; большая вероятность внесения ошибок при изменении сопряжения ради одной из функций.
3. Временная связность (СС=3). Части модуля не связаны, но необходимы в один и тот же период работы системы.
Недостаток: сильная взаимная связь с другими модулями, отсюда — сильная чувствительность внесению изменений.
4. Процедурная связность (СС=5). Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения.
5. Коммуникативная связность (СС=7). Части модуля связаны по данным (работают с одной и той же структурой данных).
6. Информационная (последовательная) связность (СС=9). Выходные данные одной части используются как входные данные в другой части модуля.
7. Функциональная связность (СС=10). Части модуля вместе реализуют одну функцию.
Сцепление. Типы сцепления.
Сцепление модулей — это мера относительной независимости модулей.
Слабое сцепление определяет высокий уровень независимости модулей. Модули являются полностью независимыми, если каждый из них не содержит о другом никакой информации. Чем больше информации о другом модуле в них используется, тем менее они независимы и тем более сцеплены.
Независимое сцепление возможно, если модули не вызывают друг друга и не обрабатывают одну и ту же информацию.
Модули сцеплены по данным, если они имеют общие простые элементы данных, которые передаются от одного модуля к другому как параметры. (пр, структура – массив, а передается в качестве параметра элемент массива; при этом изменения в структуре данных не повлияют на другой модуль). Модули со сцеплением по данным не имеют общей области данных (глобальных переменных).
Модули сцеплены по образцу, если в качестве параметров используются структуры данных (например, в качестве параметра передается массив). Недостаток: оба модуля должны содержать информацию о другом модуле (внутренней структуре данных), т.е изменения должны отображаться и в др. модуле.
Модули сцеплены по общей области, если они разделяют одну и ту же глобальную структуру данных.
Модули сцеплены по управлению, если какой-либо из них управляет решениями внутри другого с помощью передачи флагов, переключателей и т.д.
Модуль сцеплен по внешним ссылкам, если у него есть доступ к данным другого модуля через внешнюю точку входа.
Модули сцеплены по кодам, если коды их команд объединены друг с другом, используют общий участок памяти. Если модули косвенно обращаются друг к другу (ч/з другие модули), то между ними также существует сцепление.
Сцепление модулей зависит от спроектированной структуры данных и способов взаимодействия между модулями. Необходимо использовать простые параметры и не применять глобальных данных
Источник: topuch.com