Размещено на http://www.allbest.ru/

Департамент образования города Москвы

государственное бюджетное профессиональное

Образовательное учреждение города Москвы

«колледж современных технологий

имени Героя Советского Союза М.Ф. Панова»

Специальность: 090204 Информационные системы (по отраслям)

КУРСОВОЙ ПРОЕКТ

Тема: «Проектирование, моделирование и разработка информационной системы: учёт расходных материалов медицинского центра»

Наименование учебной дисциплины: ПМ.01 Эксплуатация и модификация информационных систем. МДК.01.01 Эксплуатация информационной системы.

Группа СИС-214/15

Студент М.Д. Мотлохов

Преподаватель А.В. Павлов

г. Москва 2016



Оглавление

• Условные обозначения
• Введение
• Глава 1. Описание предметной области
• 1.1 Исследование предметной области
• 1.2 Технико-экономическое обоснование
• 1.3 Методологии проектирования
• 1.4 Методы проектирования
• 1.5 Проектирование в SADT
• 1.6 Проектирование в UML
• Глава 2. Моделирование информационной системы
• 2.1 Техническое задание на информационную систему
• 2.2 Создание модели в стандарте SADT (IDEF0)
• 2.3 Декомпозиция родительской модели
• 2.4 Модели в нотации языка UML
• Глава 3. Разработка информационной системы
• 3.1 Охрана труда
• 3.2 Инструменты разработки
• 3.3 Создание таблиц базы данных и связей между ними
• 3.4 Создание бизнес логики
• 3.5 Создание программного интерфейса
• Заключение
• Список литературы
• 

Условные обозначения

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

БД - база данных;

АИС - автоматизированная информационная система;

ИС - информационная система;

Рис. - рисунок;

UML - Unified Modeling Language;

IDEF - functional modeling;



Введение

Актуальность данного проекта обусловлена необходимостью учёта расходного материала медицинского учреждения для оптимизации оборота используемых материальных средств.

Диаграмма 1 Опрос населения «наиболее острые проблемы здравоохранения» (I-II квартал 2015 г.) URL: http://o-gorod.net/news/352096/ С сайта «Открытый город» (Дата обращения 10.10.2016)

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

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

Для достижения данной цели мне необходимо решить следующие задачи:

1. Провести анализ особенности учёта медицинского расходного материала

2. На основе анализа выявить проблемы учёта

3. Спроектировать информационную систему учета медицинских расходных материалов.

4. Смоделировать информационную систему учета медицинских расходных материалов.

5. Разработать информационную систему

Объект исследования - система учёта медицинских расходных материалов

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

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

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

Теоретическую основу курсовой работы составили авторы: В.В. Персианов, Е. И. Логвинова, Кибиткин А. И., Дрождинина А. И., Мухомедзянова Е. В., Скотаренко О. В.

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

Структура работы. Работа состоит из введения, трех глав и заключения.

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

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

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

В заключение описаны выводы о поставленной цели.



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

1.1 Исследование предметной области

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

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

Дав определению медицины, мы понимаем область ее действия, следующее, что необходимо определить, что такое «медицинский центр». За этим обратимся к сайту «Википедия». Медицинский центр Цитирование с сайта «Википедия», URL: http://ru.wikipedia.org/wiki/Медицинский_центр (Дата обращения 11.10.2016) - вид гражданского стационарного медицинского учреждения, направленного на лечение больных и/или специализированную углубленную дифференциальную диагностику заболеваний в стационарных условиях. Проще говоря, медицинский центр - сооружение по предоставлению медицинских услуг.

По этому определению можно выделить некоторые объекты системы медицинского центра:



Рисунок 1 Связь между пациентами и персоналом

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

1. Специалисты - сотрудники, оказывающие услуги в медицинском центре (медсестры, врачи, лаборанты)

2. Управление - сотрудники, занимающиеся в основном управлением персоналом, так же являющиеся специалистами (Главный врач, зам. Главного врача).

3. Сторонний персонал - сотрудники, не имеющие отношения к медицинской деятельности, но работающие в медицинском центре (кладовщик)

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

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

