Создание программного обеспечения для небольшого супермаркета. Дипломная (ВКР). Информационное обеспечение, программирование.

Создание программного обеспечения для небольшого супермаркета. Дипломная (ВКР). Информационное обеспечение, программирование.




🛑 👉🏻👉🏻👉🏻 ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻


























































Информационное обеспечение, программирование

Вы можете узнать стоимость помощи в написании студенческой работы.


Помощь в написании работы, которую точно примут!

Похожие работы на - Создание программного обеспечения для небольшого супермаркета

Скачать Скачать документ
Информация о работе Информация о работе


Скачать Скачать документ
Информация о работе Информация о работе

Нужна качественная работа без плагиата?

Не нашел материал для своей работы?


Поможем написать качественную работу Без плагиата!

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, СИМВОЛОВ, СПЕЦИАЛЬНЫХ ТЕРМИНОВ


.1      Общая схема построения системы


.2 Функциональная схема подсистемы «Учет и реализация товара»


. ОСНОВНЫЕ ПРИНЦИПЫ СОЗДАНИЯ БАЗЫ ДАННЫХ


.1 Требования, предъявляемые к базе данных


. СРЕДА DELPHI КАК СРЕДСТВО ДЛЯ РАЗРАБОТКИ АСУ


.2 Разработка главной формы режима «Администратор»


.3 Разработка формы «Вход в программу»


.4 Разработка формы Добавление товара


.5 Разработка формы Изменение товара


.7 Разработка формы Единицы измерения


СУБД        система управления базами данных


АСУ автоматизированная система управления


MIS информационная
система руководства


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


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


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


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


·             самих торговых или кассовых мест;


·             учета товарооборота магазина;


·             бухгалтерского учета супермаркета, а также расчетов с
поставщиками, покупателями.


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


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


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


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


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


-      Рассмотреть структуру работы и основные принципы работы супермаркета


-      Раскрыть понятие баз данных


-      Разработать структуру базы данных супермаркета


-      Разработать приложение для работы с базами данных
супермаркета


Теоретическую основу исследования составили сайты разработчиков АСУ.


Объектом исследования явились супермаркеты.


Предметом исследования явилась деятельность супермаркета.


Научная новизна работы заключается в создании нового программного
обеспечения для лучшего решения автоматизации деятельности супермаркета.







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




Рисунок
1. Схема построения системы управления супермаркетом




Центром любой подобной АСУ всегда является мощный энергонезависимый
сервер, хранящий информацию о деятельности всех подсистем супермаркета в виде
совокупности распределенных баз данных. Каждая база данных содержит одну или
несколько информационных таблиц, содержание которых определяется названием БД и
может различаться по внутренним характеристикам; одна и та же база данных может
использоваться для работы различных подсистем путем выделения из нее
соответствующей информационной таблицы.


Из-за некритичности рассматриваемой АСУ во времени (определенные задержки
в выполнении тех или иных операций не грозят системе аварийным сбоем и не
подвергают опасности жизнь людей) система не содержит объединенного пульта
управления, информация на который выводится со всех интегрированных подсистем и
подвергается посекундному контролю опытных операторов; вместо этого каждая из
подсистем включает в себя определенное количество оборудованных дисплеями
оконечных рабочих мест, выводящиеся на которые и снимаемая с которых информация
строго систематизирована по своему характеру.


Каждая из подсистем супермаркета включает в себя программное и аппаратное
обеспечение, обеспечивающие: 1) извлечение данных из БД, связанных с
соответствующей подсистемой; 2) запись в БД измененных или новых данных; 3)
связь с внешними устройствами, необходимыми для функционирования подсистемы.
Разделение супермаркета на подсистемы необходимо для реализации на базе каждой
из подсистем определенного подмножества функций, схожих по предметной области;
подобное разделение также необходимо с целью организации подразделений АСУ,
выполняющих контроль за подотчетной каждому из них подсистемой. Несмотря на то,
что подсистемы связаны между собой совместно используемыми базами данных,
разделение по предметной области четко определяет круг задач, выполняемых
каждой из подсистем.




1.2 Функциональная схема подсистемы «Учет и
реализация товара»




