Автоматизированное рабочее место заведующего складом торгового предприятия

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

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

КУРСОВОЙ ПРОЕКТ

по дисциплине «Проектирование АСОИиУ»

на тему «Автоматизированное рабочее место заведующего складом торгового предприятия»

Содержание

Введение

1. Введение в предметную область

1.1 Информационные технологии, метода, используемые при проектировании АСОИиУ

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

2. Технология проектирования

2.1 Техническое проектирование АСОИиУ на уровне рахработки общесистемных проектиных решений

2.2 Техническое проектирование АСОИиУ на уровне разработки локальных проектных решений

2.3 Инструментальные программные средства разработки АРМ заведующего складом торгового предприятия и их функциональные возможности

2.4 Проектирование информационной базы АРМ заведующего складом торгового предприятия на основе функциональных возможностей Microsoft Access

3. Рабочее проектирование системы

3.1 Разработка функциональных задач АРМ заведующего складом торгового предприятия на базе инструментально - программного средства Delphi

3.2 Разработка системы защиты информации АРМ от несанкционированного доступа

Заключение

Источники разработки

Приложения:

Приложение 1 - Список нормативных документы на проектирование, разработку и оформление АСОИиУ

Приложение 2 - Электронные формы документов торгового предприятия

Приложение 3 - Программный код АРМ заведующего складом торгового предприятия

1.Введение

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

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

Информатизация общества обеспечивает:

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

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

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

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

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

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

В настоящее время при растущем темпе информатизации общества стоит вопрос об автоматизации многих рутинных процессов с улучшением параметров хранения информации и её полноты.

К любому виду информации предъявляются требования: точность, достоверность, оперативность.

Точность информации обеспечивает ее однозначное восприятие всеми потребителями.

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

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

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

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

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

Информационные технологии, методы, используемые при проектировании АСОИиУ

Технология проектирования АСОИиУ - это совокупность методологий и средств проектирования АСОИиУ, а также методов и средств организации проектирования (управление процессом создания и модернизация проекта АСОИиУ), представленная на рисунке 1:

Рис. 1 Технология проектирования АСОИиУ

Проектирование - это процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом в проект АСОИиУ. С этой точки зрения проектирование АСОИиУ сводится к последовательной формализации проектных решений на различных стадиях жизненного цикла АСОИиУ.

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

Предметом любой выбираемой технологии проектирования должно являться отражение взаимосвязанных процессов проектирования на всех стадиях жизненного цикла АСОИиУ.

Методы проектирования АСОИиУ можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

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

Ручного проектирования, при котором проектирование АСОИиУ осуществляется без использования специальных инструментальных программных средств, а программирование осуществляется с помощью алгоритмических языков;

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

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

Оригинального (индивидуального) проектирования, когда проектные решения разрабатываются «с нуля», в соответствии с требованиями на проектирование АСОИиУ;

Типового проектирования, предполагающего конфигурацию АСОИиУ из готовых типовых проектных решений.

По степени адаптивности проектных решений методы проектирования классифицируются на методы:

Реконструкции, когда адаптация проектных решений выполняется путем перепрограммирования модулей системы;

Параметризации, когда проектные решения настраиваются в соответствии с измененными параметрами;

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

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

Каноническая технология;

Индустриальная технология.

Каноническая технология проектирования АСОИиУ отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей (разработчиков). Как правило, каноническое проектирование применяется для небольших локальных АСОИиУ.

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

Характеристика классов технологий проектирования представлена в таблице 1.

Таблица 1.

Класс технологии проектирования	Степень автоматизации	Степень типизации	Степень адаптивности
Каноническое проектирование	Ручное Проектирование	Оригинальное проектирование	Реконструкция
Индустриальное автоматизированное проектирование	Компьютерное проектирование	Оригинальное проектирование	Реструктуризация модели (генерация АСОИиУ)
Индустриальное типовое проектирование	Компьютерное проектирование	Типовое сборочное проектирование	Параметризация и реструктуризация модели (конфигурация АСОИиУ)

В основе канонического проектирования лежит каскадная модель жизненного цикла АСОИиУ.

Процесс каскадного проектирования строится на основе нормативного документа «Автоматизированные системы стадий создания», в котором проектирование систем по этой каскадной модели делится на 7 стадий:

