Размещено на http://www.allbest.ru/

4

ВКР допущена к защите

Заместитель директора по учебной работе

Л.П. Егорова

КУРСОВАЯ РАБОТА

Тема: Разработка программного обеспечения информационной системы «Ювелирный магазин»

Дипломник

Тюрин А.А.

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

Должанский А. М.

Москва 2015

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ

1.1 Аспекты разработки ПО

1.2 Исследование разработки программного продукта в области торговли

2. РАЗДЕЛ ПРОЕКТИРОВАНИЯ

2.1 Постановка задачи

2.2 Описание предметной области

2.3 Обоснование выбора СУБД и языка программирования

2.4 Проектирование программного продукта ИС

3. ЭКСПЕРИМЕНТАЛЬНЫЙ РАЗДЕЛ

3.1 Обоснование экономической эффективности программного продукта

ВВЕДЕНИЕ

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

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

Объектом исследования является магазин ювелирных изделий.

Целью дипломного проекта является разработка программного обеспечения информационная система «Ювелирный магазин», которое позволит автоматизировать учёт деятельности магазина. В данной ИС необходимо сформировать базу клиентов, товаров, вывод чеков и отчетности.

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

­ ознакомиться с основными аспектами разработки ПО;

­ проанализировать существующие ИС в области торговли украшениями;

­ изучить предметную область;

­ выбрать язык программирования и систему управления базами данных для будущего программного продукта.

­ описать предметную область;

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

­ разработать интерфейс программного продукта;

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

­ провести тестирование программного продукта;

­ описать технические и программные средства необходимые для нормального функционирования ПО;

­ рассчитать экономическую эффективность создаваемого приложения.

1. ТЕОРЕТИЧЕСКИЙ РАЗДЕЛ

1.1 Аспекты разработки ПО

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

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

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

1. Модифицируемость. Необходимость модификации ПО обычно возникает по двум причинам: чтобы отразить в системе изменение требований или чтобы исправить ошибки, внесенные ранее в процессе разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование предполагает составление формальных и/или формализованных спецификаций.

Реализация - преобразование этих спецификаций в программный код (автоматическое и/или автоматизированное).

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

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

Одну из таких моделей предлагает W/O (Warnier/Orr) методология. Она объединяет методологию Warnier по использованию логических структур данных и логических конструкций программ и систем и методологию DSSD (Data Structured System Development) Oppa, базисом которой является аксиома о логическом соответствии между эвристической структурой программ и данных, обрабатываемых этими программами. На практике такая: методология предполагает, что в распоряжении проектировщика системы имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.

В настоящее время DSSD-методология «переросла» из методологии разработки программ в методологию разработки систем. При этом выделены явно уровень программирования и системный уровень. Применяются в DSSD два концептуальных представления - диаграммы входов, обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы.

Следующим подходом к созданию моделей программ (по идее достаточно близким к W/O-методологии) является логическое моделирование Гэйна. Сам метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в процессе последовательного применения следующих семи этапов: описание природы предметной области с помощью диаграмм потоков данных (Data Flow Diagram); выделение первичной модели данных (списка элементов данных в каждом информационном узле); проверка того, что DFD действительно отражает структуру данных, хранимых в системе; сведение полученной на предыдущем этапе информации в двумерные таблицы, которые в дальнейшем нормализуются; коррекция DFD с учетом результатов нормализации предыдущего этапа; разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units), а также определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.

И наконец, третьим в ряду подходов к созданию модели проектируемой программы является метод Йордана (Yourdon). Он включает два компонента: инструментальные средства и методики. Ориентирована методология Йордана на проектирование систем обработки данных. Под инструментальными средствами здесь понимаются различные диаграммы, используемые при описании моделей требований и моделей архитектуры проектируемой информационной системы. Самые известные из таких диаграмм - диаграммы потоков данных DFD. Однако их недостатком является отсутствие средств описания отношений между данными и их «поведения» во времени. Вот почему в инструментальные средства метода Йордана на сегодняшний день кроме DFD включены ERD-диаграммы (Entity Relationship Diagrams) и STD-диаграммы (State Transition Diagrams).

