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

Моделирование предметной области «Учет товаров» с помощью UML (Описание предметной области. Постановка задачи)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

Для написания проекта используется объектно–ориентированный подход, средством моделирования проекта является Rational Rose, технологией проектирования - технология RAD.

Глава 1. Аналитическая часть

1.1 Описание предметной области. Постановка задачи

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

Каждый товар принадлежит к определенной категории.

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

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

Формирует заказы и оформляет поступление товаров менеджер по закупкам.

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

Перечень бизнес-процессов представлен в Таблице 1.

Таблица 1. Перечень бизнес-процессов

№

Наименование бизнес-процесса

Учет товаров

Поддержка заказов

Поступление товаров

Поддержка справочника товаров

Операции бизнес-процесса представлены в Таблице 2.

Таблица 2. Операции бизнес-процессов

Операция	Исполнитель	Как часто	Входящие документы (документы-основания)	Исходящий документ (составляемый документ)
1.Учет товаров
Изменение наличия товаров	Менеджер по закупкам	При поступлении/реализации товара	Товарная накладная, чек	Список товаров, имеющихся в наличии
2. Поддержка заказов
Добавление информации о поставщиках	Менеджер по закупкам	При добавлении поставщика	Данные о поставщике	Договор
Изменение информации о поставщиках	Менеджер по закупкам	При изменении информации о поставщиках	Данные о поставщике (визитная карточка), существующий договор	Измененный договор
Удаление информации о поставщиках	Менеджер по закупкам	При удалении поставщика	Существующий договор	Договор о расторжении
Изменение заказа поставщику	Менеджер по закупкам	При изменении заказа поставщику	Заказ поставщику	Измененный заказ
Отмена заказа поставщику	Менеджер по закупкам	При отмене заказа поставщику	Заказ поставщику	Отмененный заказ
Добавление заказа поставщику	Менеджер по закупкам	При заказе поставщику	Информация о наличии товара, данные справочника о поставщиках	Заказ поставщику
3. Поступление товара
Оприходование товара	Менеджер по закупкам	При поступлении товара	Заказ поставщику	Товарная накладная
4. Поддержка справочника товаров
Изменение информации о товарах	менеджер по закупкам	При изменении информации о товарах	Список товаров	Список товаров
Удаление информации о товарах	менеджер по закупкам	При удалении информации о товарах	Список товаров	Список товаров
Добавление информации о товарах	менеджер по закупкам	При добавлении информации о товарах	Список товаров	Список товаров

Описание документов бизнес-процесса представлено в Таблице 3.

Таблица 3. Документы бизнес-процессов

Составляемый документ (исходящий документ)	Операция	Кто составляет (исполнитель)	Как часто	Документы-основания (входящие документы)
Список товаров, имеющихся в наличии	Изменение наличия товара	Менеджер по закупкам	При поступлении товара	Товарная накладная,
Список товаров, количество которых необходимо пополнить	Изменение наличия товаров	Менеджер по закупкам	При реализации товара	Чек
Договор	Добавление информации о поставщиках	Менеджер по закупкам	При добавлении поставщика	Данные о поставщике (визитная карточка)
Измененный договор	Изменение информации о поставщиках	Менеджер по закупкам	При изменении информации о поставщиках	Данные о поставщике (визитная карточка), существующий договор
Договор о расторжении	Удаление информации о поставщиках	Менеджер по закупкам	При удалении поставщика	Существующий договор
Заказ поставщику	Добавление заказа поставщику	Менеджер по закупкам	При заказе поставщику	Информация о критическом остатке товара, данные справочника о поставщиках
Измененный заказ	Изменение заказа поставщику	Менеджер по закупкам	При изменении заказа поставщику	Заказ поставщику
Отмененный заказ	Отмена заказа поставщику	Менеджер по закупкам	При отмене заказа поставщику	Заказ поставщику
Товарная накладная	Оприходование товара	Менеджер по закупкам	При поступлении товара	Заказ поставщику
Список товаров	Изменение информации о товаре; удаление информации о товаре; добавление информации о товаре	Менеджер по закупкам	При изменении информации, удалении, добавлении информации о товаре	Список товаров

