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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

- Провести анализ и описание предметной области;

- Создать хранилище данных;

- Обеспечить систему функцией контроля правильности оформления документов;

- Изучить особенности работы пользователя и области применения информационной системы;

- Обеспечить максимальную безопасность данных в системе;

- Разработать интерфейс пользователя, учитывающий особенности специфики работы пользователя;

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

1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ РЕГЛАМЕНТА БИЗНЕС-ПРОЦЕССОВ

1.1Основные понятия процессного подхода

Для того чтобы приступить к реализации курсового проекта «Разработка регламента выполнения процесса «Учет реализации лекарственных препаратов через аптечную сеть», необходимо разобраться в теоретических аспектах. Перечислим основные понятия процессного подхода.

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

Процесс проектирования - представляет собой преобразование входной информации об объекте и методах проектирования в проект ИС в соответствии с ГОСТом.

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

Субъектами проектирования являются проектная организация и организация заказчик.

Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» {divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:

- количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);

- связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» - High Cohesion).

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

- каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

- каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

Термин CASE-средства (Computer Aided Software Engineering) означает программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.

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

- подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

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

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

Наибольшая потребность в CASE-средствах – начальные этапы анализа и спецификации требований. Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколько порядков превышает цену ошибок, выявленных на более поздних этапах разработки.

Преимущества CASE-технологии по сравнению с традиционной технологией оригинального (ручного) проектирования сводятся к следующему:

- улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

- возможность повторного использования компонентов разработки;

- поддержание адаптивности и сопровождения ЭИС;

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

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

- возможность коллективной разработки ЭИС в режиме реального времени.

CASE-системы классифицируются по следующим признакам:

1. по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2. по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными;

3. по степени интегрированности: tools (отдельные локальные средства), toolkit (набор интегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных – репозиторием);

4. по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ЛВС, ГВС и смешанного типа;

5. по режиму коллективной разработки проекта: на поддерживающие коллективную разработку, ориентированные на режим реального времени и на режим объединения подпроектов;

6. по типу операционной системы (ОС): Windows, UNIX, OS/2 и др.

Архитектура CASE-средства представлена на рисунке 1.1

Рисунок 1.1- Архитектура CASE-средства

Ядро системы – база данных проекта – Репозиторий (словарь данных), представляющий собой специализированную базу данных, предназначенную для отображения состояния проектируемой ИС в каждый момент времени.

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

- проектировщиков и их права доступа к различным компонентам системы;

- организационных структур;

- диаграмм, и связей между ними;

- компонентов диаграмм;

- структур данных;

- программных модулей;

- процедур;

- библиотеки модулей и т.д.

Графический редактор позволяет выполнять следующие операции:

- создавать элементы диаграмм, их взаимосвязи и описания;

- задавать описания элементов диаграмм  и связей между ними;

- редактировать элементы диаграмм, их взаимосвязи и описания.

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

Верификатор – служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС.

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

Администратор проекта – это инструменты, необходимые для выполнения таких функций, как:

- инициализация проекта:

- задания начальных параметров проекта;

- назначения и изменения прав доступа к элементам проекта;

- мониторинга выполнения проекта.

Сервис – набор системных утилит по обслуживанию репозитория (архивация данных, восстановления данных и создания нового репозитория).

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

Одним из наиболее популярных CASE-средств, поддерживающих методологию структурного (функционального проектирования) является пакет AllFusion Modeling Suite, выпущенный компанией Computer Associates.

В этот пакет входит 5 продуктов:

1.  AllFusion Process Modeler .AllFusion Process Modeler является новым именем хорошо известного BPwin.

2.  AllFusion ERwin Data Modeler - инструмент создания моделей данных и генерации схем баз данных.

3.  AllFusion Data Model Validator - система поиска и исправления ошибок модели данных.

4.  AllFusion Model Manager  Система организации коллективной работы, хранилище моделей BPwin и ERwin.

