Разработка информационной системы "Оптовая база"

Разработка информационной системы "Оптовая база"

Рассматриваемая дипломная работа написана на базе Донецкой ОАО Донецкая мануфактура для магазина Cleonelly.

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

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

Предприятия, занимающиеся проектированием и разработкой устройств различного назначения, в настоящее время широко используют различные средства как автоматизированного проектирования - САПР (CAD), так и мониторинга производственных процессов - АСУТП (SCADA/DCS). Однако для устройств собственной разработки необходимо разрабатывать собственные средства контроля их работоспособности и анализа качества продукции.

Технологический процесс учета продукции на складе в магазине Cleanelly включает этап ведение учетности продаваемой продукции.

Целью настоящего дипломного проекта является реализация автоматизированного рабочего места (АРМ) позволяющего осуществить учет продукции на складе магазина.

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

ѕ провести анализ бизнес-процессов магазина;

ѕ исследовать информационные потоки, возникающие на этапе сдачи разрабатываемого изделия;

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

ѕ разработать программное обеспечение для АРМ учета продукции

ѕ провести оценку экономической эффективности информационной системы.

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

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

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

К основным преимуществам моей системы Оптовая База можно отнести относительную низкую стоимость внедрения данной системы ,а также еще ряд преимуществ:

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

ѕ Удобство пользования интерфейсом;

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

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

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE - средство верхнего уровня All Fusion Process Modeler (BPwin), поддерживающие методологии IDEF0 (функциональная модель), DFD (Dataflow Diagram) и IDEF3 (Workflow Diagram). BPwin является мощным программным продуктом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство, для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. [24]

С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм, т.е. единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействие с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая система описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее для достижения нужной степени подробности. [26]

Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию DFD или IDEF3. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями. [26]

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

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

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

В основе методологии IDEF0 лежат четыре основных понятия.

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

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

- верхняя сторона имеет значение «Управления» (Control);

- левая сторона имеет значение «Вход» (Input);

- правая сторона имеет значение «Выход» (Output);

- нижняя сторона имеет значение «Механизм» (Mechanism).

Вторым «китом» методологии IDEF0 является понятие интерфейсной дуги (Arrow). Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое наименование (Arrow Label). С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на:

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

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

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

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

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции.

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

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

Рассмотрим диаграммы бизнес-процессов протекающие на складе магазина ОАО ДММ, «Cleonelly»:

Для общей видимости системы необходимо построить контекст «Деятельность склада предприятия» (смотри рисунок 1.1).

Рисунок 1.1 - Диаграмма «Деятельность склада предприятия»

После того как контекст установлен, проводится декомпозиция, т.е. построение следующих диаграмм в иерархии.

Каждая последующая диаграмма является более подробным описанием одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на рисунке 1.2. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, данная система разбивается на три уровня.

Рисунок 1.2 - Диаграммы декомпозиции первого уровня

Далее каждый из блоков декомпозиции системы будет еще разбиваться, декомпозиция «Оформление товара» можно увидеть на рисунке 1.3, «Отпуск товара» - рисунок 1.4, «Оприходывание товара» - рисунок 1.5.

Рисунок 1.3 - Диаграмма «Оформление товара»

Рисунок 1.4 - Диаграмма «Отпуск товара»

Рисунок 1.5 - Диаграмма «Оприходывание товара»

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

Основными компонентами диаграммы потоков данных являются:

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

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

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

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

Рассмотрим диаграмму потоков данных (DFD) «Отпуск товара» рисунок 1.6. На этой диаграмме показано движение документов при поступлении в организацию «заявки на товар».

Рисунок 1.6 - Диаграмма DFD «Отпуск товара»

Рассмотрим следующую диаграмму потоков данных «Оформление товара» (смотри рисунок 1.7). Здесь показано процесс выполнения работ и движение документов при «отпуске товара».

Рисунок 1.7 - Диаграмма DFD «Оформление товара»

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

Организационная структура предприятия, занимающегося продажей махровых изделий, рассмотрена на примере компании ОАО “Донецкая Мануфактура М” магазина Cleonelly:

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

1. Это контроль за поставляемыми и хранящимися на складе товарами.

2. Информацию о поставщиках и потребителях

3. Также содержится информация информация и операции по товару

4. Содержится журнал отчета отпущенного товара

5. Содержится справочник товаров

6. Автоматизация складских функций (приход, расход, списание, резервирование товара)

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

8. Создание накладных и учет выданного товара

9. Проведение инвентаризации складов с созданием сличительной ведомости, акта недостачи и излишек

10. Создание комплектов товаров

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

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

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

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

ѕ документирование результатов.

ѕ сохранить данные в базе;

ѕ рассчитать количество материала на складе;

ѕ Информационная система должна быть реализована как программа на базе интегрированной среды Visual Fox Pro.

Работа программы осуществляется в операционной системе Windows 2000/NT/XP.

Различают четыре основных этапа процесса разработки требований (рисунок 1.8):

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

- формирование и анализ требований;

- специфицирование требований и создание соответствующей документации;

- аттестация требований.

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

Определение корректных требований -- это, наверное, самый ответственный этап программного проекта. Очень важно, чтобы формат проекта соответствовал требованиям к ПО, собранным командой разработчиков, в противном случае эти требования не смогут быть поддержаны и представлены в программном продукте. Спецификация требований к ПО - Software Requirements Specification(SRS) имеет ключевое значение для всего жизненного цикла разработки программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний. Аттестация -- это оценка качества работы менеджеров проекта. Она определяет степень соответствия программного продукта установленным требованиям. Спецификация SRS выступает в роли некоего механизма фиксирования системных требований, которые используются в качестве критериев при аттестации .

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

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

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

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

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

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