Автоматизированная информационная система должна содержать:

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

Система должна осуществлять расчет суммы по документам.

1.2 Предлагаемые мероприятия по улучшению бизнес-процессов

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

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

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

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

Глава 2. Проектная часть

2.1 Выбор средства для моделирования предметной области решаемой задачи

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

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

RAD (rapid application development) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы.

Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Боэма и Скотта Шульца. А в 1991 году Мартин опубликовал книгу, в которой детально изложил концепцию RAD и возможности её применения. С конца XX века RAD получила широкое распространение и одобрение. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов. Именно средства разработки, основанные на RAD, имеют наибольшую популярность среди программистов.

Среды разработки, использующие принципы RAD: Borland Delphi, Borland C++ Builder, Microsoft Visual Studio, IBM Lotus Domino Designer , Macromedia Flash и другие.

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

Применение технологии RAD целесообразно, когда:

требуется выполнение проекта в сжатые сроки (90 дней). Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня. Если система проектируется долго, то весьма высока вероятность, что за это время существенно изменятся фундаментальные положения, регламентирующие деятельность организации, то есть, система морально устареет еще до завершения ее проектирования.
нечетко определены требования к ПО. В большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО. Требования могут быть вообще не определены к началу проекта либо могут изменяться по ходу его выполнения.
проект выполняется в условиях ограниченности бюджета. Разработка ведется небольшими RAD группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения.
интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.
проект большой, но поддается разделению на более мелкие функциональные компоненты. Если предполагаемая система велика, необходимо, чтобы ее можно было разбить на мелкие части, каждая из которых обладает четкой функциональностью. Они могут выпускаться последовательно или параллельно (в последнем случае привлекается несколько RAD групп).
ПО не обладает большой вычислительной сложностью.

Фазы разработки:

Планирование. На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, сложности, которые могут возникнуть при разработке, определяют функции, которые должна выполнять система, выделяют наиболее приоритетные из них, ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Результатом данной фазы является список функций будущей АИС, предварительные функциональные и информационные модели ИС.
Проектирование. На протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и при необходимости корректируется функциональная модель. Каждый процесс рассматривается детально. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и выбрать рабочую модель, отвечающую их требованиям.
Конструирование - этап, в котором основная задача заключается в разработке программ и приложений. Пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование.

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

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

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

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

1. Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Проектирование диаграммы вариантов использования

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

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

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

Диаграмма вариантов использования представлена на рисунке 1.

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

Поведения основных действующих лиц представлено в таблице 4.

Таблица 4 Поведения основных действующих лиц

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

Формирование диаграмм последовательности

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

формировать данные о поставщиках;
формировать документ оприходования;
формировать отчет о товарах в наличии.

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

1. Формировать данные о поставщиках.

S-1.1 – просмотр списка поставщиков
S-1.2 – ввод информации о новом поставщике
S-1.3– редактирование информации о поставщике
S-1.4 – удаление информации о поставщике
S-1.5 – поиск по списку поставщиков

Таблица 5 S-1.1 – просмотр списка поставщиков

Описание	Вывод на экран таблицы с данными справочника поставщиков
Актер	Менеджер по закупкам
Предусловие	-
Постусловие:	-

Таблица 6 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду открыть справочник поставщиков
2	Система	Открывает форму справочника поставщиков и выводит в ней сведения о поставщиках(E-1.1)
3	Менеджер по закупкам	Дает команду закрыть справочник поставщиков
4	Система	Закрывает форму справочника поставщиков
	Сценарий завершен

Таблица 7 S-1.2 – ввод информации о новом поставщике

Описание	Ввод информации о новом поставщике
Актер	Менеджер по закупкам
Предусловие	S-1.1
Постусловие:	S-1.1

Таблица 8 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на создание нового поставщика
2	Система	Открывает форму элемента справочника поставщиков
3	Менеджер по закупкам	Вводит сведения о поставщике и сохраняет их
4	Система	Проверяет правильность ввода данных(Е-1.2), сохраняет их в базу данных, закрывает форму элемента справочника поставщиков
	Сценарий завершен