Методики в методе Йордана помогают перейти от бланка на бумаге и/или экранной формы к хорошо организованной системной модели. Первоначально эти методики базировались на традиционном top-down проектировании. В настоящее время здесь используется метод событийного разбиения (event partitioning). При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечивает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. По существу, событийное разбиение не что иное, как метод объектно-ориентированного проектирования.

Проблемы, возникающие при использовании метода ERD-диаграмм, связаны, прежде всего, с трудностями интеграции компонентов при разработке всей системы. Вот почему в последнее время этот метод был обобщен за счет введения интегрированной базы данных. При этом ERD-метод трансформируется в структурную методологию, основные этапы которой сводятся к разработке ERD (здесь выделяются как собственно сущности с их типами, так и связи, тоже с их типами); определению кардинальности (cardianality) - однозначности-многозначности типов связей; преобразованию ERD по определенным правилам в соответствующий файл и структуру БД. В процессе такого преобразования каждый тип сущности трансформируется в отношение, а тип связи - в особое (stand alone) отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. Разработка прикладных программ на основе сформированного файла и структуры базы данных является заключительным этапом в этом подходе.

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

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

Наиболее распространёнными проблемами, возникающими в процессе разработки ПО, считают:

- Недостаток «прозрачности»;

- Недостаток контроля;

- Недостаток трассировки;

- Недостаток мониторинга;

- Неконтролируемые изменения;

- Недостаточная надёжность;

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

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

1.2 Исследование разработки программного продукта в области торговли

ИП: Ювелирный Магазин - это удобная и простая в использовании программа для ювелирного магазина.

Достоинства:

- возможность ведения учёта как в количественном, так и в идентифицированном виде;

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

Недостатки:

- требует специальной подготовки пользователей

- не прогнозирует закупки ювелирных изделий

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

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

Достоинства:

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

- упрощенная работа со складом и поставщиками;

Недостатки:

- снижается оперативность обслуживания клиентов

- нельзя следить за персоналом в online.

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

2. РАЗДЕЛ ПРОЕКТИРОВАНИЯ

2.1 Постановка задачи

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

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

- добавление, изменение, удаление и сохранение записей;

- просмотр и редактирование справочников товаров;

- учет закупки продукции;

- просмотр журнала по товарам;

- учет продажи товаров;

- оформление чеков на поставку и продажу;

- ведение склада;

- формирование отчетов по поставкам и продажам за выбранный перод.

Разрабатываемое приложение должно быть защищено паролем и оснащено авторизацией.

2.2 Описание предметной области

Ювелирный магазин занимается торговлей ювелирных изделий - колец и сережек.

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

Устройство ювелирного магазина:

1. Скупка. Организаторы занимаются скупкой ювелирных изделий бывших в употреблении, лома золота и других драгоценных металлов со вторичного рынка. Скупка золота, как правило, производится у населения. Отличительной особенностью этого бизнеса является отсутствие специальных документов инспекции пробирного надзора у продавцов, т.е. у физических лиц, тогда как у покупателей такие документы быть обязаны. Скупка - это квинтэссенция рентабельности в России. Золото купленное у населения загрязнено, требует специальной обработки аффинажа, но оно изначально дешевле банковских слитков на 18% НДС. Эти 18% в самом начале пути превращают новые ювелирные изделия в разы дешевле, но об этом далее по тексту.

2. Ломбард. Ломбард - относят также к финансовым организациям. Ломбарды оказывают банковские услуги по выдаче микро кредитов под залог золота. Всё невыкупленное золото становится предметом продажи в ювелирную отрасль. Как только золото перешло в руки ломбарда, он превращается в скупку. Очень часто ломбард и скупка действуют в одном предприятии, сотрудники такого предприятия всегда спрашивают посетителей: в залог или продаёте? Этим они определяют дальнейшие документы оформления и путь золота.

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

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

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

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

7. Ювелирные магазины. Ювелирные магазины могут быть как глубоко несчастными, так и очень влиятельными, разбогатевшими настолько, что начинают влиять на всех участников рынка, диктуя свои условия. Всё зависит от вас, господа бизнесмены. Как организовать свой ювелирный бизнес правильно, мы постараемся раскрыть в этом пособии: «Ювелирный бизнес изнутри».

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