Спецификация SRS служит основой для модернизации. В этом документе рассматривается сам продукт, а не процесс разработки проекта, поэтому на ее основании можно производить расширение завершенного продукта.

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

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

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

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

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

Проверка на непротиворечивость.

Проверка на полноту.

Проверка на выполнимость.

Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности:

Обзор требований.

Прототипирование.

Генерация тестовых сценариев.

Автоматизированный анализ непротиворечивости.

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

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

Следующим шагом аттестации требований является непосредственное создание прототипов.

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

Прототип основного меню данного модуля представлен на рисунке 1.9.

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

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

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

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

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

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

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

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

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

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

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

ѕ направленность на миссии организации;

ѕ направленность на требованиях;

ѕ направленность на разработке;

ѕ возможность к адаптации;

ѕ необходимость гибкости.

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

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

ѕ файл-серверная;

ѕ клиент-серверная;

ѕ многоуровневая.

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

Клиент-сервер. В основе этой концепции лежит идея о том, что помимо хранения файлов базы данных, центральный сервер должен выполнять основную часть обработки данных. Пользователи обращаются к центральному серверу с помощью специального языка структурированных запросов (SQL, Structured Query Language), на котором описывается список задач, выполняемых сервером. Запросы пользователей принимаются сервером и порождают в нем процессы обработки данных. В ответ пользователь получает уже обработанный набор данных. Между клиентом и сервером передается не весь набор данных, как это происходит в технологии файл-сервер, а только данные, которые необходимы клиенту. Запрос пользователя длиной всего в несколько строк способен породить процесс обработки данных, затрагивающий множество таблиц и миллионы строк. В ответ клиент может получить лишь несколько чисел. Технология клиент-сервер позволяет избежать передачи по сети огромных объемов информации, переложив всю обработку данных на центральный сервер. Кроме того, рассматриваемый подход позволяет избежать конфликтов изменений одних и тех же данных множеством пользователей, которые характерны для технологии файл-сервер. Технология клиент-сервер реализует согласованное изменение данных множеством клиентов, обеспечивая автоматическое соблюдение целостности данных. Эти и некоторые другие преимущества сделали технологию клиент-сервер очень популярной. К недостаткам этой технологии можно отнести высокие требования к производительности центрального сервера. Чем больше клиентов обращается к серверу, и чем больше объем обрабатываемых данных, тем более мощным должен быть центральный сервер.

Исходя из этих рассуждений при проектировании архитектуры АРМ за основу была принята технология клиент-сервер. Диаграммы размещения отражают физические взаимосвязи между программными и аппаратными компонентами системы).

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

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

элементы управления системой;

навигация между блоками системы;

визуальный дизайн экранов программы.

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

снижение количества ошибок пользователя;

снижение стоимости поддержки системы;

уменьшение потерь продуктивности работников при внедрении системы и более быстрое восстановление утраченной продуктивности;

улучшение морального состояния персонала;

уменьшение расходов на изменение пользовательского интерфейса по требованию пользователей;

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

АРМ оптовая база разрабатывается как приложение использующее технологию клиент-сервер.

Основным модулем «АРМ Оптовая База» является модуль Luck.exe, обеспечивающий реализацию основной функциональности диаграммы вариантов использования, представленной на рисунке 1.9 раздела 1.4.

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

Интерфейс программы, администраторская часть:

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

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

форма «Заказчики», благодаря этой форме можно видеть полную информацию о заказчиках предприятия (рисунок 2.7);

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

Интерфейс программы пользовательская часть:

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

В меню расход там тут происходят операции проводимые сотрудника склада по отпуску и продаже товара.

В меню остатки происходит подсчет товара, наименования хранящегося на складе.

В меню касса тут хранятся информация по приходным ордерам и расходным кассовым ордерам.(скриншоты)

Рис 2.0 Главное меню программы

Главное окно программы показано на рис. 1.9. Как видно из рисунка, кроме главного меню, уже описанного выше, оно также будет содержать панель управления (кнопки «Приход», «Расход», «Доступ», «Остатки», «Касса»,«Переоценка»,«Аналитика»,«Справочники»,«Служебные» и «Выход из программы»).

Рисунок 2.1 Окно меню прихода или поступления на склад .

Рисунок 2.2 Окно меню расхода

Рисунок 2.2 Окно меню регулирующее права доступа к программе.

Рисунок 2.3 Окно меню остатка товара.

Рисунок 2.4 Окно меню касса.

Рисунок 2.4 Окно меню переоценка.

Для проектирования базы данных был использован ERwin 4.0 от Computer Associates Int.

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

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

Диаграмма сущность - связь (Entity Relationships Diagram (ERD));

Модель данных, основанная на ключах (Key Based model (KB));

Полная атрибутивная модель (Fully Attributed model (FA)).

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

Логическая модель - наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи (смотри приложение Б). [26]

Физическая модель данных напротив зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физическом уровне модели содержится информация обо всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует (например, нет стандарта на типы данных), физический уровень модели зависит от конкретной реализации СУБД. Следовательно, одному и тому же логическому уровню модели могут соответствовать несколько разных физических уровней различных моделей. Если на логическом уровне модели не имеет большего значения, какой конкретно тип данных у атрибута (хотя и поддерживаются абстрактные типы данных), то на физическом уровне модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Разделение модели данных на логический и физический уровни позволяет решить несколько важных задач. [20]

Страницы: 1, 2