5.  AIIFusion Component Modeler -инструмент создания объектных моделей.

 

Рисунок 1.2 - Общая схема взаимодействия инструментальных средств AllFusion Modeling Suite

 

Для проведения анализа и реорганизации бизнес-процессов предназначено CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как «внешняя ссылка» и «хранилище данных», что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент «перекресток», что позволяет описать логику взаимодействия компонентов системы.

На основе модели BPwin можно построить модель данных. Для построения модели данных Computer Associates предлагает мощный и удобный инструмент - AIIFusion ERwin Data Modeler (ERwin). Хотя процесс преобразования модели BPwin в модель данных плохо формализуется и поэтому полностью не автоматизирован, Computer Associates предлагает удобный инструмент для облегчения построения модели данных на основе функциональной модели - механизм двунаправленной связи BPwin - ERwin (стрелка 1 на рис. 1.2). ERwin имеет два уровня представления модели - логический и физический, причем модель данных может содержать как оба этих уровня, так и только один из них. Модели, содержащие только один уровень, могут быть синхронизированы, что особенно удобно при создании гетерогенных информационных систем. На логическом уровне данные не связаны с конкретной СУБД, поэтому могут быть наглядно представлены даже для неспециалистов. Физический уровень данных - это, по существу, отображение системного каталога, который зависит от конкретной реализации СУБД. Создание одного логического уровня и нескольких соответствующих ему физических позволяет вести одновременную разработку баз данных для нескольких СУБД. ERwin позволяет проводить процессы прямого и обратного проектирования баз данных (стрелка 2, рисунок 1.2). Это означает, что по модели данных можно сгенерировать схему базы данных или автоматически создать модель данных на основе информации системного каталога. Кроме того, ERwin позволяет выравнивать модель и содержимое системного каталога после редактирования.

Для больших, содержащих сотни таблиц моделей данных существенной проблемой становится поиск и исправление ошибок. Решение этой проблемы вручную - слишком трудоемкая задача, которая может недопустимо затянуть выполнение проекта. AllFusion Data Model Validator (ERwin Examiner) - основанный на базе знаний инструмент, который позволяет анализировать структуру баз данных с целью выявления недочетов и ошибок проектирования. ERwin Examiner дополняет функциональность ERwin, автоматизируя трудоемкую задачу поиска и исправления ошибок. ERwin Examiner может использовать в качестве источника метаданных готовую модель ERwin, DDL - скрипт или провести обратное проектирование базы данных (стрелки 3 и 4 на рисунке 1.2).

При проектировании больших ИС ключевой проблемой является создание качественной документации по моделям. BPwin и ERwin позволяют генерировать разнообразные отчеты, которые могут быть использованы для анализа и документирования моделей. Отчеты могут быть экспортированы в распространенные форматы - текстовый, MS Office, HTML и др. Результаты экспорта могут быть использованы для создания отчетов с помощью средств других производителей, например Crystal Reports. BPwin поддерживает также экспорт и импорт модели в текстовый файл формата IDL, который является стандартом для экспорта и импорта моделей IDEF0, позволяет разрабатывать функциональные модели одновременно инструментальными средствами различных производителей.

Создание современных ИС, основанных на широком использовании распределенных вычислений, объединении традиционных и новейших информационных технологий, требует тесного взаимодействия всех участников проекта: менеджеров, бизнес-аналитиков и системных аналитиков, администраторов баз данных, разработчиков. Для этого использующиеся на разных этапах и разными специалистами средства моделирования и разработки должны быть объединены общей системой организации совместной работы. Фирма Computer Associates предлагает систему ModelMart - хранилище моделей, к которому открыт доступ для участников проекта создания ИС (стрелка 5 на рисунке выше).

1.2 Этапы разработки регламента процесса

После выбора Case-средства разработки регламента процесса, необходимо создать техническое задание

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

