Borland Delphi 7 может работать в среде операционных систем от Windows 98 до Windows 7/Vista. Особых требований, по современным меркам, к ресурсам компьютера пакет не предъявляет: процессор должен быть типа Pentium или Celeron с тактовой частотой не ниже 166 МГц (рекомендуется Pentium II 400 МГц), оперативной памяти - 128 Мбайт (рекомендуется 256 Мбайт), достаточное количество свободного дискового пространства.
Delphi 7 содержит развитые библиотеки и инструменты для создания приложений, полностью интегрирует соответствующие технологии и качественно повышает производительность разработчиков. Интегрируя ведущие приложения разработки в единый и легкий в использовании пакет,
Delphi 7 сокращает жизненный цикл разработки приложений и ускоряет вывод создаваемых с его помощью продуктов на рынок ПО [7].
Таким образом, с учетом требований для разработки системы контроля и учета автозапчастей используются следующие среды:
MS SQL
Хранение
SQL -запросы
Delphi
Формы
Печать
Взаимодействия пользовательского приложения
MS Access - для хранения данных;
Borland Delphi 7 - для организации пользовательского интерфейса;
Для резервного копирования и восстановления архивных данных используется Microsoft Word.
Особенности взаимодействия используемых сред отражены на рисунке
На основании спроектированной структурной схемы системы контроля и учета автозапчастей получен алгоритм работы приложения, приведенный на рисунке 1.2.
Алгоритм функционирования приложения
1.3 Анализ существующих на рынке БД «Автозапчасти»
База данных, разрабатываемая в рамках дипломного проекта,
занимается автоматизацией систем контроля автозапчастей и учетом клиентов.
Перед разработкой базы данных «Автозапчасти» проводился
тщательный анализ существующих на рынке баз данных и были выявлены
недостатки. Ниже приведены недостатки аналогичных баз данных и
предложены пути решения.
1.3.1 БД «АвтоКаталог»
«АвтоКаталог» представляет собой электронную версию "бумажных" каталогов запасных частей по отечественным и иностранным автомобилям и двигателям. По сути, это электронный каталог запчастей, компьютерный справочник (база данных) с информацией об устройстве автомобилей - от крупных узлов и агрегатов до запчастей с их кодами (каталожными номерами), наименованиями и графическими изображениями (чертежами). АвтоКаталог обладает присущей компьютерным программам компактностью (всего 6 компакт - дисков, поставка может быть и на DVD), высокой скоростью поиска информации, широкими возможностями работы с ней (масштабирование, печать), потрясающим удобством и наглядностью в работе. Интерфейс программы можно увидеть на рисунке 1.3.
Рисунок 1.3 - Интерфейс программы «АвтоКаталог»
К большому недостатку программы можно отнести отсутсвие учета и регистрации клиентов. Это один из главных атрибутов функций продажи автозапчастей. Перед нами большая база знаний без связки «клиент - продажа - автозапчасть».
1.3.2 БД «АвтоДилер»
Программа «АвтоДилер» занимается учетом в автосервисе и в автомагазине, имеет каталоги запчастей, нормы времени ремонта.
«АвтоДилер» - это специализированное программное обеспечение для автобизнеса. Система предназначена для автоматизации учета, планирования и анализа работы любых предприятий: крупных и мелких автомастерских, автосалонов, магазинов автозапчастей, автомоек, шиномонтажных мастерских и станций замены масла, автостраховщиков.
При открытии программы тут же вскакивает рекламное окно, которое представлено на рисунке 1.4.
Рисунок 1.4 - Реклама при входе в систему «АвтоДилер»
Также имеется большой недостаток в отсутствии логистики. База данных имеет много таблиц и вкладок, что не позволяет пользователю с любым уровнем подготовки выполнять необходимые задачи (Рисунок 1.5).
Хорошая программа должна иметь понятный интерфейс и логистику, а не коммерческую универсальность. То есть, еще одним недостатком системы «АвтоДилер» является то, что он не разработан под определенное предприятие. которое представлено на рисунке 1.5.
Рисунок 1.5 - Интерфейс программы «АвтоДилер»
При выходе из программы еще раз появляется реклама, которая показана на рисунке 1.6.
Рисунок 1.6 - Назойливая реклама при выходе из программы
В данном дипломном проекте были учтены ошибки аналогов базы данных «Автозапчасти» и устранены.
2. Проектирование и разработка базы данных «Автозапчасти»
2.1 Требования к системе
а) обеспечение разработки системы на основе установленных на целевом компьютере ПО;
б) простой и удобный пользовательский интерфейс;
в) обеспечение обработки и хранения большого объема данных;
г) формирование отчетности;
д) возможность резервного копирования данных;
е) переносимость системы.
2.2 Архитектура системы
Архитектура разрабатываемой программной системы представлена на рисунке 2.1.
На диаграмме прецедентов (вариантов использования) показано взаимодействие между вариантами использования и действующими лицами.
Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования - это функции, выполняемые системой, а действующие лица - это заинтересованные по отношению к создаваемой системе [4].
Рисунок 2.1 - Архитектура автоматизированной системы контроля автозапчастей и учета клиентов
2.3 Разработка UML-диаграмм БД «Автозапчасти»
2.3.1 Диаграмма прецендентов
Основная задача диаграммы вариантов использования - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Рисунок 2.2 - Диаграмма прецедентов
Таблица 2.1 - Распределение требований по субъектам и прецедентам
|
Клиент должен иметь возможность получить информацию по состоянию его заказа. |
Клиент |
Информация о заказе |
|
|
Клиент должен получить окончательный счет за оказание услуг в автозапчасти с отчетом о покупке в печатном виде. |
Клиент |
Конец обслуживания клиента |
|
|
Персонал автозапчасти должен иметь возможность ввести данные о выполненном заказе (номера услуг, стоимость и т.д.) для формирования окончательного счета. |
Персонал автосервиса |
Конец обслуживания клиента |
2.3.2 Вид с точки зрения процесса
Диаграммы видов деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы. Диаграмма видов деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.
Диаграммы деятельности можно использовать для моделирования динамических аспектов поведения системы. Как правило, они применяются, чтобы промоделировать последовательные (а иногда и параллельные) шаги вычислительного процесса [5].
Основными элементами диаграмм видов деятельности являются обозначения состояния («начало», «конец»), действия (овал) и момента синхронизации действий (линейка синхронизации, на которой сходятся или разветвляются несколько стрелок).
Рисунок 2.3 - Диаграмма видов деятельности для прецедента «Оформление заказа»
2.3.3 Вид с точки зрения проектирования
Диаграмма последовательности действий призвана наглядно отобразить набор процессов, их последовательность и взаимодействие по времени их появления. Например, когда нужно проработать буквально по шагам какой - то важный участок выполнения программы.
Рисунок 2.3 - Диаграмма последовательности прецедента «Оформление заказа»
Рассмотрим каждый элемент диаграммы, по отдельности:
Объект, Участник (Object, Participant). Обозначается прямоугольником, в котором показывается информация об участнике действий. Размещаются объекты (как правило) вдоль верхнего края диаграммы. От прямоугольника вниз опускается Линия Жизни.
Линия жизни (Life Line).Линия, исходящая вниз от участника, означающая отведенное объекту время жизни. Обозначается пунктирной линией.
Активация, фрагмент выполнения (Activation
Bar,
Execution
Occurances).Обозначается узким прямоугольником (серого или белого цвета), размещенным на линии жизни. Показывает начало и завершение действия, в котором участвует объект. Поскольку линия жизни - это метафора времени, то прямоугольник на линии жизни указывает на активизацию объекта во времени.
2.3.4 Вид с точки зрения развертывания
Физическое представление программной системы не может быть полным, если отсутствует информация о том, на какой платформе и на каких вычислительных средствах она реализована. Для представления общей конфигурации и топологии распределенной программной системы в UML предназначены диаграммы размещения.
Диаграмма размещения предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения. При этом представляются только компоненты-экземпляры программы, являющиеся исполняемыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются. Так, компоненты с исходными текстами программ могут присутствовать только на диаграмме компонентов. На диаграмме размещения они не указываются.
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе. Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев, часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйн фреймом [3].
На данной диаграмме представлены процессоры, то есть те устройства, которые могут обрабатывать данные.
Диаграмма размещения содержит графические изображения устройств и связей между ними. В отличие от диаграмм логического представления, диаграмма размещения является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Разработка диаграммы размещения, как правило, является последним этапом спецификации модели программной системы [2].
Рисунок 2.5 - Диаграмма развертывания
2.4 Проектирование БД «Автозапчасти»
2.4.1 Построение логической модели БД «Автозапчасти»
Для разработки данной БД «Автозапчасти» было использовано СУБД MS SQL.
В прoцеccе лoгичеcкого прoектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД.
Основной целью данного этапа является устранение проблем данных с использованием специальных форм нормализации. Цель нормализации - как можно минимизировать повторения данных и возможные изменения БД при процедурах обновления. Это достигается разделением одной таблицы в несколько с последующим использованием при запросах операции навигации ими. Навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на его запрос. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.
Специального обсуждения заслуживает процедура управления БД. Она наиболее проста в однопользовательском режиме. В многопользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользователей без принятия специальных мер возможно нарушение целостности информации. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей.
Транзакция - процесс изменения файла, записи или базы данных, вызванный передачей одного входного сообщения. Особенности блокирования и варианты блокировки далее будут рассмотрены отдельно.
Логический (концептуальный) уровень построен с учетом специфики и особенностей конкретной СУБД. Этот уровень представления данных ориентирован больше на компьютерную обработку и на программистов, которые занимаются ее разработкой. На этом уровне формируется концептуальная модель данных, то есть специальным способом структурированная модель предметной области, которая отвечает особенностям и ограничениям выбранной СУБД.
Рисунок 2.6 - Логический уровень
Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Разделение модели данных на логические и физические позволяет решить несколько важных задач [8].