Разработка программы «Графический редактор»

Разработка программы «Графический редактор»

программирование delphi графический редактор

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

Целью курсовой работы является разработка программы «Графический редактор», которая позволяет пользователю просматривать и редактировать графические файлы.

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

изучить методическую литературу по технологии разработки программных продуктов;

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

рассмотреть палитру свойств формы;

определиться со средством разработки приложения;

подготовить дизайн-проект приложения;

организовать удобную навигацию в программе;

1. Теоретические основы разработки программных продуктов

1.1 Понятие ЖЦПО и виды моделей разработки программного продукта

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

«Понятие жизненного цикла ПО (ЖЦПО) является одним из базовых понятий программной инженерии. ЖЦПО определяется как период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации».

Структуру жизненного цикла ПП, состав процессов, действия и задачи, которые должны быть выполнены во время создания ПП, определяет и регламентирует международный стандарт ISO/IEC 12 207: 1995 «Information Technology — Software Life Cycle Processes» (ISO — International Organization for Standardization — Международная организация по стандартизации; IEC — International Electrotechnical Commission — Международная комиссия по электротехнике; название стандарта «Информационные технологии — Процессы жизненного цикла программ»).

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

Каждый процесс разделен на набор действий, каждое действие — на набор задач. Запуск и выполнение процесса, действия или задачи осуществляются другими процессами.

В России, начиная с 1970;х годов, создание ПП регламентировалось стандартами ЕСПД (Единая система программной документации — серия ГОСТ 19. ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время указанные стандарты устарели концептуально и по форме, их сроки действия закончились и дальнейшее использование этих стандартов нецелесообразно. В результате для каждого серьезного проекта приходится создавать комплекты нормативных и методических документов, регламентирующих процессы создания конкретного прикладного ПП, поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ГОСТ Р ИСО/МЭК 12 207−99 все процессы ЖЦ ПО разделены на три группы:

— пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение);

— восемь вспомогательных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем);

— четыре организационных процесса (управление, инфраструктура, усовершенствование, обучение).

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

Стандарт ISO/IEC 12 207 не предлагает конкретные модели жизненного цикла и методы разработки ПП. Положения стандарта являются общими для любых моделей жизненного цикла, методов и технологий разработки ПП.

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

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

Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

1. Каскадная модель, или «водопад» (Waterfall model)

В однородных информационных системах 1970;х и 1980;х годов прикладные ПП представляли собой единое целое. Для разработки такого типа ПП применялась каскадная модель, или «водопад» (waterfall)

Рис.

Каскадная модель

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

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

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

2. V-образная модель (V-shaped model)

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

V-образная модель

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

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

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

3. Модель прототипирования (Prototype model)

Модель прототипирования позволяет создать прототип ПП до или в течение этапа составления требований к ПП.

Модель прототипирования

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

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

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

Модель прототипирования рекомендуется применять в следующих случаях:

— требования к ПП заранее неизвестны,

— требования не постоянны или неудачно сформулированы;

— требования необходимо уточнить;

— нужна проверка концепции;

— существует потребность в пользовательском интерфейсе;

— выполняется новая, не имеющая аналогов разработка;

— разработчики не уверены в том, какое решение следует выбрать

4. Модель быстрой разработки приложений, или RAD-модель (RAD — Rapid Application Development model)

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

Рис.

RAD-модель

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

На рис. поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.

Модель включает в себя следующий фазы:

— составление требований и планирование — осуществляются с использованием так называемого метода совместного планирования требований (планирование работ по созданию ПП и составление требований к ПП выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач;

— описание пользователя — проектирование ПП, выполняемое при непосредственном участии заказчика;

— создание — детальное проектирование, кодирование и тестирование ПП, а также поставка его заказчику;

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

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

5. Многопроходная модель (Incremental model)

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

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

Многопроходная модель

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

6. Спиральная модель (Spiral model)

Для преодоления проблем, связанных с использованием многопроходной модели, в середине 1980;х годов была предложена спиральная модель жизненного цикла .

Спиральная модель

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

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

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

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

Использование спиральной модели целесообразно, если существует хотя бы одна из следующих причин:

— целесообразно создание прототипа;

— организация обладает навыками, требуемыми для адаптации модели;

— требуется выполнять проекты со средней и высокой степенями риска;

— заказчики не уверены в своих потребностях;

— требования слишком сложные;

— проект очень большой.

1.2 Краткий обзор средств разработки ПО

Система программирования — совокупность языка программирования и системы разработки программ, обеспечивающей автоматизированную разработку и выполнение программ на данном языке, и подготовку соответствующей документации. Как правило, система программирования включает не эталонный вариант языка, а его некоторую версию, содержащую определенные упрощения или расширения. Некоторые системы программирования могут поддерживать разработку программ на нескольких языках. Наиболее известные системы программирования для персональных IBM-совместимых компьютеров: Visual Studio, разработанная фирмой Microsoft, поддерживающая языки программирования Basic, Java, C++; Delphi фирмы Inprise (Borland International Inc.), и др.

Компьютеризацию сегодня принято считать панацеей — только компьютер может повысить эффективность образования и промышленности, банковского дела и торговли, объединить через Интернет весь мир! И, очевидно, эта «пандемия» неостановима… Как всякий новый этап в развитии общества, компьютеризация несет с собой и новые проблемы. И одна из наиболее важных — экологическая. Много слов в печати и в других СМИ сказано о вредном влиянии компьютера на здоровье пользователей. Некоторые бойкие авторы даже грозят вымиранием человечеству, сидящему за дисплеями. Поэтому необходимо объективно оценивать эти проблемы, так как для борьбы с любой опасностью прежде всего надо знать, что она собой представляет. Именно зная правила работы за ПК и соблюдая их, можно избежать всех негативных влияний на здоровье пользователей или свести их к минимуму.

Структурное программирование

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

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

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

Наконец, структурное программирование призвано улучшить эффективность программ.

Всякая программа, в соответствии со структурным подходом к программированию, может быть построена только с использованием трех основных типов блоков:

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

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

2. Условная конструкция

Этот блок включает проверку некоторого логического условия (P), в зависимости от которого выполняется либо один (S1), либо другой (S2) операторы.

3. Блок обобщенного цикла

Этот блок обеспечивает многократное повторение выполнения оператора S пока выполнено логическое условие P: цикл с параметром и цикл с предусловием.

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

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

При проектировании и написании программы нужно выполнить обратное преобразование, то есть этот блок разбить на последовательность подблоков, затем каждый подблок разбить на последовательность более мелких блоков до тех пор, пока не будут получены «атомарные» блоки, рассмотренных выше типов. Такой метод конструирования программы принято называть нисходящим («сверху вниз»).

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

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

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

Объектно-ориентированное программирование

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

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

Основные шаги разработки программы, предусмотренные данной методологией:

— определить проблему;

— развить неформальную стратегию, представляющую общую последовательность шагов, удовлетворяющую требованиям к будущей программе;

— формализовать стратегию;

— идентифицировать объекты и их атрибуты;

— идентифицировать операции;

— установить интерфейсы;

— реализовать операции.

Большинство современных языков и систем программирования развиваются в направлении все большего использования объектной методологии в создании программ. Характерными примерами являются универсальные языки: Паскаль, Си.

Реальные объекты окружающего мира обладают тремя базовыми характеристиками: они имеют набор свойств, способны разными методами изменять эти свойства и реагировать на события, возникающие как в окружающем мире, так и внутри самого объекта. Именно в таком виде в языках программирования и реализовано понятие объекта, как совокупности свойств (структур данных, характерных для этого объекта), методов их обработки (подпрограмм изменения свойств) и событий, на которые данный объект может реагировать и которые приводят, как правило, к изменению свойств объекта.

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

Основными отличительными свойствами объекта являются:

Наследование

Важнейшая характеристика класса — возможность создания на его основе новых классов с наследованием всех его свойств и методов и добавлением собственных. Класс, не имеющий предшественника, называется базовым. Например, класс «животное» имеет свойства «название», «размер», методы «идти» и «размножаться». Созданный на его основе класс «кошка» наследует все эти свойства и методы, к которым дополнительно добавляется свойство «окраска» и метод «пить». Наследование позволяет создавать новые классы, повторно используя уже готовый исходный код и не тратя времени на его переписывание.

Полиморфизм

В большинстве случаев методы базового класса у классов-наследников приходится переопределять — объект класса «кошка» выполняет метод «идти» совсем не так, как объект класса «амеба». Все переопределяемые методы по написанию (названию) будут совпадать с методами базового объекта, однако компилятор по типу объекта (его классу) распознает, какой конкретно метод надо использовать, и не вызовет для объекта класса «кошка» метод «идти» класса «животное». Такое свойство объек тов переопределять методы наследуемого класса называется полиморфизмом.

Инкапсуляция

При проектировании объектов программист должен решить, какие части объекта Должны быть доступны для пользователя, а какие следует изолировать в объекте. Детали класса, остающиеся невидимыми для пользователя, называются инкапсулированными (encapsulated) в классе.

Закрытые данные объекта не могут изменяться пользователем, что уменьшает вероятность вмешательства в работу объекта или зависимости пользовательского кода от внутренней структуры объекта. Если пользовательский код зависит от структуры объекта, изменение объекта может нарушить работу пользовательского кода.

1.3 Этапы разработки программных продуктов

Для создания демонстрационной программы в качестве средства разработки была выбрана среда программирования Delphi 7, так как Delphi — это одна из самых популярных систем визуального программирования.

Delphi — это комбинация нескольких важнейших технологий:

высокопроизводительный компилятор в машинный код;

объектно-ориентированная модель компонент;

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

средства для построения баз данных.

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

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

2. Разработка программы «Графический редактор»

2.1 Постановка задачи и разработка спецификации на задачу

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

Функциональные требования:

— программа должна демонстрировать работу некоторых компонентов редактора;

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

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

Требования к графическому интерфейсу пользователя:

— пользовательское меню;

— элементы управления;

— хорошо оформленный дизайн.

Физические требования:

— наличие операционной системы Windows.

Информация будет представлена в виде:

— графических изображений.

Требования к интерфейсу программы:

— стандартный интерфейс приложения Windows.

Требования к уровню диалога:

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

По результатам постановки задачи формируется спецификация программного продукта:

Спецификация

Таблица 1

2.2 Разработка модели задачи

2.3 Проектирование

Была разработана главная форма на которой я разместил такие компоненты как: MainMenu — для меню пользователя; Shape — стандартная фигура (рисует одну из простейших геометрических фигур); OpenPictureDialog — диалог открытия изображений; SavePictureDialog — диалог сохранения изображений; ColorDialog — диалог выбора цвета (создает и обслуживает стандартное диалоговое окно выбора цвета).

Рис.

2.4 Отладка и тестирование программы

В процессе выполнения программы были допущены некоторые ошибки, которые приведены в таблице 2 с протоколом всех ошибок.

Таблица 2. Протокол ошибок

Таблица 3. Оформление результатов

2.5 Документирование программы

2.5.1 Описание применения

Описание применения:

Назначение программы: программа «Графический редактор», предназначена для создания и редактирования пользователем графических изображений.

Условия применения: минимальные системные требования: ПК на базе процессора PI 233 MHz, оперативная память 16 Mb, операционная система не ниже Windows 95.

Описание задачи

С помощью разрабатываемого проекта были определены следующие задачи: разработка и проектирования Графического редактора ООП Delphi.

Для решения этих задач использовалась среда визуального программирования Borland Delphi 7.

2.5.2 Руководство программиста

Назначение и условия применения проекта: Состав и назначение файлов входящих в проект: Project1. exe— загрузочный файл главной формы;

Назначение данного проекта заключается в демонстрации графических компонентов.

Раздел «Графически компоненты» имеет следующие функции:

Создание графических файлов .

Редактирование графических файлов.

Дополнительная информация

Для эффективной работы проекта требуются следующие минимальные требования:

Windows: 98/2000/XP, 32/64 Mb RAM, HDD-lOGb, SVGA

Экран — 1024×768, TrueColor

2.5.3 Руководство оператора (или пользователя)

Назначение программы

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

Выполнение программы

Последовательность действий оператора (пользователя):

Запуск программы (щелкнуть по значку «Project1»)

После этого должна, появится главная форма с кнопками

Заключение

Целью моей курсовой работы была разработка программы «Графический редактор», которая позволяет пользователю просматривать и редактировать графические изображения.

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

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

1.Васюков В. Н. Цифровая обработка сигналов и сигнальные процессоры в системах подвижной радиосвязи: Учебник для вузов Учебники НГТУ. 2003 — 235 с.

2.Вендров А. М. Проектирование программного обеспечения для экономических систем. М.: Финансы и статистика, 1999.

3.Головин О. В., Чистяков Н. И., Шварц В., Хардон Агиляр И. Радиосвязь. Под ред. проф. О. В. Головина. М., Горячая линия — Телеком, 2001

4.Культин Н. Б. Программирование в Turbo Pascal и Delphi.- СПб.: БХВ — Санкт-Петербург, 2000.

5.Симонович С., Евсеев Г., Алексеев А. Специальная информатика. Учебное пособие. — М.: АСТ — ПРЕСС: Инфорком — Пресс, 1998.

6.Семакин И. Г., Шестаков А. П. Основы программирования: Учебник.- М.: Мастерство, 2002.

7.Рудаков. Технология разработки программных продуктов. Учебное пособие, 2007.

8.Процессы жизненного цикла программных средств. Информационная технология. ГОСТ Р ИСО/МЭК 12 207−99, М.: Госстандарт России, 2000.

9.Схемы алгоритмов и программ. Правила выполнения. ГОСТ 19.002−80. М.: Госстандарт России, 1980.

Приложение 1

Рис. 1. Главная форма

1) Первоначально я разместил на форме два компонента Shape для отображения основного и вспомогательного цветов, компонент Image для отображения палитры десяти цветов и еще один компонент Image в качестве холста для картинок.