Таблица 9 S-1.3– редактирование информации о поставщике

Описание	редактирование информации о поставщике
Актер	Менеджер по закупкам
Предусловие	S-1.2, S-1.1
Постусловие:	S-1.1

Таблица 10 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на редактирование сведений о поставщике
2	Система	Открывает форму элемента справочника поставщиков; заполняет поля данными о поставщике
3	Менеджер по закупкам	Вносит изменения в поля и сохраняет их
4	Система	Проверяет правильность ввода данных(Е-1.2), сохраняет их в базу данных, закрывает форму элемента справочника поставщиков
	Сценарий завершен

Таблица 11 S-1.4 – удаление информации о поставщике

Описание	Удаление информации о поставщике
Актер	Менеджер по закупкам
Предусловие	S-1.2, S-1.1
Постусловие:	S-1.1

Таблица 12 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Выбирает нужного поставщика из справочника и дает команду на удаление сведений
2	Система	Выводит окно подтверждения удаления
3	Менеджер по закупкам	Подтверждает удаление(Е-1.3)
4	Система	Закрывает окно подтверждения удаления поставщика, удаляет запись о поставщике из базы данных(Е-1.4) и выводит окно с информацией об успешном удалении
	Сценарий завершен

Таблица 13 S-1.5 – поиск по списку поставщиков

Описание	Поиск поставщиков по заданным параметрам
Актер	Менеджер по закупкам
Предусловие	S-1.1
Постусловие:	S-1.1

Таблица 14 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на поиск сведений о поставщике
2	Система	Выводит на форме справочника поставщиков панель поиска с полями ввода
3	Менеджер по закупкам	Вводит поисковый запрос и дает команду на выполнение поиска
4	Система	Осуществляет поиск в базе данных и подсвечивает первый найденный элемент справочника поставщиков(Е-1.5)
5	Менеджер по закупкам	Дает команду на поиск следующего элемента(Е-1.6)
6	Система	Осуществляет поиск в базе данных следующего элемента и подсвечивает найденный элемент справочника поставщиков(Е-1.7)
7	Менеджер по закупкам	Дает команду на закрытие панели поиска
8	Система	Закрывает панель поиска
	Сценарий завершен

Таблица 15 Альтернативный поток событий

Номер ситуации	Ошибка	Исправление ошибки
Е-1.1	Список поставщиков пуст	Система открывает окно с сообщением «Справочник поставщиков пуст!» Менеджер подтверждает сообщение Система закрывает окно, продолжает выполняться сценарий S-1.1
Е-1.2	Некорректный ввод данных в поля формы или не все поля заполнены	Система открывает окно с сообщением о вводе некорректных данных, пользователь подтверждает сообщение, вносит корректные данные и заполняет все поля
Е-1.3	Отмена подтверждения удаления	Выполнение сценария S-1.1
Е-1.4	Невозможно удалить поставщика	Система открывает окно с сообщением о невозможности удаления поставщика, пользователь подтверждает сообщение, продолжает выполняться сценарий S-1.1
Е-1.5	Отсутствие результата поиска	Система открывает окно с сообщением «Элемент не найден», пользователь подтверждает сообщение и задает новые условия для поиска, продолжает выполняться сценарий S-1.5
Е-1.6	Отмена продолжения поиска	Система закрывает панель поиска, продолжает выполняться сценарий S-1.1
Е-1.7	Отсутствие следующего элемента поиска	Система открывает окно с сообщением «Достигнут конец поиска», пользователь подтверждает сообщение, продолжает выполняться сценарий S-1.5

- 1. Формировать документ оприходования
S-2.1 – просмотр журнала документов поступления
S-2.2 – ввод информации о новом документе поступления
S-2.3– редактирование информации о документе поступления
S-2.4 – удаление информации о документе поступления
S-2.5 – поиск по журналу документов поступления

Таблица 16 S-2.1 – просмотр журнала документов поступления

