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

Разработка модели автоматизированной системы «Аптека №73»

Содержание:

Введение

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

Проектирование – это разработка технического проекта новой ИС. Это разработка детализированных моделей системной архитектуры и ее внутренних механизмов, построение ее скелета, определение идей, технологий, базовых сущностей, моделей данных, разработка прототипов интерфейсов пользователя и подходов к реализации требуемых функций. В проектировании создается структура объектов. Результатом работы обычно выступает технический проект.

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

Целью курсовой работы является разработка модели автоматизированной системы «Аптека №73», в которой требуется выполнить моделирование предметной области аптеки, используя язык UML, подготовить техническую документацию для разработки программного продукта (техническое задание на программное обеспечение и спецификации).

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

Задачи работы:

рассмотреть понятие и применение UML-диаграмм;
рассмотреть основные виды UML-диаграмм;
дать краткую характеристику ОАО «Аптека № 73»;
описание бизнес-процессов и спецификацию настроек ИС в ОАО «Аптека № 73» ;
составить проект реализации операций бизнес-процесса «Планирование закупок и размещение заказов поставщикам».

Объект исследования – аптечная компания ОАО «Аптека № 73».

Предмет исследования – операции бизнес-процесса «Планирование закупок и размещение заказов поставщикам»

Научно-методической основой работы служат труды отечественных и зарубежных ученых в области ИТ - инфраструктуры, теории проектирования. При выполнении работы использовалась научно-методическая литература, публикации в периодической печати и научных изданиях, материалы Интернет-порталов, информация, предоставленная ОАО «Аптека № 73».

Методы исследования – анализ информации, методы анализа информационных показателей.

Глава 1. Теоретические основы и виды диаграмм UML

1. Понятие и применение UML

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

История этого языка началась, по компьютерным меркам, не так уж недавно, но и не сказать, чтобы сильно давно - в 1994 году. Так что UML практически ровесник нашей газеты. Зародился он в недрах компании Rational Software, которая задумала выпустить на рынок новый язык объектно-ориентированного моделирования - естественно, лучший, чем все, которые уже существовали на тот момент.

Обычно начало истории UML связывают с фамилиями Буч, Рамбо и присоединившегося к ним позже Якобсона, которые в конце 1995 уже создали консорциум Object Management Group (OMG), который осенью 1996 выпустил версию 0.9 спецификации UML, которую многие считают важной вехой в истории языка. Поскольку после неё к консорциуму присоединились компании Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, сама прародительница UML Rational Software, а также Texas Instruments и Unisys. С их помощью в январе 1997 увидела свет версия 1.0 стандарта. Но сейчас, конечно, более актуальной является выпущенная в 2005-м версия 2.0.

UML - язык формальный и искусственный. Искусственный он потому, что у него имеются авторы: Гради Буч, Ивар Якобсон и Джеймс Рамбо(в то же время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками). Формальным его можно назвать, поскольку имеются правила его употребления (правда, описание UML содержит и явно неформальные элементы). Еще один нюанс: UML - графический язык моделироапния общего назначения (т. е. его можно применять для проектирования чего угодно - от простых качелей, до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.

Как и любой формальный искусственный язык, UML содержит следующие части:

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

UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.

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

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

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

Ни одна отдельная диаграмма не является моделью. Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, а не одна диаграмма, вырванная из контекста. Более подробно рассмотрим типы диаграмм.

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

2.2. Виды UML- диаграммы

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

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

Диаграммы классов (class diagram), - носит структурный характер.

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

Основным элементом диаграммы классов является класс.

Обозначается значком:

Рисунок 1 – Значок диаграммы классов

Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции - в терминах UML).

Абстрактные классы отличаются наклонным написанием заголовка:

Рисунок 2 – Значок абстрактных классов

Под атрибутами класса в терминологии UML понимают его поля.

Атрибуты записываются с указанием доступности, имени и типа.

Например:

Рисунок 3 – Атрибуты

Знак «-» означает, что атрибут является приватным (private).

Знак «+» означает, что атрибут является публичным (public).

Знак «#» означает, что атрибут является защищенным(protected).

После имени следует указание типа атрибута.

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

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

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

Проще всего привести описание диаграммы коммуникаций на примере:

Рисунок 4 – Описание диаграммы коммуникаций