По характеру своей
деятельности супермаркет - организация, целью которой является продажа
населению продуктов и прочих товаров широкого потребления с целью получения
прибыли. В связи с этим естественным представляется отведение большинства
реализуемых АСУ функций соответствующей подсистеме.)      Генерация списков
товаров, присутствующих на складах; эта функция необходима для быстрого
определения товаров, закончившийся запас которых на витринах может быть
оперативно пополнен без необходимости заказа новых партий товара поставщику;) Генерация
списков товаров, отсутствующих на складах, для оформления поставщику
соответствующего заказа;)        Генерация списков товаров, имеющихся в
наличии на складах и на витринах, срок годности которых истек; эта функция
необходима для списания соответствующих товаров и оформления поставщику новых
заказов на эти товары; при этом стоимость списанных товаров засчитывается в
чистый убыток супермаркета;)  Смена цен товаров в БД при изменении последних;)         Автоматизированное
начисление наценок на товары в соответствии с текущим экономическим положением
супермаркета;) Занесение в товарную БД наименований товаров, отсутствовавших в
ней ранее, при поступлении соответствующих товаров от поставщика с последующим
назначением этим товарам уникальных идентификационных номеров и цен,
определяемых поставщиком; увеличение числа товарных единиц при поступлении от
поставщика товаров, присутствовавших в БД;)        Сверка идентификационных
номеров товаров при покупке последних пользователем супермаркета,
автоматическое определение цен товаров по этим номерам и уменьшение числа
соответствующих единиц товара в БД в соответствии с размером сделанной
пользователем покупки. При этом стоимость купленных товаров записывается в
чистую прибыль супермаркета.


Все указанные функции, кроме
последней, выполняются операторами складского терминала; последняя функция
выполняется операторами торгового зала.


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





2. ОСНОВНЫЕ ПРИНЦИПЫ СОЗДАНИЯ
БАЗЫ ДАННЫХ




2.1
Требования, предъявляемые к базе данных




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


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


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


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


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


К современным базам данных, а
следовательно, и к СУБД, на которых они строятся, предъявляются следующие
основные требования.


-      Высокое быстродействие (малое время отклика на
запрос). Время отклика - промежуток времени от момента запроса к БД до
фактического получения данных.


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


-      Совместное использование данных многими
пользователями.


-      Безопасность данных - защита данных от преднамеренного
или непреднамеренного нарушения секретности, искажения или разрушения.


-      Стандартизация построения и эксплуатации БД
(фактически СУБД).


-      Адекватность отображения данных соответствующей
предметной области.


-      Дружелюбный интерфейс пользователя.


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


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


-      отсутствие неточно введенных данных или двух
одинаковых записей об одном и том же факте;


-      защиту от ошибок при обновлении БД;


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


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


-      сохранность данных при сбоях техники (восстановление
данных).


Защита данных от
несанкционированного доступа предполагает ограничение доступа к
конфиденциальным данным и может достигаться:


-      получением разрешений от администратора базы данных
(АБД);


-      запретом от АБД на доступ к данным;


-      формирование видов - таблиц, производных от исходных и
предназначенных конкретным пользователям.


Три последние процедуры легко
выполняются в рамках языка структуризованных запросов Structured Query Language - SQL,
часто называемого SQL2.




Первоначально (начало 60-х
годов) использовалась файловая система хранения. Для решения преимущественно
инженерных задач, характеризующихся небольшим количеством данных и значительным
объемом вычислений, данные хранились непосредственно в программе. Применялся
последовательный способ организации данных, имелась их высокая избыточность,
идентичность логической и физической структур и полная зависимость данных. С появлением
экономико-управленческих задач (MIS), отличающихся большими объемами данных и малой долей
вычислений, указанная организация данных оказалась неэффективной. Требовалось
упорядочение данных, которое, как выяснилось, возможно было проводить по двум
критериям: использование (информационные массивы); хранение (базы данных).
Первоначально применяли информационные массивы, но вскоре стало ясно
превосходство баз данных. Использование файлов для хранения только данных было
предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе
произвольного) к таким файлам, при этом физическая и логическая структуры уже
различались, а физическое расположение данных можно было менять без изменения
логического представления.


В конце 70-х годов появились
современные СУБД, обеспечивающие физическую и логическую независимость,
безопасность данных, обладающие развитыми языками БД. Последнее десятилетие
характеризуется появлением распределенных и объектно-ориентированных баз
данных, характеристики которых определяются приложениями средств автоматизации
проектирования и интеллектуализации БД.


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


Существует два подхода к
построению БД, базирующихся на двух подходах к созданию автоматизированной
системы управления (АСУ).


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


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


В работе БД возможен одно- и
многопользовательский (несколько пользователей подключаются к одному компьютеру
через разные порты) режимы.


БД используются обычно не
самостоятельно, а являются компонентой различных информационных систем: банков
данных, информационно-поисковых и экспертных систем, систем автоматизированного
проектирования, автоматизированных рабочих мест, автоматизированных систем
управления.


