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

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

Система имеет двух актеров – администратора ИС и администратора БД. Базовыми вариантами использования являются «Сортировка данных», «Поиск лекарства», «Формирование отчетов», «Ввод данных», «Редактирование данных».

Рис. 4.1 Диаграмма вариантов использования.

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

 

Таблица 4.1. Шаблон для написания сценария отдельного варианта использования

Главный раздел	Раздел «Типичный ход событий»	Раздел «Исключения»	Раздел «Примечания»
Имя варианта использования	Типичный ход событий, приводящий к успешному выполнению варианта использования	Исключение №1 Исключение №2 Исключение №3	Примечания
Актеры
Цель
Краткое описание
Тип
Ссылки на другие варианты использования

 

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

Главный раздел сценария представлен в таблице 4.2.

Таблица 4.2. Главный раздел

Вариант использования	Формирование отчетов
Актеры	Администратор ИС
Цель	Ведение учета продаж лекарств
Краткое описание	Администратор должен вводить и редактировать данные заявок от клиентов, формировать содержание отчета на основе запросов.
Тип	Базовый

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

 

Таблица 4.3. Раздел «Типичный ход событий»

Действия актеров	Отклик системы
1.          Администратор ИС выбирает сортировку данных по алфавиту или по возрастанию. Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру.	2. Система отображает записи в  соответствии с параметрами сортировки  в БД.
3. Администратор ИС выбирает поиск  лекарств. Исключение №2: администратор ИС не имеет прав доступа ввод / редактирование / удаление информации о лекарствах.	4. Система выдает лекарства по  заданному критерию.
5. Пользователь выбирает формирование  отчетов. Исключение №3: отсутствие записей по продажам лекарств за выбранный месяц.	6. Система формирует отчет.

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

Таблица 4.4. Раздел «Исключения»

Действия актеров		Отклик системы
Исключение №1: администратор ИС не имеет возможности упорядочить все данные сразу, а только по одному параметру.
7. Пользователь отменяет упорядочивание  данных по продажам лекарств.	Система предлагает отменить упорядочивание данных.
Исключение №2: администратор ИС не имеет прав доступа ввод / редактирование / удаление информации о лекарствах.
8. Пользователь отменяет добавление / удаление / изменение данных по продажам лекарств.	Система предлагает отменить добавление / удаление / изменение данных по продажам лекарств.
Исключение №3: отсутствие записей по продажам лекарств за выбранный месяц.
9. Пользователь отменяет формирование  отчета.	Система предлагает не формировать отчет.

4.2 Построение диаграммы  деятельности

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

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

Диаграмма деятельности для «Проектирования ИС предприятия оптовой торговли лекарственными препаратами» представлена на рис. 4.2.

Рис. 4.2 Диаграмма деятельности

 

В рамках вариантов использования инициируемых действующим лицом «Администратор ИС» система имеет восемь состояний действия: «Ввести пароль», «Ввести данные по лекарствам», «Ввести данные по клиентам», «Ввести данные по поставщикам», «Ввести заказ от клиента», «Выбрать шаблоны отчетов», «Распечатать отчет» и «Выйти из приложения».

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

4.3 Построение диаграммы  классов

Диаграммы классов являются центральным звеном методологии объектно-ориентированных анализа и проектирования.

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

Диаграмма классов для «Проектирования ИС оптовой торговли лекарственными препаратами» представлена на рис. 4.3.

 

Рис. 4.3. Диаграмма классов

Модуль Заказа лекарств управляется модулями Клиенты, Поставщики и Лекарства. Одно лекарство может быть поставлено несколькими поставщиками и наоборот. Клиентов управляет модулем Заказ лекарства, заказ делается индивидуально от каждого и в один день может быть подано несколько заявок на одно и то же лекарство одним и тем же покупателем.

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

 

5. Проектирование формы  первичного документа 

 

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

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

2) выделение справочных реквизитов, группировочных реквизитов и реквизитов-оснований;

3) выделение реквизитов, имеющих  одно или несколько значений  на документ, т.е. выделение однозначных  и многозначных реквизитов;

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

5) согласование последовательности  реквизитов в документе с макетами  размещения информации на экране  ПК.

Формы первичного документа для лекарств, поставщиков, клиентов представлены соответственно в форме 5.1, 5.2, 5.3.

Форма 5.1. Форма «Лекарства»

Код товара	Наименование товара	Количество	Единица измерения

Форма 5.2. Форма «Поставщики»

Код поставщика	Наименование поставщика	Город	Адрес	Телефон

Форма 5.3. Форма «Клиенты»

Код клиента	Наименование клиента	Город	Адрес	Телефон

 

5.1 Проектирование форм  документов результатной информации

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

1) выделение трех зон в документе;

2) разделение реквизитов на однозначные, т.е. имеющие одно значение на  документ, и многозначные реквизиты, имеющие несколько значений в документе;

3) выделение группировочных реквизитов, помещаемых во вторую зону  документа, и размещение этих  реквизитов в порядке убывания  старшинства;

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

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

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

 

Форма 5.4

Предприятие оптовой торговли лекарственными препаратами Отчет по продажам Стол заявок Месяц					Количество листов ___ Номер листа ___ Количество экземпляров ____ Номер экз. ___
Наименование клиента	Код клиента	Наименование товара	Код товара	Цена товара	Количество	Сумма
Итого по цене товара
Итого по наименованию товара
Итого по наименованию клиента
Подпись ________________________ Дата _________________

 

  

 

 

Заключение

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

В данной курсовой работе были подробно разобраны следующие разделы:

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

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

3) функционально-ориентированное  проектирование информационной системы представлено построением контекстной диаграммы, диаграмм декомпозиции IDEF0, созданием диаграммы IDEF3 и диаграммы потоков данных DFD.

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

 

Список используемой литературы

1. Архангельский, А.Я. Программирование в Delphi 7/ А.Я. Архангельский. - М.:ООО Бином – Пресс, 2004.–1152 с.

2. Бобровский, С.И. Delphi 7. Учебный курс/ С.И. Бобровский.– СПб.: Питер, 2004.–736 с.

3. Вендров, А.М. Практикум по проектированию программного обеспечения экономических информационных систем/ А.М. Вендров. - М.: Финансы и статистика, 2004.–192 с.

4. Вендров, А.М. CASE-технологии. Современные  методы и средства проектирования  информационных систем/ А.М. Вендров. - М.: Финансы и статистика, 1998.–176 с.

5. Избачков, Ю.С. Информационные системы. 2-е издание/ Ю.С. Избачков, В.Н. Петров–СПб.: Питер, 2005.–161 с.

6. Маклаков, С.В. BPWin и ERWin. Case-средства  разработки информационных систем/ С.В. Маклаков-М.: ДИАЛОГ–МИФИ, 1999.–256 с.

7. Марко Кенту. Delphi 7 для профессионалов/ Марко Кенту–СПб.: Питер, 2004.–543 с.

8. Марков, А.С. Базы Данных. Введение в теорию и методологию/ А.С. Марков, К.Ю. Лисовский-М.: Финансы и статистика, 2006. – 55 с.

9. Орлов, С.А. Технологии разработки программного обеспечения/ С.А. Орлов–СПб.: Питер, 2002.–464 с.

10. Хомоненко, А.Д. Работа с базами данных в Delphi/. А.Д. Хомоненко, В.Э. Гофман–СПб.: БХВ - Петербург, 2003.–624 с.