На примере видим, что актор User взаимодействует с экземпляром страницы LoginPage, который в свою очередь работает с классом SecutiryManager, который оперирует объектами типа User.

Элементы диаграммы коммуникаций могут быть связаны отношением «Ассоциация». Как я уже указывал выше Ассоциация имеем достаточно широкое значение и может трактоваться по-разному.

Диаграммы прецедентов (use case diagram), является отправной точкой в процессе моделирования. Она предназначена для описания взаимодействия проектируемой системы с любыми внешними или внутренними объектами - пользователями, другими системами и т.п.

Основными понятиями при работе с диаграммой вариантов использования являютсяАктор (Actor) и Вариант использования (Use case).

Актор – это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой.

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

Рисунок 5 – Значок актора

Друг с другом акторы могут быть связаны различного рода отношениями.

Например, акторы могут наследоваться друг от друга.

Рисунок 6 – Акторы наследуются друг от друга

Диаграммы взаимодействия, на которых представлены связи между объектами, показаны, в частности, сообщения, которыми объекты могут обмениваться. Обычно рассматриваются два частных случая это вида диаграмм: диаграммы последовательностей (sequence diagram), которые отражают временную упорядоченность сообщений, и диаграммы кооперации (collaboration diagram), на которых показана структурная организация обменивающихся сообщениями объектов. Эти виды диаграмм являются изоморфными, то есть свободно могут быть трансформированы друг в друга.

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

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

Диаграммы состояний состоят из элементов двух основных типов: Состояний и Переходов.

Элемент Состояние (State) отображает состояние объекта или процесса в какой-либо момент времени.

Обозначается значком:

Рисунок 7 – Значок состояния

Переход (Transition) – элемент, отображающий путь перехода из одного состояния в другое.

Например:

Рисунок 8 – Переход

Для обозначения начала и конца всего процесса переходов используются псевдосостояния: инициирующее (Initial) и финализирующее (Final).

Если Состояние сопряжено с некоторой деятельностью, то это тоже отображается на диаграмме.

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

Рисунок 9 – Переход по результатам деятельности

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

Кроме обычных Состояний (State) существуют также Суперсостяния (State Machine), которые могут включать в себя другие состояния и переходы.

При этом контекст Суперсостояния является актуальным для всех элементов, находящихся внутри этого Суперсостояния.

Рисунок 10 – Суперсостояние

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

Если несколько параллельных потоков переходов должны быть синхронизироваться в какой-то момент, то для это используется псевдо-состояние Synch.

Существует также дополнительный элемент Fork/Join – используется для разбивки или объединения нескольких потоков состояний.

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

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

Диаграммы активностей имеют те же элементы, что и диаграммы состояний, а именно: псевдо-активности начала и конца потоков, переходы, Fork/Join, Суперактивности.

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

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

Кроме того, на этой диаграмме присутствует новый элемент Решение (Decision) – Этот элемент знаком нам по блок-схемам и обозначает момент ветвления или соединения потоков. Отличие от Fork/Join состоит в том, что процесс продолжается только по одной ветке, в то время как после Fork/Join – по всем веткам параллельно.

Существенным дополнением диаграммы деятельности является элемент Partition, который сам по себе логического значения не имеет и предназначен для визуальной группировки работ по какому-либо признаку.

Диаграммы компонентов (component diagram), предназначены для грамотного разделения приложения на модули, что является очень сложной задачей. Это позволяет эффективно распределить работу внутри коллектива разработчиков и избежать ошибок несовместимости компонент приложения, правильно работающих в отдельности. Использование грамотного разделения программы на компоненты дает возможность накопления наработок в отдельных областях (создания библиотек готовых компонентов), их повторного использования и сборки готовых программ из ранее разработанных компонентов.

Рисунок 12 – Диаграмма компонентов системы управления страховыми полисами

Диаграммы развертывания (deployment diagram), на которых представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.

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

Глава 2. Проектирование реализации операций бизнес-процесса в информационной системе

2.1. Краткая характеристика ОАО «Аптека № 73»

ОАО «Аптека № 73» — это единственная аптечная компания на территории Верхоянского района. Аптека предлагает покупателям большой ассортимент лекарственных средств, товаров для здорового образа жизни и красоты. ОАО «Аптека № 73» была зарегистрирована 25 декабря 2008 года.

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

