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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


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

Информация:

Тип работы: курсовая работа. Добавлен: 22.06.2012. Сдан: 2011. Страниц: 22. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Содержание
Введение 3
1 Теоретические основы разработки 4
     1.1 Системные требования 4
     1.2 Техническое задание 4
     1.3 Жизненный цикл 5
           1.3.1 Схемы модели ЖЦ ПО 5
           1.3.2 Другие типы моделей ЖЦ ПО 10
           1.3.3 Процессы жизненного цикла ПО 12
     1.4 Проектирование программного обеспечения 15
2 Практические основы разработки 16
     2.1 Реализация программного продукта 16
           2.1.1 Описание программного кода 21
     2.2 Тестирование и отладка программного продукта 28
     2.3 Достоинства и недостатки программного продукта 29
     2.4 Руководство пользователя 29
Заключение 31
Список использованных источников 32
Приложение А - UML - диаграмма программы 33
Приложение Б - Программный код 35
Приложение В - Презентация 43 
 
 
 
 
 
 
 
 
 

     Введение
     Тема  курсовой работы звучит так: разработка программы перевода чисел между системами счисления.
     Целью курсовой работы является разработка программы, которая переводила бы числа  одной системы счисления в  любую другую, заданную пользователем программы и могла сохранять или открывать полученные результаты. Кроме того, она должна содержать в себе справочный материал для пользователя программы.
     Задачей является, сделать так, чтобы программа была наиболее понятной для любого пользователя, нормальной для зрительного восприятия. Кроме всего этого стоит задача научиться создания графического интерфейса пользователя, закрепления навыков тестирования и отладки программного продукта, создание справочного модуля.
     Данную  работу решено разработать на  языке программирования Delphi. В этой среде предстоит научиться использовать такие компоненты как, кнопки (Button, BitBtn), поля Memo, Edit, создание графического интерфейса.
     Delphi был выбран вследствие того, что  он прост в освоении и применении. Использование Delphi позволяет создавать как самые простые приложений, на разработку которых требуется не большое количество времени, так и серьезные корпоративные проекты, предназначенных для работы десятков и сотен пользователей. Вследствие чего Delphi предназначен не только для программистов-профессионалов, но и для решения прикладных задач, не привлекая для этого специалистов со стороны.
     Актуальность  темы заключается в том, что с помощью моей программы можно переводить числа одной системы счисления в другую. Тем самым это может облегчить работу тем людям, которые работаю с числами, например программистам. Программа может сохранять преобразованные числа или открывать сохраненные результаты, если это необходимо. 
 
 
 
 
 

     1 Теоретические основы  разработки
     1.1 Системные требования
     Программный продукт помещается на дискету. Его размер составляет 928 Кб.
     Данный  программный продукт работает с  операционными системами такими как: Windows 98/XP и даже на Windows 7. Этот программный продукт может работать как на слабых машинах, так и на сильных так как у него слабые системные требования. Программный продукт не требует установки на компьютер.
     1.2 Техническое задание
     Delphi — результат развития языка  Турбо Паскаль, который, в свою  очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, а Delphi — объектно-ориентированный язык программирования с возможностью доступа к  описанию классов и их членов.
     Среда быстрой обработки (RAD Studio 2009) объединяет Delphi 2009 и C++Builder 2009 в единую интегрированную  среду разработки. Также дает возможность  пользователю ознакомиться с возможностями пакета Delphi Prism, с помощью которого можно создавать приложения .NET. В версии реализована поддержка таких технологий .NET, как WinForms, WPF, ADO.NET, ASP.NET и LINQ. Дополнительная поддержка фреймворка Mono обеспечивает возможность создания таких кросс-платформенных приложений, которые работают под операционными системами Windows, Linux и Mac OS X.
     Под индивидуальные потребности разработчиков  созданы три версии RAD Studio. RAD Studio Professional позволяет создавать приложения, которые взаимодействуют с локальными базами данных. RAD Studio Enterprise обеспечивает возможность создания клиент-серверных решений, многоуровневых баз данных и веб-приложений. В свою очередь RAD Studio Architect моделирует и проектирует базы данных Embarcadero ER/Studio Developer Edition.
     Основные  принципы RAD:
    Инструментарий должен быть нацелен на минимизацию времени разработки.
    Создание прототипа для уточнения требований заказчика.
    Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
    Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
    Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
    Управление проектом должно минимизировать длительность цикла разработки.
     Наименование  программного продукта: «Перевод чисел  между системами счисления».
     Программа предназначена для перевода чисел  разных систем счисления.
     Программный продукт по системным требованиям  подходит ко всем операционным системам.
     Для того чтоб программа работала правильно  и не возникло проблем как с  этой программой работать, необходимо знать системы счисления. Программа  должна обеспечивать высокую надежность при эксплуатации.
     1.3 Жизненный цикл
     Модель  жизненного цикла ПО описывается  набор фаз (этапов, стадий) проекта  по созданию ПО, в которых выполняются  отдельные процессы, разбитые на операции и задачи.
     Жизненный цикл проекта – набор обычно последовательных фаз проекта, количество и состав которых определяется потребностями управления проектом организацией или организациями, участвующими в проекте.
     Фаза  проекта – объединение логически  связанных операций проекта, обычно завершающихся достижением одного из основных результатов.
     Процесс – набор взаимосвязанных ресурсов и работ, благодаря которым входные  воздействия преобразуются в  выходные результаты.
     Операция, работа – элемент работ проекта. У операций обычно имеется ожидаемая  длительность, потребность в ресурсах, стоимость. Операции далее могут  подразделяться на задачи.
     В этих определениях существенным является следующее:
    состав, количество и, можно добавить, порядок выполнения фаз определяется особенностью проекта;
    каждая фаза завершается получением одного из основных результатов, в то время как процесс или задача – просто значимого результата.
     1.3.1 Схемы модели ЖЦ ПО
     Для схемы модели жизненного цикла ПО характерно следующее:
     Результатом выполнения каждой фазы является некоторая  модель ПО. Описание требований – модель того, что должен делать программный  продукт; результат анализа –  модель основных архитектурных решений и GUI.
     Результат выполнения каждой фазы является входом следующей фазы и фазы должны выполняться  в определенной моделью ЖЦ последовательности.
     Некоторые процессы могут выполняться на нескольких фазах, некоторые – в пределах одной.
     В стандарте ISO12207 модель ЖЦ  определяется как структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования, При этом, конкретные модели определяются особенностью задач, ограничениями на ресурсы, опытом разработчиков и т.д. Между тем, известны некоторые типовые модели ЖЦ ПО, которые проявили себя в определенных условиях, имеют определенные преимущества, недостатки и условия применимости. Эти типовые модели устанавливают некоторые принципы организации модели жизненного цикла ПО.
     Каскадная модель.
     Каскадная модель включает выполнение следующих фаз:
    исследование концепции – происходит исследование требований, разрабатывается видение продукта и оценивается возможность его реализации;
    определение требований - определяются программные требования для информационной предметной области системы, предназначение, линии поведения, производительность и интерфейс;
    разработка проекта – разрабатывается и формулируется логически последовательная техническая характеристика программной системы, включая структуры данных, архитектуру ПО, интерфейсные представления и процессуальную (алгоритмическую) детализацию;
    реализация — эскизное описание ПО превращается в полноценный программный продукт. Результат: исходный код, база данных и документация. В реализации обычно выделяют два этапа: реализацию компонент ПО и интеграцию компонент в готовый продукт. На обоих этапах выполняется кодирование и тестирование, которые тоже иногда рассматривают как два подэтапа;
    эксплуатация и поддержка - подразумевает запуск и текущее обеспечение, включая предоставление технической помощи, обсуждение возникших вопросов с пользователем, регистрацию запросов пользователя на модернизацию и внесение изменений, а также корректирование или устранение ошибок;
    сопровождение — устранение программных ошибок, неисправностей, сбоев, модернизация и внесение изменений. Состоит из итераций разработки.
     Основными принципами каскадной модели являются:
    Строго последовательное выполнение фаз:
    каждая последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы;
    каждая фаза имеет определенные критерии входа и выхода: входные и выходные данные;
    каждая фаза полностью документируется;
    переход от одной фазы к другой осуществляется посредством формального обзора с участием заказчика;
    основа модели – сформулированные требования (ТЗ), которые меняться не должны;
    критерий качества результата – соответствие продукта установленным требованиям.
    Каскадная модель имеет следующие преимущества:
    проста и понятна заказчикам, т. к часто используется другими организациями для отслеживания проектов, не связанных с разработкой ПО;
    проста и удобна в применении:
    процесс разработки выполняется поэтапно;
    ее структурой может руководствоваться даже слабо подготовленный в техническом плане или - неопытный персонал;
    она способствует осуществлению строгого контроля менеджмента проекта;
    каждую стадию могут выполнять независимые команды (все документировано);
    позволяет достаточно точно планировать сроки и затраты.
    При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:
    попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;
    интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;
    запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат.
     Недостатки каскадной  модели особо остро проявляются  в случае, когда трудно (или невозможно) сформулировать требования или требования могут меняться в процессе выполнения проекта. В этом случае разработка ПО имеет принципиально циклический  характер.
     Спиральная модель