2) Разместил на форме компонент MainMenu, и сделал вкладки, ещё разместил диалоги: OpenPictureDialog, SavePictureDialog и ColorDialog .

3) В качестве основного и вспомогательных цветов (по умолчанию) установил соответственно синий и белый. Компонент Image1 (палитра цветов) поделил на 20 равных частей и каждую из них окрасил различными цветами. Для этого обработал событие OnCreate формы следующим образом:

Var i, t: Integer;

begin

{присваивание цвета по умолчанию}

Shape1.Brush.Color:=clWhite;

Shape2.Brush.Color:=clBlue;

Image2.Canvas.Brush.Color:=clWhite;

{Деление Image1 на 10 равных частей}

t:=Image1.Width div 20;

{смена ширины палитры}

Image1.Width:=20*t;

{рисование 10 равных прямоугольников}

For i:=0 to 19 do

Begin

Case i of

{выбор цвета ячейки по номеру}

0: Image1.Canvas.Brush.Color:=clBlack;

1: Image1.Canvas.Brush.Color:=clAqua;

2: Image1.Canvas.Brush.Color:=clBlue;

3: Image1.Canvas.Brush.Color:=clFuchsia;

4: Image1.Canvas.Brush.Color:=clGreen;

5: Image1.Canvas.Brush.Color:=clLime;

