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

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

Содержание:

Введение

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

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

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

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

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

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

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

Внутренняя организационная структура организации представляет собой схему, изображенную на рисунке 1.1

Рис. 1.1 – Внутренняя структура организации

Объектом автоматизации являются следующие отделы организации:

- Отдел снабжения,

- Отдел сбыта,

- Склад.

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

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Источниками оперативной информации в нашем случае являются:

- информация о материалах;

- информация от клиента;

- информация о приходных и расходных накладных.

Анализ состава информации, связанной с учетом заказов, позволяет сгруппировать основные расчеты на ПЭВМ, выполняемые в рамках создаваемой АИС:

- математическая обработка (расчет суммы заказа);

- группировка информации, как символьной, так и числовой.

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

- экранная форма с данными о материалах и контрагентах;

- форма работы с накладными;

- реестр приходных накладных;

- реестр расходных накладных.

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

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

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

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

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

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

Для того чтобы графически представить поведение АИС, была применена методология визуального моделирования. Унифицированный язык моделирования UML – это нотация, которая позволяет детально описать информационную систему, а также отметить особенности реализации системы.

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

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

Диаграмма вариантов использования описывает функциональность АИС. Каждая функциональность изображается в виде прецедентов использования (use case) или просто прецедентов.

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

  1. Начальник отдела склада и снабжения - контролирует деятельность отдела;
  2. Специалист по закупкам формирует закупки необходимых ТМЦ.
  3. Кладовщик – оприходует и выдает ТМЦ.
  4. Менеджер – контролирует учет материалов.

Трассировка – один из видов зависимости, указывающий на связь между элементами, которые представляют собой одну и туже концепцию, находящуюся на разных уровнях значимости, диаграммы трассировки для основных вариантов использования, рисунки 2.2-2.5

Рисунок 2.2 Диаграмма трассировки «Выдача ТМЦ»

Рисунок 2.3 Диаграмма трассировки «Инвентаризация»

Рисунок 2.4 Диаграмма трассировки «Прием ТМЦ»

Рисунок 2.5 Диаграмма трассировки «Формирование отчетности»

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

Далее рассмотрены сценарии вариантов использования, каждый из которых представлен графическими диаграммами (рисунки 2.6 – 2.37). Для составления диаграмм были использованы:

- диаграммы последовательности;

- диаграммы взаимодействия;

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

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

Вариант использования «Авторизация пользователя»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

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

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

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

Результат успешного завершения: пользователь вошел в систему.

Сценарий.

  1. Запуск проверки введенного имени и пароля пользователя – пользователь системы вводит свои имя и пароль в специальное поле на интерфейсе «Авторизация в системе».
  2. Запуск процедуры авторизации – интерфейс «Авторизация в системе» посылает данные пользователя контролеру «Авторизация».
  3. Проверка имени и пароля – контролер «Авторизация» посылает запрос к таблице «Пользователи» для нахождения введенного имени и пароля, и устанавливает существование таких данных.
  4. Подтверждение имени и пароля – форма «Авторизация в системе» получает подтверждение запроса к таблице.
  5. Форма «Авторизация в системе» регистрирует результат авторизации в «Журнал».
  6. Форма «Авторизация в системе» получает результат записи в «Журнал».
  7. Далее отображение интерфейса авторизации пользователя – с интерфейса «Авторизация в системе» происходит отображение результата авторизации.

Альтернативные сценарии.

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

Диаграмма последовательности, иллюстрирующая описанный сценарий «Авторизация пользователя в системе», изображена на рисунке 2.6.

Рисунок 2.6 - Диаграмма последовательности «Авторизация пользователя в системе»

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

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

Диаграмма взаимодействия, иллюстрирующая описанный сценарий «Авторизация пользователя в системе», изображена на рисунке 2.7.

Рисунок 2.7 Диаграмма взаимодействия «Авторизация пользователя в системе»

Вариант использования «Обновление информации в системе о ТМЦ»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

Контекст использования: сотрудник отдела склада и снабжения (Пользователь) вводит информацию в соответствующие поля о изменения в состоянии ТМЦ (выдаче ТМЦ, приемке ТМЦ, местоположении ТМЦ).

Результат успешного завершения: все поля интерфейса корректно заполнены.

Сценарий.

  1. Вызов интерфейса «Справочник ТМЦ» – главный интерфейс с помощью метода Show() вызывает интерфейс «Открытие справочника ТМЦ».
  2. Отображение интерфейса – происходит отображение интерфейса «Открытие справочника ТМЦ».
  3. Добавление данных о ТМЦ – сотрудник заполняет все поля на форме.
  4. Присвоение штрих-кода.
  5. Проверка и сохранение информации – интерфейс «Справочник ТМЦ» посылает введенные данные в процедуру «Контролер Базы данных».
  6. Данные о ТМЦ сохраняются в таблице «Товарно-материальные ценности».
  7. Ответ из таблицы «Товарно-материальные ценности» поступает в «Контролер Базы данных»
  8. «Контролер Базы данных» сообщает о результате сохранения.
  9. Форма «Справочник ТМЦ» регистрирует результат авторизации в «Журнал».
  10. Форма «Справочник ТМЦ» получает результат записи в «Журнал».
  11. Форма «Справочник ТМЦ» отображает результат сохранения информации в системе о ТМЦ.