ОАО «Аптека № 73» придерживается стратегии расширения ассортимента, которая предполагает ввод новых товарных групп и располагает широким ассортиментным портфелем, включающий лечебную косметику, антисептики и дезинфицирующие препараты, антигистаминные препараты, косметические средства, спортивное питание, товары для беременных и кормящих женщин, товары для новорожденных, в том числе детское питание и др.

Основными направлениями деятельности общества являются:

обеспечение населения лекарственными средствами, изделиями медицинского назначения, предметами очковой оптики;
снабжение лекарственными средствами и изделиями медицинского назначения лечебно-профилактических учреждений (ЛПУ) Верхоянского района Республики Саха(Якутия), а также детских садов, школ, интернатов и т.п.;
снабжение иммунобиологическими препаратами, дезинфицирующими средствами, лекарственным растительным сырьем населения и ЛПУ Верхоянского района.
оставку и отпуск лекарственных средств отдельным категориям граждан по льготным ценам;
увеличение прибыли общества;
улучшение благосостояния работников общества.

Общество имеет 1 филиал по всей территории района.

Учредителем Общества и единственным акционером с владением 100% пакета акций является Республика Саха (Якутия).

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

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

На момент проведения диагностики штат компании составляет 7 сотрудников.

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

В процессе выполнения практического задания проводится анализ и оформление результатов обследования деятельности ОАО «Аптека № 73» и на его основе разрабатываются документы, необходимые для настройки типовой ИС.

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

Предварительная информация.
Видение выполнения проекта и границы проекта.
Отчет об обследовании.
Функциональные требования к информационной системе.

Основными целями проекта автоматизации ОАО «Аптека № 73» являются:

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

В рамках проекта развертывание новой системы предполагается осуществить только в следующих подразделениях ОАО «Аптека № 73»:

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

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

Список программного обеспечения, используемого компанией на момент обследования

"1С: Предприятие 8.3" ("Бухгалтерия", "Торговля", "Зарплата", "Касса", "Банк") для работы бухгалтерии.

Две собственные разработки на базе конфигуратора "1С" – "Закупки" и "Заказы поставщикам".

MS Excel для планирования закупок.

Таблица 1

Существующий уровень автоматизации

Количество рабочих станций, всего:	36
Количество сотрудников отдела IT	1
Количество ПК, одновременно работающих в сети	2
Наличие и форма связи с удаленными объектами	Терминальная связь со складом
Количество рабочих станций на удаленном объекте	2
Характеристики компьютеров	Intel® Celeron 2957U 1.4Ггц
Операционная система	Windows 10
Системы, которые представляется возможным оставить без изменения	"1С: Предприятие 8.3" в модульном составе "Бухгалтерия", "Зарплата" для работы бухгалтерии

Одно из основных требований ОАО «Аптека № 73» к будущему решению состоит в том, чтобы оно было построено на фундаменте единой интегрированной системы, а работа всех сотрудников велась в одном информационном пространстве.

Основные функциональные требования к информационной системе:

Аутентификация (получение пользовательских или администраторских прав);
Планирование заказов;
Размещение заказов;
Добавление или удаление товаров и изменение информации о товарах;
Просмотр, изменение и добавления статусов заказов;
Контроль взаиморасчетов с поставщиками
Получение отчетов для руководителя фирмы.

Таблица 2.

Пример форм отчетных документов:

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

Итого:

Отчет о требуемых закупках
Инвентарный код	Название материала/товара	Ед. измерения	Требуется закупить	Предыдущая дата приобретения
				Название поставщика	Дата последнего приобретения	Стоимость приобретения

ОАО «Аптека № 73» использует типовой российский план счетов, три аналитики (контрагенты, договора, регионы).

Таблица 3.

Фрагмент плана счетов

Наименование счета	Номер счета	Номер и наименование субсчета
Основные средства	01	По видам основных средств
Амортизация основных средств	02
Доходные вложения в материальные ценности	03	По видам материальных ценностей
Нематериальные активы	04	По видам нематериальных активов и по расходам на научно-исследовательские, опытно-конструкторские и технологические работы
Амортизация нематериальных активов	05
Продолжение таблицы 3.
Материалы	10
Налог на добавленную стоимость по приобретенным ценностям	19	1. Налог на добавленную стоимость при приобретении основных средств 2. Налог на добавленную стоимость по приобретенным нематериальным активам 3. Налог на добавленную стоимость по приобретенным материально-производственным запасам
Товары	41	1. Товары на складах 2. Товары в розничной торговле 3. Тара под товаром и порожняя 4. Покупные изделия
Касса	50	1. Касса организации 2. Операционная касса 3. Денежные документы

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

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

