Проектирование системы автоматизации складского учета

Далее объекты ADO получают доступ к источнику данных OLE DB. OLE DB представляет собой набор специализированных объектов СОМ, инкапсулирующих стандартные функции обработки данных, и специализированные функции конкретных источников данных и интерфейсов, обеспечивающих передачу данных между объектами.

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

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

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

Рисунок 1 – Принцип работы механизма ADO

 

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

Так как технология ADO основана на стандартных интерфейсах  СОМ, которые являются системным  механизмом Windows, это сокращает общий объем работающего программного кода и позволяет распространять приложения БД без вспомогательных программ и библиотек.

3.2  Разработка модели прецедентов

 

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

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

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

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

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

Моделирование контекста системы состоит из следующих шагов:

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

- Организация  похожих актеров с помощью  отношений обобщения/специализации. 

- Введение стереотипов  для каждого актера, если это облегчает понимание.

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

 

 

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

Рисунок 2 –  Модель прецедентов (работа склада)

 

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 3 –  Расширенная модель прецедентов  работы ИС

 

 

3.3  Концептуально-инфологическая модель  базы данных.

 

Моделирование данных является важнейшим процессом  при проектировании информационных систем. Являясь признанным лидером в области объектных методологий, фирма Rational Software Corporation создала свое собственное средство моделирования данных Data Modeller, в котором UML используется как средство создания логических моделей данных.

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

 

Таблица 1. Соответствие элементов логической и физической модели

Логическая  модель	Физическая  модель
Class (Класс)	Table (Таблица)
Operation (Операция)	Constraint (Ограничение)
Attribute (Атрибут)	Column (Колонка)
Package (Пакет)	Scheme (Схема)
Component (Компонент)	Database (База данных)
Association (Ассоциация)	Relationship (Связь)
Нет	Trigger (Триггер)
Нет	Index (Индекс)

 

Учитывая все  преимущества Data Modeler можно отметить следущее:

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

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

- Data Modeler тесно  интегрирован с Rational Rose, а диаграмма  Data Model естественным образом вписывается  в общую технологию разработки  ПО с использованием линейки  продуктов фирмы Rational Software Corporation;

- Можно отказаться  от интеграции Rational Rose с другими  средствами генерации физических  моделей. 

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

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

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

Данная сущность связана с другими сущностями связями один-ко-многим: журнал безопасности, операции на складе, номенклатура.

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Рисунок 7 –  Логическая модель данных ИС

 

 

 

Рисунок 8 –  Физическая модель данных ИС

Заключение

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

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

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

   

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

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

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

Разработаны схемы  и диаграммы процессов и данных в системах ERWin и BPWin, а также Rational Roses.

 

Список литературы.

 

1. Горин С.В., Тандоев А.Ю. Проектирование ИС: Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных./ С.В. Горин , А.Ю Тандоев //"СУБД".2010-№3.

 

2. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования./ Д.А Марка, К. МакГоуэн //"МетаТехнология", 2009.

 

3. Балдин К.В., Уткин В.Б. Информационные системы в экономике.

/ К.В. Балдин, В.Б Уткин - М., Издательский центр Академия, 2010 – 288 с.

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник./ А.М. Вендров – 2-е изд., перераб. и доп.– М.: Финансы и статистика, 2011. – 544 с: ил.
5. Hello World, Часть 1: Rational Software Architect. Проектирование простого приложения телефонной книги 2010.// http://www.sdteam.com/t6300
6. Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML/ Л.А. Мацяшек -М.: Издательский дом "Вильямс", 2011. - 432