Проектирование информационной системы для расчета оплаты труда в торговле
Суть данной диаграммы состоит в следующем: проектируемая система представляется в форме графа деятельности, в котором вершинами являются состояния действия, а дугами — переходы от одного состояния к другому. При этом состояния действия — это специальные случаи состояния с некоторыми входными действиями и, по крайней мере, одним переходом, выходящим из состояния. Переход переводит деятельность… Читать ещё >
Проектирование информационной системы для расчета оплаты труда в торговле (реферат, курсовая, диплом, контрольная)
Расчетно-пояснительная записка к курсовому проекту
«Проектирование информационной системы для расчета оплаты труда в торговле»
Сегодня на рынке представлен ряд программных продуктов, так или иначе решающих задачи расчета оплаты труда в торговле.
Программа позволяет объединить в себе ряд функций, таких как ввод и редактирование данных, обработка данных, формирование отчета в электронном виде о назначенных премиях с возможностью вывода на печать.
Целью данной работы является проектирование информационной системы для расчета оплаты труда в торговле.
Курсовой проект состоит из пяти разделов.
В первом разделе описывается предпроектная стадия создания информационной системы. Раздел содержит общее описание предметной области, примеры разработок проектов-аналогов. Приводится описание выбранной технологии, методов и средств проектирования; выбранного метода проведения обследования; выбранного метода сбора материалов обследования. Дана разработанная программа обследования и план-график выполнения работ на предпроектной стадии.
Во втором разделе «Постановка задачи» описаны требования к информационной системе в целом, к функциям и к видам обеспечения, дается постановка задачи, представлены документы предметной области.
Третий раздел «Проектирование ИС» представлен построением моделей IDEF0, созданием диаграммы IDEF3, диаграммы потока данных DFD.
В четвертом разделе «Объектно-ориентированное проектирование информационной системы» разработаны три диаграммы на языке UML: диаграмма вариантов использования, диаграмма деятельности и диаграмма классов.
В пятом разделе «Проектирование экранных форм документов» рассматривается проектирование формы первичного документа и формы документа результатной информации.
1. Предпроектная стадия создания информационной системы
1.1 Описание предметной области автоматизации
Автоматизированная ИС для назначения премии продавцам-менеджерам фирмы в зависимости от суммы проданного ими товара.
Данная система реализует следующие функции:
— расчет первых трех мест, занятых менеджерами, по сумме продаж;
— расчет 20% от общей выручки;
— назначение коэффициентов в соответствии с занятыми местами;
— расчет премии;
— формирование отчетов по требованию.
1.2 Примеры разработок проектов для аналогичных систем
Подобных программ в Интернете найдено не было, можно сделать вывод, что вся обработка данных, заполнение таблиц и вывод отчетов выполняется в ручную.
1.3 Описание выбранной технологии методов и средств проектирования
Для проектирования информационной системы для расчета оплаты труда в торговле используются:
— метод оригинального или индивидуального проектирования, так как проектные решения разрабатываются с нуля в соответствии с требованиями ИС.
— метод реструктуризации модели, т. е. когда изменяется модель предметной области, то на ее основе меняются проектные решения.
— технология индустриального автоматизированного проектирования с использованием CASE-технологий (BPWin, ERWin).
При проектировании данной ИС используются следующие средства проектирования:
— операционные средства, поддерживающие проектирование операций обработки информации;
— средства, поддерживающие проектирование отдельных компонентов;
— средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования.
1.4 Описание выбранного метода проведения обследования
Для проектирования информационной системы для расчета оплаты труда в торговле использовались следующие методы проведения обследования:
1) по цели проектирования — метод системного обследования, т. к. применяется для изучения всего объекта с целью разработки проекта информационной системы в целом;
2) по числу исполнителей — индивидуальный метод, т. к. осуществляется одним проектировщиком;
3) по степени обхвата — выборочное обследование, т. к. применяется при наличии типовых по структуре подразделений;
4) по отношению к этапам — параллельное обследование, т. е. одновременно со сбором материала осуществлялся процесс изучения материалов обследования.
1.5 Описание выбранного метода сбора материалов обследования
При сборе материалов обследования использовались следующие методы:
1) метод бесед и консультаций с руководителем подразделения;
2) метод анализа предоставленного материала. Был представлен перечень функций для реализации;
3) метод личного наблюдения.
1.6 Программа обследования и план-график выполнения работ на предпроектной стадии
На основе собранного материала обследования о данном проекте составлена программа обследования, которая представлена в таблице 1.1.
Таблица 1.1. Программа обследования
№ п.п. | Наименование вопроса | Источник информации | Получатель информации | |
Цель функционирования объекта | Сазонова Г. А. | Ширяев А.Н. | ||
Организационно-функциональная структура объекта | Сазонова Г. А. | Ширяев А.Н. | ||
Состав объекта | Сазонова Г. А. | Ширяев А.Н. | ||
На основе программы обследования был составлен план-график выполнения работ на предпроектной стадии по разработке ИС, который представлен в таблице 1.2.
Таблица 1.2. План-график выполнения работ на предпроектной стадии
№ п. п | Наименование работы | Код работы | Испол; нитель | Дата начала | Длительность выполнения | Дата окончания | |
Определение цели и параметров системы | Ширяев А.Н. | 09.04.10 | 3 дня | 11.04.10 | |||
Определение организационной структуры | Ширяев А.Н. | 12.04.10 | 3 дня | 14.04.10 | |||
Определение функциональной структуры | Ширяев А.Н. | 12.04.10 | 3 дня | 14.04.10 | |||
Определение материальных потоков и процессов их обработки | Ширяев А.Н. | 15.04.10 | 4 дня | 18.04.10 | |||
Определение информационных потоков и процессов их обработки | Ширяев А.Н. | 19.04.10 | 4 дня | 22.04.10 | |||
Анализ материалов обследования | Ширяев А.Н. | 23.04.10 | 6 дней | 28.04.10 | |||
1.7 Формализация материалов обследования
Анализ материалов обследования позволяет представить функциональную структуру ИС в виде схемы связей из компонентов, представленных на рис. 1.1:
Рис. 1.1 — Функциональная структура ИС для расчета оплаты труда в торговле.
1) Блок ввод входных данных. В интерфейсной части ввод исходной информации по экспертам, по результатам суммы продаж за месяц.
2) Просмотр и редактирование записей. При просмотре сформированных отчетов пользователь при необходимости может удалить или изменить исходные данные, а также вставить новые. Вся информация сохраняется в базе данных.
3) Блок обработки результатов. Пользователь имеет возможность сформировать отчеты.
2. Постановка задачи
2.1 Назначение, цели создания ИС
Целью создания ИС для расчета оплаты труда в торговле является автоматизированное начисление премии. ИС предназначена для накопления и хранения данных по ежемесячным платежам в базе данных, а также для эффективной обработки данных (реализация запросов к БД).
2.2 Характеристика объектов автоматизации. Документы предметной области
Объектом автоматизации является ведомость «Заявки от клиентов»
Входные документы предметной области:
— информация о клиентах (Форма 2.1)
Форма 2.1. Список клиентов
Код клиента | Наименование клиента | Город | Адрес | Телефон | |
— информация о поставщиках (форма 2.2)
Форма 2.2. Список поставщиков
Код поставщика | Наименование поставщика | Город | Адрес | Телефон | |
— список лекарств на складе (форма 2.3)
Форма 2.3. Список лекарств на складе
Код товара | Назименование товара | Количество | Единица измерения | |
— список поставленных лекарств (форма 2.4)
Форма 2.4. Документ поставки
Код поставки | Наименование поставщика | Наименование товара | Количество | Дата поставки | |
— заявка от клиента (форма 2.5)
Форма 2.5. Форма заявки от клиента Код заявки_________
Код клиента | Наименование клиента | Наименование товара | Количество | Единица измерения | |
Дата заявки ___________________
Выходные документы предметной области:
— отчет о продаже лекарств (форма 2.6)
Форма 2.6. Форма отчета о проданных лекарствах Код заказа ___________________________________
Дата заказа ___________________________________
Наименование клиента _________________________
Код товара | Наименование товара | Количество | Единица измерения | Цена | |
Сумма ___________
2.3 Требования к ИС
2.3.1 Требование к системе в целом
К системе предъявляется ряд требований:
— ИС должна обеспечить накопление и хранение в базе данных всей необходимой информации;
— ИС должна вести автоматизированный учет продаж лекарственных препаратов;
— Система должна быть легко переносимой с одного компьютера на другой;
— Работа системы не должна зависеть от версии Windows;
— Система должна работать на компьютерах различных конфигураций.
2.3.2 Требования к функциям (задачам)
Информационная система должна реализовывать следующие функции
— ввод и редактирование данных по лекарствам;
— ввод и редактирование данных по клиентам;
— ввод и редактирование данных по поставщикам;
— поиск лекарства по названию для просмотра его цены;
— вывод клиента, купившего больше всех лекарственных препаратов;
— обработка данных (сортировка лекарств по алфавиту, сортировка лекарств по возрастанию цены, расчет суммы проданных лекарств за месяц).
2.3.3 Требования к видам обеспечения
Для функционирования ИС необходим ПК с минимальными системными требованиями: процессор с тактовой частотой не меньше 1000 MHz; ОЗУ — 128 МВ; Video — 4 МВ; ОС — Windows 2000; ПО — Delphi 7.0, сервер СУБД — MS Access; клавиатура / мышь.
Оптимальными для работы ИС являются широко распространённые и поддерживающие большинство программных продуктов операционные системы Windows 2000/XP и конфигурация: процессор с тактовой частотой не меньше 1500 MHz; ОЗУ — 256 МB; Video — 64 МВ; ПО — Delphi 7.0, MS Access; мышь / клавиатура.
При максимальной конфигурации: процессор с тактовой частотой 2000 MHz; ОЗУ — 256МВ; Video — 128МВ; ОС — Windows XP; ПО — Delphi 7.0, MS Access; мышь / клавиатура.
Данные вводятся в таблицы Access через экранные формы, разработанные в среде Delphi 7, производится их обработка (расчет суммы, сортировка, выборка), вывод результатов также производится с помощью экранных форм Delphi. Планируемый объем поступающей информации не должен превысить объема жесткого диска, поэтому он должен быть не меньше 3 Gb. Информация будет представляться в виде отчетов (в электронном варианте), с возможностью отправки на печать — необходимо наличие принтера.
Факторы, относящиеся к эксплуатационным характеристикам компьютера:
— компьютеры данной конфигурации имеются на предприятии;
— пользователи уже имеют необходимый опыт работы на компьютере;
— выполнены все условия эксплуатации.
На выбор ОС оказывают влияние следующие факторы:
— совместимость с другими ОС;
— возможность использования различных устройств ввода-вывода;
— требование поддержки сетевой технологии;
— необходимое число поддерживаемых программных продуктов;
— быстродействие;
— наличие дружественного интерфейса и простота использования;
— возможность переконфигурации и быстрой настройки на новые аппаратные средства;
— поддержка новых информационных технологий.
Всеми этими качествами обладает ОС Windows XP и для данной конфигурации P4−2000/256 Mb/20Gb/32 Mb AGP/CD-ROM-40x/SB Live 128 — является оптимальной, компьютера такой мощности вполне достаточно для функционирования системы.
Основные факторы, влияющие на выбор методов и средств проектирования ПО системы:
— совместимость;
— получение качественного продукта;
— сокращение времени и стоимостных затрат на проектирование;
Для реализации функций ИС применяется СУБД MS Access. Выбор обусловлен тем, что она отвечает предъявляемым требованиям:
— масштаб применения СУБД (персональная — настольная СУБД);
— язык общения;
— выполняемые функции (информационные — организация хранения информации и доступа к ней, операционные функции — связанные с обработкой информации);
— сфера возможного применения.
3. Функционально-ориентированное проектирование информационной системы
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования. Для проектирования ИС оптовой торговли лекарственными препаратами применялись CASE-средства (Computer Aided System/Software Engineering — автоматизация процесса разработки сложных ИС).
BPwin — CASE-средство функционального моделирования, реализующее методологию IDEF.
3.1 Построение контекстной диаграммы
Методология IDEF0 может использоваться для моделирования широкого круга предметных областей. Процесс моделирования какой-либо системы в IDEF0 начинается с построения контекстной диаграммы, т. е. наиболее абстрактного уровня описания системы в целом. Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействие с внешней средой.
Контекстная диаграмма модели ИС представлена на рис. 3.1.
Рис. 3.1 — Контекстная диаграмма модели ИС предприятия оптовой торговли лекарственными препаратами.
Вход представляет собой информацию, преобразуемую функциональным блоком. Для данной модели входной информацией являются данные о лекарствах и поставщиках, клиентах, заявки от клиентов. Управляющим механизмом является уровни доступа, шаблоны отчетов, параметры обработки. Исполняющим механизмами является информационная система и администратор ИС. В качестве выходной информации служат отчеты продаж и БД по лекарствам.
3.2 Построение диаграмм IDEF0
Процесс проектирования ИС для обработки заявки от клиента состоит из трех этапов: «Авторизация и аутентификация пользователя», «Заполнение БД», «Обработка данных» (рис. 3.2).
Рис. 3.2 — Диаграмма декомпозиции 1-го уровня.
Этап «Обработка данных» состоит из четырех функциональных блоков: «Поиск по значению поля», «Сортировка записей», «Обработка заявки», «Вывод данных», (рис. 3.3).
Рис. 3.3 — Диаграмма декомпозиции 2-го уровня.
Основные элементы модели «Проектирование ИС предприятия оптовой торговли лекарственными препаратами» представлены в таблицах 3.1 — 3.3.
Таблица 3.1. Основные элементы модели
Название проекта: Проектирование ИС предприятия оптовой торговли лекарственными препаратами | ||
Цель проекта: реализация структурной функциональной модели ИС | ||
Технология моделирования: метод функционального моделирования IDEF0 | ||
Инструментарий: программный продукт BPwin 4.0 | ||
Список данных | Перечень функций | |
Информация о лекарствах и поставщиках Информация о клиентах Заявки от клиентов Уровни доступа Шаблоны отчетов Отчеты по продажам лекарств Администраторы системы Информационная система БД лекарств | А0. Проектирование ИС предприятия оптовой торговли лекарственными препаратами | |
Информация о лекарствах и поставщиках Информация о клиентах Заявки от клиентов Уровни доступа Шаблоны отчетов Отчеты по продажам лекарств Администраторы системы Информационная система БД лекарств | A1. Авторизация и аутентификация пользователя А2. Заполнение БД А3. Обработка данных | |
БД по лекарствам Заявки от клиентов Параметры обработки Право на обработку Шаблоны отчетов Отчеты по продажам лекарств Запросы на изменение БД Информационная система Администратор ИС | A31. Поиск записи по значению поля А32. Сортировка записей А33. Обработка заявки А34. Вывод данных | |
Таблица 3.2. Словарь
Термины | Определение | |
Информационная система | Совокупность программных приложений, баз данных, используемых для управления. | |
Данные | Факты, характеризующие деятельность предприятия, подлежащие количественному выражению. | |
Имеющиеся ресурсы | Персонал и информационная система в распоряжении предприятия. | |
Методология учета | Совокупность приемов и методов ведения управленческого учета. | |
Обработанные данные | Данные, разнесенные по объектам учета. | |
Управленческая информация | Информация, необходимая для принятия управленческих решений. | |
Входящие документы | Данные, предоставляемые от внешнего источника, например, сведения о лекарствах. | |
Таблица 3.3. Описание функциональных блоков
Наименование блока | Описание решаемых задач | |
A1. Авторизация и аутентификация пользователя | На данном этапе информационная система проверяет пароль, введенный пользователем. | |
А2. Заполнение БД | На этом этапе собираются, накапливаются все данные администратором БД и подвергаются изменению при запросах на изменение. | |
А3. Обработка данных | На этапе выполняется обработка данных из БД по заявке от клиента и формируется отчет по проданным лекарствам. | |
А31. Поиск записи по значению поля | На данном этапе выполняется поиск по заданному параметру обработки. | |
А32. Сортировка записей | На данном этапе выполняется сортировка по заданному параметру обработки. | |
А33. Обработка заявки от клиента | Здесь обрабатывается заявка от клиента администратором ИС. | |
А34. Вывод данных | На данном этапе формируется отчет по проданным лекарствам | |
3.3 Построение диаграммы IDEF3
IDEF3 является технологией для сбора данных, требующихся для проведения структурного анализа системы. IDEF3 используется как дополнение к IDEF0 для разработки моделей, в которых изучается последовательность выполнения действий и взаимосвязей между ними.
На диаграмме (рис. 3.4.) изображен процесс расчета премии.
Рис. 3.4 — Диаграмма IDEF3.
Основные элементы модели представлены в таблицах 3.4 — 3.6.
Таблица 3.4. Основные элементы модели
Название проекта: Проектирование ИС для расчета оплаты труда в торговле | |||
Цель проекта: реализация структурной функциональной модели ИС | |||
Технология моделирования: метод описания бизнес-процессов IDEF3 | |||
Инструментарий: программный продукт BPwin 4.0 | |||
Перечень действий | Тип соединения | ||
Название | Вид | ||
1. Получить данные о работнике | Соединение «И» J1 | Разворачивающее | |
3. Выбрать систему обработки запросов 4. Выбрать шаблон отчета 5. Запросить данные из текущей БД | Соединение «ИЛИ» J2 | Сворачивающее | |
6. Вывести отчет | |||
Таблица 3.5. Словарь
Термины | Определение | |
Текущая БД | БД, которая имеет актуальное содержимое своих таблиц. | |
Шаблон отчета | Заранее сформированный образец отчета, который можно выбрать из списка. | |
Сворачивающее соединение «И» | Объединяет потоки. Завершение одного или нескольких действий вызывает выполнение другого действия. Каждое исходное действие обязательно должно завершиться. | |
Разворачивающее соединение «И» | Разъединяет потоки. Все следующие процессы должны быть запущены. | |
Система обработки заявок | Часть ИС, в которой администратором выполняется заявка клиента. | |
Таблица 3.6. Описание действий
Наименование действия | Описание решаемых задач | |
2. Принять заявку на обработку | На данном этапе происходит получение данных заказов лекарств. | |
3. Выбрать подсистему обработки заявок | На этом этапе происходит выбор системы обработки заявок. | |
4. Выбрать шаблон отчета | Выбор шаблона отчета по продажам лекарств. | |
5. Запросить данные из текущей БД | Запрос информации из БД лекарств для их отображения. | |
6. Вывести отчет | Вывод отчета по лекарствам администратору ИС с последующей печатью | |
3.3 Построение диаграммы потоков данных DFD
Диаграммы потоков данных DFD моделируют систему как набор действий, соединенных друг с другом стрелками.
В данной диаграмме имеются хранилища данных (заявки, клиенты, счета) и внешние сущности, представленные потребностью и складом (рис. 3.5).
Рис. 3.5 — Диаграмма DFD.
Основные элементы модели представлены в таблицах 3.7 — 3.9.
Таблица 3.7. Основные элементы модели
Название проекта: Проектирование ИС предприятия оптовой торговли лекарственными препаратами | ||
Цель проекта: реализация структурной функциональной модели ИС | ||
Технология моделирования: метод построения диаграмм потоков данных DFD | ||
Инструментарий: программный продукт BPwin 4.0 | ||
Список данных | Перечень объектов | |
Право на обработку Данные счетов Запросы на изменение БД Обработанная заявка Ответы на запросы Продукция | Функциональные блоки: 1. Обработать заявки 2. Проконтролировать оплату 3. Доставить лекарства | |
Лекарства Счета и платежные документы | Внешние сущности: 1. Лекарства 2. Потребность | |
Название и адрес клиента Данные счетов Информация о доставке | Хранилища данных: 1. Заявки 2. Счета 3. Клиенты | |
Таблица 3.8. Словарь
Термины | Определение | |
Данные | Факты, характеризующие деятельность предприятия, подлежащие количественному выражению. | |
Таблица 3.9. Описание объектов
Наименование объекта | Описание функций | |
Функциональные блоки: | ||
1. Обработать заявки | На данном этапе происходит ввод данных по заявкам и их обработка. | |
2. Проконтролировать оплату | На этом этапе ведется администратором ИС контроль оплаты выписанных лекарств. | |
3. Доставить лекарства | Доставка лекарств клиенту для удовлетворения его потребности в них. | |
Внешние сущности: | ||
1. Потребность | Представляет собой необходимость получить товар в определенном количестве. | |
Хранилища данных: | ||
1. Счет | Здесь собирается и хранится информация о счетах оплаты. | |
2. Заявки | Здесь собирается и хранится информация о заявках от клиентов. | |
3. Клиенты | Здесь содержится информация о клиентах | |
4. Объектно-ориентированное проектирование информационной системы
4.1 Построение диаграммы вариантов использования
Для описания функционального назначения системы построена диаграмма вариантов использования (use case diagram). Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Разработка диаграммы вариантов использования преследует следующие цели:
— определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы;
— сформулировать общие требования к функциональному поведению проектируемой системы;
— разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в форме так называемых вариантов использования, с которыми взаимодействуют некоторые внешние сущности или актеры. При этом актером или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. В свою очередь вариант использования служит для описания сервисов, которые система предоставляет актеру.
Построение диаграммы вариантов использования является первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого — представить совокупность функциональных требований к поведению проектируемой системы. Разработанная диаграмма вариантов использования представлена на рис. 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 с.
11. Черемных, С. В. Структурный анализ систем: IDEF-технологии. /С.В. Черемных, И. О. Семенов, В.С. Ручкин-М.: Финансы и статистика, 2003.-208 с.