Исследование и обоснование создания системы;

Разработка технического задания;

Создание эскизного проекта (для сложных систем);

Техническое проектирование;

Рабочее проектирование;

Ввод в действие;

Сопровождение, модернизация.

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

Рис. 2 Процесс канонического проектирования АСОИиУ

Основанием для проектирования АСОИиУ является предметная область.

В качестве предметной области по теме курсового проектирования дисциплины «Проектирование АСОИиУ» является склад торгового предприятия «Компакт», занимающегося поставками и реализацией мебели в лице заведующего складом.

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

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

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

Формирование и обработка информации по движению товара на складе;

Формирование и обработка информации по отчетной документации на приобретенный товар;

Формирование и обработка информации по учетной документации на наличие товара на складе;

Формирование, обработка и актуализация информации по прайс-листу;

Формирование и обработка информации по отчетной документации на списание товара со склада;

Формирование и обработка информации по документации на реализуемый товар.

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

наличным способом;

безналичным.

В рамках Курсового проекта по дисциплине «Проектирование АСОИиУ» разработано автоматизированное рабочее место заведующего складом торгового предприятия. Разработка системы выполнялась на базе канонической технологии проектирования, индивидуального метода, каскадной модели на модульной основе, на единой информационной базе с учетом нормативных документов на проектирование, разработку и оформление АРМ с реализацией функциональных задач системы.

Разработка АРМ по ее структурным составляющим разрабатывалась на основе инструментальных программных средств. Для информационной части была выбрана среда разработки профессиональных приложений MS Office Access для программной части системы - Borland Delphi 7.

2. Техническое пректирование АСОИиУ

2.1 Техническое проектирование АСОИиУ на уровне разработки общесистемных проектных решений

Техническое проектирование АСОИиУ входит во вторую стадию проектирования и является первым ее этапом.

Работы на этапе технического проектирования выполняются на основе согласованного и утвержденного ТЗ на проектирование и разработку АСОИиУ. На данном этапе разрабатываются две группы работ, это: разработка общесистемных проектных решений и разработка локальных проектных решений. Рассмотрим технологию выполнения работ в каждой группе технического проекта.

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

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

Список функций, выполняемых системой;

Описание интерфейса между системой и пользователем.

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

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

Проектирование форм входных и выходных документов, системы ведения документов и макетов экранных форм документов;

Проектирование состава и структур файловой информационной базы;

Проектирование технологии решения каждой задачи.

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

Характеристика задачи;

Описание выходной информации;

Описание входной информации.

Разработка функциональной спецификации задач АСОИиУ

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

Для определения функциональной архитектуры АСОИиУ наиболее принципиальной в группе разработки общесистемных проектных решений является разработка функциональной спецификации по задачам, которая должна определить какие функции должны выполняться для удовлетворения требований, выставленных в ТЗ на ВКР, и обеспечения интерфейса между системой и пользователем.

Рассмотрим перечень задач ТЗ по их функциональной спецификации:

1. Задача «формирование и обработка информации по движению товара на складе» осуществляет обработку информации по перемещению товара на складе, т. е. его приобретение, хранение, списание и т. д.;

2. Задача «формирование и обработка информации по отчетной документации на приобретение товара» выполняет формирование и обработку информации на приобретение товара у поставщиков по следующим параметрам: код товара, наименование, количество, поставщики, закупочная цена и т. д.;

3. Задача «формирование и обработка информации по учетной документации на наличие товара на складе» выполняет обработку учетной документации на наличие товара на складе;

4. Задача «формирование, обработка и актуализация информации по прайс-листу» выполняет формирование и обработку информации по актуализации прайс-листа за единицу времени;

5. Задача «формирование и обработка информации по отчетной документации на списание товара со склада» выполняет формирование и обработку информации по отчетной документации на списанный товар по следующим параметрам: код товара, наименование, количество, поставщики и цена;

6. Задача «формирование и обработка информации по заявке торгового отдела» выполняет формирование и обработку информации по заявкам клиентов, формируемых в торговом отделе;

7. Задача «анализ информации по заявке клиентов на основе прайс-листа» выполняет обработку клиентской заявки по прайс-листу, т. е. имеющемуся товару на складе;