Создать саму БД (не СУБД)
средствами Delphi очень сложно, даже невозможно. Если выбрать двух- или
трехзвенную архитектуру, не обойтись без сервера БД, который создать собственными
силами очень трудно (да и ни к чему, если на рынке предлагаются десятки таких
программ, а в Интернете при желании можно найти и бесплатный, но вполне
приличный сервер MySQL).


Если речь идет о
файл-серверной БД, то и здесь понадобятся специальные средства. В Delphi для
этих целей обычно используется утилита Database Desktop.


Могут также применяться
промышленные СУБД «Paradox*-, «dBASE» (корпорации Borland), «FoxPro», «Access»
(корпорации Microsoft) и др. В рамках данной дипломной работы используются средства
Database Desktop и сервер InterBase, так как они входят в комплект поставки
Delphi и являются собственными продуктами корпорации Borland.


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


Нормализованной называется
БД, в которой выполняется как минимум 3 условия. Выполнение условия называется
приведением БД к соответствующей нормальной форме.


Первая нормальная форма (1НФ)
требует, чтобы каждое поле таблицы было неделимым и не содержало повторяющихся
групп. Пусть в таблице хранится информация о книгах. Эту информацию можно
держать в единственном поле, но это противоречит 1НФ. В соответствии с ней в
таблице должны быть поля Название, Автор, Издательство и др., совокупность
которых дает исчерпывающую информацию о книге. Это облегчает реализацию таких
запросов к БД, которые позволят узнать количество разных авторов, количество
книг одного автора, количество книг, выпущенных определенным издательством, и
т. п. Повторяющимися являются поля, содержащие сходную информацию. Если,
например, таблица содержит информацию о покупателе и купленных им книгах, то, в
соответствии с 1НФ, список книг должен выделяться в отдельную таблицу.


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


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


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


Как уже говорилось,
проектирование БД - творческий процесс, а описанные выше требования носят лишь
рекомендательный характер. На практике безусловное выполнение этих требований
(в особенности ЗНФ) приводит к появлению множества небольших по объему таблиц и
может существенно замедлять работу с СУБД. Для повышения скорости ее работы
проектировщики часто идут на сознательное нарушение описанных требований.


Единицей хранящейся в БД информации
является таблица. Каждая таблица представляет собой совокупность строк и
столбцов, где строки соответствуют экземпляру объекта, конкретному событию или
явлению, а столбцы - атрибутам (признакам, характеристикам, параметрам) этого
объекта, события, явления.


В терминах БД столбцы таблицы
называются полями, а ее строки - записями.


Базы данных, между отдельными
таблицами которых существуют связи, называются реляционными (от relation -
связь, отношение).


Связанные отношениями таблицы
взаимодействуют по принципу главная (master) - детальная (detail).


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


Первичные ключи облегчают
установление связи между таблицами.


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


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


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





3. СРЕДА DELPHI
КАК СРЕДСТВО ДЛЯ РАЗРАБОТКИ АСУ




- это среда разработки,
используемой прежде всего для создания и поддержки приложений, предназначенных
как для отдельных персональных компьютеров, так и для серверов. Delphi, как и
разработанные с ее помощью приложения, могут функционировать под практически
любой 32 разрядной операционной системой типа Windows. Это довольно легкая в
изучении среда, и в то же время довольно сложная.имеет пользовательский
графический интерфейс, подобный Visual Basic и C++. На данный момент множество
фирм приняло за стандарт данный интерфейс для собственных приложений. Весь
исходный текст программы на Delphi пишется на языке Object Pascal, практически
ничем не отличающимся от принципов, заложенных в такой знаменитой программной
оболочке. Синтаксис, принцип модуля, процедуры, функции, все взято за основу.


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


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


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


Контекстно-зависимое
внедрение файлов справки позволяет поднять уровень проектируемого приложения на
порядок выше.


При работе в среде
программирования посредством так называемого BDE (Borland Database Engine),
системного администратора баз данных, можно получать прямой доступ к таким
стандартным форматам данных, как dBASE, Paradox, FoxPro, Access, ASCII
таблицам. Набор драйверов Borland SQL Links обеспечивает все необходимые
соединения с SQL-серверами.


Интерфейс среды разработки
Delphi состоит из следующих окон.


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





