Файл: Разработка автоматизированной системы учета лекарств в аптеке.pdf
Добавлен: 23.04.2023
Просмотров: 4123
Скачиваний: 119
СОДЕРЖАНИЕ
1.1. Характеристика предприятия и его деятельности
1.2 Организационная структура управления предприятием
2. Информационное обеспечение задачи
2.1 Информационная модель и её описание
2.2 Используемые классификаторы и системы кодирования
2.3 Характеристика нормативно-справочной, входной и оперативной информации
2.4 Характеристика результатной информации
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
3.2 Характеристика базы данных
3.3 Структурная схема пакета (дерево вызова программных модулей)
2.2 Используемые классификаторы и системы кодирования
Для того чтобы приспособить экономическую информацию для эффективного поиска, обработки на ЭВМ и передачи по каналам связи, её необходимо представить в цифровом виде, с этой целью её нужно сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификатора. Основными объектами классификации и кодирования являются справочные реквизиты-признаки, описывающие процессы, место, время выполнения процессов, субъекты и объекты действия, отражаемые в показателе. Кодированию в документах подлежат те признаки, по которым выполняется группировка информации в ПК. В нашей информационной системе создан локальный классификатор, с использованием иерархического метода классификации.
2.3 Характеристика нормативно-справочной, входной и оперативной информации
В данном разделе приведены функциональные и нефункциональные требования к приложению в виде таблиц на основе учета предметной области. Спецификация функциональных требований показана в табл.1
Таблица 1
Спецификация функциональных требований
|
Идентификатор требования |
Название требования (варианта использования) |
Атрибуты требований |
||
|
Приоритет |
Трудность |
Контакт |
||
|
1 |
2 |
3 |
4 |
5 |
|
FR-UC-01 |
Авторизация |
Обязательное |
Средняя |
Директор, старший провизор, провизор |
|
FR-UC-02 |
Добавить данные в базу данных фармацевтических товаров |
Обязательное |
Средняя |
Директор, старший провизор |
|
FR-UC-03 |
Редактирование данных в базе данных фармацевтических товаров |
Рекомендуемое |
Средняя |
Директор, старший провизор |
|
FR-UC-04 |
Удаление данных из базы данных фармацевтических товаров |
Обязательное |
Средняя |
Директор, старший провизор |
|
FR-UC-05 |
Продажа товара |
Обязательное |
Средняя |
Старший провизор, Провизор |
|
FR-UC-06 |
Формирование отчета розничной торговли |
Обязательное |
Средняя |
Главный бухгалтер |
|
FR-UC-07 |
Формирование кассового отчета |
Обязательное |
Средняя |
Старший провизор, провизор |
|
FR-UC-08 |
Формирование отчета по продажам |
Обязательное |
Средняя |
Главный бухгалтер |
Спецификация нефункциональных требований показана в табл. 2
Таблица 2
Спецификация нефункциональных требований
|
Идентификатор требования |
Название требования |
атрибуты требований |
|||
|
Приоритет |
Трудность |
Контакт |
|||
|
1 |
2 |
3 |
4 |
5 |
|
|
1. Применимость |
|||||
|
ZA-01 |
Соответствие стандартам интерфейса пользователя |
Рекомендуемое |
Низкая |
Программа |
|
|
2. Надежность |
|||||
|
NA-01 |
100% доступность |
Рекомендуемое |
Высокая |
Программа |
|
|
3. Рабочие характеристики |
|||||
|
RC-01 |
Быстродействие для транзакций в среднем 5 секунд |
Рекомендуемое |
Средняя |
Программа |
|
|
RC-02 |
Время запуска системы - не более 5 сек. |
Рекомендуемое |
Низкая |
Программа |
|
|
RC-03 |
Время на обработку запроса на поиск данных в БД - не более 2 сек. |
Рекомендуемое |
Средняя |
Программа |
|
|
4. Эксплуатационная пригодность |
|||||
|
EP-01 |
Наличие программного продукта «1С: Предприятие 8.2» |
Обязательное |
Средняя |
Программа |
|
|
5. Атрибуты качества |
|||||
|
QA-01 |
Небольшое количество сбоев в работе системы (не более 1 - 2 за рабочий день) |
Рекомендуемое |
Средняя |
Программа |
|
В результате разработки спецификации требований был составлен глоссарий проекта, который является отправной точкой для построения более развернутых моделей предметной области, которые на стадии реализации информационной системы ложатся в основу объектной модели (для объектно-ориентированных приложений) и модели данных (для генерации схемы базы данных), разработаны варианты использования, которые содержат диаграмму вариантов использования (отражает функциональность, которая будет реализована в программном продукте), где были определены основные функции системы, спецификация, вариант использования. Проведена раскадровка данных вариантов использования, помогает четко осознать логику работы разрабатываемого приложения и позволяет заинтересованным лицам описать свои потребности аналитикам, которые на основе этих потребностей определяют требования к системе, осуществляют проверку соответствия требованиям поставленной бизнес-задач и осуществляют с ними обратную связь. По результатам раскадровки были сформулированы требования, которые подлежат согласованию с заинтересованными лицами. Результаты раскадровок могут быть использованы для получения одобрения заинтересованных лиц и выявления источника требований в рамках раскадровки. Определены спецификацию функциональных и нефункциональных требований к системе.
Разработка программы для учета фармацевтических товаров на предприятии будет осуществляться на основе платформы «1С: Предприятие».
2.4 Характеристика результатной информации
Документы, которые используются в системе приведены в табл. 3
Таблица 3
Информационный список документов
|
Код документа |
Название |
Входящий / Исходящий |
Функция |
|
DC-01 |
Чеки |
входной |
Ввод данных о расходах |
|
DC-02 |
Кассовый отчет |
выходной |
Ввод данных о расходах |
|
DC-03 |
Отчет по розничным продажам |
выходной |
Просмотр данных о продажах за период |
|
DC-03 |
Отчет по прибыли |
выходной |
Просмотр данных о доходах |
3. Программное обеспечение задачи
3.1 Общие положения (дерево функций и сценарий диалога)
Дерево функций показывает иерархию функций управления и обработки данных, которые автоматизирует разрабатываемая информационная система. При этом можно выделить функции, реализующие основные функции управления и обработки данных: ввода первичной информации, обработки, ведения справочников, ответов на запросы.
Выявление состава функций, их иерархии и выбор языка общения позволяет разработать структуру сценария диалога, дающего возможность определить состав кадров диалога и их соподчиненность.
Рисунок 8 Дерево функций ИС
Технологический процесс обработки информации представляет собой упорядоченную последовательность действий по обработке данных, информации, знаний до получения необходимого пользователю результата. Отсюда следует, что понятие информационной технологии подразумевает решение экономических и управленческих задач, связанное с выполнением ряда операций по сбору необходимой для решения этих задач информации, переработке ее по некоторым алгоритмам и выдачи лицу, принимающее решение в удобной для него форме.
Технологический процесс обработки информации зависит от характера решаемых задач, используемых технических средств, систем контроля, числа пользователей и др. факторов. Технологический процесс обработки информации может включать следующие операции (действия):
- сбор данных;
- обработка данных;
- генерация данных;
- хранение данных;
- передача данных.
В рассматриваемой системе ввод информации происходит на основании подготовленных документов, вывод информации – на основе информации в базе данных, выбираемых их соответствующих таблиц путем запросов.
Для уменьшения ошибок при вводе данных в некоторых полях базы данных задаются условия на значение. К примеру, организовать проверку на вводимые символы: одни могут быть только буквенными, другие только цифрами, третьи – смешанными. Также могут быть наложены условия на диапазоны вводимых значений.
Технологический процесс выдачи результатной информации происходит в двух направлениях:
- вывод результатной информации на печать,
- вывод результатной информации на экран.
Оба этих технологических направлений выдачи результатов решения поставленной задачи не исключают сохранения результатных данных в информационной базе. Таким образом, происходит ее пополнение, сохраненные данные являются исходными для решения аналогичных задач последующих периодов.
Актуализация данных производится при помощи соответствующих проверок (функций), которые будут напоминать пользователю о возникновении событий, когда введенные данные некорректные или неполные.
3.2 Характеристика базы данных
Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованного описания объектов предметной области в терминах некоторой модели. Проектирование баз данных, как правило, играет одну из ключевых ролей в большинстве проектов. Грамотно спроектированная база позволяет без особых проблем вносить изменения, изменять структуру системы.
Рисунок 9 ER модель информационной системы.
Структура логической модели данных отражает структуру элементов находящихся в базе данных. Основное преимущество реляционной модели - сравнительная простота инструментальных средств ее поддержки. Реляционная даталогична модель содержит набор отношений или записей, явно не связанных между собой. Связи выражаются в наличии одинаковых атрибутов в различных отношений, которые (атрибуты) позволяют при выполнении операции естественного объединения отношений получить цельную картину данных об объекте базы данных.
Разработанная реляционная схема данных не требует дальнейшей нормализации. Полученная модель базы данных является основой для генерации структур данных, индексов и триггеров на физическом этапе проектирования. Учтены целостность с неисправностью технических средств, системными ошибками и ложными действиями данных, то есть устойчивость хранимых данных к разрушению и уничтожению, связанных пользователей, которая предусматривает: отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте, защита от ошибок при обновлении базы данных, каскадное удаление связанных данных различных таблиц и сохранения данных при отказах и сбоях техники (восстановление данных).
Физическая модель определяет размещение данных во внешней памяти. Она еще называется внутренней моделью системы и форма ее представления зависит от выбранной СУБД. Если выбрана такая СУБД, которая поддерживает реляционную модель данных, то надо таблицы вместе с атрибутами и связи между таблицами перенести в среду СУБД с учетом требований к соответствующим объектам БД. Так, идентификаторы (имена) таблиц и полей должны удовлетворять требованиям СУБД, типы данных, размеры полей, ограничения также должны быть приведены в соответствие с принятыми в данной СУБД.
Таблица 4
Описание структуры записей таблицы «Справочник лекарств»
|
Наименование поля |
Идентификатор поля |
Тип поля |
Длина поля |
Прочее |
|---|---|---|---|---|
|
Код справочника |
Kod_sprav |
число |
5 |
ключевое поле |
|
Наименование лекарства |
Name_lecarstvo |
строка |
20 |
|
|
Упаковка |
Kod_pack |
строка |
20 |
|
|
Срок годности |
Srok_god |
число |
10 |
|
|
Количество |
Kod_Kol |
число |
10 |
|
|
Цена |
Kod_price |
число |
10 |
|
|
Рецепт |
Name_recipe |
строка |
30 |
Таблица 5
Описание структуры записей таблицы «Главная форма»
|
Наименование поля |
Идентификатор поля |
Тип поля |
Длина поля |
Прочее |
|---|---|---|---|---|
|
Код главной формы |
Kod_glav_form |
число |
15 |
ключевое поле |
|
Справочник лекарств |
Name_spr |
строка |
20 |
|
|
Отчет |
Kod_otchet |
строка |
25 |
|
|
Склад |
Kod_sclad |
число |
5 |
|
|
Оплата |
Kod_Oplata |
число |
10 |