Каждый элемент справочника характеризуется кодом и наименованием. Код справочника также отражает уровни иерархии. Справочники клиентов и договоров имеют трехуровневую структуру. Справочник поставщиков - двухуровневую структуру. В коде справочника для отображения уровня применен символ подчеркивания. Например, в коде справочника клиенты первый уровень обозначен символами "АС"-покупатель; второй уровень "Ар"-аптеки, "Ds"-дистрибуторы; для обозначения третьего уровня предусмотрены порядковые номера 00001, 00002 и т.д. с количеством знаков в номере 5.

Таблица 4.

Фрагмент описания справочника

Наименование справочника	Код	Наименование
Клиенты	AC_Ap_00001	Покупатель_ АПТЕКИ
	AC_Ds_00001	Покупатель_ Дистрибуторы
	OTHER_00001	Прочие
Поставщики/ Подрядчики	B_00001	Банки
	L_00001	Частные лица
	I_00001	Страховые организации
	OTHER_00001	Прочие
	B_00001	Банки
Договора
1 –наши услуги	1_COM_D/M/E	Договор комиссии_Д/M/Г по нашим услугам
2- услуги нам	1_SERV_D/M/E	Договор на оказание наших услуг_Д/M/Г
	2_COM_D/M/E	Договор комиссии_Д/M/Г по услугам нам
	2_SERV_D/M/E	Договор на оказание услуг нам_Д/M/Г
	1_COM_D/M/E	Договор комиссии_Д/M/Г по нашим услугам

Построим организационную структуру ОАО «Аптека № 73».

Рисунок 13 – Оргструктура ОАО «Аптека № 73»

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

Бизнес-процессы компании, подлежащие автоматизации, приведены в следующей таблице:

Таблица 5.

Бизнес- процессы ОАО «Аптека № 73»

№	Код бизнес-процесса	Наименование бизнес-процесса
1	Закуп-1	Закупки
2	Склад-2	Запасы-Склад
3	Врасч-3	Взаиморасчеты с поставщиками

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

Курсовая - Информационная система Аптека

Рисунок 14 – Диаграмма прецедентов «Аптека № 73»

2.3. Описание бизнес-процессов и спецификация настроек ИС

Бизнес-процессы компании, подлежащие автоматизации, приведены в следующей таблице:

Таблица 6.

Бизнес-процессы, подлежащие автоматизации

Номер бизнес-процесса	Название бизнес-процесса
1Пл_Зак	Планирование закупок

Общее описание бизнес- процесса:

1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные внешней и внутренней статистики продаж медикаментов в виде отчетов продаж.

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

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

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

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

6. Затем в группе логистики ежедневно по плану заявок, графику поставок, прайс-листам поставщиков формируются заказы поставщикам.

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

8. Если затраты на сертификацию превышают внутрифирменные нормы, то менеджер группы логистики повторяет процесс формирования заказов поставщикам. Формируются новые заказы.

9. Ежедневно подготовленный заказ поставщику акцептуется, заказ должен подписать менеджер по логистике и директор Департамента маркетинга и управления товарными запасами.

10. Ежедневно менеджер группы логистики направляет заказ в отдел закупок. Менеджер отдела закупок направляет заказ поставщику.

2.4. Проектирование реализации операций бизнес-процесса «Планирование закупок и размещение заказов поставщикам»

Составим таблицу операций бизнес процесса и внесем все операции в соответствии с общим описанием и диаграммой действий. Для этого проставим краткое наименование диаграммы и укажем номер операции – 1Пл_Зак. Также укажем исполнителей операции (менеджер группы планирования и маркетинга, менеджер отдела закупок, менеджер группы логистики). В ходе обследования компании определим частоту выполнения каждой операции. Проставим названия документов, которые используются в данной операции (входящие и исходящие документы).

Таблица 7.

Операции бизнес-процесса "Планирование закупок и размещение заказов поставщикам"