На основе утвержденного технического задания начинается стадия «Техно-рабочего проектирования», включающая два этапа работ: техническое и рабочее проектирование.

Техническое проектирование содержит:

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

- разработку локальных проектных решений, к числу которых относятся следующие операции:

-   разработка «Постановки задачи» (рис. 1.3), для задач, входящих в состав функциональных подсистем;

- проектирование форм входных и выходных документов, макетов экранных форм документов, классификаторов экономической информации;

-  проектирование состава и структур файлов информационной базы;

-  проектирование внемашинной и внутримашинной технологии решения каждой задачи;

- уточнение состава технических средств.

 

Рисунок 1.3 - Содержание «Постановки задачи»

 

В состав «Характеристика задачи» входят:

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

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

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

- описание алгоритма – формализованное описание входных и результатных показателей, перечень формул расчета, описание математической модели, экономико-математических методов  и т.д.;

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

Наиболее ответственной работой, выполняемой на этапе «Рабочего проектирования» является «Кодирование и составление программной документации», в состав которой входит:

- описание программ;

- спецификация программ;

- тексты программ;

- контрольные примеры;

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

В состав «Рабочего проекта» входит технологическая документация, включающая технологические карты разрабатываемые на процессы обработки информации при решении задач, и инструкционные карты, составляемые на каждую технологическую операцию. Технологическая документация разрабатывается в соответствии с ГОСТ 3.11.09 – 82 «Система технологической документации. Термины и определения основных понятий».

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

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

В качестве примера рассмотрим одну из широко используемых систем такого проектирования – SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования) – это графические обозначения и подход к описанию систем.

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

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

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

Метод SADT реализован в виде стандарта IDEF0.

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

Наиболее удобным языком моделирования бизнес-процессов является 1DEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT-Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна «Методология структурного анализа и проектирования SADT») В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www .idef.com.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

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

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition -определение модели и описание области.

2. РАЗРАБОТКА РЕГЛАМЕНТА ВЫПОЛНЕНИЯ ПРОЦЕССА «УЧЕТ РЕАЛИЗАЦИИ ЛЕКАРСТВЕННЫХ ПРЕПАРАТОВ ЧЕРЕЗ АПТЕЧНУЮ СЕТЬ»

2.1. Характеристика предметной области

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

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

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

Предварительная информация

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

• Краткая информация о компании (профиль клиента).
• Цели проекта.
• Подразделения и пользователи системы.

На основе предварительной информации сформировано и согласовано с заказчиком общее представление о проекте:

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

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

Отчет об обследовании содержит следующие разделы:

- Анализ существующего уровня автоматизации.

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

- Общие требования к ИС

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

- Формы документов

- Устанавливается перечень и структура документов, которые должны формироваться системой.

- Описание системы учета

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

- Учетная политика компании

- План счетов и используемых аналитик

- Список типовых хозяйственных операций и их отражение в проводках

- Описание справочников

- По каждому справочнику, проектируемому в системе, дается описание необходимой иерархической структуры.

- Организационная диаграмма

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

- Описание состава автоматизируемых бизнес-процессов

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

- Диаграммы прецедентов

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

- Физическая диаграмма

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

- Описания бизнес-процессов (книга бизнес-процессов).

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

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

Уровень конкуренции для компании в последнее время возрос, так как на рынок вышли два новых конкурента, к которым перешла часть клиентов и ряд наиболее квалифицированных сотрудников ЗАО "РИГЛА". ЗАО "РИГЛА" имеет два филиала - в Курске и Санкт-Петербурге. Каждый филиал функционирует как самостоятельное юридическое лицо, являясь полностью принадлежащей ЗАО "Аптека-РИГЛА" дочерней компанией.

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

Адреса и телефоны

Феодосия, Симферопольское шоссе, д. 36, офис 109

Телефон: (978) 345-6789, факс: (978) 345-9876

Контактные лица

Борис Иванов - Генеральный директор

Дмитрий Кононов - Исполнительный директор