8. Задача «формирование информации по выданным заявкам на приобретение товара» выполняет обработку информации по раннее созданной заявке от клиента и выдаче необходимого товара;

9. Задача «формирование информации по документации на получение товара со склада» выполняет обработку информации по получению товара со склада, т. е. выдается накладная для отгрузки товара со склада;

10. Задача «формирование и обработка информации по документации на реализуемый товар» выполняет обработку информации по документации на реализуемый товар;

11. Задача «формирование отчетной документации на реализованный товар за единицу времени» выполняет учет по реализуемым товарам и формирование, введение и обработку информации по отчетной документации на реализуемый товар по следующим параметрам: дата составления документа на реализуемый товар, дата реализации товара, наименование товара, количество, стоимость закупочная и цена реализации.

Разработка иерархического дерева АСОИиУ

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

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

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

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

Иерархическая структура состоит из модуля «Склад», который в свою очередь содержит перечень функциональных задач и процедур. На верхнем уровне Иерархического дерева расположен исполнительный модуль АРМ склада торгового предприятия «Компакт» (рис. 3).

Рис. 3 Иерархическое дерево АРМ заведующего складом торгового предприятия

2.2 Техническое проектирование АСОИиУ на уровне разработки локальных проектных решений

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

Характеристика задачи;

Описание выходной информации;

Описание входной информации.

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

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

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

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

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

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

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

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

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

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

Рис. 4 Специальные объекты - индексы

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

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

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

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

При любой модификации, добавлении или удалении записей СУБД автоматически обновляет как базовую таблицу, так и все индексы. Это замедляет операции, связанные с изменением таблиц. Чем больше индексов будет создано для таблицы, тем медленнее будут выполняться операции ее обновления. Индексы всегда создаются для внешних ключей и для полей, по которым часто проводится поиск.

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

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

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

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

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

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

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

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

Основные компоненты MS Access:

- построитель таблиц;

- построитель экранных форм;

-построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

- построитель отчётов, выводимых на печать.

Для запуска Microsoft Access выполняем команду: Пуск - Программы - Microsoft Oficce - MS Access (рис. 5).

Рис. 5 Запуск программы «Microsoft Access»

В качестве инструментального программного средства для разработки программных компонентов АСОИиУ по предприятию «Компакт» выбран современный инструментальный программный продукт Borland Delphi, позволяющий создавать широкий спектр приложений для среды Microsoft Windows.

Borland Delphi - это комбинация нескольких важнейших технологий:

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

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

визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;

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

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

В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде. В этом смысле проектирование в Delphi мало чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем то же самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения (Рис. 6).



