Разработка клиент-сервеной программы «Магазин»

Создано admin . Опубликовано в Для диплома

dev

Если Вам нужна для ознакомления полная версия проекта с исходниками, презентациями, выступлениями и т.д., то пишитеigwt@mail.ru. Проект (диплом) предоставляется только по взаимовыгодным условиям, которые обсуждаются индивидуально. Это может быть например: совместная работа над этим сайтом, участие в написании контента для сайта, разработка для этого проекта модулей, плагинов и.д. (всего, что приведет к продвижению или улучшению проекта). А также готовы выслушать ваши предложения.

 

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

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

 

Анализ и моделирование требований с использованием UML

 

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

Унифицированный язык моделирования UML (Unified Modeling Language) представляет сбой язык для определения, представления и документирования программных систем, организационно-экономических систем, технических систем и других систем различной породы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов:

—      диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов и требований к создаваемой системе;

—      диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

—      диаграммы поведения системы;

—      диаграммы реализации.

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

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

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

Распишем теперь подробнее основной поток событий.

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

Безымянный

Рисунок 2 — Диаграмма вариантов использования

Основной поток событий.

1)    Вариант использования начинается, когда менеджер получает информацию о достижении уровня минимума в отделе;

2)    Менеджер контролирует заказ товара на складе. Если товара нет, выполняется  альтернативный поток А1;

3)    Менеджер осуществляет контроль по доставке товара в отдел;

4)    Вариант использования заканчивается;

Альтернативный поток событий А1.

1)    Поток событий начинается, если товара нет на складе;

2)    Менеджер заполняет заказ на поставку необходимого товара;

3)    Менеджер исправляет коэффициент спроса на данный товар;

4)    Вариант использования заканчивается.

Диаграмма данного варианта использования, выполненная в пакете Rational Rose, показана на рисунке 2, диаграмма состояний на рисунке 3

Безымянный

Рисунок 3 — Диаграмма состояний

Анализ и моделирование требований с использованием BPWin

 

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

— с точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой;

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

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

Безымянный

Рисунок 4 — Контекстная диаграмма магазина

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

—      стрелки входа (входят в левую грань работы) – изображают данные или объекты, изменяемые в ходе выполнения работы;

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

—      стрелки выхода (выходят из правой грани работы) – изображают данные или объекты, появляющиеся в результате выполнения работы;

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

—      стрелки вызова (выходят из нижней грани работы) – изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму.

Безымянный

Рисунок 5 — Декомпозиция магазина

Безымянный

Рисунок 6 — Декомпозиция  Планирование и анализ деятельности

На рисунке 6 можно более подробно рассмотреть планирование и анализ деятельности с ее входными и выходными потоками.

На рисунке 7 рассматривается Воспроизводство ресурсов: инструмента и персонала. Необходимая нам информация это сведения об оборудовании и сведения о рынке труда Законодательство определяет правила и регламент процессов предприятия.

Безымянный

Рисунок 7 —  Декомпозиция  Воспроизводство ресурсов

Безымянный

Рисунок 8 —  Декомпозиция  Продвижение и продажи

Что же касается продвижения и продаж, то этот этап рассмотрен на рисунке 8

Здесь основой являются сведения о потенциальных потребителях.  На основе этих требований инициируются проекты по привлечению потребителей.

Безымянный

Рисунок 9 —  Декомпозиция  Мониторинг изменения и улучшения

На рисунке 9 изображена детальная схема мониторинга изменения и улучшения. Основными управляющими потоками является «Информация о проекте» и «Записи по качеству». «Информация о проекте» включает в себя всю информацию о проектах по увеличению продаж и продвижению товара. «Записи по качеству» определяют каким качеством обладает продукт.

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

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

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

Рассмотрим процесс заказа клиентом товара в магазине на рисунке 10

Безымянный

Рисунок 10 — Заказ товара IDEF3

 

Архитектурное проектирование

 

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

Архитектура «Файл-Сервер». Эта архитектура централизованных баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы централизованной базы данных. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных. Серверную часть таких систем называют «тонким» сервером, клиентскую часть – «толстым» клиентом.

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

Безымянный

Рисунок 11 — Диаграмма размещения АРМ менеджера

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

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

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

 

Информационная модель системы

 

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

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

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

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

Инфологическое проектирование, прежде всего, связано с проблемой представления семантики предметной области в модели базы данных. Решение проблемы моделирования возможно при использовании  различных CASE- средств, таких как BPwin и  Erwin. Инфологическая модель разработанной системы спроектирована с помощью CASE- средства  Erwin и представлена на рисунке 5.

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

С помощью сущности моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в систе­ме существует множество экземпляров данной сущности. Основное правило при создании таблиц сущностей – это «каждой сущности – отдельную таблицу».

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

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

В зависимости от степени связи различают следующие ее виды: Один-к-одному (1:1); Один-ко-многим (1:М); Многие-к-одному (М:1); Многие-ко-многим (M:N). Связь вида 1:1 образуется в случае, когда все поля связи основной и дополнительной таблиц являются ключевыми. Связь вида 1:М имеет место в случае, когда одной записи основной таблицы соответствует несколько записей вспомогательной таблицы. Связь вида М:N возникает в случаях, когда нескольким записям основной таблицы, соответствует несколько записей дополнительной таблицы.

