Материал: Создание автоматизированного рабочего места менеджера компьютерного магазина

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

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

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

.1 Состав выполняемых функций

Автоматизированная информационная система должна разрешить следующие основные проблемы:

учет материальных запасов;

учет денежных средств, полученных от реализации товаров;

сокращение времени формирования отчетов;

упорядоченность документооборота;

экономия времени на обслуживание клиентов.

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

учет сотрудников;

учет клиентов;

учет товаров и услуг;

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

пополнение базы данных в связи с поступлением новой техники;

составление отчетов по имеющейся и по отсутствующей на данный момент техники;

составление отчетов по объему продаж по датам и месяцам;

составление отчетов по счетам.

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

формирование ценников;

формирование счета;

формирование товарного чека.

3.2 Требования к составу и параметрам технических средств

Технические требования к аппаратному обеспечению автоматизированного рабочего места определяются минимальными требованиями платформы 1С: Предприятие 8.2:

Частота процессора не ниже 400 МГц;

ОЗУ не менее 128 Мб;

Минимальный объем дискового пространства 500 Мб;

Наличие сетевой платы и принтера.

Требованию к программному обеспечению АРМ:

ОС семейства Windows’98/XP;

ПО «1С: Предприятие 8.2», Конфигурация «1С: Бухгалтерский учет 7.7»; алгоритм автоматизация магазин

Требование к серверу БД:

Частота процессора не ниже 1,5 ГГц;

Объем ОП не менее 512 Мб;

         Минимальный объем дискового пространства 2 Гб;

Наличие сетевой платы;

ОС семейства Windows Server 2000-2003.

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

В предлагаемой методологии весь процесс проектирования базы данных подразделяется на три этапа:

Концептуальное проектирование.

Логическое проектирование.

Физическое проектирование.

Этапы проектирования базы данных представлены на рисунке 2.

Рис. 2 Этапы проектирования базы данных

4. Стадия проектирования

.1 Построение инфологической модели данных

Логическая и физическая модель данных

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

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

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). Первым этапом проектирования данных является создание независимой от конкретной СУБД логической модели. Создание модели сводится просто к выбору соответствующих символов на палитре и добавлению их на рабочее пространство. Дополнительная информация по каждому объекту вводится посредством семейства редакторов. Как только две сущности связываются между собой связью, первичный ключ (ПК) автоматически перемещается из родительской сущности в дочернюю.

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

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

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

Логическая модель базы данных изображена на рисунке 3.

Рисунок 3 - Логическая модель данных

.2 Даталогическая модель данных

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

Таблица 1 - Структура таблицы «Сотрудники»

Таблица 2 - Структура таблицы «ПоступлениеТовара»

Таблица 3 - Структура таблицы «Реализация товара»

Структура нормативно-справочной информации

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

Таблица 5 - Структура таблицы «Номенклатура»

Таблица 6 - Структура таблицы «Поставщик»

Таблица 7 - Структура таблицы «Поставщик»

Структура выходной информации

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

заявки от покупателей:

товар;

количество;

поставщик;

заявки поставщику:

товар;

количество;

дата заявки;

чек покупателю:

дата покупки,

товар,

количество товара,

цена.

.3 Реляционная модель данных

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

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

Рисунок 4 - Реляционная модель данных

Проверка возможности сохранения

Процедура ПоКнОк()

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

Если Проведен() = 0 Тогда

Если (ПустоеЗначение(Поставщик) = 1) Тогда

Предупреждение («Не выбран поставщик!»);

Если (ПустоеЗначение(Товар.Название) = 1) Тогда

Предупреждение («Не выбран товар!»);

Возврат;

КонецЕсли;

Создаем переменную-объект ККР, в которой будем хранить информацию о заказе, которому оказывается эта работа.

ККР = СоздатьОбъект («Документ.ПриходТовара»);

Находим элемент из справочника Оборудование по названию. В случае успешного нахождения присваиваем в параметр Клиент данные о текущем поставщике.

Если ККР. НайтиЭлемент(Наименование) = 1 Тогда

ККР. Клиент = Поставщик.Название;

После выполнения присвоения этих значений записываем эти данные в нашу базу. ККР. Записать();

В случае не нахождения оборудования с указанным названием (когда ККР.

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

Иначе

Предупреждение («Оборудование с названием «+Наименование+» не найдено!»);

Возврат;

КонецЕсли;

Записываем информацию об операции в базу данных.

Записать();

КонецЕсли;

Закрываем форму и указываем окончание процедуры.

Форма. Закрыть(0);    

КонецПроцедуры

Печать квитанции

Процедура ПоКнКвитанция()

Создаем объект таблица Таб.

Таб = СоздатьОбъект («Таблица»);

Таб. ИсходнаяТаблица («Таблица1»);

Таб. ВывестиСекцию («Секция_2»);

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

Если ВыпТО = 1 Тогда

Таб. ВывестиСекцию («Секция_3»);

Создаем переменную ДЗ, в которую получаем значения текущего документа.

ДЗ = СоздатьОбъект («Документ»);

ДЗ. ВыбратьПодчиненныеДокументы (ТекущийДокумент());

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

Если ДЗ. ПолучитьДокумент() = 1 Тогда       

ДЗ. ВыбратьСтроки();

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

Пока ДЗ. ПолучитьСтроку() = 1 Цикл

Ном1 = ДЗ. НомерСтроки;

ЗИП = ДЗ.ЗИП;

ЕдИзм = ДЗ. ЕдИзм;

Количество = ДЗ. Количество;

Таб. ВывестиСекцию («Секция_4»);

КонецЦикла;

КонецЕсли;

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

ВыбратьСтроки();

Пока ПолучитьСтроку() = 1 Цикл

Ном2 = НомерСтроки;

Таб. ВывестиСекцию («Секция_6»);

КонецЦикла;      

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

ИначеЕсли ВыпТО = 2 Тогда

Таб. ВывестиСекцию («Секция_8»);

КонецЕсли;

Устанавливаем значения для созданной таблицы и параметр просмотра «только для чтения». В заголовок таблицы указываем «Квитанция о приходе товара».

Таб. Опции (0,0,0,0);

Таб. ТолькоПросмотр(1);

Таб. Показать («Квитанция о приходе товара», "»);

КонецПроцедуры

5. Программная реализация проекта

.1 Выбор среды программирования

В качестве средства программирования для автоматизации сервисного центра была выбрана система «1С: Предприятие». Это специализированная объектно-ориентированная система управления базами данных (СУБД), предназначенная для автоматизации деятельности предприятия.

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