Рисунок 2 Субъекты информационной системы

Согласно книге [5], в основе организации учета материально-производственных запасов на складе и в бухгалтерии лежат следующие принципы:

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

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

Ш определение способа аналитического учета материально-производственных запасов на складах и в бухгалтерии.

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

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

Второй принцип это, то что мы можем отразить в нашей информационной системе. Из второго принципа следует, то, что каждый сотрудник использующий материальные запасы является материально ответственным лицом Согласно постановлению Минтруда от 31 декабря 2002 г. N 85, из этого следует, что в информационной системе необходимо реализовать функцию отслеживания передачи материальных запасов.

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

Определение обязанностей начнем с определения обязанностей кладовщика. В обязанности кладовщика в обязательном порядке входит:

Ш Проверка сопроводительных документов на соответствие получаемой поставке

Ш Прием материалов на склад

Ш Ведение учета складских операций

Ш Организация и проведение инвентаризации

Ш Составление дефектных ведомостей

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

На основе этого списка можно выделить основные функции кладовщика в нашей информационной системе:

ь Учет принимаемых материальных средств на склад

ь Учет распределенных материальных средств со склада

ь Учет материальных средств после инвентаризации

ь Списание материала на основе срока годности или невозможности дальнейшего использования

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

ь Добавление сотрудника в базу данных

ь Определение доступа в базу данных по должности

ь Доступ к составлению отчетной документации

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

ь Заказ материала со склада

ь Просмотр текущего количества материала

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

1.2 Технико-экономическое обоснование

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

Сколько в медицинском центре может находится материалов на учете? Пятьдесят? Сто? Двести? А может и больше. Материал может варьироваться от «Медицинских палочек» стоимость которых на момент написания курсового проекта в среднем составляет 240 - 250 рублей за 100 шт., до «Химических стерилизаторов» стоимостью от 5 т. р. до 80 т. р.

Платформой для разработки программного обеспечения будет программа Microsoft Office 2013. Выбор данной платформы обусловлен тем, что платформа Windows очень широко распространена (диаграмма 2).

Диаграмма 2 Использование операционных систем за 2016 год (в %) http://gs.statcounter.com/os-market-share/desktop/russian-federation/2016 (дата обращения 20.11.2016)

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

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

В итоге рабочая единица оборудования, которая минимально необходима, варьируется от 15 тыс. рублей до 23 тыс. рублей.

В эту стоимость входит:

1. системный блок (10 -15 т. р)

2. монитор (5 - 7 т. р.)

3. Периферия (1 т. р)

В дополнение к этому в рабочее пространство должен входить сервер, ведь наше приложение будет работать на клиент-серверной архитектуре.

Стоимость маленького сервера варьируется от 14 т. р. До 25 т. р.

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

Время на разработку программного обеспечения - 3 месяца (октябрь, ноябрь, декабрь). Время, которое будет уделяться для разработки составляет 3 часа в день по рабочим дням в течении 3 месяцев. Итого общее время разработки планируется: (3 х 5 х 4 х 3 = 180ч). Из вычисленных сто сорок четыре часа (144 ч.) отводятся для проектирования, моделирования и разработки информационной системы, а тридцать шесть часов (36 ч.) отводятся для тестирования информационной системы.

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

По формуле стоимость часа разработки рассчитывается на основе заработной платы разработчика поделенной 160 (4 недели по 40 часов). За основу заработной платы мы возьмём среднюю зарплату junior VBA программиста. Средняя зарплата junior VBA программиста по Москве составляет 27 т. р. Расчеты заработной платы на разработку представлены в таблице № 1.

Таблица 1 Расчеты затрат на разработку

Тип	Показатель
Время разработки (ч)	180
Час разработки (руб.)	27000 / 160 = 168,75
Итого (руб.)	180 х 168,75 =30375

Итоговая сумма затрат на разработку будет составлять 30375 рублей.

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

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

PC - количество компьютеров;

· PriceHW - цена за комплект оборудования;

· PriceSW - цена за комплект ПО;

· PriceServer - цена за сервер;

· PriceWork - цена за разработку