2.3 Обоснование выбора СУБД и языка программирования

Развитие информационных систем тесно связано с процессом становления поколений ЭВМ. Появление первых доступных пользователям информационных систем связано со вторым поколением ЭВМ. С появлением третьего поколения ЭВМ и четвертого связано массовое внедрение информационных технологий в производственный процесс.

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

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

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

- Системы обработки транзакций. Такие системы регистрируют продажи и закупки. Транзакция может находится в одном из двух состояний:

- Состояния завершения всех изменений и фиксация результата в базе данных системы;

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

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

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

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

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

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

Гипертекстовые информационные системы реализованы в сети в виде всемирной паутины World Wide Web (WWW). Информационная система WWW в настоящее время реализует расширенную гипермедийную технологию. Гипермедийные документы позволяет с помощью ссылок обращаться как текстовым документам, так и к графическим данным, видео данным и аудио данным.

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

Обоснование выбора СУБД рассмотрим на примере СУБД Access, входящей в состав пакета прикладных программ (ППП) Microsoft Office. При выборе любой программы первоначально рассматриваются её возможности, среда применения, пользователи, их квалификация и т.п.

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

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

Access - это популярная настольная система управления базами данных. Её успех можно связать с великолепной рекламной кампанией, организованной Microsoft, и включением её в богатое окружение продуктов семейства Microsoft Office, c прекрасной реализацией продукта, рассчитанного как на начинающего, так и квалифицированного пользователя.

СУБД Access является набором инструментальных средств, предназначенных для создания и эксплуатации информационных систем, для управления базами данных.

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

Таблица в Access является основным структурный объектом внутреннего строения БД. В неё включают записи определённого вида. Каждая запись таблицы содержит всю необходимую информацию об отдельном объекте - элементе БД. По многим причинам вводить все данные в одну таблицу нерационально, поэтому в Access предусмотрен механизм создания связанных между собой разных таблицы с различными видами данных. Таблицу Access можно связать с данными, хранящимися на другом компьютере или на сервере. В Access можно использовать таблицу, созданную в СУБД Paradox или Dbase. Данные Access очень просто комбинировать и с данными из Excel и т.п.

С помощью средств Access можно выполнять следующие операции:

- Проектировать базовые объекты ИС - двумерные таблицы с разными типами данных, включая поля объектов OLE. Например, прежде чем заполнять данными любую таблицу, надо создать её макет.

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

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

- Создавать, модифицировать и использовать производные объекты ИС (формы, запросы и отчёты).

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

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

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

- передавать управление процессам, в зависимости от состояния системы;

- создавать оболочки для баз данных, как и сами базы данных;

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

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

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

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

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

- поддержка БД.

Выше перечисленными свойствами обладают языки программирования:

- Visual Fox Pro;

- Delphi;

- Visual C++.

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

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

Для реализации данной ИС была выбрана система программирования Delphi версии 7 фирмы Enterprise (Borland), так как она предоставляет наиболее широкие возможности для программирования приложений ОС Windows.

Delphi - это продукт Borland International для быстрого создания приложений. Высокопроизводительный инструмент визуального построения приложений включает в себя настоящий компилятор кода и предоставляет средства визуального программирования, несколько похожие на те, что можно обнаружить в Microsoft Visual Basic или в других инструментах визуального проектирования. В основе Delphi лежит язык Object Pascal, который является расширением объектно-ориентированного языка Pascal.

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

Преимущества Delphi по сравнению с аналогичными программными продуктами.

- быстрота разработки приложения;

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

- низкие требования разработанного приложения к ресурсам компьютера;

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

- возможность разработки новых компонентов и инструментов собственными средствами Delphi (существующие компоненты и инструменты доступны в исходных кодах);

- удачная проработка иерархии объектов.

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

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

2.4 Проектирование программного продукта ИС

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

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

ѕ степень автоматизации проектных работ;

ѕ принятая методология процесса разработки.

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

ѕ методы традиционного (неавтоматизированного) проектирования;