6: Image1.Canvas.Brush.Color:=clMaroon;

7: Image1.Canvas.Brush.Color:=clRed;

8: Image1.Canvas.Brush.Color:=clYellow;

9: Image1.Canvas.Brush.Color:=clWhite;

10: Image1.Canvas.Brush.Color:=clOlive;

11: Image1.Canvas.Brush.Color:=clNavy;

12: Image1.Canvas.Brush.Color:=clTeal;

13: Image1.Canvas.Brush.Color:=clGray;

14: Image1.Canvas.Brush.Color:=clSilver;

15: Image1.Canvas.Brush.Color:=clMoneyGreen;

16: Image1.Canvas.Brush.Color:=clSkyBlue;

17: Image1.Canvas.Brush.Color:=clCream;

18: Image1.Canvas.Brush.Color:=clPurple;

19: Image1.Canvas.Brush.Color:=clMedGray;

end;

{рисование прямоугольника}

Image1.Canvas.Rectangle (t*i, 0, t*i+t, Image1. Height);

end;

4) Обработал события OnClick для пунктов меню:

Файл — Открыть: открыть графический файл и загрузить его в Image2

If OpenPictureDialog1. Execute then

Image2.Picture.LoadFromFile (OpenPictureDialog1.FileName);

Палитра — Перо: отобразить изменение основного цвета в Shape1