Описание	Вывод на экран таблицы со списком документов поступления
Актер	Менеджер по закупкам
Предусловие	-
Постусловие:	-

Таблица 17 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду открыть список документов поступления
2	Система	Открывает форму списка документов поступления и выводит в ней сведения о документах поступления(E-2.1)
3	Менеджер по закупкам	Дает команду закрыть список документов поступления
4	Система	Закрывает форму списка документов поступления
	Сценарий завершен

Таблица 18 S-2.2 – ввод информации о новом документе поступления

Описание	Ввод информации о новом документе поступления
Актер	Менеджер по закупкам
Предусловие	S-2.1
Постусловие:	S-2.1

Таблица 19 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на создание нового документа поступления
2	Система	Открывает форму элемента документа поступления
3	Менеджер по закупкам	Вводит сведения о номере и дате документа поступления, дает команду на выбор поставщика
4	Система	Выполняет сценарий S-1.1
5	Менеджер по закупкам	Выбирает поставщика из списка поставщиков(E-2.2)
6	Система	Закрывает окно со списком поставщиков, вводит информацию о выбранном поставщике в соответствующее поле
7	Менеджер по закупкам	Дает команду на выбор документа-основания
8	Система	Выполняет сценарий просмотра списка документов заказа поставщику
9	Менеджер по закупкам	Выбирает документ из списка документов заказа поставщику (Е-2.3)
10	Система	Закрывает окно со списком документов заказа, вводит информацию о выбранном документе в соответствующее поле
11	Менеджер по закупкам	Дает команду на добавление товара
12	Система	Добавляет новую строку в табличной части документа поступления товаров
13	Менеджер по закупкам	Дает команду на выбор товара
14	Система	Выполняется сценарий просмотра справочника товаров
15	Менеджер по закупкам	Выбирает товар (Е-2.4)
16	Система	Закрывает окно товара, выводит наименование товара в новую строку табличной части в соответствующее поле
17	Менеджер по закупкам	Заполняет информацию о количестве и цене товара и дает команду на сохранение информацию о документе поступления
18	Система	Проверяет правильность ввода данных (Е-2.5), закрывает форму элемента документа поступления, подсчитывает итоговую сумму, сохраняет информацию в базу данных
	Сценарий завершен

Таблица 20 S-2.3– редактирование информации о документе поступления

Описание	Редактирование информации о документе поступления
Актер	Менеджер по закупкам
Предусловие	S-2.2, S-2.1
Постусловие:	S-2.1

Таблица 21 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на редактирование сведений документе поступления
2	Система	Открывает форму элемента документа поступления; заполняет поля данными о документе поступления
3	Менеджер по закупкам	Редактирует сведения о номере и дате документа поступления, дает команду на выбор поставщика
4	Система	Выполняет сценарий S-1.1
5	Менеджер по закупкам	Выбирает поставщика из списка поставщиков(E-2.2)
6	Система	Закрывает окно со списком поставщиков, вводит информацию о выбранном поставщике в соответствующее поле
7	Менеджер по закупкам	Дает команду на выбор документа-основания
8	Система	Выполняет сценарий просмотра списка документов заказа поставщику
9	Менеджер по закупкам	Выбирает документ из списка документов заказа поставщику (Е-2.3)
10	Система	Закрывает окно со списком документов заказа, вводит информацию о выбранном документе в соответствующее поле
11	Менеджер по закупкам	Дает команду на добавление товара
12	Система	Добавляет новую строку в табличной части документа поступления товаров
13	Менеджер по закупкам	Дает команду на выбор товара
14	Система	Выполняется сценарий просмотра справочника товаров
15	Менеджер по закупкам	Выбирает товар (Е-2.4)
16	Система	Закрывает окно товара, выводит наименование товара в соответствующее поле
17	Менеджер по закупкам	Заполняет информацию о товаре и дает команду на сохранение информацию о документе поступления
18	Система	Проверяет правильность ввода данных (Е-2.5), закрывает форму элемента документа поступления, подсчитывает итоговую сумму, сохраняет информацию в базу данных
	Сценарий завершен