Артем Иванченко - Директор по маркетингу

Сотрудники

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

Основными целями проекта автоматизации компании "Аптека-РИГЛА" являются:

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

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

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

1. "1С: Предприятие 8.2" ("Бухгалтерия", "Торговля", "Зарплата", "Кадры", "Касса", "Банк") для работы бухгалтерии.
2. Две собственные разработки на базе конфигуратора "1С" - "Закупки" и "Продажи".
3. Собственная разработка на базе FOXPRO для финансового отдела.
4. Excel для планирования продаж.

Оргструктура предприятия оптовой торговли ЗАО "Аптека_РИГЛА" имеет следующий вид:

Рисунок 2.1 – организационная структура предприятия «Аптека-РИГЛА»

Диаграмма прецедентов компании "Аптека-РИГЛА"

На Диаграмме прецедентов представлены автоматизируемые бизнес-процессы компании и их исполнители.

Рисунок 2.2 – Диаграмма прецедентов компании

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

Внешняя статистика продаж - статистика по продажам, получаемая из сети аптек;

Внутренняя статистика продаж - статистика по продажам, получаемая из отчетов продаж клиентам компании;

Номенклатурная единица - наименование медикамента, завода-изготовителя;

ABC - классификация товара по выручке от продаж клиентам;

XYZ - классификация товара по рейтингу популярности;

Учетная цена - цена товара у поставщика с учетом скидок;

Действующие контракты - контракты, по которым имеются обязательства сторон на определенный период времени;

График поставок - очередность обращения к поставщикам, необходимая для поддержания деловых отношений;

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

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

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

2.2. Владелец процесса, выходы и входы, ресурсы процесса

Компания осуществляет закупки у отечественных и зарубежных производителей, следовательно, контрагентами компании являются отечественные и зарубежные поставщики медикаментов. Компания пользуется услугами транспортных компаний для доставки медикаментов. Следовательно, транспортные компании являются внешними контрагентами. Кроме того, компания реализует медикаменты через дистрибьюторскую сеть и сеть аптек. Следовательно, контрагентами компании являются покупатели (дистрибьюторы, аптеки). Таким образом, внешними контрагентами компании "РИГЛА" являются поставщики (отечественные, зарубежные), покупатели (дистрибьюторы, аптеки), транспортные компании.

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

Рисунок 2.3 – Физическая диаграмма компании

В целях упрощения задачи в дальнейшем объединим описание бизнес-процессов "Закупки" и "Планирование закупок" в один бизнес-процесс под названием "Планирование закупок и размещение заказов" и присвоим ему номер 1Пл_Зак.

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

Планирование закупок осуществляется в Департаменте маркетинга, в группе маркетинга и планирования. Планирование закупок осуществляется следующим образом:

