лекции. Лекции по дисциплине _Разработка программных модулей_. Лекции на специальности спо базовой подготовки 09. 02. 07 Информационные системы и программирование 2 Содержание
 Скачать 0.77 Mb.
|
|
1 М ЕТ ОДИЧ Е СК ИЕ Р ЕКО М Е НДАЦ ИИ ДЛЯ СТУ Д ЕНТ ОВ ПРОФЕССИОНАЛЬНЫЙ ЦИКЛ Разработка программных модулей ЛЕКЦИИ на специальности СПО базовой подготовки 09.02.07 Информационные системы и программирование 2 Содержание Введение………………………………………………………………………….6 Тема 1 Разработка программного обеспечения………………………………..7 Понятие ЖЦ ПО…………………………………………………………………7 Компонентно-ориентированный подход при разработке ПО………………..8 Этапы разработки ПО…………………………………………………………..9 Тема 2 Структурное программирование………………………………………11 Структурное программирование……………………………………………….11 Тема 3 Объектно-ориентированное программирование……………………..12 Объективно-ориентированное программирование…………………………..12 Тема 4 Событийно-управляемое программирование…………………………14 Основные принципы событийно-управляемого программирования………...14 Элементы управления………………………..…………………………………15 Диалоговые окна. ……………………………………………………………….16 Обработчики событий…………………………………………………………..18 Введение в графику……………………………………………………………..19 Тема 5 Модульный принцип разработки ПО…………………………………20 Основные критерии оптимизации модулей…………………………………..20 Информационная закрытость. Связность. Виды связности…………………22 Сцепление. Типы сцепления…………………………………………………..24 Тема 6 Основы работы с базами данных……………………………………..25 Специальные библиотеки……………………………………………………..25 Базовый синтаксис SQL……………………………………………………….26 Создание таблицы, работа с данными………………………………………..27 3 Python DB-API модули………………………………………………………...29 Объектно-реляционное отображение (ORM)……………………………..31 Тема 7 Разработка пользовательского интерфейса……………………….33 Правила разработки интерфейсов пользователя………………………….33 Требования к интерфейсу…………………………………………………..34 Анализ интерфейса…………………………………………………………36 Тема 8 Архитектурные шаблоны в проектировании……………………..38 Назначение и виды паттернов……………………………………………...38 Порождающие паттерны Abstract Factory, Builder, Factory method……..39 Порождающие паттерны: Prototype, Singleton……………………………41 Структурные паттерны: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy ……………………………………………………………42 Поведенческие паттерны: Iterator, Observer, State, Strategy, Visitor, Template method………………………………………………………………………44 Поведенческие паттерны: Chain of Responsibility, Memento, Command, Mediator ……………………………………………………………………45 Тема 9 Конструирование ПО………………………………………………46 Рефакторинг. Определение, причины и цели. Приемы рефакторинга….46 Составление методов. ……………………………………………………..48 Перемещение функции между методами…………………………………49 Организация данных. ………………………………………………………51 Упрощение условных выражений………………………………………….53 Упрощение вызовов методов. ……………………………………………..55 Решение задач обобщения………………………………………………….57 Экстремальное программирование………………………………………..59 Тестирование. Виды, задачи……………………………………………….60 Модульные тесты. Интеграционные тесты……………………………….61 4 Регрессионное тестирование. Нагрузочное тестирование………………63 Стандарты оформления кода…………………………………………….65 Тема 10 Проведение изменений в ПО……………………………………67 Обратный инжиниринг. Определение, цели проведения……………….67 Этапы обратного инжиниринга……………………………………………68 Анализ исходных данных………………………………………………….70 Получение экспертиз. Реверсивный инжиниринг……………………….71 Методики проведения обратного инжиниринга…………………………73 Оформление кода…………………………………………………………..74 Реинжиниринг………………………………………………………………75 Анализ интерфейса…………………………………………………………77 Список использованных источников………………………………………..78 5 Введение Программная инженерия является отраслью информатики, которая изучает вопросы построения компьютерных программ, отражает закономерности развития программирования, обобщает опыт программирования в виде комплекса знаний и правил регламентации инженерной деятельности разработчиков ПС. Международным комитетом при американском объединении компьютерных специалистов ACM (Association for Computing Machinery) и институте инженеров по электронике и электротехнике IEEE было создано ядро знаний SWEBOK (Software Engineering Body of Knowledge) (2001, 2003 гг.). В этом ядре были систематизированы разнородные знания в области программирования, планирования и управления, сформулировано понятие программной инженерии и областей, которые соответствуют процессам проектирования ПС и методам их поддержки. Программная инженерия охватывает все аспекты создания ПС, начиная от формирования требований до создания, сопровождения и снятия с эксплуатации, а также включает инженерные методы оценки трудозатрат, стоимости, производительности и качества. Кроме программистов, занимающихся непосредственно разработкой ПС, в программной инженерии задействованы: менеджеры, которые планируют и руководят проектом, отслеживают сроки его исполнения и затраты; инженеры службы ведения библиотек и репозитариев компонентов; технологи, которые определяют инженерные методы и стандарты, создают для проекта модель жизненного цикла ПС, удовлетворяющую его целям и задачам; тестировщики, которые проверяют правильность выполнения процесса разработки ПС путем тестирования, и на основе собранных данных проводят измерения характеристик качества; 6 валидаторы, которые проверяют ПС на соответствие заданным требованиям (в технике валидация подтверждает, что требования пользователя удовлетворены); верификаторы, которые проверяют правильность реализации алгоритмов и программ в проекте путем их сопоставления с эталонными данными, алгоритмами или программами (верификация — это внутренний процесс управления качеством, обеспечивающий согласование с правилами или спецификацией). Тема 1 Разработка программного обеспечения Понятие ЖЦ ПО. Создание любого программного средства выполняется по некоторой схеме. Данная схема представляет собой последовательность стандартных этапов производственного процесса. Этот процесс нужно спланировать, оценить его ресурсы. В ходе реализации этого процесса нужно: спроектировать ПС в виде системы, состоящей из компонент; описать функции этих компонент и их связи между собой; запрограммировать эти компоненты, автономно их отладить, собрать вместе и провести комплексную отладку; подготовить документацию на ПС; обучить пользователей; провести опытную эксплуатацию ПС; организовать сопровождение системы. Для сокращения затрат необходимо конкретизировать схему, упорядочить действия, выполняемые на каждом этапе, разработать методы решения возникающих на разных этапах проблем. В довершение ко всему, схема подразумевает возвраты назад (циклы), в тех случаях, когда обнаруживаются ошибки предыдущего этапа. Под жизненным циклом программного средства (ЖЦПС) понимают весь период его разработки и эксплуатации, начиная от момента возникновения замысла ПС и кончая прекращением его использования. В настоящее время можно выделить пять основных подходов к организации процесса создания и использования ПС. 7 Компонентно-ориентированный подход при разработке ПО ООП-подход в разработке ПО хорошо себя зарекомендовал. Инкапсуляция, наследование и полиморфизм помогают программисту повторно использовать функциональность базового класса и скрыть детали реализации. Но при разработке сложных систем, особенно систем, моделирующих процессы окружающего мира, ООП-программист сталкивается с рядом новых проблем, для решения которых необходим принципиально иной подход. Главное отличие компонента от объекта заключается в том, что компонент функционирует в среде как часть единой системы – «фреймворка». Фреймворк предоставляет унифицированный способ доступа к ресурсам среды в рамках компонентной модели. Под средой (или окружением) обычно понимается среда выполнения — вычислительное окружение, необходимое для выполнения программы. В конечном итоге компонент взаимодействует как с операционной системой/виртуальной машиной, так и с пользователем, БД, периферийными устройствами и прочими объектами реального мира, используя возможности фреймворка. В контексте жизненного цикла разработки ПО, под средой также может пониматься среда разработки, среда выполнения и т.п. Компонент может рассматриваться как объект, к которому предъявлен ряд дополнительных требований для функционирования в сложных средах с элементами неопределенности. Базовый класс компонента должен содержать всю необходимую функциональность, которая позволяет называть компонент компонентом. Если жизненный цикл объекта в ООП, как правило, известен заранее вплоть до мельчайших деталей еще на этапе разработки архитектуры системы, то компоненты, являющиеся частью сложной системы, могут инициировать взаимодействие друг с другом в различное время «по требованию». При этом они изначально могут ничего не знать друг о друге — на этапе написания компонента программист ограничен возможностями компонентной модели. 8 Поэтому компоненты должны уметь динамически «обрабатывать» события и обмениваться информацией о своих свойствах и умениях с другими компонентами. Вот некоторые особенности, в той или иной мере присущие компонентно- ориентированному программированию: интроспективность (способность компонентов к самоописанию), модульность и разграничение уровней доступа, автоматическая обработка исключительных ситуаций, автоматическое управление памятью, позднее связывание и динамический контроль типов, обработка событий, персистентность (способность компонентов сохранять и восстанавливать состояние), простота повторного использования. Компоненты могут представлять сущности моделируемой системы, ресурсы среды (предоставлять доступ к файловой системе, базам данных), управлять рабочим потоком, предназначаться для выполнения определенных задач. Этапы разработки ПО. Разработка любой программысостоит из нескольких этапов, грамотная реализация которых является обязательным условием для получения хорошего результата. Анализ требований В рамках этой стадии происходит максимально эффективное взаимодействие нуждающегося в программном решении клиента и сотрудников компании- разработчика, в ходе обсуждения деталей проекта помогающих более четко сформулировать предъявляемые к ПО требования. Результатом проведенного анализа становится формирование основного регламента, на который будет опираться исполнитель в своей работе — технического задания на 9 разработку программного обеспечения. ТЗ должно полностью описывать поставленные перед разработчиком задачи и охарактеризовать конечную цель проекта в понимании заказчика. Проектирование Качественный анализ перспектив и возможностей создаваемого продукта станет основой для его полноценного функционирования и выполнения всего комплекса возлагаемых на ПО задач. Одной из составных частей этапа проектирования, к примеру, является выбор инструментальных средств и операционной системы, которых сегодня на рынке присутствует очень большое количество. В рамках данного этапа стороны должны осуществить: оценку результатов проведенного первоначально анализа и выявленных ограничений; поиск критических участков проекта; формирование окончательной архитектуры создаваемой системы; анализ необходимости использования программных модулей или готовых решений сторонних разработчиков; проектирование основных элементов продукта — модели базы данных, процессов и кода; выбор среды программирование и инструментов разработки, утверждение интерфейса программы, включая элементы графического отображения данных; определение основных требований к безопасности разрабатываемого ПО. Кодирование Кодирование может происходить параллельно со следующим этапом разработки — тестированием программного обеспечения, что помогает вносить изменения непосредственно по ходу написания кода. Уровень и эффективность взаимодействия всех элементов, задействованных для выполнения сформулированных задач компанией-разработчиком, на текущем этапе является самым важным — от слаженности действий 10 программистов, тестировщиков и проектировщиков зависит качество реализации проекта. Тестирование и отладка Процесс тестирования позволяет смоделировать ситуации, при которых программный продукт перестает функционировать. Отдел отладки затем локализует и исправляет обнаруженные ошибки кода, «вылизывая» его до практически идеального состояния. Эти два этапа занимают не меньше 30% затрачиваемого на весь проект времени, так как от их качественного исполнения зависит судьба созданного силами программистов программного обеспечения. Нередко функции тестировщика и отладчика исполняет один отдел, однако самым оптимальным будет распределить эти обязанности между разными исполнителями, что позволит увеличить эффективность поиска имеющихся в программном коде ошибок. Тема 2 Структурное программирование Структурное программирование Алгоритмизация - это представление неформального, неточного и неполного описания известного метода решения задачи в виде четкого алгоритма. Это - не простая проблема. Систематические методы алгоритмизации появились лишь в начале 70-х годов и связаны, прежде всего, с двумя независимыми друг от друга идеями: структурное программирование и разработка сверху вниз. Эти идеи произвели настоящую революцию в программировании и способствовали его индустриализации. Они лежат в основе современной технологии программирования. В принципе, обе идеи достаточно просты и используются не только в программировании. Структурное программирование - это метод программирования, в котором используются только алгоритмы, построенные из стандартного набора базовых структур (так называемые структурные алгоритмы). 11 Идея структурного программирования - стандартизация для борьбы с ошибками: ограничить возможную структуру алгоритмов, сделав их более простыми и наглядными. При этом облегчается понимание, разработка, изменение, отладка и верификация алгоритма, уменьшается количество возможных ошибок, упрощается их поиск и, в конечном счете, увеличивается производительность труда программистов и повышается качество программ. В частности, повышаются их надежность и мобильность, упрощается модернизация. При этом, правда, алгоритм может стать более громоздким. Как и любая стандартизация, структурное программирование рассчитано, прежде всего, на индустриальный подход – коллективную разработку больших и сложных программ в промышленных масштабах. Его роль повышается с ростом размеров и сложности разрабатываемых программ. Алгоритм называется структурным (иногда говорят "структурированным"), если он имеет одну из базовых структур. Каждый блок этих структур сам может иметь внутри любую из этих допустимых структур и т.д. Таким образом из базовых структур можно построить структурный алгоритм любой сложности. В качестве базовых структур обычно используют последовательность, ветвление и цикл. Тема 3 Объектно-ориентированное программирование Объектно-ориентированное программирование Объектно-ориентированное программирование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования. Идеологически ООП — подход к программированию как к моделированию информационных объектов, решающий на новом уровне основную задачу структурного программирования: структурирование информации с точки 12 зрения управляемости, что существенно улучшает управляемость самим процессом моделирования, что, в свою очередь, особенно важно при реализации крупных проектов. Управляемость для иерархических систем предполагает минимизацию избыточности данных (аналогичную нормализации) и их целостность, поэтому созданное удобно управляемым — будет и удобно пониматься. Таким образом, через тактическую задачу управляемости решается стратегическая задача — транслировать понимание задачи программистом в наиболее удобную для дальнейшего использования форму. Основные принципы структурирования в случае ООП связаны с различными аспектами базового понимания предметной задачи, которое требуется для оптимального управления соответствующей моделью: абстракция для выделения в моделируемом предмете важного для решения конкретной задачи по предмету, в конечном счёте — контекстное понимание предмета, формализуемое в виде класса; инкапсуляция для быстрой и безопасной организации собственно иерархической управляемости: чтобы было достаточно простой команды «что делать», без одновременного уточнения как именно делать, так как это уже другой уровень управления; наследование для быстрой и безопасной организации родственных понятий: чтобы было достаточно на каждом иерархическом шаге учитывать только изменения, не дублируя всё остальное, учтённое на предыдущих шагах; полиморфизм для определения точки, в которой единое управление лучше распараллелить или наоборот — собрать воедино. То есть фактически речь идёт о прогрессирующей организации информации согласно первичным семантическим критериям: «важное/неважное», «ключевое/подробности», «родительское/дочернее», «единое/множественное». Прогрессирование, в частности, на последнем 13 этапе даёт возможность перехода на следующий уровень детализации, что замыкает общий процесс. Тема 4 Событийно-управляемое программирование Основные принципы событийно-управляемого программирования Событийно-ориентиированное программиирование (англ. event-driven programming; в дальнейшем СОП) — парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь, сенсорный экран), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета). СОП можно также определить как способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события. Как правило, в реальных задачах оказывается недопустимым длительное выполнение обработчика события, поскольку при этом программа не может реагировать на другие события. В связи с этим при написании событийно- ориентированных программ часто применяют автоматное программирование. Под событием в языке программирования обычно понимается способ внедрения того или иного фрагмента в программный код с целью изменения поведения программы. Как только происходит изменение среды вычислений из числа представляющих интерес для разработчика или пользователя программного обеспечения, активизируется событие и выполняется соответствующий фрагмент кода. В целом, с точки зрения практического программирования, обработка события подобна вызову процедуры, причем в роли параметров выступают те или иные характеристики среды вычислений. 14 Любой современный интерфейс пользователя (или, в математической терминологии, среда вычислений) построен на основе обработки событий (onClick, onMouseMove, onMouseOver и т.д.). События, которые осуществляют взаимодействие с каналами локальных сетей, операционной системой, сторонними приложениями и т.д. могут также активизироваться по времени. В соответствии со схемой двухуровневой концептуализации, первый уровень может означать, например, инициацию пользователем события "щелчок левой кнопкой мыши", а второй - изменение состояния объекта меню при выборе соответствующего пункта меню. Как видим, сначала возможный индивид становится действительным (т.е. происходит активация события), а затем осуществляется означивание объекта программы (изменяется текущая позиция меню). Фрагментом кода программы в таком случае является метод, изменяющий текущую позицию меню, который активизируется, исходя из значения первого соотнесения (т.е. конкретизации события). Таким образом, на основе механизма событий осуществляется управление программой. Элементы управления Почти все современные графические интерфейсы общего назначения строятся по модели WIMP - Window, Icon, Menu, Pointer (окно, иконка, меню, указатель). Внутри окон рисуются элементы графического интерфейса, которые для краткости будут называться виджетами (widget - штучка). Меню могут располагаться в различных частях окна, но их поведение достаточно однотипно: они служат для выбора действия из набора предопределенных действий. Программа, реализующая графический интерфейс, событийно ориентирована. Она ждет от интерфейса событий, которые и обрабатывает сообразно своему внутреннему состоянию. Эти события возникают в элементах графического интерфейса (виджетах) и обрабатываются 15 прикрепленными к этим виджетам обработчиками. Сами виджеты имеют многочисленные свойства (цвет, размер, расположение), выстраиваются в иерархию принадлежности (один виджет может быть хозяином другого), имеют методы для доступа к своему состоянию. Расположением виджетов (внутри других виджетов) ведают менеджеры расположения. Виджет устанавливается на место по правилам менеджера расположения. В 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 (Окно верхнего уровня) Показывается как отдельное окно и содержит внутри другие виджеты. 16 Диалоговые окна. Пакет tkinter содержит несколько модулей, предоставляющих доступ к уже готовым диалоговым окнам. Это окна различных сообщений, выбора по принципу "да-нет", открытия и сохранения файлов и др. Рассмотрим примеры окон из модулей messagebox и filedialog пакета tkinter. Модули пакета необходимо импортировать отдельно. То есть вы импортируете содержимое tkinter (например, from tkinter import *) и отдельно входящий в состав пакета tkinter модуль. Способы импорта на примере messagebox и пример вызова одной из функций модуля: 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. 17 Рассмотрим две функции из модуля filedialog – askopenfilename и asksaveasfilename. Первая предоставляет диалоговое окно для открытия файла, вторая – для сохранения. Обе возвращают имя файла, который должен быть открыт или сохранен, но сами они его не открывают и не сохраняют. Делать это уже надо программными средствами самого Python. Опция filetype позволяет перечислить типы файлов, которые будут сохраняться или открываться, и их расширения. Обработчики событий В tkinter с помощью метода bind между собой связываются виджет, событие и действие. Например, виджет – кнопка, событие – клик по ней левой кнопкой мыши, действие – отправка сообщения. Другой пример: виджет – текстовое поле, событие – нажатие Enter, действие – получение текста из поля методом get для последующей обработки программой. Действие оформляют как функцию или метод, которые вызываются при наступлении события. При вызове метода bind событие передается в качестве первого аргумента. Название события заключается в кавычки, а также в угловые скобки < и >. События описывается с помощью зарезервированных ключевых слов. Часто используемые события, производимые мышью: и т. д. Событие (Event) – это один из объектов tkinter. У событий есть атрибуты, как и у многих других объектов. При использовании функции move можно извлечь значения атрибутов x и y объекта event, в которых хранятся 18 координаты местоположения курсора мыши в пределах виджета, по отношению к которому было сгенерировано событие. Для событий с клавиатуры буквенные клавиши можно записывать без угловых скобок (например, 'a'). Для неалфавитных клавиш существуют специальные зарезервированные слова. Например, (Заметим, что есть событие Введение в графику В 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) 19 Первые координаты – верхний левый угол, вторые – правый нижний. Методом 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) |