Рис. 6 Классический вид главного меню системы Borland Delphi 7

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

Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL LINK, поэтому доступ к СУБД Oracle, Sybase, Informix и Interbase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние sql-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dbase или clipper) или .db (paradox). Если же он будет использовать локальный interbase for windows (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

Основные части среды Borland Delphi 7 и описание его компонентов изображены на рис. 7

Рис. 7 Среда Delphi 7 в деталях

2.4 Проектирование информационной базы АРМ заведующего складом торгового предприятия на основе функциональных возможностей Microsoft Access

Разработка БД для АРМ заведующего складом торгового предприятия на основе функциональных возможностей Microsoft Access сопровождалась выделением разных объектов и их атрибутов:

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

На логическом уровне БД содержит следующие поля, представленные в таблице 2:

Таблица 2

Кодовый номер
Товар
Материал
Количество
Цена
Страна производитель

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

Товар - комплектующие, поступившие на склад мебельного предприятия.

Материал - сырье, используемое при производстве товара.

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

Цена - цена одного комплекта изделия.

Страна производитель - страна, представляющая товар.

После определения логической структуры информационной базы переходим к следующему этапу разработки информационной базы - разработка физической структуры. Рассмотрим физическую структуру базы данных АСОИиУ «Компакт», представленную в таблице 3.

Таблица 3

Название таблицы	Имя поля	Тип данных поля
Таблица	Кодовый № Товар Материал Кол-во на складе Цена Страна производитель	Счетчик Текстовый Текстовый Числовой Числовой Текстовый

В таблице 3 представлена база данных с именами и типом данных полей.

При проектировании баз данных было выбрано 3 типа значений: Счетчик, Текстовый и Числовой.

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

Текстовый - числа, буквы, знаки пунктуации и символы, не более 255 (абзац среднего размера).

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

Для создания физической структуры базы данных выбрано инструментальное программное средство Microsoft Access. На основе алгоритма создания необходимо во вкладке «Файл» нажать на кнопку «Создать новую базу данных». Затем вписать в поле имя будущей базы данных (рис. 8).

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

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

Рис. 8 Создание физической модели базы данных.

Далее необходимо открыть конструктор таблиц, для чего в открывшемся окне (рис. 9) выбрать «Конструктор таблиц» .

Рис. 9 Открытие конструктора таблиц.

После запуска «Конструктора таблиц» откроется следующее окно, которое нужно заполнить данными соответствующей таблицы (рис. 10).

Рис. 10 Пустая форма таблицы.

Для заполнения таблицы необходимо перенести данные на форму в соответствующие поля через команды «CTRL+C» и «CTRL+V» (рис. 11).

Рис. 11 Таблица в режиме конструктора.

После нажатия «CTRL+S» созданная таблица с заданным именем будет сохранена в списки. При успешном выполнении всех операций получим готовую таблицу (рис. 12).

Рис. 12 Разработанная БД для торгового предприятия.

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

3.Рабочее проектирование системы

3.1 Разработка функциональных задач АРМ заведующего складом торгового предприятия на базе инструментального программного средства Delphi

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

Рассмотрим реализацию некоторых функциональных задач АРМ, в том числе:

Компоненты, включенные в главное меню системы:

unit Unit1;

interface;

uses.

Дадим перечень описанных компонентов для подключения:Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, Menus, DB, Grids, DBGrids, ADODB, jpeg, ExtCtrls;

type

TForm1 = class(TForm)

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

N11: TMenuItem;

DBGrid1: TDBGrid;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

Edit5: TEdit;

Button1: TButton;

MebelName: TADOTable;

ADOConnection1: TADOConnection;

DataSource1: TDataSource;

Image1: TImage;

MebelNameKod: TAutoIncField;

MebelNameTovar: TWideStringField;

MebelNameMaterial: TWideStringField;

MebelNameKolichestvo: TIntegerField;

MebelNameCena: TIntegerField;

MebelNameCountry: TWideStringField;

procedure Button1Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure N11Click(Sender: TObject);

procedure N9Click(Sender: TObject);

procedure N10Click(Sender: TObject);

procedure N2Click(Sender: TObject);

{элементы Delphi7 и используемые по наименованию процедуры}

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit4;

{подключение Unit2 и Unit4(форм поиска и диаграмм)}

{$R *.dfm}

Для подключения к базе данных АРМ и загрузке содержимого используем элементы ADOConnection, DataSource, DBGrid и ADOTable инструментального программного средства по следующему алгоритму:

1. Нажав два раза на ADOTable (MebelName), затем правой кнопкой мыши щелкнув, кликнем на New Field, заполнив данными:

MebelNameKod: TAutoIncField;

MebelNameTovar: TWideStringField;

MebelNameMaterial: TWideStringField;

MebelNameKolichestvo: TIntegerField;

MebelNameCena: TIntegerField;

MebelNameCountry: TWideStringField;

Получим таблицу, представленную на рисунке 13:

Рис.13. Элементы ADOTable.

2. В DataSource1 в Object Inspector свойства DataSet выбираем MebelName (рис. 14):

Рис. 14. Object Inspector элемента DataSource1.

3. В элементе DBGrid1 в Object Inspector свойства DataSource выбираем DataSource1 (рис. 15):

Рис. 15. Object Inspector элемента DBGrid1.

4. В ADOConnection щелкая два раза попадаем в новое меню, в котором выбираем Use Connection String (рис. 16):

Рис. 16. Компонент ADOConnection1.

5. В результате выполненных шагов, нажав на кнопку Build в Поставщике данных выбираем Microsoft Jet 4.0 OLE DB Provider (поставщик данных для MS Office Access) (рис.17):

Рис. 17. Свойства связи с данными компонента ADOConnection1 во вкладке Поставщик данных.

6. Далее переходим во вкладку Подключение и указываем путь и имя БД (рис. 18):

Рис. 18. Свойства связи с данными компонента ADOConnection1 во вкладке Подключение.

7. Затем нажимаем на кнопку Проверить подключение (рис. 19):

Рис. 19. Связь с данными БД.

8. После установки связи в Object Inspector компонента ADOConnection1 проставляем LoginPrompt -> False (рис. 20):



Рис. 20. Object Inspector элемента ADOConnection1.

9. В компоненте ADOTable в Object Inspector свойства Active устанавливаем True и получаем (рис. 21):

Рис. 21. Подключенная БД торгового предприятия.

Далее рассмотрим фрагмент программного кода для добавления, удаления и сохранения товара в БД, а также сортировку по различным параметрам:

procedure TForm1. N2Click (Sender: TObject); {добавление товара}

begin

Form1.MebelName.Insert;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[1].DisplayName)