На практике, при решении достаточно большого количества задач, разработка ПО имеет  циклический характер, когда после  выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов:
    ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования;
    изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования («Сказать, что должна делать программа я смогу только после того, как увижу как она работает»), или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии).
     Спиральная  модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки ПО. Основные принципы спиральной модели можно сформулировать следующим образом:
    разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам;
    создание прототипов ПО как средства общения с заказчиком для уточнения  и выявления требований;
    планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту;
    переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок;
    использование каскадной модели как схемы разработки очередного варианта;
    активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа ПО, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.
     Схема работы спиральной модели выглядит следующим  образом. Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов. В каждом цикле выделяются четыре базовые фазы:
    определение целей, альтернативных вариантов и ограничений;
    оценка альтернативных вариантов, идентификация и разрешение рисков;
    разработка продукта следующего уровня;
    планирование следующей фазы.
     «Раскручивание» проекта начинается с анализа  общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания.
     Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей  устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости  их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демо-версия ПО для анализа требований заказчиком.
     Следующий цикл – разработка проекта –  начинается с планирования разработки. На фазе определения целей устанавливаются  ограничения проекта (по срокам, объему финансирования, ресурсам), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков. На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации. На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения.
     Следующий цикл – реализация программного обеспечения – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с выходом – действующим вариантном (прототипом) продукта.
     Отметим некоторые особенности спиральной модели:
    до начала разработки ПО есть несколько полных циклов анализа требований и проектирования;
    количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи;
    в модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.
     Основные  недостатки спиральной модели связаны  с ее сложностью:
    сложность анализа и оценки рисков при выборе вариантов;
    сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий);
    сложность оценки точки перехода на следующий цикл;
    бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки.
     Спиральную  модель целесообразно применять  при следующих условиях:
    когда пользователи не уверены в своих потребностях или когда требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований;
    когда достижение успеха не гарантировано и необходима оценка рисков продолжения проекта;
    когда проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения;
    когда речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата;
    при выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям.
     1.3.2 Другие типы моделей ЖЦ ПО
     Каскадная и спиральная модели устанавливают  некоторые принципы организации  жизненного цикла создания программного продукта. Каждая из них имеет преимущества, недостатки и области применимости. Каскадная модель проста, но применима  в случае, когда требования известны и меняться не будут. Спиральная модель учитывает такие важные показатели проекта как изменяемость требований, невозможность оценить заранее объем финансирования, риски выполнения проекта. Но спиральная модель сложна и требует больших затрат на сопровождение.
     Существуют  некоторые другие типы моделей, которое  можно рассматривать как «промежуточные»  между каскадной и спиральной моделями. Эти модели используют отдельные преимущества каскадной и спиральной моделей и достигают успеха для определенных типов задач.
     Итерационная модель.
     Итерационная  модель жизненного цикла является развитием  классической каскадной модели и предполагает возможность возвратов на ранее выполненные этапы. При этом, причинами возвратов в классической итерационной модели являются выявленные ошибки, устранение которых и требует возврата на предыдущие этапы в зависимости от типа (природы) ошибки – ошибки кодирования, проектирования, спецификации или определения требований. Реально итерационная модель является более жизненной, чем классическая (строгая) каскадная модель, т.к. создание ПО всегда связано с устранением ошибок. Следует отметить, что уже в первой статье, посвященной каскадной модели, Боэм отмечал это обстоятельство и описал итерационный вариант каскадной модели. практически все применяемые модели жизненного цикла имеют итерационный характер, но цели итераций могут быть разными.
     V-образная модель.
     V-образная модель была создана как итерационная разновидность каскадной модели. Целями итераций в этой модели является обеспечение процесса тестирования. Тестирование продукта обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки. План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы - на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели. Помимо планов, на ранних этапах разрабатываются также и тесты, которые будут выполняться при завершении параллельных этапов.
     Инкрементная (пошаговая) модель.
     Инкрементная  разработка представляет собой процесс поэтапной реализации всей системы и поэтапного наращивания (приращения) функциональных возможностей. На первом шаге необходим полный заранее сформулированный набор требований, которые делятся по некоторому признаку на части. Далее выбирается первая группа требований и выполняется полный проход по каскадной модели. После того, как первый вариант системы, выполняющий первую группу требований сдан заказчику, разработчики переходят к следующему шагу (второму инкременту) по разработке варианта, выполняющего вторую группу требований.
     Особенностью  инкрементной модели является разработка приемочных тестов на этапе анализа  требований, что упрощает приемку  варианта заказчиком и устанавливает  четкие цели разработки очередного варианта системы.
     Инкрементная  модель особенно эффективна в случае, когда задача разбивается на несколько  относительно независимых подзадач (разработка подсистем «Зарплата», «Бухгалтерия», «Склад», «Поставщики»). Кроме того, инкрементная модель может для внутренней итерации может использовать не только каскадную, но и другие типы моделей.
     Модель быстрого прототипирования.
     Модель  быстрого протитипирования предназначена  для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.
     Начало  жизненного цикла разработки помещено в центре эллипса. Совместно с  пользователем разрабатывается  предварительный план проекта на основе предварительных требований. Результат начального планирования - документ, описывающий в общих чертах примерные графики и результативные данные.
     Следующий уровень – создание исходного  прототипа на основе быстрого анализа, проекта база данных, пользовательского  интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления  для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования.
     Получив одобрение пользователя, быстрый  прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой.
     При разработке производственной версии программы, может понадобиться более высокий  уровень функциональных возможностей, различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени. После этого следуют тестирование в предельных режимах, определение измерительных критериев и настройка, а затем, как обычно, функциональное сопровождение.
     Программный проект – это проект создания или  внедрения программного продукта. Проектирование проекта включает в себя все стадии разработки программного проекта, от сознания проблемы или постановки задачи, до внедрения программного проекта.
     1.3.3 Процессы жизненного цикла ПО
     Основные:
    приобретение (действия и задачи заказчика, приобретающего ПО)
    поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
    разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
    эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
    сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
     Вспомогательные:
    документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
    управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
    обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
    верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
    аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
    совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
    аудит (определение соответствия требованиям, планам и условиям договора)
    разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов).
     Организационные:
    управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами);
    создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО);
    усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ);
    обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала).
     Каждый  процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
    Инициирование приобретения.
    Подготовка заявочных предложений.
    Подготовка и корректировка договора.
    Надзор за деятельностью поставщика.
    Приемка и завершение работ.
     Каждое  действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
    Формирование требований к системе.
    Формирование списка программных продуктов.
    Установление условий и соглашений.
    Описание технических ограничений (среда функционирования системы и т. д.).
     Для данной курсовой работы была выбрана  спиральная модель жизненного цикла, которая  позволяет путем структурного программирования постепенно совершенствовать программный  продукт, производя дополнение, тестирование и отладку программного кода, а также используя достоинства данной модели, такие как:
    более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях;
    поэтапное уточнение требований в процессе выполнения итераций;
    планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ;
    возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования. 
     Программный проект – это проект создания или  внедрения программного продукта. Проектирование проекта включает в себя все стадии разработки программного проекта, от сознания проблемы или постановки задачи, до внедрения программного проекта.
     Для того, чтобы начать создавать свой программный продукт, я в продумал реализацию своего проекта, после чего приступил к реализации.
     1.4 Проектирование программного обеспечения
     Для начала необходимо создать в программе  Delphi форму, на которой разместятся все необходимые объекты и компоненты.
     На  форме размещено три поля Edit для введения данных, восемь полей Label для подписи полей, одна кнопка BitBtn для преобразования и  одно поле Memo для вывода результатов.
     Одному  полю Edit было присвоено имя EdSrcBase, в него будет задаваться основание системы счисления.
     Другому полю Edit присвоено имя EdSrcNum, в него будет задаваться исходное число.
     Третьему  Edit присвоено имя EdTrgBase, в это поле будет вводиться основание системы счисления, в которое будет переводиться число. Оно будет привязано к EdScrNum и EdSrcBase. Из этих данных программа будет переводить число одной системы счисления в ту, которая заданна в поле EdTrgBase.
     Созданная кнопка BitBtn будет выполнять перевод заданного исходного числа и начальной системы счисления в другую заданную систему счисления, в которую надо перевести исходное число. И полученный результат будет выводиться в поле Memo1. Из этого поля можно будет полученный результат сохранить или открыть в это поле, сохраненный раннее результат (приложение А).
     Для открытия полученного результата надо на форме разместить OpenDialog, с помощью этого компонента можно будет открывать результат.
     При открытии документа программа будет запрашивать у пользователя текстовый документ, который необходимо открыть. Открытый результат будет помещен в поле результирующего числа.
     Для сохранения полученного результата, необходимо разместить на форме SaveDialog. Этот компонент при использовании будет запрашивать у пользователя текстовый документ, куда нужно сохранить полученный результат.
     После описания алгоритма создания программы, я приступаю к реализации программы.
     2 Практические основы  разработки
     2.1 Реализация программного продукта
     Перед началом реализации программного продукт, необходимо в  среде программирования Delphi создать новую форму (рисунок 1).
     

     Рисунок 1 - Форма программного продукта
     После этого на форме необходимо разместить три поля Edit (рисунок 2). Эти поля будут в качестве задаваемых параметров. Имя каждого поля Edit заменено на EdSrcBase,  EdSrcNum и EdTrgBase.
     

     Рисунок 2 - Форма с полями Edit
     Каждые  поля Edit выполняют свою процедуру. Поля EdSrcBase,  EdSrcNum и EdTrgBase выполняют процедуру:
     procedure TfrmMain.EdSrcNumChange(Sender: TObject);
     begin
       Restart8(Self);
       Label9.Caption := '';
     end;
     В них будут задаваться исходные значения.
     Далее на форму размещаются поля Label (рисунок 3).
     

     Рисунок 3 - Форма с полями Label
     Они будут в программе подсказывать пользователю название полей и тем самым будут служить подсказкой  в пользовании программой, одно из полей присоединено к кнопке BitBtn, оно будет оповещать пользователя о том, что число в поле EdSrcNum не соответствует заданной системе счисления (рисунок 4).
     

     Рисунок 4 - Форма с по дополнительным полем Label
     Еще одно поле Label размещено над результирующем полем (рисунок 5). Оно будет показывать пользователю какие действия происходят.
     

     Рисунок 5 - Форма с дополнительным полем Label
     Также было размещено поле Memo (рисунок 6). В этом поле будет выводиться полученный результат.
     

     Рисунок 6 - Форма с полем Memo
     Кнопка BitBtn служит для преобразования чисел (рисунок 7).
     

     Рисунок 7 - Форма с кнопкой BitBtn
     После всего проделанного раннее на форме был размещен компонент MainMenu1 (рисунок 8).
     

     Рисунок 8 - Компонент MainMenu1
     После размещения этого компонента в верхней части формы появилось вспомогательное меню. В нем будут располагаться все необходимые кнопки. Для того чтоб эти кнопки работали нужно их там разместить. Для этого нужно нажать на компонент MainMenu1 два раза и в появившемся окне дать название командам (рисунок 9). Название пишется в  разделе Caption. 
 

     

     Рисунок 9 - Открытие компонента MainMenu1
     После задания команды, нужно дать название кнопкам в этой вкладке. Для этого  жмем на названную команду и выбираем вкладку (рисунок 10). В этой вкладке задается название кнопки и её горячи клавиши (ShortCut).
     

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

     Рисунок 11 - Форма меню
     После создания вспомогательного меню, были заданны программные коды всем кнопкам в каждой вкладке.
     На  следующем этапе на форму были размещены компоненты  OpenDialog1 и SaveDialog1 необходимые для того, чтобы кнопки «Открыть» и «Сохранить» во вспомогательном меню работали правильно (рисунок 12 и 13). 
     

     Рисунок 12 - Компонент OpenDialog1
     

     Рисунок 13 - Компонент SaveDialog1
     После того, как компоненты размещены на форме, им были заданны программные коды.
     2.1.1 Описание программного кода
     В программном продукте использована функция, которая определяет, какая цифра соответствует числу:
function IntToDigit(aNum: Byte): string;
const
  SelfName: string = 'IntToDigit.';
begin
  case aNum of
    0..9: Result := IntToStr(aNum);
    10: Result := 'A';
    11: Result := 'B';
    12: Result := 'C';
    13: Result := 'D';
    14: Result := 'E';
    15: Result := 'F';
  else
    raise Exception.Create(SelfName +
      ' Числу не сопоставлена цифра!');
  end;
end;
     Функцию которая определяет, какое число соответствует цифре:
function DigitToInt(aDigit: AnsiChar; aBase: Byte): Byte;
const
  SelfName: string = 'DigitToInt.';
begin
  if aBase < 2 then
    raise Exception.Create(SelfName +
      ' Основание системы счисления должно быть >= 2!')
      ;
  case aDigit of
    '0'..'9': Result := StrToInt(aDigit);
    'A', 'a': Result := 10;
    'B', 'b': Result := 11;
    'C', 'c': Result := 12;
    'D', 'd': Result := 13;
    'E', 'e': Result := 14;
    'F', 'f': Result := 15;
  else
    raise Exception.Create(SelfName +
      ' Неизвестный символ в представлении числа!');
  end;
  if Result > aBase - 1 then
    raise Exception.Create(SelfName +
      ' В данной системе счисления нет такой цифры!')
      ;
end;
     Функция которая по записи числа в системе  счисления с основанием aBase, определяет само это число:
function XcimalStrToNumber(aStrXcimal: string; aBase: Byte): Extended;
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.