Диаграмма и номер операции на диаграмме	Операция	Исполнитель	Как часто	Входящие документы (документы-основания)	Исходящий документ (составляемый документ)
1	2	3	4	5	6
1Пл_Зак 1а	Получение внутренней статистики продаж	Менеджер гр. планирования и маркетинга	Ежесуточно	Отчет-таблица собственных продаж	Нет
1Пл_Зак 1б	Получение внешней статистики продаж	Менеджер гр. планирования и маркетинга	Ежесуточно	Отчет –таблица продаж внешних источников	Нет
1Пл_Зак 2	Расчет потребностей в товаре	Менеджер гр. планирования и маркетинга	Еженедельно	Отчет-таблица собственных продаж Отчет – таблица продаж внешних источников	Таблица потребностей в товаре
1Пл_Зак 3	Ввод в систему прайс-листов поставщиков	Менеджер отдела закупок	Ежемесячно	Прайс-листы поставщиков	Прайс-листы поставщиков
1Пл_Зак 4	Анализ предложений поставщиков и действующих контрактов.	Менеджер отдела закупок	Ежемесячно и по мере необходимости	Прайс-листы поставщиков, Контракты действующие	Список поставщиков
1Пл_Зак 5	Выбор поставщиков	Менеджер отдела закупок	Ежемесячно и по мере необходимости	Список поставщиков	Список поставщиков с расстановкой приоритетов
1Пл_Зак 6	Формирование графика поставок без указания количества	Менеджер отдела закупок	Ежемесячно и по мере необходимости	Список поставщиков с расстановкой приоритетов Таблица потребностей в товаре	График поставок
1Пл_Зак 7	Расчёт необходимого количества закупок с учётом остатка на складе и страхового запаса	Менеджер группы логистики	Ежемесячно и по мере необходимости	Таблица потребностей в товаре, график поставок	План заявок на месяц
1Пл_Зак 8	Формирование заказов поставщикам с учетом складских остатков, товара в пути и резервного запаса	Менеджер группы логистики	Ежедневно по плану заявок	План заявок на месяц, график поставок, прайс-листы поставщиков.	Заказы поставщику
1Пл_Зак 9	Расчет затрат на сертификацию	Менеджер группы логистики	По мере необходимости	Заказы поставщику	Отчет о затратах на сертификацию
1Пл_Зак 10	Проверка затрат на непревышение нормы	Менеджер группы логистики	По мере необходимости	Отчет о затратах на сертификацию	Отчет о затратах на сертификацию
1Пл_Зак 11	Подпись заказа менеджером по логистике, директором ДМ	Менеджер группы логистики	Ежедневно	Заказы поставщику	Заказы поставщику акцептованные
1Пл_Зак 12	Направление заказа в отдел закупок	Менеджер группы логистики	Ежедневно	Заказы поставщику акцептованные	Заказы поставщику акцептовые
1Пл_Зак 13	Направление заказа поставщику	Менеджер отдела закупок	Ежедневно	Заказы поставщику акцептованные	Заказы поставщику акцептованные

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

Для начала выделим участников. В пунктах №1,2 приведенного описания участник процесса - «Менеджер группы планирования и маркетинга», в пунктах № 3,4 – «Менеджер отдела закупок», с 5 по 9 пункт участник бизнес-процесса – «Менеджер группы логистики». Следовательно, в бизнес-процессе «Планирование закупок и размещение заказов поставщикам» три участника – менеджер группы планирования и маркетинга, менеджер отдела закупок, менеджер группы логистики.
Следующим шагом мы сформируем диаграмму действий. Для этого необходимо разделим поле на 3 части, каждая часть поля отводится для отображения действий участника процесса.
Чтобы сформировать диаграмму через MS Visio необходимо открыть в папке Software / UML Model Diagramm форму UML Activity.
Для удобства построения диаграммы на листе расположите его горизонтально (File / Page Setup / Landscape).
На панели инструментов «Стандартная» нужно зафиксировать пиктограмму с изображением линии Line Tool, для этого нужно удерживать левую клавишу мыши и разделить лист на три части.
На панели инструментов «Стандартная» зафиксируем пиктограмму с изображением буквы «А». Внесем в качестве заголовка полное наименование бизнес-процесса, сокращенное наименование (1Пл_Зак) и участников бизнес-процесса в соответствии с рисунком 15.

Рисунок 15 – Подготовительная стадия для изображения диаграммы действий