.AsString := Self.Edit1.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[2].DisplayName)

.AsString := Self.Edit2.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[3].DisplayName)

.AsString := Self.Edit3.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[4].DisplayName)

.AsString := Self.Edit4.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[5].DisplayName)

.AsString := Self.Edit5.Text;

Form1.MebelName.Post;

end;

procedure TForm1.N3Click(Sender: TObject); {удаление товара}

begin

if MessageDlg ('Удалить запись?', mtConfirmation, [mbYes, mbNo], 0)

= mrNO then Abort;

Form1.MebelName.Delete;

end;

procedure TForm1.N4Click(Sender: TObject); {сохранение изменений}

begin

if MessageDlg ('Сохранить изменения?', mtConfirmation, [mbYes, mbNo], 0)

= mrNO then Abort;

if Form1.MebelName.Modified then

Form1.MebelName.Post;

end;

procedure TForm1.N6Click(Sender: TObject); {сортировка по цене}

begin

Form1.MebelName.IndexFieldNames:= 'MebelNameCena';

end;

procedure TForm1.N7Click(Sender: TObject); {сортировка по материалу}

begin

Form1.MebelName.IndexFieldNames:= 'MebelNameMaterial';

end;

procedure TForm1.N8Click(Sender: TObject); {сортировка по количеству}

begin

Form1.MebelName.IndexFieldNames:= 'MebelNameKolichestvo';

end;

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

1. Добавляем новую форму (рис. 22):

Рис. 22. Добавление новой формы.

2. В открытое пустое окно добавляем необходимые кнопки, формы для загрузки таблицы, поля для хранения текста и описания к ним из «Панели инструмента». На рис. 23 представлена главная форма системы и перечень компонет:

Рис. 23. Пустая форма системы и перечень компонет

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

Рис.24. Свойства формы системы.

4. В результате выполненных шагов по алгоритму получаем главную форму системы с реализацией функциональных задач (рис. 25):

Рис. 25. Главная форма системы с ее функциональными задачами.

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

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

procedure TForm1.Button1Click(Sender: TObject); {добавление товара}

begin

Form1.MebelName.Insert;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[1].DisplayName)

.AsString := Self.Edit1.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[2].DisplayName)

.AsString := Self.Edit2.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[3].DisplayName)

.AsString := Self.Edit3.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[4].DisplayName)

.AsString := Self.Edit4.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[5].DisplayName)

.AsString := Self.Edit5.Text;

Form1.MebelName.Post;

end;

Оформление форм выполняются аналогично предыдущему описанию алгоритма. В результате, получаем формы, представленные на рисунке 26 по 32.

Главная форма системы позволяет добавлять товары, редактировать, удалять и сохранять все изменения в БД. Также можно отсортировать, имеющиеся данные по цене, материалу и количеству (рис. 26):

Рис. 26. Главная форма системы.

Рис. 27. Элементы меню «Файл».

Рис. 28. Элементы меню «Сортировка».

Полученная форма, представленная на рис. 29 позволит выполнить поиск по трем категориям: товар, материал и страна производитель.

Рис. 29. Форма Поиска системы.

Рис. 30. Окно поиска по товару.

3.2 Разработка системы защиты информации АРМ от несанкционированного доступа

информационный база склад

Большое внимание в настоящее время уделяется вопросам формирования принципов построения механизмов защиты информации (ЗИ). Дадим перечень общих требований к принципам построения механизма защиты информации:

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

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

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

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

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

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

Рассмотрим реализацию защиты информации АРМ по торговому предприятию. На рисунке 31 представлена созданная форма защиты информации от несанкционированного доступа.