(1)

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

Минимальная итоговая стоимость будет составлять:

100(15000+7500) +14000+30375 = 2.294.375 руб.

Максимальная итоговая стоимость будет составлять:

100(23000+25000) + 25000 + 30375 = 4.855.375 руб.

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

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

1.3 Методологии проектирования

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

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

Жизненный цикл информационной системы можно представить, как ряд событий, происходящих с системой в процессе её создания и использования.

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

Модели жизненного цикла:

Рисунок 3 Модели жизненного цикла

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

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

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

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

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

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

Во время всего жизненного цикла автор будет руководствоваться стандартами:

1. ГОСТ 34.601-90 - устанавливает стадии и этапы создания автоматизированных информационных систем. Стандарт описывает содержание работ на каждом этапе. Стадии и этапы работы, закреплённые в стандарте, степени соответствуют каскадной модели жизненного цикла.

2. ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды программного обеспечения. Стандарт не содержит описания фаз, стадий и этапов.

В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы жизненного цикла программного обеспечения делятся на три группы:

I. Основные процессы:

a. приобретение;

b. поставка;

c. разработка;

d. эксплуатация;

e. сопровождение.

II. Вспомогательные процессы:

a. документирование;

b. управление конфигурацией;

c. обеспечение качества;

d. разрешение проблем;

e. аудит;

f. аттестация;

g. совместная оценка;

h. верификация.

III. Организационные процессы:

a. создание инфраструктуры;

b. управление;

c. обучение;

d. усовершенствование.

1.4 Методы проектирования

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

a. от общего к частному (нисходящее проектирование)

b. от частного к общему (восходящее проектирования)

Нисходящее проектирование:

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

Ш SADT (IDEF0)

Ш UML (диаграмма прецедентов)

Ш UML (диаграмма компонентов)

Ш UML (диаграмма классов)

Ш UML (диаграмма объектов)

Ш UML (диаграмма активности)

Восходящее моделирование:

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

Ш UML (диаграмма активности)

Ш UML (диаграмма классов)

Ш UML (диаграмма объектов)

Ш UML (диаграмма компонентов)

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

1.5 Проектирование в SADT

Метод SАDT (Struсturеd Аnаlysis аnd Dеsign Tесhniquе) технология структурного анализа и проектирования считается классическим методом функционального подхода к управлению. Главный принцип процессного подхода заключается в создании единой структуры деятельности компании в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, обращающие в единую форму значимый для потребителя результат, представляют главную ценность, и именно их улучшением предстоит в дальнейшем заниматься. Модель, основанная на организационно-штатной структуре, может не всегда продемонстрировать структурированную модель. С другой стороны, модель, основанная на бизнес-процессах, содержит в себе и организационно-штатную структуру предприятия.

В соответствии с этим принципом бизнес-модель должна выглядеть следующим образом:

Рисунок 4 Принцип проектирования SADT

Метод SАDT представляет собой совокупность правил и функций, предназначенных для создание систематизированной функциональной модели объекта какой-либо предметной области. Функциональная модель SАDT отображает единую функциональную структуру объекта, т.е. производимые им действия и зависимости между этими действиями. Основные элементы этого метода основываются на следующих концепциях:

1. Графическое представление блочного моделирования.

2. Строгость и точность

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

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

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

Общий вид блока диаграммы, построенной согласно методологии IDEF0 (IDEF0-диаграммы, или IDEF0 - модели).



Рисунок 5 Состав функциональной модели URL: http://math.sgu.ru/users/oryol/files/proj1.pdf. (дата обращения 20.11.2016)

Одной из наиболее значимы особенностей метода SАDT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Каждый компонент SАDT-модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме. Диаграмма представлена в приложении 4

Построение SАDT-модели заключается в выполнении следующих действий:

Ш сбор информации об объекте, определение его границ;

Ш определение цели и точки зрения модели;

Ш построение, обобщение и декомпозиция диаграмм;

Ш критическая оценка, рецензирование и комментирование.

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

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

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

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

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

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

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

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

В IDEF0 реализованы три базовых принципа моделирования процессов:

· принцип функциональной декомпозиции;

· принцип ограничения сложности;

· принцип контекста.

Принцип функциональной декомпозиции:

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

Принцип ограничения сложности:

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

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

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



1.6 Проектирование в UML

В этом разделе мы рассмотрим инструменты проектирования языка UML.

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

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

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

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

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

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

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

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

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

Диаграмма классов

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

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

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

Диаграммы последовательности

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

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

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

Диаграмма кооперации

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

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

Рисунок 7 Диаграмма кооперации Рисунок взят с сайта Habrahabr URL: https://habrahabr.ru/post/74330/ (дата обращения 16.11.2016)

Диаграмма компонентов

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

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

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

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

Рисунок 8 Диаграмма компонентов

Диаграмма состояний

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



Рисунок 9 Диаграмма состояний

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



Глава 2. Моделирование информационной системы

2.1 Техническое задание на информационную систему

Заказ на разработку информационной системы был сделан КСТ «Лианозово». Ниже будет представлено описание технического задания на информационную систему:

1. Поддержка сетевого взаимодействия между несколькими пользователями;

2. Разделение прав доступа между пользователями;

3. Автономное добавление новых пользователей;

4. Специалисты заказывают расходный материал со склада;

5. Пользователи «Склад» отслеживают заказываемый материал;

6. Количественное отслеживание хранимого материала на складе;

7. Количественное отслеживание прихода;

8. Количественное отслеживание взятого материала сотрудниками;

9. Отслеживание движение материала в медицинском центре (списание, выдача);

10. Инвентаризация расходного материала;

11. Хранение результатов инвентаризации;

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

2.2 Создание модели в стандарте SADT (IDEF0)

Теперь после разбора инструментов моделирования можно приступить непосредственно к созданию моделей бизнес-процессов. Как было разобрано выше начинать моделирование мы будем с модели IDEF0.

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

Входные данные:

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

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

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

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

Ш Расхождение по инвентаризации: вторая наиболее важная информация в бизнес-процессах. В любой деятельности нельзя отменять человеческий фактор. Ошиблись в расчетах дали слишком много или слишком мало, недобросовестный сотрудник приворовывает со склада или сколь угодно любые случаи, инвентаризация позволит отследить расхождения в количестве. Входные данные описываю разницу количества материалов и дату проведения инвентаризации.

Выходные данные:

Ш Отчеты: обмен информацией по вертикали власти с далеких времен происходит посредством предоставления информации в бумажном виде. Отчеты выполняют эту функцию. Выходные данные представляют собой информацию на бумажном носителе, представленной в едином стандарте предприятия (информацией в отчете будут входные данные бизнес-процессов).

Ш Использование материала: предназначение материала в первую очередь, это возможность его использовать, но мы рассматриваем его переходные состояния до или после использования. Выходные данные представляют собой изменения состояния материала (приход, списание, передача сотруднику).

Управление:

Ш Законодательство: регулирует процессы работы и использования ресурсов, правила трудоустройства, необходимую квалификацию для выполнения работ и многое другое. Пример: Федеральный закон от 05.04.2013 N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд".

Ш Внутренние правила: опираясь на законодательство регулирует правила работы внутри компании, такие как время работы, штрафы, премии и т.д.

Ш ГОСТ: стандарты, опирающиеся на законодательство определяющие единые схемы, алгоритмы, правила проведения работ, услуг, оформление документов и т.д. Пример: ГОСТ Р 52623.3 - 2015 «Технология выполнения простых медицинских услуг - Манипуляции сестринского ухода»

Механизм:

Ш Персонал: все сотрудники медицинского центра.

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

2.3 Декомпозиция родительской модели

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

Взаимодействие системы с внутри описывается функциями: Модель диаграммы представлена в приложении №5

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

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

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

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

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

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

2.4 Модели в нотации языка UML

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

В данной работе используется для моделирования язык UML при помощи CASE-средства StarUML, а, следовательно, объектно-ориентированный подход.

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

Прецедент -- возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить

конкретный, измеримый и нужный ему результат. Прецедент соответствует

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