Проанализируем общее описание бизнес-процесса и выделим участника процесса, с которого начинается процесс. Очевидно, что это менеджер группы планирования и маркетинга. Действительно, процесс закупок должен начинаться только после того, как определена потребность компании в товаре (медикаментах).
Обозначим на диаграмме начало процесса символом «Initial state» и опустим стрелку вниз (рис. 3). Работа с графическими формами должна осуществляться только при активированной пиктограмме с изображением стрелки на панели «Форматирование».
Воспользуемся текстовым описанием, выделим действия, выполняемые менеджером группы планирования и маркетинга. Действия (операции), выполняемые менеджером группы планирования и маркетинга: «Получение внутренней статистики продаж», «Получение внешней статистики продаж», «Расчет потребности в товаре».
Отобразим на диаграмме действия, которые выполняет менеджер группы планирования и маркетинга. Обратим внимание, что процессы получения внутренней и внешней статистики происходят независимо друг от друга. Неважно, в какой последовательности будут получены данные статистики, поэтому действия (операции) по получению внутренней и внешней статистики отобразите на схеме параллельно.
Для изображения действия на диаграмме используем фигуру . Впишим внутри фигуры наименование и порядковый номер действия (операции). Пусть параллельные операции – имеют номера 1а), 1б). Для ввода текста на панели инструментов «Стандартная» зафиксируем пиктограмму с изображением буквы «А».
Действия соединим на диаграмме стрелками, перенося их мышкой с формы. Стрелки присоедините к отмеченным крестиком местам на фигурах.
Для изображения параллельных процессов получения внутренней и внешней статистики примените (Transition|Fork).
Расчет потребностей в товаре менеджер выполняет только после того, как получит и внутреннюю, и внешнюю статистику, следовательно, необходимо объединить параллельные процессы получения статистики в один. Для объединения независимых, параллельных процессов используйте (Transition|Join).
В результате операции по расчету потребностей в товаре (операция №2) (п. 2 общего описания) менеджер формирует документ - таблицу потребностей в товаре. Для отображения документа на диаграмме используйте изображение прямоугольника. Нарисуйте прямоугольник мышкой, зафиксировав на панели инструментов «Стандатная» соответствующую пиктограмму Rectangle Tool.
Операция и получаемый в результате ее выполнения документ на диаграмме соединяются пунктирной линией. Для изображения пунктирной линии зафиксируем пиктограмму Line Tool на панели инструментов «Стандартная» и выберите пунктирную линию на панели инструментов «Форматирование», используя меню пиктограммы ( Line Patter).
В результате на диаграмме (рис. 4) получаем изображение действий (операций), осуществляемых менеджером группы планирования и маркетинга.
После того как менеджер группы планирования и маркетинга сформировал таблицу потребностей в товаре, в работу включается менеджер отдела закупок, поэтому направьте стрелку от операции «Расчет потребности в товаре» в поле деятельности менеджера закупок, как показано на рисунке 16.

Рисунок 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» показали диаграмму прецедентов и спроектировали диаграмму действий бизнес-процесса «Планирование закупок, формирование заказов поставщикам».

СПИСОК ЛИТЕРАТУРЫ

ИСО/МЭК 15288:2002 - Проектирование систем — Процессы жизненного цикла системы.
Андерсен Бьерн. Бизнес-процессы. Инструменты совершенствования. – Москва, РИА «Стандарты и качество», 2003 г.
Шафер Д., Фатрелл Р., Шафер Л. Управление программными проектами. . М.: Изд. дом «Вильямс», 2004.
Мейер М. Теория реляционных баз данных. – М.: Мир, 2006.
Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов: Учеб. пособие. , - М.: Финансы и статистика, 2007.
Н. М. Абдикеев, Т. П. Данько, С. В. Ильдеменов и др. Реинжиниринг бизнес-процессов - М.: Эксмо, 2005.
Яблочников Е.И., Молочник В.И., Фомина Ю.Н. Реинжиниринг бизнес- процессов проектирования и производства / Учебное пособие – СПб: СПбГУИТМО, 2008. – 152 с.
Меняев М.Ф Информационные технологии управления: Книга 3: Системы управления организацией М.: Омега-Л, 2003. – 464 с
Федоров, И. Сравнительный анализ нотаций моделирования бизнес-процессов / И. Федоров // Открытие системы. — 2011.– № 8. — C.28.
Репин В.В., Элиферов В.Г. Процессный подход к управлению, моделирование бизнес- процессов. Москва - 2008.