Рис. 31. Форма ЗИ от несанкционированного доступа к системе.

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

unit Unit3;

interface

uses

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

Dialogs, StdCtrls, jpeg, ExtCtrls;

type

TForm3 = class(TForm)

Edit1: TEdit;

Edit2: TEdit;

Label1: TLabel;

Button1: TButton;

Label2: TLabel;

Label3: TLabel;

Button2: TButton;

procedure Button1Click(Sender: TObject);

procedure Button2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form3: TForm3;

implementation

uses Unit1, Unit2;

{Подключение Unit1 - Главной формы системы и Unit2 - Формы поиска системы}

{$R *.dfm}

procedure TForm3.Button1Click(Sender: TObject);

var

a, s: string;

begin

a:='tigran'; {Логин программы}

s:='21081992'; {Пароль программы}

if (Edit1.Text=a) and (Edit2.Text=s) then begin

form3.Hide;

form1.Show;

end

else showmessage('Неверно введены логин и пароль! Повторите ввод!');

end;

procedure TForm3.Button2Click(Sender: TObject);

begin

Close(); {закрытие программы}

end;

end.

Если логин и пароль введены правильно, то выполняется загрузка системы (рис. 32):

Рис. 32. Ввод логина и пароль.



Рис. 33. Вход в систему.

Чтобы не отображались поля Пароль в Object Inspector в свойстве PasswordChar выставим символ # (рис. 34):

Рис. 34. Object Inspector компонента Edit.

Получим окончательную форму защиты информации АСОИиУ от несанкционированного доступа, представленную на рис. 35:

Рис. 35. Форма ЗИ от несанкционированного доступа.

Если логин или пароль набран неверно, то выводится сообщение, представленное на рис. 36:

Рис. 36. Сообщение о неверном вводе логина или пароля.

Заключение

В рамках курсового проекта по дисциплине «Проектирование АСОИиУ» на основании задания было спроектировано и разработано Автоматизированное рабочее место заведующего складом торгового предприятия по технологии, методам и инструментально-программным средствам, изученным по дисциплине. При проектировании системы была использована каноническая технология индивидуального (оригинального) метода проектирования, по каскадной модели на модульной основе с использованием единой информационной базы. При разработке и оформлении АРМ были использованы нормативные документы на проектирование, разработку и оформление, указанные в приложении 1. Проектирование АРМ для торгового предприятия позволило получить и закрепить практические навыки проведения работ на важнейших стадиях создания АСОИиУ для более успешного осуществления инженерной деятельности по избранной специальности.

Источники разработки

Г.Н. Смирнова и др., под редакцией Ю.Ф. Тельнова. Проектирование экономических информационных систем. М.: Финансы и статистика, 2001г.

А.М. Вендров. Проектирование программного обеспечения АСОИиУ. Учебник, М.: Финансы и статистика, 2000 г.

В. Л. Кучеренко - Тонкости программирования на Delphi. - М.: «Познавательная книга плюс», 2000

М.В. Сухарев. Основы Delphi: профессиональный подход. СПб.:Наука и техника, 2004 г.

Рудинский И.Д. Технология проектирования автоматизированных систем обработки информации и управления. Учебное пособие для ВУЗов.- М.: Горячая линия - Телеком, 2011. 304с. (наличие количества экземпляров в библиотеке КБГУ- 0 экз.).

Ю. Бакаревич. Access 2010. Год издания 2011. Издательство: БХВ-Петербург. Серия: Самоучитель.

Э.Л. Тамбиева. Лекционный курс; лабораторный практикум; практическая работа по дисциплине “Проектирование АСОИиУ” - электронный ресурс.

Приложение 1

Список нормативных документы на проектирование, разработку и оформление АСОИиУ