Альтернативные сценарии.

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

Диаграмма, соответствующая данному сценарию и иллюстрирующая последовательность действий варианта использования «Обновление информации в системе о ТМЦ», представлена на рисунке 2.8.

Рисунок 2.8 Диаграмма последовательности «Обновление информации в системе о ТМЦ»

Диаграмма взаимодействия, иллюстрирующая описанный сценарий «Обновление информации в системе о ТМЦ», изображена на рисунке 2.9.

Рисунок 2.9 Диаграмма взаимодействия «Обновление информации в системе о ТМЦ»

Вариант использования «Получение информации о ТМЦ в базе данных»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

Контекст использования: сотрудник отдела склада и снабжения (Пользователь) запрашивает информацию о ТМЦ.

Результат успешного завершения: все поля интерфейса корректно заполнены.

Сценарий.

  1. Вызов интерфейса «Справочник ТМЦ» – главный интерфейс с помощью метода Show() вызывает интерфейс «Открытие справочника ТМЦ».
  2. Отображение интерфейса – происходит отображение интерфейса «Открытие справочника ТМЦ».
  3. Запрос информации о ТМЦ – сотрудник заполняет все поля на форме. Интерфейс «Справочник ТМЦ» посылает введенные данные в процедуру «Контролер Базы данных».
  4. Информация о ТМЦ запрашивается процедурой «Контролер Базы Данных» в таблице «Товарно-материальные ценности» запросом.
  5. Происходит чтение из таблицы «Товарно-материальные ценности», ответ поступает в «Контролер Базы данных».
  6. «Контролер Базы данных» сообщает о результате запроса информации.
  7. Форма «Справочник ТМЦ» регистрирует результат авторизации в «Журнал».
  8. Форма «Справочник ТМЦ» получает результат записи в «Журнал».
  9. Форма «Справочник ТМЦ» отображает результат запроса информации в системе о ТМЦ.

Альтернативные сценарии.

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

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

Рисунок 2.10 Диаграмма последовательности «Получение информации о ТМЦ в базе данных»

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

Рисунок 2.11 Диаграмма взаимодействия «Получение информации о ТМЦ в базе данных

Вариант использования «Приём ТМЦ»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

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

Результат успешного завершения: все поля интерфейса корректно заполнены, накладная проведена, получена печатная форма.

Сценарий.

  1. Открытие формы «Приём ТМЦ» – главный интерфейс с помощью метода Show() вызывает интерфейс «Приём ТМЦ».
  2. Ввод информации о накладной - сотрудник заполняет все поля на форме, выбирает поставщика и ТМЦ.
  3. Проведение накладной.
  4. Подсчет суммы.
  5. Добавление ТМЦ на склад
  6. Форма «Приём ТМЦ» отправляет запрос на сохранение информации в процедуру «Контролер Базы данных».
  7. Сохраненная информация – процедура «Контролер Базы данных» формирует информацию и посылает все данные в таблицу «Приходная накладная».
  8. Ответ о сохранении информации из таблицы «Приходная накладная» поступает в «Контролер Базы данных»
  9. «Контролер Базы данных» сообщает о результате сохранения.
  10. Форма «Приём ТМЦ» формирует печатную форму накладной.
  11. Пользователь получает печатную форму накладной.

Альтернативные сценарии.

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

Диаграмма, соответствующая данному сценарию и иллюстрирующая последовательность действий варианта использования «Приём ТМЦ», представлена на рисунке 2.12.

Рисунок 2.12 Диаграмма последовательности «Приём ТМЦ»

Диаграмма взаимодействия, иллюстрирующая описанный сценарий «Приём ТМЦ» изображена на рисунке 2.13.

Рисунок 2.13 Диаграмма взаимодействия «Приём ТМЦ»

Вариант использования «Выдача ТМЦ»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

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

Результат успешного завершения: все поля интерфейса корректно заполнены, накладная проведена, получена печатная форма.

Сценарий.

  1. Открытие формы «Выдача ТМЦ» – главный интерфейс с помощью метода Show() вызывает интерфейс «Выдача ТМЦ».
  2. Ввод информации о накладной - сотрудник заполняет все поля на форме, выбирает подразделение и ТМЦ.
  3. Проведение накладной.
  4. Подсчет суммы.
  5. Добавление ТМЦ на склад
  6. Форма «Выдача ТМЦ» отправляет запрос на сохранение информации в процедуру «Контролер Базы данных».
  7. Сохраненная информация – процедура «Контролер Базы данных» формирует информацию и посылает все данные в таблицу «Расходная накладная».
  8. Ответ о сохранении информации из таблицы «Расходная накладная» поступает в «Контролер Базы данных»
  9. «Контролер Базы данных» сообщает о результате сохранения.
  10. Форма «Выдача ТМЦ» формирует печатную форму накладной.
  11. Пользователь получает печатную форму накладной.