Таблица 22 S-2.4 – удаление информации о документе поступления

Описание	Удаление информации о документе поступления
Актер	Менеджер по закупкам
Предусловие	S-2.2, S-2.1
Постусловие:	S-2.1

Таблица 23 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Выбирает нужный документ поступления из списка и дает команду на удаление сведений
2	Система	Выводит окно подтверждения удаления
3	Менеджер по закупкам	Подтверждает удаление(Е-2.6)
4	Система	Закрывает окно подтверждения удаления, удаляет запись о документе поступления из базы данных(Е-2.7)
	Сценарий завершен

Таблица 24 S-2.5 – поиск по журналу документов поступления

Описание	Поиск документов поступления по заданным параметрам
Актер	Менеджер по закупкам
Предусловие	S-2.1
Постусловие:	S-2.1

Таблица 25 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на поиск сведений о документе поступления
2	Система	Выводит на форме списка поставщиков панель поиска с полями ввода
3	Менеджер по закупкам	Вводит поисковый запрос и дает команду на выполнение поиска
4	Система	Осуществляет поиск в базе данных и подсвечивает первый найденный элемент списка документов поступления (Е-2.8)
5	Менеджер по закупкам	Дает команду на поиск следующего элемента (Е-2.9)
6	Система	Осуществляет поиск в базе данных следующего элемента и подсвечивает найденный элемент (Е-2.10)
7	Менеджер по закупкам	Дает команду на закрытие панели поиска
8	Система	Закрывает панель поиска
	Сценарий завершен

Таблица 26 Альтернативный поток событий

Номер ситуации	Ошибка	Исправление ошибки
Е-2.1	Список документов поступления пуст	Открытие окна с сообщением «Список документов поступления пуст!» Менеджер подтверждает сообщение Система закрывает окно, продолжает выполняться сценарий S-2.1
Е-2.2	Отсутствие нужного поставщика	Выполнение сценария S-1.2
Е-2.3	Отсутствие нужного документа заказа	Выполнение сценария добавления документа заказа
E-2.4	Отсутствие нужного товара	Выполнение сценария добавление товара
E-2.5	Некорректный ввод данных или не заполнены обязательные поля	Система открывает окно с сообщением о вводе некорректных данных, пользователь подтверждает сообщение, вносит корректные данные и заполняет все поля
Е-2.6	Отмена подтверждения удаления	Выполнение сценария S-2.1
Е-2.7	Невозможность удаления позиции документа поступления	Открытие окна с сообщением о невозможности удаления позиции документа поступления, пользователь подтверждает сообщение, система закрывает окно, продолжает выполняться сценарий S-2.1
Е-2.8	Отсутствие результата поиска	Система открывает окно с сообщением «Элемент не найден», пользователь подтверждает сообщение и задает новые условия для поиска, продолжает выполняться сценарий S-2.5
Е-2.9	Отмена продолжения поиска	Система закрывает панель поиска, продолжает выполняться сценарий S-2.1
Е-2.10	Отсутствие следующего элемента поиска	Система открывает окно с сообщением «Достигнут конец поиска», пользователь подтверждает сообщение, продолжает выполняться сценарий S-2.5

- 1. Формировать отчет о товарах в наличии

Таблица 27 S-3.1 – формирование отчета о товарах в наличии

Описание	формирование отчета о товарах в наличии
Актер	Менеджер по закупкам
Предусловие	-
Постусловие:	-

Таблица 28 Основной поток событий

№	Актер/Система	Действие/Отклик
1	Менеджер по закупкам	Дает команду на формирование отчета
2	Система	Открывает форму отчета для ввода параметров запроса
3	Менеджер по закупкам	Вводит параметры запроса и дает команду сформировать
4	Система	Проверяет правильность ввода данных (Е-3.1), обращается к базе данных с запросом, формирует отчет и выводит его на экран (Е-3.2)
5	Менеджер по закупкам	Дает команду вывода отчета на печать
6	Система	Печатает отчет(Е-3.3)
7	Менеджер по закупкам	Дает команду на закрытие формы отчета
8	Система	Закрывает форму отчета
	Сценарий завершен