Безымянный

Рисунок 12 —  Инфологическая модель ЭИС

Проектирование пользовательского интерфейса

 

Менеджер, как пользователь системы, будет выполнять действия, показанные на рисунке 2. Для каждого из вариантов использования (кроме «Первичного контакта и повторного контакта») необходимо создать свою форму в приложении. Поэтому диаграмма пользовательского интерфейса будет иметь вид, показанный на рисунке 13.

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

Для взаимодействия пользователя и системы выбрана фразовая форма диалога. Диалог ведется на естественном языке и использует односложные ответы.

Интерфейс, реализующий данный диалог выполняет следующие функции:

—      взаимное преобразование сообщений из естественной формы во внутреннюю и наоборот;

—      анализ сообщений пользователей;

—      синтез сообщений системы;

—      отслеживание и запоминание пройденной части диалога.

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

Для взаимодействия пользователя и системы выбрана фразовая форма диалога. Диалог ведется на естественном языке и использует односложные ответы.

Безымянный

Рисунок 13 — Диаграмма пользовательского интерфейса

Интерфейс, реализующий данный диалог выполняет следующие функции:

—      взаимное преобразование сообщений из естественной формы во внутреннюю и наоборот;

—      анализ сообщений пользователей;

—      синтез сообщений системы;

—      отслеживание и запоминание пройденной части диалога.

Достоинством этой формы диалога является относительно свободное общение с системой.

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

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

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

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

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

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

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

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

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

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

Реализация пользовательского интерфейса

 

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

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

Рассмотрим программу «Магазин», которая представлена на рисунке 14 и предназначена для осуществления операций по отделу. Основной задачей данной программы является учет товара, его продажа и пополнение запаса.

Безымянный

Рисунок 14 – Внешний вид формы программы «Магазин»

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

Информация о фирме представлена в отдельной форме (рисунок 15). Информацию также можно редактировать.

Безымянный

Рисунок 15 – Внешний вид формы «Информация о фирме»

Формы, служащие для слежения за складом и совершением операций по нему представлены на рисунке 16 и рисунке 17 формы «типы продуктов» и «список продуктов» на рисунке 16 предназначены для хранения товара на складе.

Безымянный

Рисунок 16 – Внешний вид формы «Склад-операции»

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

На рисунке 17 представлен «Список поставщиков», где располагается информация о поставщиках. При нажатии на кнопку «Накладная прихода товара»  автоматически формируется накладная. Каждому поставщику соответствует определенный список поставляемых товаров.

Безымянный

Рисунок 17 – Внешний вид формы «Склад-состояние»

Безымянный

Рисунок 18 – Внешний вид формы «Прогнозирование»

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

Форма «Прогнозирование» представлена на рисунке 18 форма позволяет спрогнозировать продажи как каждого, отдельно взятого, продукта, так и всех продуктов. Также необходимо выбрать период, частоту выборки и метод прогноза. Для начала работы необходимо подключиться к серверу данных. Для этого необходимо нажать Соединение -> подключиться. В появившемся меню необходимо выбрать сервер.

Спрогнозировать данная форма позволяет тремя методами: тенденция временного ряда, сезонная компонента и многофакторная модель.

Рассмотрим подробнее каждую из них. На рисунке 19 представлена форма «Тенденция временного ряда».

Безымянный

Рисунок 19 – Внешний вид формы «Тенденция временного ряда»

Прогноз можно построить с использованием скользящих средних или построив тренд. Также для изучения деталей метода прогнозирования в Microsoft Excel необходимо нажать на кнопку «Переместить в Excel». На рисунке 20 представлена форма «Сезонная компонента». Для каждого вида товара устанавливается коэффициент изменения объема в зависимости от среднего показателя прошлых лет. На его основе строится прогноз.

Безымянный

Рисунок 20 – Внешний вид формы «Сезонная компонента»

Безымянный

Рисунок 21 – Внешний вид формы «Многофакторная модель»

На рисунке 21 представлена форма «Многофакторная модель». Сущность метода сводится к удалению несущественно влияющих факторов на прогнозное значение. После удаления этих факторов нажимаем на кнопку «прогноз»  и переходим к форме «Многофакторная модель — построение прогноза» представленной на  рисунке 22. Здесь необходимо ввести значения факторов и нажать кнопку «Произвести прогноз»

Безымянный

Рисунок 22 – Внешний вид формы «Многофакторная модель — построение прогноза»

Если Вам нужна для ознакомления полная версия проекта с исходниками, презентациями, выступлениями и т.д., то пишитеigwt@mail.ru. Проект (диплом) предоставляется только по взаимовыгодным условиям, которые обсуждаются индивидуально. Это может быть например: совместная работа над этим сайтом, участие в написании контента для сайта, разработка для этого проекта модулей, плагинов и.д. (всего, что приведет к продвижению или улучшению проекта). А также готовы выслушать ваши предложения.

С ув. Эдуард Тихонов.

Похожие материалы:

Понравилась статья? - поделитесь ею со своими друзьями!

Хотите Быть В Курсе Всех Новинок Сайта?!

Подпишитесь прямо сейчас, и получайте обновления на свой E-Mail:

Ваш E-Mail в безопасности

Есть что сказать? - Комментируй!

Комментарии Facebook

А Вы что думаете?