Автоматизированная информационная система «Магазин по продаже одежды»

Темой данной курсовой работы стал магазин по продаже одежды, так как актуальность этой темы в данное время велика, во всех городах, поселках, деревнях существуют магазины одежды, ведь одежда является предметом первой необходимости. Чтобы облегчить задачу учета продаваемой и поступающей одежды работникам магазина будет разработана и спроектирована данная автоматизированная система.
По данной теме существуют различные автоматизированные системы, одна из которых 1С:Бухгалтерия, очень удобна для учета товаров, поставщиков, бухгалтерского учета и многих других операций.
В данной курсовой работе будет спроектирована и разработана автоматизированная информационная система для работы в магазине по продаже одежды, она предназначена для учета товара, что облегчит работу менеджера и персонала магазина.
Перед данной ИС стоят следующие задачи:
a) надежность и безопасность работы системы,
b) простое пользование информационной системой,
c) достоверность выдачи информации,
d) защищенный доступ к изменению данных в системе,
e) создание удобного интерфейса.
1. Проектирование АИС.
Жизненный цикл (ЖЦ) АИС - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации.
Жизненный цикл АИС и его этапы.
Структура ЖЦ ПО базируется на трех группах процессов:
- основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
- вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
-организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка охватывает все работы по созданию АИС и его компонентов (анализ, проектирование и программирование) в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и качества программных проектов, материалов, необходимых для организации обучения персонала, и т.д. Эксплуатация включает в себя работы по внедрению компонентов АИС (конфигурирование базы данных и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и др.), локализация проблем, возникающих при эксплуатации с устранением причин их возникновения, модификацию АИС в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Результатами анализа, в частности, являются функциональные модели, информационные модели и соответствующие им диаграммы.
Известно несколько моделей жизненного цикла программного обеспечения. Под моделью жизненного цикла ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении всего цикла. Модель ЖЦ зависит от специфики АС и специфики условий, в которых система создается и функционирует. К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ: каскадный способ и спиральная модель. Каскадная модель применяется, как правило, для разработки однородных АС, представляющих собой единое целое. Ее основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Преимущества применения каскадного способа заключаются в следующем: на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты. В то же время этот подход обладает рядом недостатков, вызванных прежде всего тем, что реальный процесс создания АИС никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапами уточнении или пересмотре ранее принятых решений.
Разработка итерациями отражает объективно существующий спиральный цикл создания автоматизированной системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям АИС работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков АИС. Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании АИС с использованием CASE-средств, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы. Жизненный цикл АИС в соответствии с методологией RAD состоит из четырех фаз: анализа и планирования требований; проектирования; построения; внедрения.
На фазе анализа и планирования требований пользователи АИС определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Формулирование требований к АИС осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта АИС, устанавливаются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.д. Результатом этого этапа должен быть список расставленных по приоритету функций будущей АИС, а также предварительные функциональные модели АИС.
На этапе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Устанавливаются требования разграничения доступа к данным. На этой же фазе происходит определение необходимой документации. Результатом данного этапа должны быть: общая информационная модель системы; функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков; точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами; построенные прототипы экранов, отчетов, диалогов. Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап нередко происходит неконтролируемое искажение данных. Применение единой среды хранения данных о проекте позволяет этого избежать. В отличие от обычных подходов, при которых используются специфические средства, не предназначенные для построения реальных приложений, а прототипы выбрасываются после устранения неясностей в проекте АИС, в подходе RAD каждый прототип передается будущей системе. Таким образом, на следующую фазу передается более полная и полезная информация.
На этапе построения осуществляется непосредственно сама быстрая подготовка приложения. При этом разработчики выполняют итеративное построение реальной АСУ на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется CASE-средствами автоматически. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять указанным ранее требованиям. Тестирование автоматизированной системы осуществляется в процессе разработки. После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование АИС в целом. Завершается физическое проектирование АИС, включающее: определение необходимости распределения данных; анализ использования данных; физическое проектирование базы данных; определение требований к аппаратным ресурсам и способов увеличения производительности, завершение разработки документации проекта. Результатом данного этапа является готовая автоматизированная система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения АИС производится обучение пользователей и вносятся организационные изменения. Для этого этапа характерно то, что одновременно с внедрением новой АС осуществляется работа с существующей системой управления до полного внедрения новой. Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки АИС не является окончательной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется создание АИС:
а) разрабатывается совершенно новая система;
б) было проведено обследование предприятия и существует модель его деятельности;
в) на предприятии уже существует АИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с вновь разрабатываемой системой управления.
2. АНАЛИЗ СУЩЕСТВУЮЩИХ СУБД И ВЫБОР НАИЛУЧШЕЙ
Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии “клиент-сервер”.
Paradox
Paradox был разработан компанией Ansa Software, и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Borland. С июля 1996 года он принадлежит компании Corel и является составной частью Corel Office Professional.
В конце 80-х - начале 90-х годов Paradox, принадлежавший тогда компании Borland International, был весьма популярной СУБД, в том числе и в нашей стране, где он одно время занимал устойчивые позиции на рынке средств разработки настольных приложений с базами данных.
Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase - каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).
Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.
Отметим, однако, что отсутствие формата данных имеет и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах - все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.
По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE - Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).
Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.
Текущая версия данной СУБД - Paradox 9, поставляется в двух вариантах - Paradox 9 Standalone Edition и Paradox 9 Developer's Edition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Corel Office Professional, второй - в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:
1. Средства манипуляции данными Paradox и dBase.
2. Средства создания форм, отчетов и приложений.
3. Средства визуального построения запросов.
4. Средства публикации данных и отчетов в Internet и создания Web-клиентов.
5. Corel Web-сервер.
6. ODBC-драйвер для доступа к данным формата Paradox из Windows-приложений.
7. Средства для доступа к данным формата Paradox из Java-приложений.
8. Помимо этого Paradox 9 Developer's Edition содержит:
9. Run-time-версию Paradox для поставки вместе с приложениями.
10. Средства создания дистрибутивов.
11. Драйверы SQL Links для доступа к данным серверных СУБД.
Delphi. Основные характеристики продукта.
Delphi - это комбинация нескольких важнейших технологий:
· Высокопроизводительный компилятор в машинный код
· Объектно-ориентированная модель компонент
· Визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов
· Масштабируемые средства для построения баз данных
Компилятор в машинный код
Компилятор, встроенный в Delphi , обеспечивает высокую производительность, необходимую для построения приложений в архитектуре “клиент-сервер”. Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).
В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде. В этом смысле проектирование в Delphi мало чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем то же самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения.
Объектно-ориентированная модель программных компонент
Основной упор этой модели в Delphi делается на максимальном реиспользовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi . Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые вы можете создать.
В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi , советуем, прежде чем попытаться начинать решать проблему “с нуля”, просмотреть список свободно распространяемых или коммерческих компонент, разработанных третьими фирмами, количество этих фирм в настоящее время превышает число 250.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать полную версию