If ColorDialog1. Execute then

Shape1.Brush.Color:=ColorDialog1.Color;

Палитра — Фон: отобразить изменение вспомогательного цвета в Shape2

If ColorDialog1. Execute then

Shape2.Brush.Color:=ColorDialog1.Color;

5) Обработал событие OnMouseDown компонентов Image1 (палитра) и Image2 (холст).

if Sender=Image1 then

if Button=mbLeft then

Shape1.Brush.Color:=(Sender as TImage).Canvas.Pixels[x, y]

else

Shape2.Brush.Color:=(Sender as TImage).Canvas.Pixels[x, y]

else

if (Sender=Image2) then

with Image2. Canvas do

If sSpeedButton1. Down then

begin

if Button=mbLeft then Brush. Color:=Shape1.Brush.Color

else Brush. Color:=Shape2.Brush.Color;

FloodFill (x, y, Pixels[x, y], fsSurface);

End;

6) Добавил на форму четыре компонента SpeedButton. Для всех установил свойство GroupIndex=1, а свойство AllowAllUp в состояние true (тогда кнопка будет фиксироваться в нажатом состоянии).

7) Разместил кнопки вдоль холста для рисования слева и для каждой из кнопок установил свойство Glyph следующим образом:

Для SpeedButton1 (кисть):

C:Program FilesBorlandDelphi6DemosDocGraphexbrush. bmp

Для SpeedButton2 (карандаш):

C:Program FilesBorlandDelphi6DemosDocGraphexpen. bmp

Для SpeedButton3 (закрашенный прямоугольник):

C:Program FilesBorlandDelphi6DemosDocGraphexfsolid. bmp

Для SpeedButton4 (линия):

C:Program FilesBorlandDelphi6DemosDocGraphexline. bmp

8) // если кнопка (карандаш) нажата, то можно рисовать

else

If sSpeedButton2. Down then

begin

Pen.Color:=Shape1.Brush.Color;

Moveto (x, y);

end

//рисование линии

else

If sSpeedButton4. Down then

begin

//запоминаем положение курсора

x0:=x;

y0:=y;

x1:=x;

y1:=y;

//устанавливаем цвет пера

Pen.Color:=Shape1.Brush.Color;

//устанавливаем режим пера — при движении мыши стирать изображение линии}

Pen.Mode:=pmNotXor;

end

Else If sSpeedButton3. Down Then

Begin

Pen.Color:=Shape1.Brush.Color;

x01:=x;

y01:=y;

x02:=x;

y02:=y;

Pen.Mode:=PMNotXor;

end;

end;

procedure TForm1. Image2MouseMove (Sender: TObject; Shift: TShiftState; X,

Y: Integer);

begin

//после движения мыши остается след

If sSpeedButton2. Down then

If Shift=[ssleft] then

Image2.Canvas.LineTo (x, y);

If sSpeedButton4. Down then

If Shift=[ssLeft] Then

with Image2. Canvas do

Begin

{стирание прежней линии}

MoveTo (x0,y0);

LineTo (x1,y1);

{рисование новой линии}

MoveTo (x0,y0);

LineTo (x, y);

x1:=x;

y1:=y;

end;

If sSpeedButton3. Down Then

If Shift=[ssLeft] Then

With Image2. Canvas Do

Begin {рисуем прямоугольник}

Rectangle (x01,y01,x02,y02);

x02:=x;

y02:=y;

Rectangle (x01,y01,x, y);

End;

end;

procedure TForm1. Image2MouseUp (Sender: TObject; Button: TMouseButton;

Shift: TShiftState; X, Y: Integer);

begin

If sSpeedButton4. Down Then

Begin

Image2.Canvas.Pen.Mode:=PMCopy;

Image2.Canvas.MoveTo (x0,y0);

Image2.Canvas.LineTo (x, y);

end;

If sSpeedButton3. Down Then

Begin

Image2.Canvas.Brush.Color:=Shape2.Brush.Color;

Image2.Canvas.Pen.Mode:=PMCopy;

Image2.Canvas.Rectangle (x01,y01,x, y);

end;

end;

end.

Размещено на