Файл: Разработка регламента выполнения процесса «Учет реализации лекарственных препаратов через аптечную сеть (Основные понятия процессного подхода).pdf

Рисунок 2.6 - Диаграмма действий бизнес-процесса "Продажи"

Общее описание бизнес-процесса "Взаиморасчеты с клиентами"

1. Менеджер отдела продаж до 10 раз в день отгружает товары клиентам в соответствии с договорами и Приказом по кредитной линии. Одновременно с отгрузкой товара менеджер отдела продаж выставляет счет клиенту. Счет регистрируется в реестре счетов.
2. По факту произведенной отгрузки менеджер отдела продаж делает запись в журнале отгрузок и оплат, тем самым фиксируя задолженность клиента.
3. Бухгалтер компании ежедневно получает и обрабатывает выписки с расчетных счетов банков. Бухгалтер на основании банковской выписки определяет оплаченные счета и делает отметку об оплате счета в реестре счетов.
4. Менеджер отдела продаж ежедневно контролирует поступление платежей от клиентов, проверяя допустимый срок оплаты счета.
5. Если платежи по счету на расчетный счет компании не поступили и срок оплаты счета истек, то менеджер отдела продаж блокирует отгрузку товара клиенту. Если клиент оплатил счет, то менеджер вносит сведения об оплате в Журнал отгрузок и оплат.
6. Бухгалтер в конце каждого месяца выводит сальдо взаиморасчетов с клиентами.

2.3. Схемы управления процессов, схемы подпроцессов

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

Прецедент (Use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецедент только декларирует описание какого-либо действия системы, отвечая на вопрос «что делать?», но не указывает какими средствами. Конкретная реализация специфицируемого прецедентом поведения обеспечивается классом, кооперацией классов или компонентом.

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

---

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

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

Возвращаясь к моделированию информационно-справочной системы «Аптека», выделим прецеденты:

Редактирование данных,

Поиск лекарства,

Учет заказов,

Формирование отчетов,

Выдача рецепта,

Авторизация.

Элементы диаграммы прецедентов (прецеденты и актеры) должны быть связаны отношениями.

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

Кроме того, между прецедентами в языке UML определены две специфические зависимости – отношение включения и отношение расширения.

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

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

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

---

Отношение расширения изображают в виде зависимости со стереотипом «extend». Точки расширения базового сценария перечисляются в дополнительном разделе. Они являются просто метками, которые могут появляться в потоке базового прецедента.

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

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

Диаграмма прецедентов информационно-справочной системы «Аптека» показана на рис. 2.1.

Прецедент поиск лекарства предполагает поиск по группе и поиск по названию.

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

Рисунок 2.7 – Контекстная диаграмма

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

• • «Законодательство в области здравоохранения»;
  • «Устав предприятия».

В качестве входных данных выступают:

• • «Данные о товаре»;
  • «Данные о поставщике».

Результатом работы системы предусмотрены следующие выходные документы:

• • «Отчет о приходе»;
  • «Отчет о расходе».

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

Рисунок 2.8 –Декомпозиция контекстной диаграммы

В декомпозиции функциональной модели можно выделить два основных блока:

• • • • «Приход»;
      • «Расход».

Рисунок 2.9 – Декомпозиция контекстной диаграммы «Хранение лекарства»

М

М

М

М

М

М

М

1

1

М

1

Товар

Имеет

Поставляет

---

Категория

Ед. измерения

Страна

Имеет

Имеет

Поставщик

М

День

День

Приход

Расходдод

Рисунок 2.10 - ER-диаграммы типов данных будущей АИС

Вид с точки зрения проектирования является основным этапом концептуальной проработки модели. На данном этапе вводятся основные абстракции, определяются классы, и интерфейсы посредством которых реализуется решение поставленных задач. Если прецеденты только декларируют поведение системы, то на этапе разработки вида с точки зрения проектирования определяется какими средствами данные прецеденты будут реализованы. Статические аспекты данного вида разрабатываются посредством диаграммы классов, динамические – посредством диаграмм взаимодействий и состояний (автомат).

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

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

– является четко очерченной абстракцией некоторого понятия из словаря проблемной области или области решения;

– содержит небольшой, точно определенный набор обязанностей и выполняет каждую из них;

– поддерживает четкое разделение спецификаций абстракции и ее реализации;

– понятен и прост, но в то же время допускает расширение и адаптацию к новым задачам.

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

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

---

При моделировании класса Т_Адрес атрибут индекс зададим посредством примитивного типа T_POSTIDX, определяемого как шестизначное десятичное число. Примитивные типы моделируются стереотипом «type», диапазон значений указывается через ограничения, заключенные в фигурные скобки.

В классе лекарства выделим специфические атрибуты, относящиеся только к лекарству: дата поступления, цена (лекарства), единицы измерения, имеющееся количество, срок годности. Атрибут единицы измерения лучше определить специализированным типом через перечисление. Перечисления моделируются классом со стереотипом «enum» (enumeration – перечисление), допустимые значения записываются как атрибуты, метки, определяющие видимость атрибутов при этом подавляются. В рассматриваемом примере через перечисление введем специализированный класс Т_ЕдИзм, определяющий возможные единицы измерения через перечисления. В данном случае, как и везде в подобных случаях при создании классов, специфицирующих атрибуты основного класса, устанавливаются отношения зависимости.

Учитывая, что и лекарства и рецепт имеют общие атрибуты можно ввести дополнительный абстрактный класс, например, медикаменты, являющийся суперклассом для классов лекарства и рецепт, что позволит несколько сократить число связей. Класс медикаменты имеет атрибуты: наименование, группа. Атрибут группа посредством введенного через перечисление специализированного типа Т_Группа определяет к какой группе относится лекарство: к жаропонижающим, желчегонным, против гриппа или антибиотикам.

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

Класс фармацевт имеет атрибут квалификация. Класс врач имеет атрибут специальность.

При визуализации структуры классов следует обращать внимание на видимость атрибутов. Все рассмотренные атрибуты должны быть доступны и иметь видимость Public (обозначается знаком «+» или пиктограммой без замка). В рассмотренных классах мы делали упор на структуру, а не на поведение (операции не описывались и не предполагается их описывать), поэтому для облегчения восприятия диаграммы желательно изображение операций подавить.

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

---