ѕ методы автоматизированного проектирования (CASE-технология и ее элементы).

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

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

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

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

Проектирование концептуальной модели

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

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

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

Наряду с этим существуют взаимосвязи между атрибутами объекта. Различают взаимосвязи типа: "один к одному", "один ко многим", "многие ко многим".

Самой популярной моделью концептуального проектирования является модель «сущность-связь» (ER-модель), она относится к семантическим моделям.

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

Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.

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

Атрибут - характеристика (параметр) не которой сущности.

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

У сущностей выделяются ключевые атрибуты - ключ сущности - это один или более атрибутов, уникально определяющих данную сущность

С помощью ER-моделирования составим концептуальную модель

Рисунок 1 - Концептуальная модель БД «Ювелирная мастерская»

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

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

В нашем случае получаем следующую диаграмму действий (рис.2)

Рисунок 2 ? Диаграмма деятельности по редактированию справочника клиентов.

Составим словарь сущностей концептуальной модели данной предметной области. Для удобства представим словарь в табличном виде (табл. 2).

Словарь сущностей концептуальной модели

Таблица 2

Порядковый номер	Условное обозначение	Описание
1	Izdelia	Информация об изделиях
2	Izgotovlenia	Сведения о изготовлении ювелирных изделий
3	Metall	Информация о металлах
4	Kamen	Сведения о камнях
5	Zakazchik	Сведения о заказчиках
6	Master	Информация о мастерах
7	Razryad_mastera	Сведения о разряде мастера

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

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

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

Рисунок 3 - диаграмма прецедентов

Проектирование логической модели

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

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

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

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

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

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



Рисунок 4 -Логическая модель БД «Ювелирная мастерская»

Проектирование физической модели

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

Таблица 1 Master

Имя поля	Тип данных	Описание
Master	Счётчик	Код мастера
Family	Текстовый	Фамилия
Ima	Текстовый	Имя
Otchestvo	Текстовый	Отчество
Razryd	Числовой	Разряд

Таблица 2 Razryad mastera

Имя поля	Тип данных	Описание
Razryd	Числовой	Разряд

Таблица 3 Zakazchik

Имя поля	Тип данных	Описание
Zakazchik	Счётчик	Код клиента
Family	Текстовый	Фамилия
Ima	Текстовый	Имя
Otchestvo	Текстовый	Отчество
Numer pasporta	Числовой	Номер паспорта
Seria pasporta	Числовой	Серия паспорта

Таблица 4 Metall

Имя поля	Тип данных	Описание
Metall	Текстовый	Драгоценный металл
Chena(gr)	Числовой	Цена за грамм

Таблица 5 Kamen

Имя поля	Тип данных	Описание
Kamen	Текстовый	Драгоценный камень
Chena(karat)	Числовой	Цена за карат

Таблица 6 Izgotovlenia

Имя поля	Тип данных	Описание
Izgotovlenia	Счётчик	Код заказа
Izdelia	Текстовый	Название изделия
Metall	Текстовый	Драгоценный металл
Kamen	Текстовый	Драгоценный камень
Karat	Числовой	Карат в камне
Zakazchik	Числовой	Код клиента
Master	Числовой	Код мастера
Summa	Числовой	Стоимость

Таблица 7 Izdelia

Имя поля	Тип данных	Описание
Izdelia	Счётчик	Изделие
Nachenka	Текстовый	Наценка на изделие
Ves	Текстовый	Вес изделия

СУБД Microsoft Access на сегодняшний день является одной из самых популярных настольных программ для создания информационных систем. Это связано с тем, что Access предоставляет очень широкие возможности для ввода, анализа и представления данных. Эти средства являются не только удобными, но и продуктивными, что обеспечивает высокую скорость разработки приложений Исполнение Microsoft Office Access 2009/ Специальное издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2011..

Access обладает рядом уникальных возможностей:

- объединение информации из самых разных источников (электронных таблиц, текстовых файлов, других баз данных);

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

– интеграция с компонентами Microsoft Office.

