Файл: Разработка базы данных аптеки.docx

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 05.05.2024

Просмотров: 12

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.


Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Российский экономический университет им. Г.В. Плеханова» Брянский филиал


Курсовая работа
МДК . 02.02 «Технология разработки и защиты баз данных»

Специальность 09.02.03 «Программирование в компьютерных системах»

Тема: Разработка базы данных аптеки



Пояснительная записка

Листов:

Руководитель

Дуляк Н.О / И.О. Фамилия /

«_ 07 » 05 2018 г.

Исполнитель

Богатко Е.Г. / И.О. Фамилия /

«_ 07 » 05 2018 г.
2018

Содержание
Введение Error: Reference source not found

Сокращения …. 4

Глава 1. «ТЕОРЕТИЧЕСКАЯ ЧАСТЬ» 5

1.1 Анализ предметной области. Формирование требований .. ….5

1.2 Инфологичекое проектирование 8

1.3 Выбор инструментальных средств разработки 11

Глава 2. «РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» 13

2.1 Разработка серверной части БД 13

2.2 Разработка клиентского приложения 14

2.3 Тестирование и отладка 18
Заключение 20

Список используемой литературы 21

ПРИЛОЖЕНИЕ 23

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

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

  1. Определить требования к разработке интерфейса создаваемого ПО.

  2. Определить требования к предоставляемой в программе информации.

  3. Определить требования к работе приложения.

  4. Создать серверную часть базы данных.

  5. Разработать клиентскую часть приложения.

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

  7. Разработать интерфейсную часть.

  8. Протестировать и отладить программу.


Объект исследования – процесс разработки прикладных программ с использованием RAD-среды. Предмет исследования – возможности среды Delphi для разработки клиентской части приложений удаленных баз данных. В процессе написания курсовой работы использовался прикладной вид исследования. Уровень исследования – теоретико-эмпирический.

Сокращения:

Аббревиатура

Полное название

ПО

Программное обеспечение

ЖЦ

Жизненный цикл

ПК

Персональный компьютер

ОС

Операционная система

RAD

Rapid application development — быстрая разработка приложений


Обозначения:

Вид

Значение

Delphi

Среда разработки приложений, основанная на языке программирования Object Pascal.

Windows

ОС, разработанная компанией Microsoft.

ISO/IEC 12207-2010

ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы ЖЦ программных средств.

Form

Форма среды программирования Delphi.

Label

Компонент для вывода статической текстовой информации.

Button

Компонент, выполняющий роль клавиши.

Memo

Компонент для вывода текстовой информации.

Image

Компонент для вывода графической информации.

ComboBox

Компонент для создания выпадающих списков.


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


1.1. Анализ предметной области. Формировании требовании.
Автоматизированная система учета лекарств и их продаж в аптеке. Аптека занимается закупкой и продажей лекарств. Аптека закупает товар у поставщиков и хранит его в аптеке до его реализации. Аптека и поставщик заключает между собой договор о поставке лекарств. Автоматизированная система хранит информацию о лекарствах, которые поступили от поставщика. Между поставщиком и аптекой заключается договор купли продажи. Вид сети – локальная. Топология сети – звезда. А так же представлена схема, которая представляет структуру аптеки (Рисунок 1).




Рисунок 1 – Схема аптеки
Формирование требований.

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

Каждый программный продукт проходит свой жизненный цикл. Жизненный цикл ПО — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим жизненный цикл ПО, является международный стандарт ISO/IEC 12207-2010, который определяет структуру жизненного цикла, процессы, действия, работы, выполняемые во время создания ПО.

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

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

Жизненный цикл в соответствии с подходом RAD включает только четыре стадии, что облегчает процесс создания ПО:

  1. Анализ и планирование требований.

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

  1. Проектирование.

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

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


Результатом данной стадии должны быть:

  1. Общая информационная модель программы;

  2. Функциональная модель программы;

  3. Точно определенный интерфейс;

  4. Построенные прототипы экранных форм, отчетов, диалогов. 

  1. Реализация.

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

  1. Внедрение.

Основные принципы подхода RAD:

  1. Разработка приложения итерациями;

  2. Необязательность полного завершения работ на каждой стадии жизненного цикла ПО;

  3. Использование прототипов, позволяющее полнее выяснить и удовлетворить потребности пользователей;

  4. Тестирование и развитие проекта осуществляются одновременно с разработкой;

  5. Целесообразность применения CASE-средств, обеспечивающих целостность проекта и генерацию кода приложения.

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

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

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

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

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

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



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

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

Инфологическое моделирование баз данных выполняется в виде модели "сущность—связь", или "Entity Relationship". Сокращенное название этой модели - ER-модель. Большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД.

В данной курсовой работе будем рассматривать ER модель, которая будет создана с помощь ПО ErWin 4.0. Какие модели будут созданы? В данном проекте будет создано две модели, это физическая и логическая модель. Давайте более детально рассмотрим эти две модели.

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

В ходе создания физической модели было выделено несколько сущностей. Первая сущность –Postavshiki. Первичном ключом было выбрано поле Kod_nomera (Integer), так же присутствуют поля такие как Naimen(Varchar 50), Predst(Varchar 50), Telephone(Varchar 50). Следующая сущность Lekarstva. Первичный ключ – Kod_lekarstva(Integer), так же присутствуют поля Nazvanie(Varchar 50), Gruppa(Varchar 50), Stoimost(Varchar 50), Kod_post (Integer). Следующая сущность Prodagy. Первичном ключом было выбрано поле Kodpr (Integer), так же присутствуют поля такие как Kol_vo(Integer), Itogo(Integer), Kod_lekarstva (Integer). Эта таблица отображает основную информацию необходимую пользователю. (Рисунок 2)