Инспектор объектов. Окно
Object Inspector содержит две страницы. На первой, Properties, постоянно
отображаются все доступные свойства выбранного компонента. В левой колонке
содержится список, в правой - текущие значения по умолчанию. На второй
странице, Events, возможные обработчики событий для выбранного компонента. В
левой колонке - названия, в правой - соответствующие свойства или процедуры. На
рисунке 2 вы можете видеть Object Inspector с установленными свойствами формы.




Каждый объект в Delphi, даже само окно разрабатываемого приложения, имеют
определенные свойства. Например цвет, размер, отображаемый текст и т.п. Эти
свойства можно менять еще до запуска проектируемой программы на выполнение. В
зависимости от изменяемого свойства результат можно просматривать уже сразу.


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


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


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


В окне кода программист непосредственно пишет текстовую часть программы.


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




Проектировщик форм. Каждое Windows-приложение выполняется в собственном
окне. Минимальное количество таких окон равна 1. Delphi при запуске
автоматически предлагает пользователю новый проект, открывая пустое
(незаполненное) окно под названием Form1 и назначает его главным окном. Главное
окно в проекте может быть только одно. Все другие создаваемые окна будут
дочерними. Закрывая главное окно стандартной кнопкой закрытия окна, или
программно, вы закрываете и все дочерние окна.




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


При закрытии запущенной программы Delphi автоматически переводит окна в
то состояние, которое было до запуска проекта на выполнение. Снова на экране
появляется инспектор объектов и редактор формы.


Для сохранения всех файлов проекта выбираем пункт Save All, находящийся в
меню File. Delphi предлагает сохранить модуль программы Unit1 как… Сохраним его
под этим же названием, что и предлагается. Замечание: сколько существует окон в
вашей программе, столько и будет модулей (Unit). Поэтому имеет смысл сохранять
каждый проект в отдельный каталог. Особенно, если в программе много окон. Далее
будет предложено сохранить проект как… т.е. задать название всего проекта. Как
будет называться проект, под таким же именем и будут создаваться исполняемые
EXE файлы. Названия файлов должны состоять из одного слова или слов, написанных
английскими буквами, цифры допустимы только начиная со второго символа, пробелы
- недопустимы (используйте в таких случаях знак подчеркивания).


Перечень сохраняемых при этом файлов на диске:- файл проекта. Содержит он
основной код программы, ссылки на все окна (формы) проекта и относящиеся к ним
модули. В нем также содержится код инициализации. Имеет одноименное название с
проектом.- pascal файл. Он содержит текст, который вы видите в окне редактора
кода так называемого модуля программы.- delphi form. Представляет собой файл с
полными данными о проектировщике формы. Позиция, размер, расположенные
компоненты и пр. Форма приложения является неотъемлемой частью модуля PAS и
имеет то же название.- двоичный файл модуля. Имеет одноименное название с модулем.-
ресурсный файл. Содержит в себе иконки, значки указателя мыши, картинки,
звуки., DSK - содержат настройки проекта.- содержит настройки конфигурации
проекта.- откомпилированная программа. Сохраняется автоматически при запуске
проекта на выполнение. Обновляется в момент компиляции. Имеет одноименное
название проекта. Полностью самостоятельное приложение.


По ходу работы в среде Delphi могут автома
Похожие работы на - Создание программного обеспечения для небольшого супермаркета Дипломная (ВКР). Информационное обеспечение, программирование.
Реферат по теме Как вести переговоры с трудными людьми
Лабораторная Работа Цена
Контрольная работа: Моделирование как метод социальных исследований
Реферат: Монгольская национальная революция
Реферат: Необходимая оборона, понятие, признаки, условия правомерности
Курсовая работа по теме Исследование природы явления сакрального и особенностей влияния процессов сакрализации и десакрализации на человека
Ответ на вопрос по теме Основы экономики
Реферат по теме Лекарственные препараты
Реферат На Тему Английская Драма Xviii В.
Контрольная работа по теме Уникальность Delphi как программы
Эссе по теме Образ психолога в массовом сознании
Как Правильно Оформлять Курсовую В Ворде
Как Написать Вывод В Курсовой
Реферат по теме Системы связи. IP телефония
Реферат Экологическая Экспертиза И Ее Виды
Отчет По Практике Шахта
История Финансовых Реформ Реферат
Реферат по теме Планирование и формирование персонала
Курсовая работа по теме Розробка технологічного процесу виготовлення виливка 'кронштейна'
Реферат Армия И Общество
Реферат: An Analyisis Of A Raisin In The
Реферат: Mad Cow Disease Essay Research Paper For
Похожие работы на - Роль юридической профессии в политике государства

Report Page