Таблица 29 Альтернативный поток событий

Номер ситуации	Ошибка	Исправление ошибки
Е-3.1	Некорректный ввод данных	Система открывает окно с сообщением о вводе некорректных данных, пользователь подтверждает сообщение, вносит корректные данные и заполняет все поля
Е-3.2	Формирование пустого запроса	Внесение нового поискового запроса
Е-3.3	Невозможность печати отчета	Система выводит сообщение о необходимости проверки состояния принтера

Проектирование диаграмм последовательности

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

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

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

Диаграмма последовательности, отражающая добавление поставщика в справочник поставщиков, представлена на рисунке 2.

Рисунок 2 Диаграмма последовательности, отражающая добавление поставщика в справочник поставщиков

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

Диаграмма состояний заказа поставщику

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

Диаграмма состояний заказа поставщику представлена на рисунке 3.

Рисунок 3. Диаграмма состояний заказа поставщику

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

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

Диаграмма деятельности торговой компании с объектом-заказом представлена на Рисунке 4.

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

Формирование диаграмм классов

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

Общая диаграмма классов представлена на рисунке 5.

Рисунок 5. Общая диаграмма классов

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

ЗАКЛЮЧЕНИЕ

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

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

При проектировании программного обеспечения использована технология RAD.

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

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

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

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

Средством моделирования проекта является Rational Rose - средство визуального моделирования с использованием языка UML.

Также были выполнены следующие задачи:

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

- 1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2006. — 544 с: ил.;
  2. Бахтихин В.В., Глухова Л. А. Технологии разработки программного обеспечения: учеб. пособие. – Минск: БГУИР, 2010. – 267 с. : ил.

Балдин, К. В. Информационные системы в экономике : учеб. пособие студентам вузов, обучающихся по направлению 080100 Экономика / К. В. Балдин. — Москва : ИНФРА-М, 2012. — 217 с
Галкин, В. И. Практический опыт модернизации автоматизированных систем технологической подготовки производства / В. И. Галкин, А. О. Анохин // Технология машиностроения. — 2008 .— N 8 .— С. 54-59 .
Гвоздева, Т. В. Проектирование информационных систем : учеб. пособие для студентов вузов, обучающихся по специальности "Прикладная информатика" / Т. В. Гвоздева, Б. А. Баллод ; [науч. ред. Ф. Н. Ясинский]. — Ростов-на-Дону : Феникс, 2009. — 508 с.
Елманова, Н. Краткое введение в моделирование бизнес-процессов. Ч. 1. Моделирование бизнес-процессов и CASE-средства / Наталия Елманова // КомпьютерПресс. — 2007 .— N 8 .— С. 161-163 .
Кулябов Д. С., Королькова А. В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. — М.: РУДН, 2008. — 173 с.: ил
Леоненков А. В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. — Интернет-университет ин- формационных технологий — ИНТУИТ.ру, БИНОМ. Лаборатория зна- ний, 2006. — 320 с.
Леоненков А.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2007. — 576 с.: ил.
Уткин, В. Б. Информационные системы в экономике : учебник для студентов вузов / В. Б. Уткин, К. В. Балдин. — М. : Академия, 2004. — 288 с. : ил. — Библиогр.: с. 278.
Федоров, Н. В. Проектирование информационных систем на основе современных CASE-технологий : учеб. пособие / Н. В. Федоров ; Федер. агентство по образованию; Моск. гос. индустр. ун-т. — 2-е изд., стер. — М. : [МГИУ], 2008. — 278 с. : ил. — Библиогр.: с. 228-229 (21 назв.) 7
Федотова, Д. Э. CASE-технологии : Практикум / Д. Э. Федотова, Ю. Д. Семенов, К. Н. Чижик. — М. : Горячая линия-Телеком, 2003. — 160 с. : ил.

ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ А ДИАГРАММЫ КЛАССОВ

ФОРМИРОВАТЬ ДАННЫЕ О ПОСТАВЩИКАХ