Вид докумен-тации	Тип/название документа	Государственный Стандарт
Пред-проектная	1. Отчет по обследованию 2. Технико-экономическое обоснование 3. Техническое задание 4. Договорная документация	ГОСТ 7.32, ГОСТ 7.1-2003, ГОСТ 7.82-2001 -//- ГОСТ 34. 602 ГОСТ Р 6.30-2003
Проектная		ГОСТ 24.104-85, ГОСТ 24.301-80, ГОСТ 24.302-80, ГОСТ 24.303-80, ГОСТ 24.304-82, ГОСТ 19.701-90, ГОСТ 2.004-88, ГОСТ 2.051-2006, ГОСТ 2.104-2006, ГОСТ 2.105-95, ГОСТ 2.106-96, ГОСТ 2.109-73, ГОСТ 7.1-2003, ГОСТ 7.82-2001, ГОСТ 7.83-2001
Рабочая	1. Программная 2. Прочая	ГОСТ 19.103-77, ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78, ГОСТ 19.701-90, ГОСТ 2.051-2006, ГОСТ 7.83-2001 ГОСТ 24.104-85, ГОСТ 24.301-80, ГОСТ 19.701-90, ГОСТ 2.004-88, ГОСТ 2.051-2006, ГОСТ 2.104-2006, ГОСТ 2.105-95, ГОСТ 2.106-96, ГОСТ 7.1-2003, ГОСТ 7.82-2001, ГОСТ 7.83-2001
Эксплуатации-онная	1. Эксплуатация КТС 2. Прочая	ГОСТ 2.610-2006, ГОСТ 7.83-2001 ГОСТ 24.104-85, ГОСТ 24.301-80, ГОСТ 19.701-90, ГОСТ 2.004-88, ГОСТ 2.051-2006, ГОСТ 2.104-2006, ГОСТ 2.105-95, ГОСТ 2.106-96, ГОСТ 7.1-2003, ГОСТ 7.82-2001, ГОСТ 7.83-2001ГОСТ Р 6.30-2003

Приложение 2

Формы документов торгового предприятия

Накладная на закупку товара отделом «Склад».

НАКЛАДНАЯ № _____________

от «____»___________________20 г.

№	Наименование товара	Ед. изм.	Кол-во	Цена	Сумма
ИТОГО:

Сумма прописью__________________________________

Отпустил _______________________ Получил ______________

(ФИО) (ФИО)

Бланк заказа на приобретение товара отделом «Склад».

ЗАКАЗ

на приобретение товара

« »_________________ 200 г.

от _________________________________

(ФИО заказчика)

№	Наименование товара	Кол-во	Сумма
1
2
3
4
5
6
7
ИТОГО:

Принял_________________________ _________________________

(ФИО) (подпись)

Приложение 3

Программный код АРМ заведующего складом торгового предприятия

unit Unit1;

interface

uses

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

Dialogs, StdCtrls, Menus, DB, Grids, DBGrids, ADODB, jpeg, ExtCtrls;

type

TForm1 = class(TForm)

MainMenu1: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

N10: TMenuItem;

N11: TMenuItem;

DBGrid1: TDBGrid;

Label1: TLabel;

Label2: TLabel;

Label3: TLabel;

Label4: TLabel;

Label5: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Edit3: TEdit;

Edit4: TEdit;

Edit5: TEdit;

Button1: TButton;

MebelName: TADOTable;

ADOConnection1: TADOConnection;

DataSource1: TDataSource;

Image1: TImage;

MebelNameKod: TAutoIncField;

MebelNameTovar: TWideStringField;

MebelNameMaterial: TWideStringField;

MebelNameKolichestvo: TIntegerField;

MebelNameCena: TIntegerField;

MebelNameCountry: TWideStringField;

procedure Button1Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N4Click(Sender: TObject);

procedure N6Click(Sender: TObject);

procedure N7Click(Sender: TObject);

procedure N8Click(Sender: TObject);

procedure N11Click(Sender: TObject);

procedure N9Click(Sender: TObject);

procedure N10Click(Sender: TObject);

procedure N2Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1;

implementation

uses Unit2, Unit4; (подключение Unit2 и Unit4)

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject); {добавление товара}

begin

Form1.MebelName.Insert;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[1].DisplayName)

.AsString := Self.Edit1.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[2].DisplayName)

.AsString := Self.Edit2.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[3].DisplayName)

.AsString := Self.Edit3.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[4].DisplayName)

.AsString := Self.Edit4.Text;

Form1.MebelName.FieldByName(DBGrid1.Columns.Items[5].DisplayName)

.AsString := Self.Edit5.Text;

Form1.MebelName.Post;

end;

procedure TForm1.N3Click(Sender: TObject); {удаление товара}