Современные тенденции в развитии информационных технологий - интенсивное внедрение Web-технологий Internet, также получили представление в Access. СУБД Access обеспечивает публикацию баз данных в формате, доступном в сетях Internet и intranet. В Microsoft Access 2003 эти средства получили дальнейшее развитие и позволяют конструировать в интерактивном режиме Web-страницы, предназначенные для работы с базами данных.

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

Все эти и многие другие возможности СУБД Access позволяют сделать выбор в пользу Access. Основное назначение базы данных - хранение, поддержание в актуальном состоянии данных больших объемов, необходимых в различных приложениях многих пользователей - полностью реализуется в СУБД Access. Все современные тенденции - по созданию Web-страниц доступа к данным, многопользовательского режима работы, поддержание технологии клиент-сервер, интеграции с другими приложениями, даже средства разработки проектов, которые являются клиентскими приложениями Microsoft SQL Server - всеми этими возможностями обладает СУБД Access.

Схема данных будет полностью соответствовать логической модели данных (см. рис.5), но создана она будет в Microsoft Access 2009.

Рисунок 5 - Физическая модель данных

2.5 Разработка программного продукта

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

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

Рисунок 6 - Авторизация

procedure TMenu.Button1Click(Sender: TObject);

var

log,pas:string;

begin

log:=Edit1.Text;

pas:=Edit2.Text;

if (log='Admin') and (pas='555') then

begin

n1.Visible:=true;

n2.Visible:=true;

n3.Visible:=true;

GroupBox1.Visible:=false;

edit1.Text:='';

edit2.Text:='';

messagebox(0,'Авторизация завершена успешно','Сообщение',33);

end

else

begin

messagebox(0,'Не верный логин и пароль','Ошибка',33);

edit1.Text:='';

edit2.Text:='';

end;

end;

Рисунок 7 - Панель вкладок

procedure TMenu.N1Click(Sender: TObject);

begin

Application.CreateForm(TOsnowa,Osnowa);

end;

procedure TMenu.N2Click(Sender: TObject);

begin

Application.CreateForm(TPrepod,Prepod);

end;

procedure TMenu.N4Click(Sender: TObject);

begin

Application.CreateForm(TPredmet,Predmet);

end;

procedure TMenu.N5Click(Sender: TObject);

begin

Application.CreateForm(TNapravlenia,Napravlenia);

end;

procedure TMenu.N6Click(Sender: TObject);

begin

Application.CreateForm(TKonkurs,Konkurs);

end;

procedure TMenu.Button1Click(Sender: TObject);

var

log,pas:string;

begin

log:=Edit1.Text;

pas:=Edit2.Text;

if (log='Admin') and (pas='555') then

begin

n1.Visible:=true;

n2.Visible:=true;

n3.Visible:=true;

GroupBox1.Visible:=false;

edit1.Text:='';

edit2.Text:='';

messagebox(0,'Авторизация завершена успешно','Сообщение',33);

end

else

begin

messagebox(0,'Не верный логин и пароль','Ошибка',33);

edit1.Text:='';

edit2.Text:='';

end;

end;

end.

Перейдя во вкладки «Основа», Открывается форма с полным списком обучающихся детей и информация о них. Детей можно добавлять, удалять и производить поиск по Фамилии и полу.(рис. 8).



Рисунок 8 - Основная форма

unit Unit3;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Mask, DBCtrls, Grids, DBGrids;

type

TOsnowa = class(TForm)

Osnowa: TDBGrid;

DBEdit1: TDBEdit;

Button1: TButton;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

DBEdit2: TDBEdit;

DBEdit3: TDBEdit;

Button2: TButton;

Button3: TButton;

Button4: TButton;

DBEdit5: TDBEdit;

DBEdit6: TDBEdit;

DBEdit7: TDBEdit;

DBEdit8: TDBEdit;

Label5: TLabel;

Label6: TLabel;

Label7: TLabel;

Label8: TLabel;

Label9: TLabel;

DBLookupComboBox1: TDBLookupComboBox;

DBLookupComboBox2: TDBLookupComboBox;

RadioButton1: TRadioButton;

RadioButton2: TRadioButton;

Label10: TLabel;

Edit1: TEdit;

Button5: TButton;

Button6: TButton;

procedure FormClose(Sender: TObject; var Action: TCloseAction);

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

...