1. Менеджер группы планирования и маркетинга ежесуточно получает от контрагентов данные внешней и внутренней статистики продаж медикаментов в виде отчетов продаж.
2. Для планирования закупок медикаментов менеджер группы планирования и маркетинга еженедельно на основании статистики продаж производит расчет потребности в товаре. В результате расчета формируется Таблица потребностей в товаре.
3. Определив количество и номенклатуру заказываемых товаров, менеджер отдела закупок приступает к анализу предложений поставщиков. Данный процесс осуществляется ежемесячно или по мере необходимости. Выбираются наиболее выгодные условия поставки. Для этого сравниваются цены поставщиков. Данные сведения берутся из прайс-листа для закупок. При выборе поставщика важно учесть предоставляемую отсрочку платежа. Эта информация берется из контрактов, отмеченных как приоритетные (действующие). В результате формируется список поставщиков, каждой позиции присваивается признак основного и запасных поставщиков в порядке убывания приоритета.
4. Менеджер отдела закупок ежемесячно на основании Таблицы потребностей в товаре и списка выбранных поставщиков формирует графики поставок с указанием сроков и периодичности, но без количества поставки.
5. Ежемесячно после определения потребности в товаре менеджер группы логистики рассчитывает необходимое количество закупок. Необходимое количество закупок рассчитывается на основании фактических запасов на складе, необходимого минимального и максимального уровня запасов. Нормы минимального и максимального количества запасов устанавливаются в днях. При расчете необходимого количества закупки учитывается также время товара в пути. Таким образом, данный расчет должен обеспечить возможность бесперебойного отпуска товара со склада. По результату расчетов формируется план заявок на месяц.
6. Затем в группе логистики ежедневно по плану заявок, графику поставок, прайс-листам поставщиков формируются заказы поставщикам.
7. Если предстоит сделать заказ импортному поставщику, то менеджер группы логистики рассчитывает затраты на сертификацию, создается отчет о затратах на сертификацию. Затраты на сертификацию проверяются на соответствие внутрифирменным нормам. Данная операция производится по мере необходимости.
8. Если затраты на сертификацию превышают внутрифирменные нормы, то менеджер группы логистики повторяет процесс формирования заказов поставщикам. Формируются новые заказы.
9. Ежедневно подготовленный заказ поставщику акцептуется, заказ должен подписать менеджер по логистике и директор Департамента маркетинга и управления товарными запасами.
10. Ежедневно менеджер группы логистики направляет заказ в отдел закупок. Менеджер отдела закупок направляет заказ поставщику.

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

Рисунок 2.4 - Диаграмма действий менеджера группы планирования и маркетинга

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

Рисунок 2.5 - Диаграмма действий бизнес-процесса "Запасы - Склад (приходование)"

Общее описание бизнес-процесса «Продажа»

1. Менеджер отдела продаж ежедневно получает от клиента Заказ на конкретную номенклатурную единицу медикаментов. В Заказе номенклатурных единиц клиент указывает желаемую отсрочку платежа.
2. При получении Заказа менеджер отдела продаж по справочнику лицензий проверяет наличие у клиента действующей лицензии на право реализации медикаментов. При отсутствии лицензии продажа медикаментов клиенту не производится. Наличие лицензии проверяется по мере необходимости.
3. Менеджер отдела продаж ежедневно проверяет наличие необходимого количества заказанных медикаментов на складе.
4. Если медикаментов недостаточно для выполнения заказа, то менеджер отдела продаж размещает Заказ в реестре "неудовлетворенный спрос". Затем менеджер ежедневно проверяет возможность выполнения Заказа, размещенного в реестре "неудовлетворенный спрос".
5. При наличии у клиента необходимой лицензии и достаточном количестве товара на складе в отделе продаж на основании Заказа и договора формируется Заявка на номенклатурные единицы. Заявки формируются ежедневно.
6. Ежедневно на основании Заявки менеджер отдела продаж осуществляет резервирование товара.
7. Менеджер отдела продаж ежедневно контролирует кредитный лимит и дебиторскую задолженность потенциальных покупателей.
8. Если кредитный лимит и дебиторская задолженность не превышают допустимых значений, то Заявка передается на склад в Учетно-операционный отдел.
9. При превышении кредитного лимита или наличии просроченной дебиторской задолженности свыше допустимого количества дней менеджер отдела продаж заявку в Учетно-операционный отдел не передает, процесс продаж приостанавливается, осуществляются переговоры с клиентом.
10. Менеджер учетно-операционного отдела, получив Заявку, ежедневно производит подборку номенклатурных единиц.
11. Менеджер учетно-операционного отдела ежедневно формирует упаковочные листы для вложения их в каждый ящик.
12. Менеджером учетно-операционного отдела ежедневно формируются для клиента следующие документы: счет, расходная накладная, счет-фактура.
13. При фактической отгрузке товара со склада осуществляется его списание. Списание медикаментов осуществляется по расходной накладной и сопровождается формированием проводки Д62-К41.

