2 Практическая часть
2.1 Описание предметной области
В данном курсовом проекте описана деятельность аптеки по реализации лекарств.
Рынок по реализации лекарственных препаратов на сегодняшний день является достаточно насыщенным, тем не менее, даже несмотря на это, развитие фармацевтической сети всегда привлекает инвесторов простотой организации аптечных учреждений. Во многом на это повлиял опыт других стран, в которых, не смотря ни на что, этот бизнес не только успешно функционирует, но и успешно развивается.
Аптечное учреждение занимается реализацией лекарств и других компонентов, выпускающих фармацевтической промышленностью, а также предоставляет возможность клиентам заказать нужное им лекарство у поставщика. В данном бизнес-процессе имеются клиент и поставщик – внешние сущности, и они непосредственно взаимодействуют с аптекой.
Администратор аптечного учреждения является главным звеном в бизнес-процессе, который должен поддерживать актуальную базу лекарств и сопутствующих продуктов фармацевтики, для большего спроса клиентов. Администратор работает с большим объемом информации, ведет базу поставщиков, а также клиентов, принимает заявки клиентов на заказы лекарств, непосредственно заказывает их у поставщика.
2.2 Документ описания требований АСУ Деятельность аптечного учреждения по реализации лекарственных препаратов
1. Предварительные замечания к проекту
1.1. Цели и рамки проекта
Целью данного проекта является разработка информационной системы для ведения и оптимизации работы аптечного учреждения.
АСУ «АПТЕКА» должна быть проста в использовании и не требовать от пользователя глубоких знаний.
1.2. Деловой контекст
Многие люди в наше время пользуются аптеками. Быть администратором аптечного учреждения и вести учет очень трудоёмкое дело. Для этого будет разработана простая в использовании программа
1.3. Участники проекта
Заказчик – Куренов Владимир Сергеевич(kerilev@mypochta.ru)
Разработчик – Волков Максим Сергеевич (volkov@coolsoft.com)
1.4. Идеи в отношении решений
Программа должна быть реализована в виде настольного
приложения для операционных систем семейств MS Windows.
2. Системные сервисы
2.1. Рамки системы
Аптека содержит каталог лекарственных препаратов, имеющихся в наличии в данный момент времени. Клиент, обратившийся в аптеку, выбирает лекарство по каталогу и покупает лекарственное средство, оплачивая его через кассовый аппарат. Дополнительно нужно предусмотреть возможность принимать заказы от клиентов на пополнение ассортимента, то есть, если какого-либо лекарства нет в каталоге, клиент может оставить соответствующую заявку.
Аптека должна периодически обновлять ассортимент лекарств и лекарственных препаратов, предлагаемых для реализации (с учетом срока годности и поступивших заявок). Аптека должна регулярно сдавать выручку инкассаторам.
2.2. Функциональные требования
Назначение системы.
С помощью создаваемой информационной системы, аптечное учреждение может предлагать следующий перечень услуг:
быстрый поиск лекарственного средства по названию
поиск лекарств по названию болезни
В базе данных разрабатываемого программного продукта будут храниться данные о поставщике (клиенте):
id клиента ;
ФИО;
телефон;
адрес;
паспортные данные; реквизиты юридического лица.
Лекарства, хранящиеся в аптеке, характеризуются следующими параметрами:
id лекарства;
название;
страна, завод-изготовитель;
поставщик;
в наличии.
В случае, когда сотрудник продает выбранное клиентом лекарство, оформляется публичный договор купли-продажи, путем выдачи кассового чека, в котором указываются все необходимые данные для этого платежного документа.
В создаваемой информационной системе могут работать группы пользователей:
сотрудники;
поставщики (клиенты).
Сотрудники благодаря данному программному продукту могут решать следующие задачи:
добавлять данные о лекарствах;
составлять договор заказа на то, или иное лекарство;
оформлять договоры с поставщиками, реализовывать лекарства;
сдавать выручку инкассатору;
добавлять информацию о клиентах (поставщиках)
Клиентам тоже предоставляется возможность пользования данной программой. Для них предусмотренные следующие возможности:
осуществлять поиск лекарств;
просмотр своих данных;
3. Системные ограничения
3.1. Требования к интерфейсу
ИС должна иметь стандартный интерфейс приложений,
разработанных для ОС MS Windows.
3.2. Требования к производительности
Особых требований к производительности ИС нет.
3.3. Требования к безопасности
С программой могут работать несколько человек, входя в
программу под своими именами. Для обеспечения конфиденциальности каждое имя можно защитить паролем. Добавление, изменение и удаление пользователей осуществляется в администраторе пользователей.
3.4. Эксплуатационные требования
ИС должна функционировать на ОС Windows XP, OC Windows Vista, ОС Windows 7. Минимальные аппаратные требования определяются минимальными аппаратными требованиями к выше- перечисленным ОС.
3.5. Политические и юридические требования
Нет.
3.6. Другие ограничения
Нет.
2.3 Диаграмма вариантов использования
Диаграмма вариантов использования описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Она является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества так называемых вариантов использования, предоставляемых системой множеству актеров или сущностей, взаимодействующих с системой. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. Варианты использования определяют функциональные возможности. Каждый из них представляет определенный способ использования. Таким образом, каждый вариант использования соответствует последовательности действий для того, чтобы клиент мог получить определенный результат. На рисунке представленном ниже, изображена диаграмма вариантов использования для аптеки. Клиент - все люди, желающие воспользоваться услугами аптечного учреждения; аптека – предоставляет услуги по обеспечению лекарствами; поставщик – внешнее лицо, которое поставляет лекарственные средства аптечному учреждению. Клиенты и поставщики являются внешними сущностями. Клиент обращается в аптеку, для предоставления ему услуг, таких как заказ, продажа лекарства. Выбрав нужную услугу, клиент проходит процедуру идентификации, и если нужно регистрируется в базе данных клиентов. Основным вариантом использования служит “выдача лекарства”. Для получения лекарства, клиент смотрит в каталог лекарственных препаратов и выбирает нужное ему лекарственное средство, поэтому “выдача лекарства”, включает (include) “просмотр каталога лекарств”. После выбора лекарства, клиенту необходимо пройти процедуру идентификации, администратор проверяет БД клиентов на наличие клиента в базе, следовательно, выдача включает “работу с базой данных клиентов”. Заказывая лекарство, клиент также смотрит в каталог лекарств. Для этого вариант использования “заказ лекарства” имеет расширение (extend). Таким образом свойства варианта использования “заказ лекарства” дополняются благодаря наличию свойств у расширенного варианта использования “выдача лекарства”. При возврате лекарства (по каким-либо причинам), клиент проходит идентификацию у администратора, который проверяет клиента в БД клиентов, тем самым вариант использования “возврат лекарства” включает работу с БД клиентов. После того, как клиент вернул лекарство, ему необходимо произвести возврат внесенной за него платы, следовательно, вариант использования “возврат лекарства” включает (include) вариант использования “оплата”.
Рисунок 1 - Диаграмма вариантов использования
2.4 Диаграмма последовательности
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Одним из аспектов взаимодействия является время. Для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности.
Хотя рассмотренные ранее диаграммы и используются для спецификации динамики поведения систем, время в явном виде в них не присутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности.
На рисунке ниже представлена диаграмма последовательности. Клиент пришел в аптечное учреждение. Выбрав нужное лекарство из каталога, он подает заявку на нужное ему лекарство администратору. Администратор, проверяет наличие лекарства, т.к. в данном примере рассмотрен случай заказа лекарства, только после проверки аптеки, нужного лекарства нет. Администратор обращается к клиенту с просьбой подтвердить заказ нужного ему лекарства. После подтверждения, он отправляет заказ лекарства поставщику и производит процедуру регистрации клиента, т.е. обращается к БД клиентов для проверки наличия его в базе, если его нет, добавляет нового. Как только лекарство поступило в аптеку, администратор сообщает клиенту об этом и ожидает. Как только клиент пришел, администратор идентифицирует клиента. После клиент вносит сумму стоимости заказа, получая при этом нужное ему лекарство.
Рисунок 3 - Диаграмма последовательности
2.5 Диаграмма состояний
Диаграмма состояний описывает процесс изменения состояний только одного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Главное предназначение этой диаграммы - описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. На рисунке представлена диаграмма состояний, которая отображает деятельность администратора аптеки. Заметим, что любая деятельность администратора начинается из состояния ожидание. Поступает заявка от клиента. В этом случае, администратор проверяет наличие лекарства в аптеки, и если нужное лекарство имеется, то он выбирает нужного клиента из базы для оформления заявки. Если же нужного лекарства нет, администратор подает заявку поставщику.
Как только лекарство доставлено от поставщика, администратор сообщает об этом клиенту, для того чтобы он мог прийти и взять заказанный им товар (лекарство).
Рисунок 5 - Диаграмма состояний
2.6 Диаграмма деятельности
Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения. На рисунке 6 представлена диаграмма деятельности для клиента аптеки в процессе выдачи лекарства. Клиент приходит в аптеку. Просматривая каталог лекарств, выбирает нужное ему. После этого, клиент проходит идентификацию у администратора, или регистрируется, если является новым клиентом в этой аптеке. Далее клиенту необходимо предоставить залог за нужное ему лекарство, после чего оплатив он его получает, если же у клиента не оказывается оплаты, он получит отказ в получении лекарства.
Рисунок 6 - Диаграмма деятельности
2.7 Диаграмма размещения
На ней показано, что в среде есть сервер обработки заказов, к которому подключен принтер и три типа рабочих станций. Для соединения рабочих станций с сервером используется локальная сеть склада. Также на диаграмме указан узел, относящийся к окружению системы -- узел бухгалтерской системы, подключенный к серверу обработки заказов. СУБД развёрнута на сервере обработки заказов.
2.8 Диаграмма классов
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами.
Данная диаграмма показывает взаимосвязи между сущностями аптечного учреждения, описывает внутреннюю структуру и типы отношений.
На рисунке 2 представлена диаграмма классов.
Администратор (Case worker) – является ключевой фигурой, так как взаимодействует с актерами в бизнес системе. Главным атрибутом класса является: ФИО. База данных клиентов (Business Entity) – содержит базу всех клиентов зарегистрированных в аптечной системе, также имеет возможность расширения и изменения списка клиентов. Главным атрибутом класса является: идентификационный номер клиента.
Каталог лекарств (Business Entity) – перечень всех лекарственных препаратов представленных в аптечном учреждении. Главным атрибутом класса является: наименование лекарства. Заявка (Business Entity) – для заказа лекарства, клиенту необходимо подать заявку, после чего администратор начинает процедуру заказа. Залог (Business Entity) – документ или иной ценный предмет, который взимается у клиента на определенное время для обеспечения выкупа клиентом лекарства после его получения от поставщика.
Рисунок 6 - Диаграмма классов