Файл: Разработка модели автоматизированной системы «Аптека №73».pdf
Добавлен: 26.06.2023
Просмотров: 677
Скачиваний: 11
СОДЕРЖАНИЕ
Глава 1. Теоретические основы и виды диаграмм UML
Глава 2. Проектирование реализации операций бизнес-процесса в информационной системе
2.1. Краткая характеристика ОАО «Аптека № 73»
2.2.Порядок выполнения практического задания и требования к информационной системе
Рисунок 16 – Диаграмма действий менеджера группы планирования и маркетинга
- Просмотрим общее описание бизнес-процесса и выделим действия (операции), выполняемые менеджером отдела закупок. Определим также действия, которые менеджер отдела закупок выполняет после действий менеджера группы логистики.
- На диаграмме последовательно отобразим следующие действия менеджера отдела закупок:
- Ввод в систему прайс-листов поставщиков (операция № 3)
- Анализ предложений поставщиков (операция № 4)
- Выбор поставщиков (операция № 5)
- Формирование графика поставок без указания количества (операция №6)
- Соединим действия менеджера отдела закупок стрелками аналогично описанию, приведенному в п. 12.
- Поставим в соответствие действиям менеджера отдела закупок документы, формируемые в системе. В данном случае это прайс-листы и контракты, список поставщиков с расстановкой приоритетов, график поставок. Выполним работу по рисованию диаграммы в соответствии с описанием в п. 15-16.
- После формирования менеджером отдела закупок графика поставок в работу включается менеджер группы логистики.
- На диаграмме отобразим следующие действия менеджера группы логистики:
- Расчет необходимого количества закупок (операция № 7);
- Формирование заказов поставщикам (операция № 8);
- Расчет затрат на сертификацию импортных товаров, если медикаменты импортные) (операция № 9);
- Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы);
- Формирование заказов поставщикам при превышении затрат на сертификацию (операция № 10);
- Подпись заказа (операция № 11);
- Направление заказа менеджеру отдела закупок (операция № 12).
- Изучая общее описание бизнес-процесса, обратим внимание на то, что менеджер группы логистики дважды производит проверку условий и в зависимости от результата выполняет то или иное действие.
- Покажем действие "Расчет необходимого количества закупок" и опустите стрелку вниз.
- Ввиду того, что формирование заказов поставщикам может происходить неоднократно при превышении затрат на сертификацию, предусмотрите эту ситуацию и используйте графику для объединения параллельных потоков (Transition|Join).
- Покажем действие "Формирование заказов поставщикам" после символа объединения потоков.
- Покажем ромб-символ проверки условия . Проведите из него две стрелки и надпишите их "Импорт", "Россия".
- Стрелку "Россия" направьте к операции № 11 "Подпись заказа".
- По направлению стрелки "Импорт" диаграммируйте последовательно два действия "Расчет затрат на сертификацию импортных товаров", "Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы".
- За операцией "Проверка суммы затрат на сертификацию на непревышение внутрифирменной нормы" вновь отобразите ромб-символ проверки условия . Проведите из него две стрелки и надпишите их "больше х%", "меньше х%". Здесь х% - норма затрат на сертификацию.
- Стрелку с надписью "больше х%" соедините с операцией № 8 "Формирование заказов поставщикам" через символ объединения потоков.
- Стрелку с надписью "меньше х%" направьте к операции № 11 "Подпись заказа".
- Поскольку к операции № 11 "Подпись заказа" направлено два потока действий (п. 29 и п. 33), воспользуемся обозначением объединения независимых (параллельных) потоков (Transition|Join). В операцию №11 "Подпись заказа", как и в любую другую, должна входить только одна стрелка. Для выполнения этого правила и используем символ объединения потоков.
- Поставим в соответствие операции "Подпись заказа" документ - акцептованный заказ поставщику аналогично тому, как написано в п. 15-16.
- В качестве следующей операции покажем операцию № 12 "Направление заказа менеджеру отдела закупок". На этом действия, выполняемые менеджером группы логистики, завершаются. Вновь работа переключается на менеджера отдела закупок, поэтому направьте стрелку от 12 операции в поле действий менеджера закупок.
- Отобразим на диаграмме переход документа "Заказ поставщику" от менеджера группы логистики к менеджеру отдела закупок. Для этого сначала поставим в соответствие операции № 12 "Направление заказа менеджеру отдела закупок" документ "Заказ поставщику" так, как это описано в п. 15-16. После этого изображение документа с надписью "Заказ поставщику" путем копирования разместите в поле действий менеджера отдела закупок. Затем направим пунктирную стрелку (Object Flow) между двумя отображениями документа "Заказ поставщику" в направлении поля действий менеджера отдела закупок.
- Соединим операцию № 12 "Направление заказа менеджеру отдела закупок" с операцией № 13 "Направление заказа поставщику", выполняемой менеджером отдела закупок. Это последняя операция в соответствии с заданием.
- Укажим на диаграмме конец процесса. Для этого используем символ (Final State). Соедините стрелкой операцию № 13 "Направление заказа поставщику" с символом Final State.
Рисунок 15 – Диаграмма действий бизнес-процесса «Планирование закупок, формирование заказов поставщикам»
Заключение
Проектирование операций бизнес-процессов не такая простая задача, так как требует достаточно глубокого знания потребностей и возможностей компании, ее организационной структуры и должностных обязанностей сотрудников.
Обычно с проектированием бизнес-процессов лучше всего справляются внутренние специалисты и группы специалистов организации, которые хорошо знают как возможности программного обеспечения, так и существующую организационную структуру компании. Возможно привлечение и внешних консультантов по бизнес-процессам, но им может потребоваться значительное время для построения эффективных процессов в незнакомых им организаций.
Мы просмотрели понятие, историю создания и применение языка UML, как универсальное средство моделирования проектных решений. Выявили множество UML-диаграмм и назвали 7 самых основных и чаще используемых в проектировании диаграмм, таких как диаграмма классов, диаграмма коммуникаций, диаграмм прецедентов и т.д.
Несмотря на мощные и продвинутые во всех отношениях специализированные инструменты, некоторые разработчики считают UML чересчур сложной технологией. В общем-то, для мелких проектов её применение действительно может быть и не лучшим из всех возможных вариантов, поскольку для них чаще легче сразу написать код. UML действительно трудно применять, предварительно в нём не разобравшись, а потому делать так чревато всякими осложнениями в процессе разработки. Ну и уж совсем не стоит пытаться применять UML в проектах, которые пишутся не на объектно-ориентированных языках. Тем не менее, в большинстве случаев UML всё же очень и очень полезен. Он позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы, и при этом диаграммы UML более просты для чтения и изменения, нежели готовый код, пластичность которого, как известно, низка и чревата багами. Богатый инструментарий позволяет выбрать то, что наилучшим образом подходит для конкретного проекта. А поддержка со стороны гигантов индустрии гарантирует, что перспективы у UML есть.
На примере ОАО «Аптека № 73» показали диаграмму прецедентов и спроектировали диаграмму действий бизнес-процесса «Планирование закупок, формирование заказов поставщикам».