Рисунок 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 (обозначается знаком «+» или пиктограммой без замка). В рассмотренных классах мы делали упор на структуру, а не на поведение (операции не описывались и не предполагается их описывать), поэтому для облегчения восприятия диаграммы желательно изображение операций подавить.

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

Множественность отношения фармацевт – лекарства «многие к одному». Каждое лекарство относится к определенному фармацевту, в свою очередь определенному фармацевту может соответствовать несколько лекарств, поэтому ассоциация фармацевт – лекарства имеет тип множественности «многие к одному». На данной ассоциации со стороны фармацевта можно указать роль: учёт данных (т.е. формирование отчётов, редактирование данных и т.д.).

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

Аналогично введём ассоциацию между врачом и лекарством: тип множественности ассоциации «многие к одному».

Диаграмма классов приводится на рис. 2.11.

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

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

Перейдем к определению интерфейсов. Классы взаимодействуют с внешним миром через интерфейсы.

Интерфейс (Interface) – это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда – их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя. Интерфейс редко существует сам по себе – обычно он присоединяется к реализующему его классу или компоненту. Интерфейс всегда предполагает наличие некоторого «контракта» между стороной, которая декларирует выполнение ряда операций и стороной, которая эти операции реализует.

Рисунок 2.11 – Интерфейс будущего приложения

Рис. 2.12- Упрощенная диаграмма классов

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

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

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

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

Диаграмма последовательности ввода новой записи о лекарстве в системе «Аптека» представлена на рис. 2.13.

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

Рисунок 2.13 - Ввод данных о лекарстве. Диаграмма последовательности

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

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

Рисунок 2.14 - Ввод данных о лекарстве. Диаграмма кооперации

ЗАКЛЮЧЕНИЕ

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

Пользователям предлагается большое количество автоматизированных систем управления (АСУ). Есть системы, которые автоматизируют отдельный участок работы (например, бухгалтерский учет), и которые рассчитаны на охват всех сторон деятельности аптек или аптечных сетей.

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

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

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

1.Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – 2-е изд., перераб. И доп. – М.: Финансы и Статистика, 2006 – 544 с., с.24-36.

2.  Проектирование экономических информационных систем: Учебник/ Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов; под ред. Ю. Ф. Тельнова. – М.: Финансы и Статистика, 2003. – 512 с., Глава 13.

3.  Уткин В. Б. Информационные системы в экономике: Учебник для студ. высш. учеб, заведений / В. Б. Уткин, К. В. Балдин. — М.: Издательский центр «Академия», 2004. — 288с., Глава 4.

4. Базы данных. Учебник для высших учебных заведений. Под ред. А.Д. Хомоненко.- С-Петербург. – Корона принт.- 2002.

5. Дейт К. Руководство по реляционной СУБД DB2. – М.: Финансы и статистика, 1988. – 320 с.

6. Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

7. Тиори Т., Фрай Дж. Проектирование структур баз данных. В 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 с.

8. Хаббард Дж. Автоматизированное проектирование баз данных. – М.: Мир, 1984.

9. Терри Кватрани. Rational Rose и UML. Визуальное моделирование: Пер. с англ. – М.: ДМК Пресс, 2001. – 176 с.: ил.

10. Червенчук И.В. Моделирование информационных систем с помощью UML: Учебное пособие по курсу «Информационные системы и процессы, моделирование и управление». – Омск: Изд.-во ОГИС, 2006. – 48 с.

11. Рамбо Д., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. – СПб.: Питер, 2007. – 545 с.: ил.

12. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. – М. Мир, 1999. – 192 с.: ил.

13. Культин Н.Б. Основы программирования в Delphi 7. – СПБ.: БХВ – Петербург, 2003. – 608 с.:ил.

14. Малков О.Б. Работа с базами данных в среде Delphi: учебное пособие для студентов заочной формы обучения. – Омск, 2004. – 26 с.

15. www.pharmanet.direct.ru

16. www.remedium.ru.