Альтернативные сценарии.

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

Диаграмма, соответствующая данному сценарию и иллюстрирующая последовательность действий варианта использования «Выдача ТМЦ», представлена на рисунке 2.14.

Рисунок 2.14 Диаграмма последовательности «Выдача ТМЦ»

Диаграмма взаимодействия, иллюстрирующая описанный сценарий «Выдача ТМЦ» изображена на рисунке 2.15.

Рисунок 2.15 Диаграмма взаимодействия «Выдача ТМЦ»

Вариант использования «Формирование отчета склада ТМЦ»

Главное действующее лицо – сотрудник отдела склада и снабжения (Пользователь).

Контекст использования: сотрудник отдела склада и снабжения (Пользователь) формирует отчет склада ТМЦ.

Результат успешного завершения: все поля интерфейса корректно заполнены.

Сценарий.

  1. Вызов интерфейса «Отчет о работе склада ТМЦ» – главный интерфейс с помощью метода Show() вызывает интерфейс «Отчет о работе склада ТМЦ».
  2. Отображение интерфейса – происходит отображение интерфейса «Отчет о работе склада ТМЦ», отображение формы с указанием периода формирования отчета.
  3. Сотрудник заполняет все поля на форме. Интерфейс «Отчет о работе склада ТМЦ» запрашивает построение отчета у процедуры «Построитель отчетов».
  4. «Построитель отчетов» отправляет запрос информации о входящей документации в процедуру «Контроллер Базы данных».
  5. «Контролер Базы данных» запрашивает информацию в таблицу «Приходная накладная».
  6. «Контролер Базы данных» получает информацию из таблицы «Приходная накладная».
  7. «Контролер Базы данных» передает в контроллер «Построитель отчетов» результат запроса.
  8. «Построитель отчетов» отправляет запрос информации о материальных ценностях в процедуру «Контроллер Базы данных».
  9. «Контролер Базы данных» запрашивает информацию в таблицу «Товарно-материальные ценности».
  10. «Контролер Базы данных» получает информацию из таблицы «Товарно-материальные ценности».
  11. «Контролер Базы данных» передает в контроллер «Построитель отчетов» результат запроса.
  12. «Построитель отчетов» отправляет запрос информации о выходных документах в процедуру «Контроллер Базы данных»
  13. «Контролер Базы данных» запрашивает информацию в таблицу «Накладная выдачи».
  14. «Контролер Базы данных» получает информацию из таблицы «Накладная выдачи».
  15. «Контролер Базы данных» передает в контроллер «Построитель отчетов» результат запроса.
  16. «Построитель отчетов» отображает отчет о работе склада.
  17. Процедура «Отчет о работе склада» регистрирует результат операции в «Журнал».
  18. Процедура «Отчет о работе склада» получает результат записи в «Журнал».
  19. Процедура «Отчет о работе склада» отображает информацию.
  20. Процедура «Отчет о работе склада» производит печать документов.

Альтернативные сценарии.

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

Диаграмма, соответствующая данному сценарию и иллюстрирующая последовательность действий варианта использования «Формирование отчета склада ТМЦ», представлена на рисунке 2.16.

Рисунок 2.16 Диаграмма последовательности «Формирование отчета склада ТМЦ»

Диаграмма взаимодействия, иллюстрирующая описанный сценарий «Формирование отчета склада ТМЦ» изображена на рисунке 2.17

Рисунок 2.17 Диаграмма взаимодействия «Формирование отчета склада ТМЦ»

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

Рисунок 2.18 – Диаграмма классов

Заключение

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

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

  1. Рамбо Дж., Блаха М. / UML 2.0 Объектно-ориентированное моделирование и разработка, 2-е издание. – СПб.: Питер, 2017. – 544 с.: ил.
  2. Шмуллер Дж. / Освой самостоятельно UML за 24 часа, 3-е издание. - Пер. с англ. – М.: Издательский дом «Вильямс», 2016. – 416 с.: ил.
  3. Фаулер М. / UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2016. – 192 с., ил.
  4. Буч Г. / Язык UML. Руководство пользователя. / Грэйди Буч, Джеймс Рамбо, Айвар Джекобсон: Пер. с англ. Слинкин А. А. – 2-ое изд., стер. – М.: ДМК «Пресс»; СПБ.: Питер, 2016 – 432 с.: ил.
  5. Леоненков А. / Самоучитель UML, 2-е издание. – СПб: БХВ-Петербург, 2015. – 432 с.: ил.
  6. Нейбург, Эрик, Дж., Максимчук, Роберт, А. Проектирование баз данных с помощью UML.: Пер. с англ. – М.: Издательский дом «Вильямс», 2012. – 288 с.: ил.