Загрузка...
Учебная работа. Курсовая работа: Информационная система МУЗ Алексеевская центральная районная больница
Резвое развитие технологий, усложнение и обилие предлагаемых видов информационных технологий, возникновение большего количества индивидуальных компов, увеличение требований потребителей – все эти и остальные конфигурации в мире вынуждают хозяйствующие субъекты находить способы для наилучшей адаптации к новеньким условиям. Выражается это в том, что в управлении организациями, предприятиями, учреждениями увеличивается роль автоматической информационной системы.
Существует огромное количество технологий и инструментальных средств, при помощи которых можно воплотить в неком смысле лучший проект ИС, начиная с шага анализа и заканчивая созданием программного кода системы. Эти технологии представлены CASE-средствами верхнего уровня либо CASE-средствами полного актуального цикла (upper CASE tools либо full life-cycle CASE tools). Они не разрешают улучшить деятельность на уровне отдельных частей проекта, и, как следствие, почти все создатели перебежали на так именуемые CASE-средства нижнего уровня (lower CASE tools).
Унифицированный язык моделирования UML (Unified Modeling Language) дозволяет сделать типичный чертеж, тщательно описывающий архитектуру системы. При помощи такового описания (либо модели) упрощается разработка и обновление программкой системы, также гарантируется реализация всех технических требований к приложениям. Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством заслуги компромисса меж этими подходами. Существует достаточное количество инструментальных средств, поддерживающих при помощи UML актуальный цикл информационных систем, и, сразу, UML является довольно гибким для опции и поддержки специфичности деятель разных установок разрабов.
Большая часть имеющихся способов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. язык моделирования — это нотация (в главном графическая), которая употребляется способом для описания проектов. процесс — это описание шагов, которые нужно выполнить при разработке проекта.
Потому избранная тема курсовой работы является животрепещущей, своевременной, нужной для рассмотрения и исследования.
Цель нашей работы: обобщение, классификация познаний по общей теории АИС.
Для заслуги поставленной цели нужно решить последующие задачки:
1. Выполнение анализа технической, экономической, методической литературы по избранной теме.
2. Углубленное рассмотрение унифицированного языка моделирования UML.
3. Моделирования АИС Алексеевской ЦРБ.
объект исследования: АИС.
Методологической основой нашего теоретического исследования являются материалы учебных изданий и остальные источники. Для проведения учебного исследования мы употребляли такие способы: анализ литературы, осмысление данных; классификация и обобщение материала.
структура курсовой работы: работа состоит из введения, главный части, заключения, перечня использованной литературы и приложения.
1. Теоретическая часть. Унифицированный язык моделирования UML
1.1 Суть объектно-ориентированного подхода
В базе объектно–нацеленного подхода лежат понятия «объект» и «класс». Принцип объектно–направленной декомпозиции заключается в представлении прикладной системы в виде совокупы классов и объектов предметной области. При всем этом иерархический нрав сложной системы отражается в виде иерархии классов, а ее функционирование рассматривается как взаимодействие объектов.
Класс – тип, описывающий общую структуру и объект – экземпляр класса, находящийся в определенном состоянии и имеющий определенное объект может лишь поменять состояние, вести себя, управляться либо становиться в определенное отношение к остальным объектам.
Достоинства объектной модели: объектная модель дозволяет употреблять способности объектно-ориентированных языков программирования, внедрение объектного подхода значительно увеличивает уровень унификации разработки и пригодность для повторного использования не только лишь программ, да и проектов, внедрение объектной модели дает возможность системе развиваться равномерно и не приводит к полной переработке в случае конфигурации требований, объектная модель уменьшает риск разработки сложных систем за счет того что процесс интеграции растягивается на всегда разработки, объектная модель нацелена на человеческое восприятие мира.
ОО методология разделяется на 3 шага: ООА, OOD, OOP.
Объектно-ориентированный анализ – методология анализа, которая разглядывает систему деятель исходя из убеждений объектов и классов и их взаимодействия.
Объектно-ориентированное проектирование – методология проектирования, соединяющая внутри себя процесс объектной декомпозиции и приемы представления логической и физической, также статической и динамической моделей проектируемой системы.
Объектно-ориентированное программирование — методология программирования, основанная на представлении программки в виде совокупы объектов, любой из которых является экземпляром определенного класса.
При проектировании ИС либо при реорганизации деятель, сначало нужно осознать из каких объектов состоит предметная область, и какие процессы протекают в предметной области. На шаге ООА строится диаграмма классов и диаграмма прецедентов с целью определения главных объектов системы и их взаимодействие, также главные процессы, проходящие в предметной области. На шаге ООD нужно знать области и методы выполнения операций (действий). На шаге OOP строятся диаграммы модулей и диаграммы действий (размещения).
анализ требований и предварительное проектирование системы.
Как понятно, проектирование прикладной программной системы начинается с анализа требований, которым она обязана будет удовлетворять. Таковой анализ проводится с целью осознать предназначение и условия эксплуатации системы так, чтоб суметь составить ее подготовительный проект.
При объектно-ориентированном подходе анализ требований к системе сводится к разработке моделей данной для нас системы. Моделью системы (либо какого-нибудь другого объекта либо явления) мы называем формальное описание системы, в каком выделены главные объекты, составляющие систему, и дела меж этими объектами. Построение моделей — обширно всераспространенный метод исследования сложных объектов и явлений. В модели опущены бессчетные детали, усложняющие осознание. Моделирование обширно всераспространено и в науке, и в технике.
Модели помогают: проверить работоспособность разрабатываемой системы на ранешних шагах ее разработки; разговаривать с заказчиком системы, уточняя его требования к системе; заносить (в случае необходимости) конфигурации в проект системы (как сначала ее проектирования, так и на остальных фазах ее актуального цикла).
понятие объектно-ориентированного программирования. При проектировании сложной либо довольно объёмной программной системы её, обычно, делят на части, каждую из которых потом разглядывают и разрабатывают раздельно. При всем этом употребляется или функциональное деление системы, или объектная декомпозиция. При многофункциональном делении программной системы её структура быть может описана блок-схемой, узлы которой обозначают выполняемые функции, а связи указывают последовательность их выполнения. Программные модули, реализующие функции, обычно, употребляются лишь в составе данной системы. При объектной декомпозиции система разбивается на объекты либо составляющие, которые ведут взаимодействие друг с другом, обмениваясь сообщениями. Сообщения обрисовывают либо представляют собой некие действия. Получение объектом сообщения активизирует его и вдохновляет делать предписанные его программным кодом деяния. Как следствие, программная система перестает быть последовательностью определенных на шаге кодировки действий, а становится событийно-управляемой. Зачинателями событий могут быть не только лишь объекты системы, да и её наружное свита, к примеру, юзеры.
Объекты имеют характеристики и способы. Характеристики объекта — это значения, которые инсталлируются для определения его вида и поведения. Способы объекта – это программные процедуры, обеспечивающие выполнение им определенных действий. совокупа объектов, имеющих общий набор параметров и характеризующихся схожим поведением, именуется классом. Классы могут строится по иерархическому принципу, когда один класс быть может подклассом другого класса. Из определения класса следует, что любой объект является экземпляром 1-го определенного класса.
Принципиальной индивидуальностью объекта является его автономность и возможность использования в качестве библиотечного компонента языка программирования. Таковым образом, в один прекрасный момент разработанный и отлаженный программный код может неоднократно применяться в разных программных модулях. Чтоб побудить объект выполнить нужные деяния довольно установить его характеристики и вызвать соответственный способ. При наличии для применяемого языка программирования развитой библиотеки компонент разработка программ сводится, в большей собственной части, к связыванию имеющихся объектов, что значительно упрощает и ускоряет процесс проектирования. Таковая разработка разработки программных модулей получила заглавие объектно-ориентированного программирования.
Главными принципами объектно-ориентированного программирования являются наследование, инкапсуляция и полиморфизм.
Принцип, в согласовании с которым познание о наиболее общей группы разрешается использовать для наиболее узенькой группы, именуется наследованием. Наследование тесновато соединено с иерархией классов. При всем этом, если некий родительский класс владеет фиксированным набором параметров и поведением, то производный от него класс должен содержать тот же набор параметров и владеть таковым же поведением, также доп качествами и видами поведения, которые будут определять неповторимость сделанного таковым образом класса.
Принцип инкапсуляции охарактеризовывает сокрытие деталей внутреннего устройства классов от наружных по отношению к нему объектов либо юзеров. Другими словами, взаимодействующему с классом объекту либо юзеру не необходимо знать, каким образом реализован тот либо другой способ класса, чтоб им пользоваться.
Полиморфизм в объектно-ориентированном программировании значит, что деяния, выполняемые одноименными способами, могут различаться зависимо от того, какому из классов они относятся.
1.2 Унифицированный язык Моделирования
UML (Unified Modeling Language) — Унифицированный язык Моделирования. UML – это обычная нотация зрительного моделирования программных систем, принятая консорциумом Object Managing Group (OMG) в осеннюю пору 1997г., и на нынешний денек она поддерживается почти всеми объектно-ориентированным CASE продуктами, включая Rational Rose 98i.
Потому что, в крайнее время наблюдается общее увеличение энтузиазма ко всем нюансам, связанным с разработкой сложных программных приложений, то для почти всех организаций корпоративное программное обеспечения и базы данных (БД) представляют стратегическую Ценность. Существует высочайшая заинтригованность в разработке и верификации способов и подходов, позволяющих заавтоматизировать создание сложных программных информационных систем (ИС). Понятно, что систематическое внедрение таковых способов дозволяет существенно сделать лучше свойство, уменьшить стоимость и время поставки ИС. В истинное время эти способы содержат в себе:
— компонентную технологию разработки моделей ИС,
— зрительное программирование (RAD средства),
— внедрение образцов (patterns) при проектировании ИС,
— зрительное средства)
Зрительные модели обширно употребляются в имеющихся разработках управления проектированием систем, сложность, масштабы и функциональность которых повсевременно растут. В практике эксплуатации ИС повсевременно приходится решать такие задачки как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение сохранности доступа к ИС, оптимизация балансировки перегрузки ИС, устойчивость к сбоям и т.п.
Построение модели корпоративной ИС до ее программной разработки либо до начала проведения строительной реконструкции настолько же нужно, как наличие проектных чертежей перед строительством огромного строения. Зрительные модели обеспечивают ясность представления избранных строительных решений и разрешают осознать разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает возрастать, и потому увеличивается актуальность использования «добротных» способов моделирования ИС. язык моделирования, обычно, содержит в себе:
— элементы модели — фундаментальные концепции моделирования и их семантику;
— нотацию — зрительное предоставление частей моделирования;
— принципы использования — правила внедрения частей в рамках построения тех либо других типов моделей ИС.
Построение зрительных моделей дозволяет решить сходу несколько обычных заморочек. Во-1-х, разработка зрительного моделирования, дозволяет работать со сложными и весьма сложными системами и проектами. Во-2-х, зрительные модели разрешают содержательно организовать общение меж заказчиками и разрабами. Зрительное моделирование не является «серебряной пулей», способной раз и навечно решить все трудности, но его внедрение значительно упрощает заслуги таковых целей как:
— увеличение свойства программного продукта,
— сокращение цены проекта,
— поставка системы в запланированные сроки.
Рис. 1. Пример диаграммы классов
При проектировании сложной ИС ее разбивают на части, любая из которых потом рассматривается раздельно. Вероятны два разных метода такового разбиения ИС на подсистемы: структурное (либо функциональное) разбиение и объектная (компонентная) декомпозиция. Сущность многофункционального разбиения отлично отражена в известной формуле: “Программка=Данные + методы”. При многофункциональной декомпозиции программной системы ее структура быть может описана блок-схемами, узлы которых представляют собой “обрабатывающие центры” (функции), а связи меж узлами обрисовывают движение данных. Объектное разбиение в крайнее время именуют компонентным, что отыскало отражение в особом термине: «разработка, основанная на компонентах» (Component Based Development — CBD). При всем этом употребляется другой принцип декомпозиции — система разбивается на “активные сути” – объекты либо составляющие, которые ведут взаимодействие друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении “клиент/”. Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения «объекту-серверу» эквивалентна вызову соответственного способа объекта.
Итак вот, если при проектировании информационная система разбивается на объекты (составляющие), то UML быть может применен для ее зрительного моделирования. Если употребляется многофункциональная декомпозиция ИС, то UML не нужен, и следует употреблять остальные (структурные) нотации. Исходя из убеждений зрительного моделирования, UML можно охарактеризовать последующим образом. UML предоставляет выразительные средства для сотворения зрительных моделей, которые: единообразно понимаются всеми разрабами, вовлеченными в проект и являются средством коммуникации в рамках проекта.
Унифицированный язык Моделирования (UML): не зависит от объектно-ориентированных (ОО) языков программирования, не зависит от применяемой методологии разработки проекта, может поддерживать хоть какой ОО язык программирования. UML является открытым и владеет средствами расширения базисного ядра. На UML можно содержательно обрисовывать классы, объекты и составляющие в разных предметных областях, нередко очень различающихся друг от друга.
Принципы моделирования. Внедрение языка UML основывается на последующих общих принципах моделирования:
— абстрагирование — в модель следует включать лишь те элементы проектируемой системы, которые имеют конкретное отношение к выполнению ей собственных функций либо собственного мотивированного назначения. Остальные элементы опускаются, чтоб не усложнять процесс анализа и исследования модели;
— многомодельность — никакая единственная модель не может с достаточной степенью точности обрисовать разные нюансы системы. Допускается обрисовывать систему неким числом взаимосвязанных представлений, каждое из которых отражает определенный нюанс её поведения либо структуры;
— иерархическое построение – при описании системы употребляются разные уровни абстрагирования и детализации в рамках фиксированных представлений. При всем этом 1-ое системы с растущей степенью детализации прямо до физического уровня. Модель физического уровня в языке UML отражает компонентный состав проектируемой системы исходя из убеждений ее реализации на аппаратурной и программной платформах определенных производителей.
При зрительном моделировании на UML употребляются восемь видов диаграмм, любая из которых может содержать элементы определенного типа. Типы допустимых частей и отношений меж ними зависят от вида диаграммы. Разглядим некие диаграммы.
Диаграммы использования. Эти диаграммы обрисовывают функциональность ИС, которая будет видна юзерам системы. «Любая функциональность» изображается в виде «прецедентов использования» (use case) либо просто прецедентов. Прецедент — это обычное взаимодействия юзера с системой, которое при всем этом:
— обрисовывает видимую юзером функцию,
— может представлять разные уровни детализации,
— обеспечивает достижение определенной цели, принципиальной для юзера.
Рис. 2. Элементы и дела меж ними на диаграмме классов
Прецедент рисуется как овал, связанный с обычными юзерами, именуемыми «актерами» (actors). Актеры употребляют систему (либо употребляются системой) в данном прецеденте. Актер, представляющий человека-пользователя, характеризуется ролью в данном прецеденте. На диаграмме изображается лишь один актер, но, настоящих юзеров, выступающих в данной роли по отношению к ИС, быть может много. Перечень всех прецедентов практически описывает многофункциональные требования к ИС, при помощи которых быть может сформулировано техническое задание.
Диаграммы классов (class diagrams) обрисовывают статическую структуру классов. Эти диаграммы могут обрисовывать «словарь предметной области» на концептуальном уровне. С иной стороны, на детализированном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Они употребляются для генерации каркасного программного кода на данном языке программирования, также для генерации SQL DDL предложений, определяющих логическую структуру реляционных таблиц БД.
Для описания динамики употребляются диаграммы поведения (behavior diagrams), которые разделяются на диаграммы состояний (statechart diagrams), диаграммы активностей (activity diagrams) и диаграммы взаимодействия (interaction diagrams), состоящие из диаграмм последовательности (sequence diagrams), диаграмм взаимодействий (collaboration diagrams)
И, в конце концов, диаграммы реализации (implementation diagrams) состоят из компонентных диаграмм· (component diagrams) и диаграмм развертывания· (deployment diagrams). На рисунке 5 показаны элементы и дела для диаграмм взаимодействий, диаграмм последовательности·и диаграмм состояний.
Рис. 3. Элементы и дела для диаграмм взаимодействий, последовательности и состояний
процесс проектирования с внедрением той либо другой зрительной нотации принято именовать методологией проектирования, и все нотации, предыдущие UML, использовались в рамках соответственной методологии. Методологию тяжело стандартизировать, и UML – это лишь нотация, которая может употребляться в рамках различных методологий. одной из таковых методологий является Rational Unified Process (RUP) — методология компании Rational Software. RUP обрисовывает удачно испытанные на практике подходы к созданию ИС и описывает компанию коллективной работы над проектом на базе последующих принципов:
— итерационная разработка проекта,
— управление требованиями,
— внедрение компонентной архитектуры,
— зрительное моделирование,
— тестирование свойства ИС,
— контроль конфигураций и конфигураций в ИС.
порядок использования UML диаграмм упрощенно можно представить последующим образом. Сначала для ИС определяется ее наружная функциональность, выделяются все актеры и все прецеденты. дела меж ними изображаются на серии диаграмм использования. Предстоящая работа над проектом «управляется прецедентами». Для всякого прецедента строится описание его динамики в виде серии диаграмм взаимодействия и диаграмм активностей. Из этого описания определяются те объекты, которые задействованы в реализации данного прецедента. Дальше диаграммы классов определяют статическую структуру, описывающую отношения соответственных объектов друг с другом. Поведение классов, со сложной динамикой реагирования на действия, определяется на диаграмме состояний. Размещение объектов по программным модулям описывается в компонентных диаграммах, а программных модулей по сети и компам — в диаграммах распределения.
1.3 Виды диаграмм UML
Графические изображения моделей системы в UML именуются диаграммами. В определениях языка UML определены последующие их виды:
— диаграмма вариантов использования либо прецедентов (use case diagram)
— диаграмма классов (class diagram)
— диаграммы поведения (behavior diagrams)
— диаграмма состояний (statechart diagram)
— диаграмма деятель (activity diagram)
— диаграммы взаимодействия (interaction diagrams)
— диаграмма последовательности (sequence diagram)
— диаграмма кооперации (collaboration diagram)
— диаграммы реализации (implementation diagrams)
— диаграмма компонент (component diagram)
— диаграмма развертывания (deployment diagram)
Любая из этих диаграмм конкретизирует разные представления о модели системы. При всем этом, диаграмма вариантов использования представляет концептуальную модель системы, которая является начальной для построения всех других диаграмм. Диаграмма классов является логической моделью, отражающей статические нюансы структурного построения системы, а диаграммы поведения, также являющиеся разновидностями логической модели, отражают динамические нюансы её функционирования. Диаграммы реализации служат для представления компонент системы и относятся к ее физической модели.
Из вышеперечисленных диаграмм некие служат для обозначения 2-ух и наиболее подвидов. В качестве же самостоятельных представлений употребляются последующие диаграммы: вариантов использования, классов, состояний, деятель, последовательности, кооперации, компонент и развертывания.
Для диаграмм языка UML есть три типа зрительных обозначений, которые важны исходя из убеждений заключенной в их инфы: связи, которые представляются разными линиями на плоскости; текст, содержащийся снутри границ отдельных геометрических фигур; графические знаки, изображаемые поблизости зрительных частей диаграмм.
При графическом изображении диаграмм рекомендуется придерживаться последующих правил: любая диаграмма обязана быть законченным представлением некого фрагмента моделируемой предметной области; выставленные на диаграмме сути модели должны быть 1-го концептуального уровня; вся информация о сущностях обязана быть очевидно представлена на диаграмме; диаграммы не должны содержать противоречивой инфы; диаграммы не следует перегружать текстовой информацией; любая диаграмма обязана быть самодостаточной для правильной интерпретации всех ее частей; количество типов диаграмм, нужных для описания определенной системы, не является строго фиксированным и определяется разрабом; модели системы должны содержать лишь те элементы, которые определены в нотации языка UML.
состояние деяния (action state) является особым случаем состояния с неким входным действием и, по последней мере, одним выходящим из состояния переходом. Этот переход неявно подразумевает, что входное действие уже закончилось. Состояние деяния не может иметь внутренних переходов, так как оно является простым. Обыденное внедрение состояния деяния заключается в моделировании 1-го шага выполнения метода (процедуры) либо потока управления.
Графически состояние деяния изображается прямоугольником с округленными углами (рис. 5). Снутри этого изображения записывается выражение деяния (action-expression), которое обязано быть неповторимым в границах одной диаграммы деятельности.
Рис. 4. Изображение состояния деяния
действие быть может записано на естественном языке, неком псевдокоде либо языке программирования. Никаких доп либо неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени обычного деяния употреблять глагол с объяснительными словами. Если же действие быть может представлено в неком формальном виде, то целенаправлено записать его на том языке программирования, на котором предполагается реализовывать определенный проект.
время от времени возникает необходимость представить на диаграмме деятель некое сложное действие, которое, в свою очередь, состоит из нескольких наиболее обычных действий. В этом случае можно употреблять особое обозначение состояния под-деятель (subactivity state). Такое состояние является графом деятель и обозначается специальной пиктограммой в правом нижнем углу знака состояния деяния (рис. 6). Эта система может применяться к хоть какому элементу языка UML, который поддерживает вложенность собственной структуры. При всем этом пиктограмма быть может добавочно помечена типом вложенной структуры.
Рис. 5. Изображение состояния под-деятель
Любая диаграмма деятель обязана иметь единственное изначальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний. При всем этом любая деятельность начинается в исходном состоянии и завершается в конечном состоянии. Саму диаграмму деятель принято располагать таковым образом, чтоб деяния следовали сверху вниз. В этом случае изначальное состояние будет изображаться в верхней части диаграммы, а конечное в нижней.
2.Практическая часть. Информационная система ЦРБ
2.1 МУЗ «Алексеевская центральная районная поликлиника»
МУЗ «Алексеевская центральная районная поликлиника» размещена в городке Алексеевка в 180 км от областного центра в юго-восточной части области, связь осуществляется жд и авто сообщением, граничит с Воронежской областью (Ольховатский и Острогожский районы), (Ровеньской, Красненский и Красногвардейский районы) Белгородской области на площадях 0,4 га в центре городка.
Алексеевская центральная районная поликлиника лицензирована. Амбулаторно-поликлиническая помощь оказывается по 35 специальностям, стационарная по 27 специальностям.
Район промышленно-аграрный, город Алексеевка занимает 1,5 часть района. В городке действует большие промышленные компании. 3 автотранспортных. Ведущими из их являются 12 компаний, из их: ОАО « Эфирное» — работающих 1266 человек, ЗАО « Сладкий комбинат» — работающих 794 человек, АО « Молочно-консервный комбинат » — работающих 775 человек, АО « Химмаш» — работающих 595 человек, ОАО «Мясоптицекомбинат»-311 человек, ООО «Координирующий центр «Эфко-Каскад»-546 человек и остальные.
В районе работает 22 сельскохозяйственных акционерных обществ, ведущими из их являются: Агротехгарант, СПК «Алейниково», ООО Луценково Агротехгарант «Алексеевское», ООО «МКК-Русское», СПК «Калитва» Русский докторский участок, ООО «МКК-Верный путь» Иващенковский докторский участок, АПК «Родина» с. Подсереднее, ООО «Белгородагроинвест», «Агротехгарант «Щербаковское».
С 1992 года Алексеевский район и с 1993 года город Алексеевка признаны территорией с льготно-экономическим статусом в связи с трагедией но Чернобыльской АЭС с популяцией в количестве 59975 человек, из их малышей -10925 человек в тем числе сельского населения — 18421 человек, из их малышей — 2663 человек. МУЗ «Алексеевская центральная районная поликлиника» является ведущим лечебно-профилактическим учреждением в оказании квалифицированной, спец, стационарной, амбулаторно — поликлинической, консультативной и в оказании скорой неотложной мед помощи, а так же центром организационно-методического управления лечебно-профилактических учреждениях района.
Всего работающего населения в районе — 18238 человек. Из их: город — 14767 человек, село — 3471 человек. Всего дамского населения: в районе — 34715 человек. город — 20781 человек. Село — 13934 человек. Мужского населения в районе — 30679 человек. город — 18545 человек. Село — 12134 человек. Фертильного дамского населения в районе – 17382 человек. Город — 11514 человек. Село — 5868 человек.
МУЗ «Алексеевская центральная районная поликлиника» и сельские лечебно-профилактические учреждения обслуживают население городка и района, что показано в таблице 1:
Таблица 1
Население района на 2007 год
всего
Из их
Взрослые
Дети
Малыши
город
39326
32262
1754
5310
Приписной
4241
3566
90
585
Город с приписным
7633
6578
165
890
Иловское отделение ВОП
7633
6578
165
890
Русская участковая больн.
4593
3802
130
661
Луценковская амбулатория
1848
1572
39
237
Иващенковская амбулатория
1470
1219
34
217
М-Удеровская амбулатория
1702
1458
32
212
Щербаковская амбулатория
2238
1916
46
276
М-Гезовская амбулатория
1651
1372
39
240
Жуковская амбулатория
1631
1390
40
201
Всего сельских
26068
21092
1160
3816
Район
65394
53354
2917
9126
Кардиологическое отделение для нездоровых инфарктом миокарда развернуто на 37 кроватях. В отделении работают 6 докторов, из их 3-е имеют высшую квалификационную категорию; 20 мед сестер, большая часть из которых имеют высшую либо первую квалификационную категорию. Круглые сутки работает дежурная бригада. Главными направлениями работы отделения является исцеление пациентов с: острым инфарктом миокарда (в ранешном постинфарктном периоде); острым коронарным терапия от греч. [therapeia] — лечение, оздоровление) — процесс); нарушениями ритма сердца (подбор и корректировка процесс, подготовка к восстановлению ритма сердца); тяжеленной (декомпенсированной) сердечной дефицитностью, кардиомиопатиями (дилатационной, гипертрофической), артериальной гипертонией, подготовка и послеоперационное ведение пациентов. Кардиологическое отделение для нездоровых инфарктом миокарда употребляет все современные методики многофункциональной диагностики. Жителям городка Алексеевки и Алексеевского района, при наличии страхового полиса, мед помощь оказывается в рамках ОМС. Жителям остальных районов РФ
В рамках контракта добровольческого мед страхования клиника дает усовершенствованные условия пребывания пациентов (ускоренная перевозка в клинику, размещение в одно- и двухместных палатах). В Алексеевском районе и городке Алексеевка Белгородской области интенсивно и везде решается неувязка профилактики кардиологических болезней на базе учреждений здравоохранения, образования, публичных организаций, промышленных и сельскохозяйственных компаний.
2.2 Организация АИС Алексеевской поликлиники
АСУ можно представить состоящей из 2-ух компонент: базисной и многофункциональной. В базу базисной составляющие входят информационное, техническое и математическое обеспечение. К многофункциональной компоненте относят набор взаимосвязанных программ, автоматизирующих определенные функции управления (планирование, финансово-бухгалтерскую деятельность и остальные). Информационное обеспечение АСУ – это совокупа реализованных решений по объектам, размещению и формам организации инфы, циркулирующей в АСУ в процессе ее функционирования.
база АИС поликлиники – это встроенная обработка производственно-экономической инфы, обхватывающая решение задач прогнозирования, планирования и управления с внедрением современных средств. Разработка и введение в действие АИС кардиологического отделения имеет свои специальные индивидуальности. В технических системах главную роль играют свойства оборудования, а в АИС — человек. Потому при разработке АИС нужно учесть действия, групповую психологию, личные воздействия и т. п. Огромное
Автоматизация районной поликлиники будет проходить поэтапно, по подсистемам. На рисунке представлен вид архитектуры АИС (См. приложение 1). АИС районной поликлиники решает последующие задачки:
— оперативное планирование и управление больничным комплексом;
— технико-экономическое планирование и учет материально-технического снабжения;
— учёт движения товарно-материальных ценностей снутри больничного комплекса, расчётов с/к с поставщиками, кассовых и банковских операций.
В итоге автоматизация больничного комплекса дозволит: понизить трудоёмкость работ за счет уменьшения выполнения людьми рутинных обязательств; уменьшить время обработки инфы за счет упрощения ведения электрических документов по сопоставлению с картонными; сделать предпосылки рациональной организации хода производственного процесса приятии; прирастить скорость и свойство обслуживания пациентов; повысить эффективность и культуру работы; повысить эффективности управления; повысить эффективность оперативного принятия решений; расширить диапазон предоставляемых нездоровым услуг; усовершенствовать способности длительного планирования и прогнозирования.
Для выбора типа компьютерной сети и операционной системы нужно проанализировать размещение автоматических рабочих мест работников поликлиники и интенсивность обмена данными меж ними. Автоматическое рабочее пространство (АРМ) — рабочее пространство персонала АИС, снаряженное индивидуальным компом, связанным с местной вычислительной сетью и иными информационными сетями, также особым программным обеспечением, созданным для решения задач юзера АРМ.
Итак, в итоге мы получили, что для автоматизации больничного комплекса нужны 61 комп. С учетом того, что в больничном комплексе уже имеются 11 компов, то нужно приобрести еще 50 шт. Не считая этого нужна компьютерная техника. Список нужного компьютерного оборудования представлен в таблице 1:
Таблица 2
Наименование оборудования
количество, шт.
Комп Pentium IV
50
Монитор ж/к
50
Принтер струйный
18
принтер лазерный
14
Сканер
15
Факс-модем
50
Размещение автоматических рабочих мест в больничном комплексе нужно найти, чтоб избрать пригодный тип сети. Сетью именуется группа соединенных компов и остальных устройств. Теория соединенных и вместе использующих ресурсы компов носит заглавие сетевого взаимодействия. Основное предназначение компьютерных сетей — совместное внедрение ресурсов и воплощение интерактивной связи как снутри, так и за пределами поликлиники. Ресурсы — это данные, приложения и периферийные устройства, такие, как наружный дисковод, принтер, мышь, модем и остальные.
Выбор операционной системы. Операционная система описывает, какие приложения могут быть запущены на компе, какой вид имеет интерфейс юзеров, также, каким образом приложения будут вести взаимодействие меж собой. Microsoft – это основная мощная сторона операционной системы Windows. С разными технологиями Microsoft (ASP, ActiveX, NET, MS SQL и почти всеми иными) можно получить мощнейший инструмент для сотворения встроенной системы.
Работа с Windows выдвигает завышенные требования к оборудованию. Но такие удобства, как унифицированный графический интерфейс, общие для всех программ шрифты и устройства, возможность работы сходу с несколькими приложениями и использования буфера памяти для переноса данных меж ними, окупаются довольно стремительно.
Как для юзеров, так и для разрабов Windows дает огромное количество преимуществ, которые содержат в себе: обычные и прогнозируемые операторы: если юзер понимает, как употреблять одно приложение Windows, то он сумеет работать со всеми остальными. Для всякого приложения нет необходимости устанавливать драйверы устройств и устройства: в Windows предусмотрены драйверы для поддержки периферийной аппаратуры, межпрограммное взаимодействие и связь. Многозадачность: возможность сразу запускать огромное количество программ. Доступ к большему размеру памяти: Windows поддерживает защищенный режим.
Обобщая все выше произнесенное, Windows 2000, 2002, 2003 Server дозволит организации свести к минимуму прерывания при работе конечных юзеров в сети. Благодаря улучшенной системной архитектуре, увеличивающей время работоспособного состояния сервера, увеличению доступности вследствие отказоустойчивости и избыточности, также способностям интерактивной опции и обслуживания, Windows 2003 Server обеспечивает надежную работу серверов.
2.3 Информационная система подсистемы «Диетпитания» кардиологического отделения
Подсистема «Диетпитание» — одна из подсистем больничного комплекс.а На рис. 6 представлена структура подсистемы «Диетпитание».
Рис. 6. Структура подсистемы «Диетпитание»
Итак, как можно узреть, что подсистема «Диетпитание» состоит из 3-х подразделений: доктор-диетолог; Столовая; Кухня. Функциями данной для нас подсистемы являются последующие: доп обследование пациента (с учетом отклонении в состоянии здоровья обследуемого либо о причине погибели»> , отклонении в состоянии здоровья обследуемого или о причине смерти), поставленного диагностическим отделением целебного комплекса); предназначение питания пациента, соответственное его диагнозу и общему состоянию; конкретно питание пациента – кардиологического хворого.
На рисунке 7. можно созидать многофункциональную схему подсистемы.
Обозначения на схеме рис.7:
информационные потоки;
вещественные потоки (блюда).
На вход подсистемы «Диетпитание» поступают данные о заболевании пациента от самого пациента, также из кардиологического отделения целебного комплекса. Зависимо от основного отклонении в состоянии здоровья обследуемого либо о причине погибели»> , отклонении в состоянии здоровья обследуемого или о причине смерти) пациента и его доп жалоб на согласовании с совокупность правил употребления пищи) врач-диетолог устанавливает меню питания данного пациента, другими словами перечень блюд на ближайшую недельку.
Рис. 7. Циркуляция ресурсов в подсистеме «Диетпитание»
Эти данные о меню передаются в столовую, а оттуда заказы поступают на кухню, где заказанные блюда будут готовиться и поступать в столовую. На выходе подсистемы «Диетпитание» будут готовые блюда для пациентов.
Моделируя АИС кардиологического отделения и подсистему «Диетпитания», используем сути в UML. В UML определены четыре типа сущностей: структурные, поведенческие, группирующие и аннотационные. Сути являются главными объектно-ориентированными элементами языка, при помощи которых создаются модели.
Структурные сути — это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, надлежащие концептуальным либо физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».
Поведенческие сути являются динамическими составляющими модели UML. Это глаголы, которые обрисовывают автомат — метод поведения, определяющий последовательность состояний, через которые объект либо взаимодействие проходят в ответ на разные действия.
Группирующие сути являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Таковая первичная суть имеется в единственном экземпляре — это пакет. Пакеты представляют собой всепригодный механизм организации частей в группы. В пакет можно поместить структурные, поведенческие и остальные группирующие сути. В отличие от компонент, которые реально есть во время работы программки, пакеты носят чисто концептуальный нрав, другими словами есть лишь в процессе разработки.
Аннотационные сути – это объяснительные части модели UML: комменты для доп описания, объяснения либо замечания к хоть какому элементу модели. Имеется лишь один базисный тип аннотационных частей — примечание. Примечание употребляют, чтоб снабдить диаграммы комментами либо ограничениями, выраженными в виде неформального либо формального текста. Классы — это базисные элементы хоть какой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им качествами — атрибутами, операциями, отношениями и семантикой.
В рамках модели любому классу присваивается неповторимое имя, отличающее его от остальных классов. Если употребляется составное имя (сначала имени добавляется имя пакета, куда заходит класс), то имя класса обязано быть неповторимым в пакете. Атрибут — это свойство класса, которое может принимать огромное количество значений. Огромное количество допустимых значений атрибута образует домен. Атрибут имеет имя и отражает некое свойство моделируемой сути, общее для всех объектов данного класса. Класс может иметь случайное количество атрибутов.
Операция — реализация функции, которую можно запросить у хоть какого объекта класса. Операция указывает, что можно создать с объектом. Выполнение операции нередко соединено с обработкой и конфигурацией значений атрибутов объекта, также конфигурацией состояния объекта.
На рисунке 8 приведено графическое изображение класса «Заказ» в нотации UML.
Рис. 8. Изображение класса в UML
Классы в UML изображаются на диаграммах классов, которые разрешают обрисовать систему в статическом состоянии — найти типы объектов системы и различного рода статические связи меж ними.
Классы показывают типы объектов системы. Меж классами вероятны разные дела, выставленные на рисунке 9: зависимости, которые обрисовывают имеющиеся меж классами дела использования; обобщения, связывающие обобщенные классы со спец; ассоциации, отражающие структурные дела меж объектами классов.
Зависимостью именуется отношение использования, согласно которому изменение в спецификации 1-го элемента (к примеру, класса «продукт») может воздействовать на использующий его элемент (класс «строчка заказа»). Нередко зависимости демонстрируют, что один класс употребляет иной в качестве аргумента.
Рис. 9. Отображение связей меж классами
Ассоциация — это отношение, показывающее, что объекты 1-го типа некоторым образом соединены с объектами другого типа («клиент» в состоянии сделать «заказ»). Если меж 2-мя классами определена ассоциация, то можно передвигаться от объектов 1-го класса к объектам другого. По мере необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это значит, что с объектом некого класса можно связать остальные объекты из такого же класса. Ассоциации быть может присвоено имя, описывающее семантику отношений. Любая ассоциация имеет две роли, которые могут быть отражены на диаграмме на рисунке 10. Роль ассоциации владеет свойством множественности, которое указывает, сколько соответственных объектов может участвовать в данной связи. Набросок иллюстрирует модель формирования заказа. Любой заказ быть может сотворен единственным клиентом (множественность роли 1.1). Любой нездоровой может сделать один и наиболее заказов (множественность роли 1..n). Направление навигации указывает, что любой заказ должен быть «привязан» к определенному клиенту – нездоровому кардиологического отделения.
Рис. 10. характеристики ассоциации
На диаграммах прецедентов, не считая связей меж действующими лицами и прецедентами, может быть внедрение еще 2-ух видов связей меж прецедентами: «внедрение» и «расширение» (рис. 11). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько огромную многофункциональную нагрузку. Ее следует использовать при описании конфигураций в обычном поведении системы. Связь типа «внедрение» дозволяет выделить некоторый фрагмент поведения системы и включать его в разные прецеденты без повторного описания. На рисунке 11 показано, что при выполнении прецедента «формирование заказа» может быть внедрение инфы из предшествующего заказа, что дозволит не вводить все нужные данные. А при выполнении прецедентов «оценить риск сделки» и «согласовать стоимость» нужно выполнить одно и то же действие — высчитать стоимость заказа. Динамические нюансы поведения системы отражаются приведенными ниже диаграммами.
В отличие от неких подходов объектного моделирования, когда и состояние, и поведение системы показываются на диаграммах классов, UML отделяет описание поведения в диаграммы взаимодействия. В UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений меж объектами выносится на диаграммы взаимодействия. Как правило, диаграмма взаимодействия обхватывает поведение объектов в рамках 1-го варианта использования.
Прямоугольники на диаграмме представляют разные объекты и роли, которые они имеют в системе, а полосы меж классами показывают дела (либо ассоциации) меж ними. Сообщения обозначаются ярлычками около стрелок, они могут иметь нумерацию и демонстрировать возвращаемые значения.
Рис. 11. Связи на диаграммах прецедентов
Есть два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы.
Диаграммы последовательностей. Этот вид диаграмм употребляется для четкого определения логики сценария выполнения прецедента. Диаграммы последовательностей показывают типы объектов, взаимодействующих при выполнении прецедентов, сообщения, которые они отправляют друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях демонстрируют «время жизни» объекта. Полосы со стрелками и надписями заглавий способов означают вызов способа у объекта. Сообщения возникают в той последовательности, как они показаны на диаграмме — сверху вниз. Если предусматривается отправка сообщения объектом себе (самоделегирование), то стрелка начинается и завершается на одной «полосы жизни».
На диаграммы быть может добавлена управляющая информация: описание критерий, при которых посылается сообщение; признак неоднократной отправки сообщения (маркер итерации); признак возврата сообщения.
Рис. 12. Диаграмма последовательности обработки заказа
Вводятся строчки заказа; по каждой строке проверяется наличие товаров; если припас достаточен — инициируется поставка на кухню; если припас недостаточен — инициируется дозаказ (повторный заказ).
Рис. 13. Кооперативная диаграмма прохождения заказа
На кооперативных диаграммах объекты (либо классы) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках 1-го варианта использования. Временная последовательность сообщений отражается их нумерацией. Диаграммы состояний употребляются для описания поведения сложных систем. Они определяют все вероятные состояния, в каких может находиться объект, также процесс смены состояний объекта в итоге неких событий. Эти диаграммы обычно употребляются для описания поведения 1-го объекта в нескольких прецедентах.
Прямоугольниками представляются состояния, через которые проходит объект во время собственного поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от 1-го состояния к другому, которые вызываются выполнением неких функций объекта. Имеется также два вида псевдо-состояний: изначальное состояние, в каком находится лишь что сделанный объект, и конечное состояние, которое объект не покидает, как туда перебежал.
Переходы имеют метки, которые синтаксически состоят из 3-х необязательных частей (см. рис.14:
Рис. 14. Диаграмма состояний объекта «заказ»
<Событие> <[Условие]> < / действие>. На диаграммах также показываются функции, которые производятся объектом в определенном состоянии. Синтаксис метки деятель: выполнить/< деятельность >.
Диаграмма деятельности — это личный вариант диаграммы состояний. На диаграмме деятель представлены переходы потока управления от одной деятельности к иной снутри системы. Этот вид диаграмм обычно употребляется для описания поведения, включающего в себя огромное количество параллельных действий.
Главными элементами диаграмм деятель являются (рис. 15):
Рис. 15. Диаграмма деятель — обработка заказа, овалы, изображающие деяния объекта; линейки синхронизации, указывающие на необходимость окончить либо начать несколько действий (модель логического условия «И»); ромбы, отражающие принятие решений по выбору 1-го из маршрутов выполнения процесса (модель логического условия «ИЛИ»); стрелки — отражают последовательность действий, могут иметь метки критерий
На диаграмме деятель могут быть представлены деяния, надлежащие нескольким вариантам использования. На таковых диаграммах возникает огромное количество исходных точек, так как они отражают сейчас реакцию системы на огромное количество наружных событий. Таковым образом, диаграммы деятель разрешают получить полную картину поведения системы и просто оценивать воздействие конфигураций в отдельных вариантах использования на конечное деятельность быть может предана предстоящей декомпозиции и представлена в виде отдельной диаграммы деятель либо спецификации (словесного описания).
Заключение
Выполнив анализ предложенной литературы и остальных источников по избранной теме, обобщив изученный материал, мы можем создать такие выводы:
Информационные потоки в организациях, учреждениях в истинное время громадны, нужны и должны реально употребляться и сохраняться. структура банка и базы данных, системы данных СУБД соответствуют современным требованиям информационного обслуживания, работы на индивидуальных компах. База данных нужна для обработки инфы и выполнения набора документов.
Эффективность функционирования организации впрямую зависит от скорости, точности и своевременности обмена данными как снутри меж его составляющими частями (отделами, подсистемами и т.д.), так и вне его, другими словами взаимодействие и обмен данными данной для нас организации с иными. автоматическая система управления – это человеко-машинная система, обеспечивающая автоматический сбор и обработку инфы, нужной для оптимизации управления в разных сферах деятель.
Мы провели анализ больничного комплекса Алексеевского ЦРБ, разглядели и проанализировали внутреннюю структуру по организации кардиологического отделения в подсистеме «Диетпитание».
Проанализировав численность персонала, было рассчитано мало нужное количество ПК и остальных компьютерных технических средств для автоматизации поликлиники и сотворения современной информационной системы. С учетом интенсивности обоюдного обмена данными меж подразделениями, территориальной удаленностью подразделений друг от друга, рассчитанного количества ЭВМ , также требований к скорости обмена данными и условия вероятного расширения был избран лучший вариант локальной вычислительной сети и доп аппаратных средств для автоматизации больничного комплекса.
С учетом особенностей и предпочтений персонала, также требований администрации к уровню надежности и защищенности данных сотворена информационная система кардиологического отделения подсистемы «Диетпитание» ЦРБ. Разглядели возможность моделирования АИС кардиологического отделения в системе унифицированного языка UML. Это позволило проанализировать дела меж классами языка, принципами построения модели АИС, сущностями языка и диаграммами, составляющими варианты использования потоков данных.
Таковым образом, в итоге анализа объектно-ориентированного подхода в построении модели АИС унифицированного языка UML, обобщили и классифицировали познания по общей теории АИС, отдельных видов диаграмм, подбора нужного аппаратного и программного обеспечения для его автоматизации, можно прийти к выводу, что создание и внедрение АИС больничным комплексом дозволит неоднократно прирастить оперативность работы всякого подразделения в отдельности и приведет к значительному увеличению эффективности работы всей ЦРБ в целом.
Перечень использованной литературы
Бондарев В.А., Рублинецкий В.И., Качко Е.Г. Базы программирования. – Харьков: Фолио; Ростов на дону н/Д, Феникс, 1998. – 368 с.
Информатика: Энциклопедический словарь для начинающих/Сост. Д.Д. Поспелов. – М.: Педагогика – Пресс, 1994. – 352 с.
Информатика. 10 – 11 кл./Под.ред. Н.В. Макаровой. – СПб.: «Питер», 2001. – 304 с.
Максимов Н.В., Попов И.И. Компьютерные сети. – М.: форум ИНФРА – М, 2005. – 336 с.
Могилев А.В. и др. Информатика./ 2-е изд.,стер. – М.: Издательский центр «Академия», 2003. – 216 с.
Насонов М.И. Диаграммы последовательности. – М.: прогресс – АРТ, 2004. – 643 с.
Базы современных компьютерных технологий./Под ред.Хомоненко А.Д. – СПб. КОРОНА принт., 1998. – 448 с.
Попов А.А. Программирование в среде СУБД FохРrо 2.0. Построение систем обработки данных. – М.: Радио и связь, 1994. – 284 с.
Симонович С.В., Евсеев Г.А., Алексеев А.Т. Особая информатика – М: АСТ – ПРЕСС, ИНФОРКОМ – ПРЕСС, 2000. – 480 с.
Хондашева И.Н., Истомина И.Т. Программное обеспечение вычислительной сети. – М.: ИКЦ «МарТ», Ростов на дону н/Д, Издательский центр «МарТ», 2005. – 238 с.
Ярцев В.С., Хохлов М.Б. Компьютерные технологии. – Новосибирск: «Аква», 2002. – 236 с.
Мамошова В.В. Компьютеризация рабочих мест. – Спб.: КОРОНА, — 2000. – 448 с.
См. kulihki.txt
См. index.htm
См. Obazvred.doc
приложение 1
Рис. 1. Вид структурной схемы больничного комплекса
На рис. 11. представлена схема взаимодействия (диаграмма взаимодействия последовательности) подсистемы «Диетпитание» с иными подразделениями.
доктор – диетолог. Доктор-диетолог занимается решением последующих задач:
определение системы питания на планируемый срок;
выбор альтернативного продукта в блюде;
подмена блюда Бi
на эквивалентное ему блюдо Бj
в рамках рациона, назначенного врачом-диетологом.
Пациент, поступивший в больничный комплекс, получает консультацию врача-диетолога, который, в согласовании с поставленным диагнозом, назначает подобающую диету. Пациент в течение всего времени пребывания получает питание, с подходящим диете количеством приемов еды в денек (завтрак, обед, полдник и ужин).
Рис.12. Схема информационных и вещественных потоков подразделений подсистемы «Диетпитание» с подразделениями остальных подсистем комплекса
В функции врача-диетолога также заходит процесс подмены 1-го продукта на иной, эквивалентный первому по составу, в случае отсутствия либо нехватки его на складе. информация о отсутствии либо недостающем количестве товаров на складе поступает к врачу-диетологу со склада.
]]>